Experimental: removes access restrictions for a connectivity profile

[daniel-j-h]

Experimental: do not merge. Idea is to run this on the demo server and then do two requests: one against the proper demo server and one against this stack, comparing the snapped coordinates for connectivity issues.

cc @MoKob @srividyacb @srividyacb

[daniel-j-h]

Some more details what this connectivity profile is all about:

We are trying out the following for a more realistic small components layer: use a custom connectivity profile and enable routing over tags such as access=destination and others which are routing engine limitations but not data issues.

The small components layer then shows data issues not influenced by the absence of features in the routing engine.

The small component layer is for the OpenStreetMap community to debug data issues. In contrast, the debug endpoint will continue to stream vector tiles in realtime from the routing engine's interal view, for debugging routing issues.

[daniel-j-h]

This needs an update to the latest osrm version - we have a vast amount of fixes since January.

@woodpeck how do you generate these components do you have an osrm version fixed for it? I guess the update here needs to be coordinated with your setup in some way?

[woodpeck]

@daniel-j-h currently I don't generate anything myself, instead it has been you (as in "someone on your team using an ssh key that begins with johan@") who, until the 20th of January, uploaded a components.shp/shx/dbf to my OSMI server. This has meanwhile stopped and I'll either have to set up my own toolchain to generate a suitable file with OSRM, or if you can continue supplying something that would also be welcome.

[daniel-j-h]

Based on the conversation in #3570 we stopped generating and uploading components to you osrm server. Maybe there was a misunderstanding here?

[woodpeck]

Ah, I think I had simply overlooked that. Guess it would be easiest to take a current car.lua and kill all the access restrictions from it instead of trying to update an old one?

[daniel-j-h]

Yes feel free to close this pull request and use the current car profile as a building block.

Take a look at the changes here - you will need to replicate them. The idea is to show OSM contributors problems in the data but not problems arising from limitations in the routing engine.

[daniel-j-h]

Closing here (but keeping branch alive) as stale.

@woodpeck you good here?

[woodpeck]

Ah sorry I meant to reply earlier and forgot. So we tried to apply your ideas (ignore access restrictions etc) to the current car profile and run with that. But we felt that while it certainly did omit a few false alarms, it would also ignore a few problems that we actually wanted highlighted. So we ditched the idea of using a special profile and are now generating the "routing islands" view (our name for "small components") on OSMI from your standard car.lua profile using OSRM 5.10. (Converting the GeoJSON to sqlite is rather memory intensive with ogr2ogr at the moment and we contemplated adding direct sqlite output to OSRM but then thought better of that, it would have been a niche feature used hardly anywhere and the box needs to have a lot of RAM for generating the profile in the first place.)

Yes we're good ;)

[daniel-j-h]

Ah, yes the osrm-components tool is now really optimized for ease of usability but not for scalability anymore. If you want to change this single line you could output in what ever format you want.