[Discussion] SharedStreets dependency in pipeline

[lmz]

We have been discussing the use of SharedStreets tools and data in our pipeline/network creation process.

From our MTC Network Rebuild Requirements:

The roadway, pedestrian, and bicycle networks will be based on OpenStreetMap (OSM) as processed by SharedStreets (https://sharedstreets.io/). The SharedStreets project seeks to provide a unique, stable identifier for every roadway in the world, allowing users of spatial information to more efficiently interact with each other. We think there is potential long-term value in having SharedStreets identifiers on the TM2 roadway network. NACTO and the Open Transport Partnership are supporting SharedStreets. In the near-term, the value of using the SharedStreets identifiers is that it allows us to use the SharedStreets conflation tools for merging other datasets with the new base map.
MTC would like to create a year 2015 roadway network. However, we would like to start with a newer extraction from OSM under the theory that, over time, OSM gets more accurate. The most recent SharedStreets extraction of OSM is from December 24, 2018. As such, the source information for the base map will be from December 2018.

We would like to understand/document the repercussions of this, especially given that SharedStreets has not published an OSM extraction since 2018 (see sharedstreets-js/issue#72) and it's not clear if they will do so again, or if these pieces of software will be maintained or abandoned.

For example, when links are broken up, then SharedStreets links end up being aggregate versions of those links, which seems like it'll be more of an issue as time goes on? Similarly, what about new links that don't correspond to any SharedStreets link? (Side note: the pipeline creation process should log the magnitude and details of these types of issues, if it doesn't already.)

cc @DavidOry @i-am-sijia @e-lo @FlaviaTsang @yuqiww

[DavidOry]

A few thoughts on this:

1. Both SharedStreets and OSMnx provide routable network extractions of OSM.
2. I think an important feature of Ranch that we need to maintain is the ability to create networks from OSM via either OSMnx or SharedStreets. So if SharedStreets does not publish another tile set, Ranch can still create current year networks via OSMnx. We prefer SharedStreets mostly because we like their conflation tools, which work better when every link in the network has a ShStReferenceId.
3. When you say "when links are broken up", this can be for two reasons: (a) a user adding a node in OSM to reflect an attribute that is not important to us, say a park bench, or (b) a geometry change in OSM that is important to us, say a new intersection. Both SharedStreets and OSMnx should suppress type (a) and create a new link in type (b). In the case of (b), the conflation of the old network to the new network (via SharedStreets conflation tools or other tools), will fail, which will require MTC to manually update the attributes. This seems to be the heart of your concern: how well will successive networks built from source align, which then determines how much work is needed to attribute the new network. Is that right?
4. Even if SharedStreets did publish new tile sets, it's not obvious to me that the idea of having stable identifiers will be meaningfully better than conflation. I hope so. But it's a hard problem -- see track changes for streets sharedstreets/sharedstreets-ref-system#22. So, the situation of the problem described in (3) may not be different with either OSMnx or SharedStreets. Ideally, SharedStreets would log changes, as discussed in the linked issue, which would give you definitive-ish guidance as to where to spend your time updating network attributes.

[JonathanEhrlichMC]

There is a value to node numbers being stable across rebuilds, so project cards don't need to be rebuilt. I'm not sure if this is possible at all, even with SharedStreets.