Update to Overhead Structures data

[al-tabb]

As a result of our 2020 LiDAR Survey, I have a substantial update to the overhead structures dataset. I'm hoping that we're able to change the schema at this time as well. The updated dataset does not have as many fields and this may be a good time to clean up the inconsistencies in the schema of the current dataset.

I believe we're currently using the field "Posted_Limit" to determine if a feature is an 'Overhead structure with posted limit' or an 'Overhead structure without posted limit'. Is it possible to determine this directly from the height fields? i.e. Categorize based on having a value in any of the height fields vs. having null values in all height fields.

There will also be a slight modification to the identification of "Overhead Directional signs". Features with a StructureType = 'Sign' should be included in this category in addition to the existing feature type(s).

The updated dataset is available here: https://devapi.regionalroads.com/simplewfs/?service=WFS&version=1.0.0&request=GetFeature&outputFormat=application/json&typeName=GM_OverheadStructures

Please let me know if these changes are possible and the anticipated level of effort.

Thanks.

[NicoledeGreef]

@qqnluaq - would you please consider this enhancement request and provide an estimate? thanks!

[qqnluaq]

@NicoledeGreef I estimate 1 day for this change.

[NicoledeGreef]

thanks @qqnluaq - please proceed with this at your earliest availability.

[qqnluaq]

This fix has been deployed to https://translink-d.apps.gov.bc.ca/trp/

[NicoledeGreef]

@al-tabb the Overhead Structures data update is in Delivery, ready for your review in conjunction with the other recent changes: #220 and #221

https://translink-d.apps.gov.bc.ca/trp/

there is some iteration happening with respect to layer re-ordering when there is interaction with the layer list and proposed route being hidden so things are not yet settled but do have a look and let us know about the new symbology and such.

[al-tabb]

@qqnluaq I realized that we didn't have a way to determine if an overhead structure has a sign or not. This is because we're now displaying measured values for many features that don't have signage. I've added two boolean fields to the dataset (PublicPostedLimitP and PublicPostedLimitO). Is it possible to use these new fields to split the dataset into the three layers?

• Overhead Structure with Posted Limit: ("PublicPostedLimitP" = true OR "PublicPostedLimitO" = true) AND ("PublicStructureType" !='Overhead Sign/signal' AND "PublicStructureType" != 'Sign')
• Overhead Structure without Posted Limit: "PublicPostedLimitP" = false AND "PublicPostedLimitO" = false AND "PublicStructureType" != 'Sign' AND "PublicStructureType" != 'Overhead Sign/signal'
• Overhead Directional Sign: "PublicPostedLimitP" = false AND "PublicPostedLimitO" = false and ("PublicStructureType" = 'Sign' OR "PublicStructureType" = 'Overhead Sign/signal')

[qqnluaq]

@al-tabb I don't see these new fields in the data at https://devapi.regionalroads.com/simplewfs/?service=WFS&version=1.0.0&request=GetFeature&outputFormat=application/json&typeName=GM_OverheadStructures

[al-tabb]

@qqnluaq I've just refreshed the GeoServer service, you should see the new fields now. Please also note that I've dropped the "public" prefix from the fields as this is something we just use internally. Here is the filtering using the correct field names:

• Overhead Structure with Posted Limit: ("PostedLimitP" = true OR "PostedLimitO" = true) AND ("StructureType" !='Overhead Sign/signal' AND "StructureType" != 'Sign')
• Overhead Structure without Posted Limit: "PostedLimitP" = false AND "PostedLimitO" = false AND "StructureType" != 'Sign' AND "StructureType" != 'Overhead Sign/signal'
• Overhead Directional Sign: "PostedLimitP" = false AND "PostedLimitO" = false and ("StructureType" = 'Sign' OR "StructureType" = 'Overhead Sign/signal')

Here are the updated field names documents:
2022-11-07.TRP.Datasets.Field.Names.UI.pdf
2022-11-07.TRP.Datasets.Field.Names.UI.docx

[qqnluaq]

@al-tabb merged change to the develop branch: https://translink-d.apps.gov.bc.ca/trp/

[al-tabb]

@qqnluaq I think there might be a few features missing / ending up in the wrong layer. Here are some comparison screenshots between TRP dev and my desktop app using the filtering specified above:
Overhead Structures without Posted Limit:


Overhead Directional Signs:

I think that these missing features might be incorrectly ending up in the Overhead Structures with Posted Limit layer in some cases. For example the feature OverheadID = 254 does not have a posted limit (PostedLimitP = false and PostedLimitO = false) but it shows up in this layer:

[qqnluaq]

@al-tabb try the dev build again, the build process had failed earlier. Now. it should be ok.

[al-tabb]

@qqnluaq Thanks, this looks good in terms of the way the layers are split up. Is it possible to show height clearances for the Overhead Directional Signs where there are values in the Height fields? The data now has measured clearances based on LiDAR measurements for some overhead signs.

[qqnluaq]

@al-tabb The heights are shown in the identify popup for the overhead structures. Is that sufficient?

[al-tabb]

@qqnluaq I'm not seeing the height values in the popup. This popup is shown after identifying the feature where OverheadID = 521. This feature has height values for lanes 1O-3O.

[qqnluaq]

@al-tabb updated dev build so that the overhead signs layer shows the sign heights in identify

[al-tabb]

@qqnluaq Awesome, this looks good. Thanks Ben.

[al-tabb]

@qqnluaq I've just updated this dataset and I'm hoping we can get it to production. It looks to me like the Overhead Structures without Posted Height layer is not showing the measured heights when they are available (i.e. Lane 1 Height, Lane 2 Height, etc. fields). The other layers look good to me. Once we get this corrected are we able to push this through to staging and production?

[qqnluaq]

@al-tabb fixed

[al-tabb]

@qqnluaq Looks good, thanks Ben. Are we able to push this to staging and production? I guess we'll need to be somewhat coordinated on the timing of this so let me know what works for you.

[qqnluaq]

@al-tabb I think @NicoledeGreef can coordinate the deploy to prod.

[al-tabb]

@qqnluaq Nicole has moved on to a new position. Do you know who is taking over for her and able to coordinate this in her absence?