[Tagging] Semi-colon separated route values
Volker Schmidt
voschix at gmail.com
Mon Jan 24 16:30:50 UTC 2022
A quick search with RelationAnalyzer for "Ciclopedonal" in the Name
<http://ra.osmsurround.org/searchRelation?name=CICLOPEDONAL&relationType=&route=&ref=&network=&operator=>
produces a list of 41 route relations which are likely candidates for
routes that are suitable for hiking and bicycle in Italy.
Volker
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#m_7465009652896755282_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Sun, 23 Jan 2022 at 23:12, Martin Koppenhoefer <dieterdreist at gmail.com>
wrote:
>
> Am So., 23. Jan. 2022 um 13:15 Uhr schrieb Andy Townsend <
> ajt1047 at gmail.com>:
>
>> > The obvious alternative is to create quasi-duplicated relations with a
>> > single route=* value. It seems simpler, easier to dealt with for data
>> > consumer and also to maintain (what if I'm a cyclist and don't know
>> > about horse-riding specificity ?).
>>
>> As a data consumer it makes essentially no difference to me. As you
>> said, the tagging is just a fact, so as a data consumer, you just deal
>> with it.
>>
>> As an example, The Pennine Bridleway
>> https://www.openstreetmap.org/relation/50288 in England is tagged like
>> this and the extra work to render routes of this type is one line of
>> code:
>>
>> https://github.com/SomeoneElseOSM/SomeoneElse-style/blob/master/style.lua#L7626
>>
>
>
> this is the line:
> ( keyvalues["network"] == "ncn;nhn;nwn" )) then
>
> it is just one line if you only want to support network=ncn;nhn;nwn
> but if you also want to support the (identical meaning?)
> network=nhn;nwn;ncn
> and
> network=nhn;ncn;nwn
> and
> network=nwn;nhn;ncn
> and
> network=nwn;ncn;nhn
> and
> network=ncn;nwn;nhn
> and the similar
> network=ncn;nhn
> and
> network=ncn;nwn
> and
> network=nwn;ncn
> and
> network=nwn;nhn
> and
> network=nhn;ncn
> and
> network=nhn;nwn
>
> then it will be more lines of code, and potentially your performance might
> slow down if you do it for all values and all tags (it meaning split by
> semicolon into an array and look what you got).
>
>
> From a tagging point of view, where it does make sense to have separate
>> routes is if some sections differ for different modes.
>
>
>
> even if some (potentially not interesting properties) differ, e.g. a route
> that was opened in 1986 for hikers and cyclists and in 1992 became
> accessible and signposted for horse riders as well, would have different
> start_date tags, although the current situation is probably not that
> different from a route that started as a combined route for all 3 modes of
> transport and did never change. (And someone will also come up with a tag
> like start_date:horse=1992, because you can always invent a new key in OSM).
>
> At first, it might seem almost the same amount of work to produce 3 almost
> identical relations (simply duplicate one and adjust the tags) or to have a
> combined one. Which variant is better for later maintenance will depend on
> the kind of modification you expect. If there will be variations for one
> (or more) means of transport (e.g. horse riders at this one spot take a
> different route for some meters (or more)), the individual relations are
> easier and less work to modify (less errorprone also, and the modifications
> are much more likely to be done at all), but if the modifications are
> always relating to all means of transport, then it is much lighter to have
> just one relation to care for (also less weight in the db).
>
> Without being able to back it with actual research it seems obvious that
> people will be more hesitant to make modifications for just one means of
> transport if it is tagged as combination with others, and it is more likely
> that the object will not be interpreted correctly or even skipped
> completely if there are multiple values in a relevant tag.
>
> Cheers,
> Martin
> _______________________________________________
> 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/20220124/c12d1ee3/attachment.htm>
More information about the Tagging
mailing list