High-level feedback on transportation schema (communication + adoption)

[emilyeros]

I just read through the schema as manifested in PR #14 and wanted to share some high-level feedback + suggestions around communication and roll-out

• The way you envision segmentation and linear-referenced properties seems conceptually correct and offers a once-in-decades chance to reboot from things that aren't ideal about OSM. It's clean and it makes sense. But this schema will be much more difficult to work with than OSM (which may be conceptually incorrect but it does have a reasonably flat structure).

• You’re shifting a lot of burden onto downstream algorithms. I think that’s appropriate, but it could be a high bar for folks to clear before they can begin to work with the schema. It might be simple for a machine to ingest the data, but that depends on a human engineer wrapping their head around it first... and I think that would take at least a day or two. This could be a barrier to adoption, especially for folks who are used to OSM and have a viable alternative to Overture. (On the other hand, there don't necessarily need to be map editing tools built on top of Overture, so at least you have a reduced ecosystem of essential tooling.)

Seems like there are two ways to counter these challenge: either start small to establish familiarity and then build on top... or go all in and do your best to bring people along for the ride.

• Since there's an incumbent, existing map data product (OSM), it seems difficult to start small - I can see why you're more or less fitting the whole transportation world into the data schema from the get-go. I see that you've left certain things (rail, water, bicycle) as partially-solved problems to tackle later. Hypothetically, are there any other ways you could trim the spec until there's more familiarity? Or keep the spec but roll it out incrementally in new releases? (Or is this too difficult, since the network would need to work for use cases like nav apps that must continue to handle data about axle restrictions, HOV lanes, and other 'tags' that belong in Overture's linear-referenced properties?)

• If you are going to go all-in on this, it may help to really lean into communication strategies and working examples of code. On the communication front, it may be a good idea for Overture to think about "step-wise" communication materials. Get people familiar with a few key concepts before they read the schema details, so they don't react like deer in headlights. E.g. Some people in the OSM community might appreciate a 1-pager equivalent that explains the segmentation/LR approach very simply, points out what's different and the same in OSM, and explains why. Maybe it talks about what's harder and what's better in this new world. Maybe there's a separate set of visual materials that you can use for webinars, which builds on this but has more examples.

• The faster people start building on top of this schema, the better the outlook will be for adoption. What sort of lightweight tools, examples, libraries, whatnot can Overture members create? Ideally these would be for internal purposes and would make some attempt to solve a problem or pivot an existing tech stack, otherwise they'll gather dust. Also, how can you support or amplify the voices of other folks outside the membership as they experiment with the schema?

• Since the spec will have various releases and become more stable over time... what about waiting for certain adoption milestones before moving on to the next release? I'm not sure if that's conventional, but it would force an emphasis on usability and adoption, so you're not perfecting something on a shelf.

[vcschapp]

Great feedback Emily. Hopefully we'll engage on some of your specific points in the days ahead, but for now I just wanted to say thanks for the careful thought.

[d3netxer]

These roads with linear referencing do seem interesting. I just read TomToms blog post: https://engineering.tomtom.com/overture-transportation-network-linear-referencing/

I'm assuming it is not implemented yet, but will appear in a future release, is this correct? I am eager to see some examples

I have some questions:
-Does TomTom already use these types of roads internally?
-How will roads from OSM imported into Overture be converted?

I think having the tools to do network routing algorithms on these roads is important

[Azbesciak]

To do not make a spam, but still in the same topic, please revisit your definition, or at least documentation, for the lanes order, since right now the description seems not synchronized with the reality, at least in the doc - hopefully.

https://docs.overturemaps.org/guides/transportation/roads/#lane-numbering