Validator for invalid turn restrictions

[daniel-j-h]

(I haven't found a validator for this - if we already have one in place feel free to close this)

For turn restrictions of the form (fromWayId, viaNodeId, toWayId) the viaNodeId needs to connect the way fromWayId to the way toWayId. Turn restrictions where the via node is not shared across the two ways are invalid.

Our routing engine filters via-node turn restrictions that are invalid and discards them. We should have a validator in place since this type of error should be easy to detect and fixing it is of high value for routing.

---

Related to that - turn restrictions have a well-defined format:

http://wiki.openstreetmap.org/wiki/Relation:restriction#Members

the relation members have to be:

• from - of type way, exactly 1 way, except can be multiple ways only when no_entry restriction!
• to - of type way, exactly 1 way, except can be multiple ways only when no_exit restriction!
• via - either a single node or multiple ways

We should have a validator in place for checking all turn restrictions making sure they conform to this schema.

cc @srividyacb @Rub21

[srividyacb]

This is a must validator to have. Based on my knowledge - we use OSM-QA tiles and tile-reduce for most of the linters scripts to detect tagging and connectivity errors. But I don't think OSM-QA tiles have turn-restriction in it.

@Rub21 how can we build this validator?

cc @daniel-j-h

[planemad]

Thats right osm-qa tiles do not have turn restrictions.

@ramyaragupathy have we ever made a global tileset of turn restrictions?

Also here's an interesting web QA tool for TR: http://restrictions.morbz.de/#15/37.78645/-122.40611

[ramyaragupathy]

Nope, but this can be done with osmlazer @planemad

[daniel-j-h]

Flagging: there is also an edge case with no_entry and no_exit which we stumbled upon lately

https://github.com/Project-OSRM/osrm-backend/issues/4241

and our routing engine does not handle it yet. It's on our feature list to implement.

What's interesting in the context of validators is @mokob sampled the OpenStreetMap data for no_entry and no_exit and found quite a few issues with how they're getting used and simple mis-uses. At the moment there are only a couple hundreds no_entrys and no_exits in the dataset - it could make sense to check them, too.

[Rub21]

@daniel-j-h , I thought this could be possible using the Multipolygon mbtiles that have been in the test(this contain some relations) but not, it does not contain the TR relations.

@ramyaragupathy could we get TR data from osmlazer as geojson? @daniel-j-h , Maybe do you know other ways to get these TR data as geojson?

if it so, we could use the geojson to combine with the osm-qa-tiles to do the analysis and detect those invalid TR.

[ramyaragupathy]

could we get TR data from osmlazer as geojson?

Nope, only the count works @Rub21

[ramyaragupathy]

Worked w/ @planemad to expand on earlier work of grouping relations. Script here regroups relations by their ID & append member geometries to each relation in a GeometryCollection.

We ran it against TRs in SF & got the geojson formatted to represent relations as Geometry Collection. Contents are shared in dropbox.

• the input file SFTR_Input.geojson
• output file SFTR_reorganised.geojson & output.mbtiles

Interactive map

More on the data structure

Sample file of a TR as GeometryCollection.

All relation related properties at feature level:

"properties": {
    "type": "restriction",
    "restriction:type": "no_left_turn",
    "restriction:id": 6191617,
    "members": [
      {
        "label": "from"
      },
      {
        "label": "via"
      },
      {
        "label": "to"
      }
    ]
  }

members array within properties store info on each role that constitutes a TR. Order within the member array matches the geometry order within geometries array of a feature.

cc @Rub21 @daniel-j-h @srividyacb @maning

[Rub21]

@ramyaragupathy This is nice!! the mbtiles works fine!! , I am doing some analysis to detect invalid TR, but I could not find to any of this in SF, could you create a mbtiles for US?

[geohacker]

@ramyaragupathy nice work! the output.mbtiles you posted above doesn't seem to have any GeometryCollections. Is that right?

@Rub21 @ramyaragupathy @planemad - just want to flag that Tile Reduce does not support GeometryCollections, unfortunately, which means OSMLint may not work. We have tried this before.

[ramyaragupathy]

Looks like tippecanoe just treats each geometry within the GeometryCollection as a separate feature, instead of treating all the geometries as an unit @geohacker @planemad @Rub21

Thinking of osmium here. For relations, though it does not return the geometry data, it contains details that can be used to generate geometries:

{ restriction: 'only_right_turn', type: 'restriction' }
[ { type: 'w', ref: 478760157, role: 'from' },
  { type: 'n', ref: 176581223, role: 'via' },
  { type: 'w', ref: 61840757, role: 'to' } ]

From the id, geometries can be obtained and then linters could be run in the same script for validation.

[geohacker]

geometries can be obtained and then linters could be run in the same script for validation.

This is not the pattern we follow in OSMLint, so this validator will have to be outside of this repository.

[ramyaragupathy]

yeah the workflow will be different from the existing ones @geohacker

[Rub21]

Because mbtiles does not support relation, we created another report to detect invalid relations https://github.com/osmlab/osmlint-osmium/tree/master/validators

Close this ticket here!!