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

Mateusz Konieczny matkoniecz at tutanota.com
Fri Apr 8 15:57:48 UTC 2022


For start one may check whether
https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access_restrictions
matches reality, actual tagging and consensus of mappers or not.

This page since 2010 was described as "possible, upcoming default value system".


Apr 8, 2022, 17:12 by jwhelan0112 at gmail.com:

> So a first step might be to list the regional defaults?
>
> Once they exist then we can expect tools that use them to have better quality data than those tools that don't.
>
> That I think might well work as an incentive, especially as the maps will be smaller to hold the same information.  Useful for the off line smartphone apps etc.
>
> Cheerio John
>
> On Fri, Apr 8, 2022, 11:07 Sarah Hoffmann via talk <> talk at openstreetmap.org> > wrote:
>
>> 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 <http://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 <http://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
>>  
>>  _______________________________________________
>>  talk mailing list
>>  >> talk at openstreetmap.org
>>  >> https://lists.openstreetmap.org/listinfo/talk
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20220408/1f49a793/attachment.htm>


More information about the talk mailing list