Mapping to OSM data model

[e-lo]

It was my (relatively uneducated, but enthusiastic) understanding that the overture datasets would be leveraging a great deal of data in open street map. However, when reviewing many of the schema structures I wasn't sure if/how OSM data would "nest" or fit within it. I'm specifically thinking about the linear referencing method of adding attributes as opposed to the OSM method of "splitting" ways when various tags change...but I suspect there are also other places as well that aren't neatly compatible.

I'm sure this has been thought through by the Overture Team and I'd love to hear what their Team's thoughts are on it (and if I'm missing how they are actually beautifully compatible in a way that I don't see!)

[RobSoetewey-TomTom]

Hi e-lo,

Your understanding on leveraging OSM data is correct. However, as we want to built a base map that can be referenced by many sources, we believe that the churn introduced by splitting ways on tag changing is adding unwanted churn and object instability. Data layers referencing that base map need to stay on top and process all these splits. Additionally, those layers referring the base map have no means to split the objects in the base map to their needs. With linear referencing we offer a method to attribute parts of a "way".

For layers where we leverage OSM, we will re-calculate the "ways" into Overture segments, and apply the attribution making use of linear referencing.

We are aware that relatively simple interfacing with the OSM ecosystem will facilitate adoption. We do have that in mind.

[e-lo]

we believe that the churn introduced by splitting ways on tag changing is adding unwanted churn and object instability.

☝️ I totally agree. I was really more curious as to how the interchange of data would occur (if that was a goal). If I'm understanding you correctly, the segments would potentially have linearly-referenced data from ways on top of their segment-wide scoped attributes? If that is the case, what happens if segment-wide scoped attributes conflict with linear-referenced attributes?

As a potential example:
If there is a segment that contains two ways which have a different # of lanes but all else the same, then can a segment contain a value for the property lanes and then a linear referenced lanes which sits on top of it?

• If so, are these prevented from overlapping/ conflicting in the spec?
• If they are overlapping, how is conflict resolution handled?

I guess this question now becomes a question about how to resolve conflicts/overlapping data and if that is going to be handled on the backend by Overture (and if so, using what precedence/algorithm) or something the users will have to resolve?

[RobSoetewey-TomTom]

Hi @e-lo,

Contradicting information on the segment and as linear referenced would be considered a quality problem. In your example above, all lanes tags will be Linear referenced without overlap.

[e-lo]

If so, it might be prudent in the schema description to provide some shall not statements to the effect of:

• if lanes (and other relevant properties) provided in segment data, it shall not be provided in any linear-referenced data.
• if lanes (and other relevant properties) provided in a linear-referenced data, it shall provide 100%, non-overlapping coverage of the segment.

And it would probably be useful to see an example of linear-referenced properties like this and how they are packaged/associated with with the segment-level data since they will be dependent on each-other in order to assess if you have a valid dataset. i.e. how do I know what other data the segments data requires in order to be complete?

[larsskaug]

A consequence of this choice is that a large number of OSM IDs are not imported into Overture, correct? If a road is split into many segments (ways) in OSM, it may be included in Overture with fewer segments and therefore fewer OSM IDs, right? Please confirm or correct my understanding. Thanks!

[jwass]

@larsskaug Every Overture feature specifies all its sources (datasets and record_ids) - including the geometry and all attributes. An Overture segment that joins more than OSM way will specify all of them including when there are more than one. So all OSM IDs that are in Overture will be included in a "source" record somewhere even if there are fewer total segments.

For example: In the April beta release, segment with id 0861ea5a97ffffff04731d30f0c1de01 has the following item in its sources:

[
  {
    "property": "",
    "dataset": "OpenStreetMap",
    "record_id": "271609027",
    "confidence": null
  },
  {
    "property": "",
    "dataset": "OpenStreetMap",
    "record_id": "925475354",
    "confidence": null
  }
]

So this is comprised of https://www.openstreetmap.org/way/271609027 and https://www.openstreetmap.org/way/925475354

Its geometry is the following wkt:

LINESTRING (12.9939218 45.9195392, 12.9941164 45.9193517, 12.9944574 45.9189959, 12.9945464 45.918903, 12.9946197 45.9187755, 12.9948052 45.9184778, 12.9951907 45.9175287, 12.9956795 45.9162969, 12.9958508 45.9159688, 12.9959182 45.915875, 12.9960941 45.9156302, 12.996109 45.9156095, 12.9964793 45.9151879, 12.9969865 45.9147502, 12.9975465 45.9143698, 12.9981228 45.9140342, 13.0007786 45.9124248, 13.0012372 45.9121102, 13.0014907 45.9119087, 13.0019196 45.9115238, 13.0023558 45.9110325, 13.0026257 45.9106422, 13.0028374 45.9102852, 13.0029778 45.909965, 13.0030292 45.9098357)

So in this case it just joins the two together end-to-end.

[larsskaug]

Thank you for the clarification!