[Tagging] Traffic_sign discussion

Paul Johnson baloo at ursamundi.org
Tue Oct 9 22:49:32 UTC 2018


This whole "trying to cram everything including direction and how it
relates to everything into a node" idea is fundamentally hosed.  Also
literally why relations are a thing that exist.

On Tue, Oct 9, 2018 at 5:26 PM yo paseopor <yopaseopor at gmail.com> wrote:

>
>
> On Tue, Oct 9, 2018 at 8:37 PM Tobias Knerr <osm at tobias-knerr.de> wrote:
>
>> On 09.10.2018 17:42, yo paseopor wrote:
>> > So Please , let's talk about it. What will be the correct way to tag a
>> > traffic sign?
>>
>> How about the existing tagging scheme for traffic signs on nodes,
>> documented at https://wiki.osm.org/Key:traffic_sign ?
>>
>> To sum it up:
>>
>> - Place a node for the traffic sign into the highway=* way.¹
>>
> It is
>
>> - Tag the node as traffic_sign=<ISO>:<ids>.
>>
> It is
>
>> - As with your suggestion, <ISO> is the ISO country code.
>>
> It is
>
>> - <ids> is composed of one or more country-specific traffic sign ids, as
>> an ordered list separated by commas.
>>
> It is better to manage the information with each position to avoid the
> mixtures. One of the errors of the mass edition were the edition of
> ways...with traffic signs tag. If any way would not have this key dedicated
> to the nodes there weren't these errors.
>
>> - If there are multiple groups of traffic signs, these groups are
>> separated by semicolons.
>>
> Each traffic sign can have its position like Finnish people do , with :2
> :3 :4 subkeys
>
>> - Custom inscriptions on a sign are appended to the sign id in square
>> brackets [].
>>
> but which information are these brackets? Are maxspeed values? Are
> maxleght values? Are custom inscriptions or designations? It is better to
> expose this information with their own keys to process it by the renders
>
>>
>> ¹ The page also documents how to map traffic signs next to the way, but
>> I understand you would like to talk about mapping them as part of the way.
>>
> Thanks for this consideration
>
>>
>> I haven't seen a convincing reason for changing this yet. I'm aware of
>> the general argument against semicolon-separated or comma-separated
>> lists of values, but imo this is less critical for keys that have
>> well-defined semantics for such characters.
>>
> multiple values are a problem for the processing of the data. Nowadays a
> lot of values are yes/no, etc. In this way of tagging it is logic to make
> the pairs :2 :3 or  :forward    :backward    , etc.
>
>>
>> > traffic_sign:direction=forward/backward/both
>> >
>> > Also accepts other facing directions like 90/270...
>>
>> In my opinion, traffic signs should use the normal direction=* key for
>> angles such as 90 or 270. This usage is part of the approved proposal of
>> that key:
>>
>
> If direction=0 is forward and direction=180 is =  backward ok I'm agree.
> Because if it marks the cardinal orientation these direction would change
> in every curve making less intuitive the tagging of the direction.
>
>>
>> https://wiki.osm.org/Proposed_features/direction#Point_features
>>
>> Using traffic_sign:direction specifically for the "forward" and
>> "backward" values, as discussed in the recent iD-related thread, is fine.
>>
>
> Some people does not agree and says the reason of the edition (make the
> scheme compatible with iD solution) sucks.
>
>
>>
>> >
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Extended_traffic_signs_tagging
>>
>> I find it hard to discuss this proposal because it includes so many
>> different ideas:
>>
>> - introducing a system of "categories" for signs: caution, warning, etc.
>>
> All these categories you can find in every traffic sign's law and also on
> the API of one of the possible sources: Mapillary. These keys help to make
> human-readable values and also international (because of the people does
> not want to use ISO codes) . There are also in OSM some categories like
> maxspeed , restriction...
>
>
>> - using :2, :3 etc. instead of comma-separated ids
>>
>
> Finnish people do so well
>
>
>> - using human-readable values instead of unambiguous national IDs
>>
>
> It would be an important decision because with country codes we can show
> exact traffic sign as it is for the country, not similar: equal.
>
>> - re-purposing maxspeed (and maxspeed:hgv etc.) for traffic sign mapping
>>
> Reusing tags for OSM. Only we have to change some options for validators
>
>> - adding a side=* key
>>
> For making a exact position using relatives to the way
>
>> - improving destination sign and roundabout mapping
>>
> Destination signs are one of the more important traffic signs because they
> show towns, local places  which connects to data in real place.
>
>>
>> Trying to change all that at once likely leads to discussions that mix
>> all sorts of loosely related topics.
>
> It is true it is complex. But as the topic for me is so important (making
> a tagging scheme for a World collaborative project like OSM) that I try to
> think ( I have started with this in 2011) how to do it and try and
> establish a complete (4 position, 3 panels (12 localizations) in two
> directions and two sides with basic colors)
> Now we can discuss with a base that works. We can modify all we want, all
> we agree, all we think,  but we have the base.
>
>
>> And there's not really a reason why
>> e.g. introducing the side=* key would also require using numeric
>> suffixes. These are independent changes that could easily be discussed
>> separately.
>>
>
> Well this time I will start all the discussions to find a solution. I
> don't want to fight or read things like "sucks" or "stinky". I have
> dedicate lots of time, like other people and I don't think I deserve these
> words.
>
> yopaseopor
>
>
>>
>> _______________________________________________
>> Tagging mailing list
>> Tagging at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> _______________________________________________
> 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/20181009/dd61b5e0/attachment.html>


More information about the Tagging mailing list