[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