[OSM-talk] Good practice, and should we rely on defaults?

[Sarah Hoffmann]

On Fri, Apr 08, 2022 at 11:12:05AM +0100, Richard Fairhurst wrote:
> Martin Koppenhoefer wrote:
> > What are your thoughts about this rule, what is it meant to prevent,
> > and what is beyond the intentions?
> 
> I won't comment on what should happen, but I'll say what _does_ happen.
> 
> Very few worldwide OSM-based maps do any significant regional processing. Car routers probably understand which countries are right-hand drive and which are left-hand. Some bike routers (though not all) understand that highway=trunk is legal to cycle in some countries but not others. But in the general case, there's not much more than that.
> 
> The upshot is that those very few routers/maps which do any regional processing have an advantage. I say this with some knowledge because cycle.travel (my site) is one of them. It has lots of regional processing, and as a result it's the only bike router that will take you (say) across America on quiet roads without you dying of dysentry in true Oregon Trail fashion.
> 
> You'll also find that sites whose customer base is mostly within one country tend to interpret tags according to the customs of that country.
> 
> So if you're happy that your hard mapping work will be interpreted correctly by cycle.travel, a handful of other small sites embedded deeply within the OSM community, and some national sites, then by all means use region-sensitive tagging. But if you want it to be used by the big guys (Strava, Komoot etc., let alone the really big companies) then realistically you need to use global tagging.
> 
> Wikidata is not an answer to this. The OSM data format is .osm.pbf. That is what every tool reads. You are not realistically going to get all these tools, including a lot of proprietary ones you've never seen, being rewritten to pull in a multi-GB Wikidata dependency just so they can find a bike route across England. Again, I'm not saying what should happen, but what does and will happen.
> 
> A machine-readable GeoJSON file with a few defaults per polygon (LHD vs RHD, bikes allowed on trunk, etc.) would not necessarily be a bad thing. If it was kept relatively simple then it might get widespread adoption. But anything as stupidly complex as the opening hours syntax, say, is not going to fly.

I don't think this is a question of how simple or complicated the data
is or where it is stored. The essential point is tool support.

What you need is that the standard tools (osm2pgsql, imposm, osmium,
tilemaker, etc.) start offering support for tagging the country location
of an OSM object plus tag completion based on the country. If they take
care of pulling the defaults from whereever the OSM community decides to
store them, then the information will be used.

Sarah