OasisLMF
OED support for public infrastructure
@MattDonovan82 @johcarter
As part of IDF projects I've been looking at how OED supports / can further support public infrastructure, while also promoting interoperability with GED4ALL (see docs.riskdatalibrary.org/ged4all.html#lifelines) on the supported assets, below. GED4ALL uses existing taxonomies:
- Road and rail (OSM taxonomy)
- Pipeline (Syner-G and STREST project taxonomy)
- Energy (HAZUS)
- Water (HAZUS)
- Communications (HAZUS)
Main gap: OED seems to lack support for representing linear or network features - recommend that a geometry field can be added, to represent these, in addition to lon/lat and address for point features.
- GEOM field added to OED loc table
There does not seem to be the need for adding a new location table, per the approach to population, because most assets are already well covered.
Unknown: how many vulnerability curves exist to support the asset types listed below, therefore the level of detail we should add now. Adding the detail would support interoperability with GED4ALL though.
Findings on support for asset types:
-
OED supports many of the asset types in GED4ALL, with existing occ/con code combinations (assuming there are not restrictions on them being used in combination)
-
OED does not provide for different classifications of road and rail - this should be improved by adding occ/con codes - ADD
-
OED does not provide for different size of potable / wastewater treatment plants - this could be improved by adding occ/con codes. May be more detail than needed. - ADD?
-
OED generally covers Pipelines well, but an occ/con combination for oil pipelines seems to be missing - ADD?
-
OED generally covers power plants well, but occ/con combinations for oil/biomass/gas power plants seem to be missing - ADD?
-
OED provides for Substations, labelled as IFM - is there a restriction on the type of model the IFM codes can be used with in Oasis, or is this legacy description from CEDE? No differentiation for high, medium, low voltage of substations, or other power capacity - could be added - ADD?
-
GED4ALL / HAZUS provide attributes on soil type (corrosive/non-corrosive), anchorage, code provision (none, low, moderate, high and unknown) and pipe diameter - these could be included in OED as optional fields relevant to pipelines (or could direct users to use user-defined fields?). - ADD?
-
OED provides for Pipeline material and position (under/at grade) generally well. There are several pipeline construction material types in HAZUS that could be added to OED. HAZUS provides for joint type, not covered in OED, but may be more detail than is practically used. - ADD?
To do: same assessment for natural assets - forestry, crops, livestock
Suggested next step - can I walk you through a spreadsheet to elaborate on the above per category
@stufraser1 happy to have a call to go through these. If there are no current con/occ codes that satisfy what's needed then we can discuss them, we just want to avoid duplication.
Is having them in the OED for property the best place? it sounds like you want to avoid a separate schema? Following that, do you think the 'loc population' fields should be included in the property one?
Suggestions for transport: add codes to describe different types of road (primary, secondary, motorway, etc) and rail (monorail, light rail, standard rail, etc) assets.
OED_LocInfrastructure_Transport.xlsx
GED4ALL codes are included to help with Open Data Transform mapping, and to guide the addition of OED codes to align with existing taxonomy, in the case of transport: OpenStreetMap.
Suggestions for utilites: add codes to describe different types of road (primary, secondary, motorway, etc) and rail (monorail, light rail, standard rail, etc) assets.
OED_LocInfrastructure_Utilities.xlsx
GED4ALL codes are included to help with Open Data Transform mapping, and to guide the addition of OED codes to align with existing taxonomy, in the case of utilities: HAZUS, and academic projects Syner-G and STREST (Crowley et al., 2016)
Suggestions for using user-defined fields to record little-used infrastructure details. Lists suggested codes to be included, based on existing taxonomies, namely HAZUS. OED_LocInfrastructure_userDefined.xlsx
Additional notes:
- soil class has been added in v2.3.1
- Pipeline material and position above/below ground is defined in CON codes 5650-5662. No provision for Polyethylene, Welded steel, Reinforced plastic mortar, Resin transfer moulding, Clay, Other material, Unknown - brittle, Unknown - ductile. But to add these in the same way would mean additional 16 additional codes, and there is no space in the existing order. To be considered whether these are needed. (If not added, OED will not align with existing taxonomies/GED4ALL.)
Could OED add a GEOM field to enable polyline features to be stored in OED Location file?
Guidance on infrastructure modelling to be clear on how linear networks are modelled in Oasis: Where centroid of line segment is used to record the intensity affecting the infrastructure, users should ensure line segments are a reasonable length for this assumption.
@stufraser1 My comments:
Transport:
- Your suggestions for additional construction codes for highways and rail and look reasonable to me. Rather than your suggestions of railways starting from 5463, I would suggest starting from 5460 (light rail)- 5464 (tram).
- I agree the current Occ code of 1250 relates to the "establishments" rather than the actual highway, so I suggest adding a new code of 1257 - "Transportation, highways - network" and for the same reason, adding 1258 - "transportation, rail - network". Did you mean rail (not road network) in cell P12 of your spreadsheet?
Utilities
- All your construction code suggestions look reasonable to me.
- In regards to choosing the occ codes between non IFM and IFM, it's difficult to answer. I guess its model specific and depends on how the model would use these and whether any hazard or vulnerabilities functions are assigned to IFM or not. Your suggestions for new IFM codes again look ok to me, but this should be up for further discussion.
User Defined Fields Are you asking for more user defined fields to be added to OED? There are currently 15 (5 for each account, policy, loc). Can you just not use the current LocUserDef1-5?
Additional notes Is there much demand for 16 codes all relating to pipeline material? this seems a lot. Is it an issue if OED does not exactly align with GED4ALL/other taxonomies?
Adding a GEOM field - would this be just one field or multiple?
User Defined Fields Q: Are you asking for more user defined fields to be added to OED? There are currently 15 (5 for each account, policy, loc). Can you just not use the current LocUserDef1-5? A: Proposal would be to fit these codes into the LocUserDef1-5 fields, not to add new ones. We just need to flag that these are codes that could be used / this is how these features should be coded given there isn't a specific field.
Additional notes Q: Is there much demand for 16 codes all relating to pipeline material? this seems a lot. Is it an issue if OED does not exactly align with GED4ALL/other taxonomies? A: It does seem like a lot, and I don't think pipeline material in general is going to be commonly used now or in the very near future in the types of risk assessments I've seen/worked on though they may be used in analyses focussed on infrastructure which may become more common. There are other fields where there is not exact alignment between GED4ALL/OED, so this wouldn't be the only case, but would be better if it could align. Is the concern about having redundant codes in OED? It doesn't seem a difficult addition, but I agree may create redundant codes, so I think its ODS call on the preference - stick to OED principles or allow for a bit more future-proofing. Having said that, if the need arises for those codes they could be added at a later date, correct?
Q: Adding a GEOM field - would this be just one field or multiple? A: This would be a single field, which contains the geometry of that location: point, polyline, or polygon. See this example from postgis geometries. For a point location, this could wither be redundant or store the same coordinates as in the lon lat field. For polyline/polygon, this would be where the geometry is stored (lon lat fields wouldn't have that capability, and may store the centroid or be empty?)
On IFM: I don't understand whether IFM models / vulnerability curves differ in Oasis LMF from non-IFM models/curves. Is this not just a legacy of CEDE coding where AIR/Verisk had a specific IFM model? If there is no 'IFM' different model format in LMF< then this is just a labelling issue, and maybe the codesets should not have the IFM label in the OED name or OED description (but could still be matched against CEDE IFM codes).
@stufraser1 thanks for your comments.
- User Def fields - These are just free-form text fields for data capture/reporting so you can use these for anything you like. Am I right in thinking you are suggesting to populate these with some permanent codes, as per your attachment? We cant assign permanent codes or values to these fields as they are user defined.
- Unless pushback from the community, adding the 16 pipe material code for future-proofing should be ok.
- GEOM - single field. No problem - we just need a clear description to accompany it.
- IFM codes - I agree that these are probably legacy from the CEDE codes. We can re-label them by removing "IFM" for the OED code but can leave in the (CEDE) IFM code for reference separately.
For user def fields, is it worth adding to docs a section on modelling infrastructure (and population while we're at it), where we can provide guidance that user def fields should be used for those additional codes we defined as suitable for userdef, rather than their own codes?
From: MattDonovan82 @.> Sent: Wednesday, July 13, 2022 4:31:09 PM To: OasisLMF/OpenDataStandards @.> Cc: Stuart Fraser @.>; Mention @.> Subject: Re: [OasisLMF/OpenDataStandards] OED support for public infrastructure (Issue #74)
@stufraser1https://github.com/stufraser1 thanks for your comments.
- User Def fields - These are just free-form text fields for data capture/reporting so you can use these for anything you like. Not quite sure what you are proposing?
- Unless pushback from the community, adding the 16 pipe material code for future-proofing should be ok.
- GEOM - single field. No problem - we just need a clear description to accompany it.
- IFM codes - I agree that these are probably legacy from the CEDE codes. We can re-label them by removing "IFM" for the OED code but can leave in the (CEDE) IFM code for reference separately.
— Reply to this email directly, view it on GitHubhttps://github.com/OasisLMF/OpenDataStandards/issues/74#issuecomment-1183371363, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AC7PNYTSP4JI7D3JFFLU67LVT3OL3ANCNFSM5ZUZMK5Q. You are receiving this because you were mentioned.Message ID: @.***>
For GEOM: refer to http://postgis.net/workshops/postgis-intro/geometries.html for the field contents
GEOM field to be added to OED Location with field type: geometry Value of GEOM can be in the following form: 'Point', 'POINT(0 0)' Would be equivalent to using lon/lat fields. Use case: building location, communication / power towers
'Linestring', 'LINESTRING(0 0, 1 1, 2 1, 2 2)' Would be new capability. Use case: roads, railways, communication/power networks, pipelines. Need to consider how a line feature would be modelled in LMF - use hazard intensity at centroid of line or max/median etc along line?.
'Polygon', 'POLYGON((0 0, 1 0, 1 1, 0 1, 0 0))' Would be new capability. Use case: building footprints, area of cropland/other natural areal features. Need to consider how a polygon feature would be modelled in LMF - use hazard intensity at centroid or max/median etc in area?
'PolygonWithHole', 'POLYGON((0 0, 10 0, 10 10, 0 10, 0 0),(1 1, 1 2, 2 2, 2 1, 1 1))' Would be new capability. Use case: buildings, other areal features? Again, consider how it would be modelled.
'Collection', 'GEOMETRYCOLLECTION(POINT(2 0),POLYGON((0 0, 1 0, 1 1, 0 1, 0 0)))'_ 'Collection' can include multiple GEOM types in one row of data, in the same field. I'm not sure of the use case in Oasis. You could have a series of lines and points in a collection to represent a distribution network in a single row of OED Location data? But the occ/con codes of the towers and the distribution lines would be different anyway, so might want to separate those. A more likely use case would be to include the location of multiple points that all have the same occ/con, but an issue would be how the total TIV of the single row would be spread across all points - model functions would have to handle that.
For Transport suggest not adding new occupancy codes but varying description of 1250 and 1251 slightly if needed.
IFM codes are typically used to refer to larger, higher quality, well engineered structures. It's not just AIR CEDE that has this so I suggest NOT refactoring / renaming IFM codes without broad syndication across Oasis-based vendors.
UserDef fields: suggest not using them this way as they lose their purpose as UserDef fields. If rarely used suggest adding extra (Optional) fields (ie add in secondary modifiers). Note that ConstructionQuality and FoundationConnection already exist and so perhaps could be used for the first 2 user defined suggestions.
@stufraser1 Just picking up on this as I'm working on the release candidate for ODS v3.0.0. As per @jones-matt suggestions - do you have any further comments? IFM - leave as is and for rarely used codes, rather than using user def fields, can you suggest the additional secondary mods to cover these unique codes that can go into OED?
@stufraser1 @jones-matt On transport - If changing the current occ descriptions from "establishments" that work on highways, to the actual highways makes more sense, do we then need to add new occ codes for the "establishments" separately? Depends how people are using these but I suspect most that are using them, are coding the actual highway rather than the establishment.
I don't think that the new Geom field would allow the users to add shapes with having just 5 values defined. I think it needs two fields - one to specify what it is (e.g. line, polygon, etc) - basically the current Geom, while the other needs to have a list of coordinates entered - although it can be rather challenging, as the list seems to come as a comma separated one, and Oasis uses csv files. An alternative would be to store the entire string in Geom field, e.g. 'Polygon', 'POLYGON((0 0, 1 0, 1 1, 0 1, 0 0))'. But again, the same issue arises as it contains commas.
@stufraser1 @johcarter any further comments on this? Cant think of any issues with Aiste's suggestions?
For the type @aiste-kalinauskaite we could adopt the geometry type field from the Risk Data Library Standard https://docs.riskdatalibrary.org/en/latest/reference/codelists/#geometry-type
I don't have a solution for the comma separated problem of an array shape. Where is this requirement coming from please?
As discussed, Geom needs to have the whole string of information, not just pre-defined values of "line", "polygon", etc.
The whole geom definition is designed to be put directly into the field GEOM.
@MattDonovan82 The proposed changes to the spec are; Remove all GEOM rows (Codes 1,2,3,4,5) from 'Other Values' tab In ' OED Input Fields' change GEOM description to 'Geometry of the location: refer to http://postgis.net/workshops/postgis-intro/geometries.html'
Wrapping the Geom string in double quotes within the csv file will avoid any issues with column alignment when opened in excel, or read in python. e.g use "POLYGON((0 0, 1 0, 1 1, 0 1, 0 0))" rather than just POLYGON((0 0, 1 0, 1 1, 0 1, 0 0))