[Tagging] Use of highway=track vs highway=service cemeteries, parks, allotment gardens, golf courses, and recreation areas

Bert -Araali- Van Opstal bert.araali.afritastic at gmail.com
Fri Mar 5 15:37:31 UTC 2021


I do belief that creating a new tag or two-tier system for this could be 
very useful. Both to express usability by mappers as for data consumers.
Again I am trying to look at this on a global scale, relying on local 
experience.

Paved and unpaved, neither does any of these values say or provide 
conclusive information about the drive-ability of a road. Smoothness=* 
does in some way. Neither does it provide for easy tagging changing road 
conditions due to weather conditions, and or related issues regarding 
run-off, drainage etc... of roads.

F.i. many of the roads in Africa are unpaved but have a base layer of 
compacted ground and a top layer of murram. Murram, in dry conditions is 
often as smooth and drivable as asphalt, it turns however into a slide 
hazard, for all road users, when wet.  We consider it as a kind of 
pavement. Not ground, although it is a natural material mix abundantly 
available. It is also often mixed with gravel, to counteract the hazards 
in wet conditions.  Paved also doesn't mean sealed. Same for asphalt. 
Many asphalt roads worldwide become more a hazard during rainy 
conditions. Forming of tracks, poor drainage, water freezing on the 
surface etc... Asphalt is also a mix of different materials, and their 
mix is adopted to make the top layer semi-permeable, or more open to 
cope with wet or freezing conditions.  In many cases asphalt can not be 
called a seal. Same goes for other "pavements". All very useful data, 
not so difficult to obtain on the ground, and very useful to data 
consumers targetting different purposes or audiences like cyclists, 
hikers etc... all could benefit from it.

I am not saying a two tier system is the optimal solution here, but it 
deserves us thinking about a new tag or tagging to provide more 
conclusive and simple tags instead of making the existing data or 
structures more ambiguous and complicated (unusable in the long term) 
for data consumers and renderers alike.

On 05/03/2021 13:42, Mateusz Konieczny via Tagging wrote:
>
>
>
> Mar 5, 2021, 11:06 by marc_marc at mailo.com:
>
>     Le 05.03.21 à 10:50, Richard Fairhurst a écrit :
>
>         You really do not need two keys to express this.
>
>
>     I agree, but the fact that each tool has to build a list of values
>     and then classify them into main groups is not ideal either.
>
> Why? Different tools will have different needs and
> data consumers will need to make their own decisions.
>
> For example surface=grass_paver is horrible for bicycles and fine for 
> cars,
> surface=sand is bad for cars and bicycles, fine or maybe preferable
> for hikers.
>
>     you have made such a list, others also make such a list and with each
>     new value, you have to make a new piece of code to say that the new
>     "ultra precise" value is in practice in category A or B
>
> What is preferable to taking classification from some external dataset.
>
>     at least there should be a way to build this list in a
>     collaborative way
>     and easily readable by a program, this would allow to build a
>     preprocessor to group all the ultra detailed values into larger groups
>     for those who do not need to make the difference between a
>     paving_stone
>     variant A and variant B.
>
> That would be far more complex.
>
> BTW, you may use https://wiki.openstreetmap.org/wiki/Data_items 
> <https://wiki.openstreetmap.org/wiki/Data_items>
> for that.
>
> But it would not be not useful at least in cases known to me.
> For any place where I processed surface values I would prefer
> a manually curated list.
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20210305/9e9f6fef/attachment.htm>


More information about the Tagging mailing list