From OpenStreetMap Wiki
Jump to: navigation, search

Suggestions for improvement / Verbesserungsvorschläge

Sign combination / Kombination von Verkehrszeichen Tagging (optional) Remarks / Bemerkungen
1000-33 für Einbahnstraße siehe wiki TODO --Bk 22:31, 24 June 2010 (UTC)
1024-17 (Vehicles that cannot or must not drive faster than 25 km/h are allowed) agricultural=yes This is different from access=agricultural. This one is a vehicle class. --Driver2 23:01, 25 June 2010 (UTC)

This definition is really strange, why choose the same name for something completely different? Looking at tagwatch, it seems to be used wrongly already. Isn't there a sane synonym? --Bk 19:22, 22 July 2010 (UTC)

1024-10 car=yes This is different from the motorcar-class, which includes all motor vehicles that have two tracks (zweispurig). car=yes might not be the best choice given the similarities, but I couldn't think of a better word that represents 'PKW'. I have mentioned it here but have yet to get an answer. --Driver2 23:01, 25 June 2010 (UTC)

Makes sense, but can we wait till there is a proper proposal, or it is widely used / accepted? --Bk 19:22, 22 July 2010 (UTC)

1024-12 hgv=yes --Driver2 23:01, 25 June 2010 (UTC)

Done. --Bk 19:22, 22 July 2010 (UTC)

1024-14 bus=yes --Driver2 23:01, 25 June 2010 (UTC)

Done. --Bk 19:22, 22 July 2010 (UTC)

all traffic_sign=<country-code>:<signs> s. Proposed_features/Traffic_sign - would be very helpful especially considering possible future interpretations of traffic-signs (s. 237-241 in Germany ;)) --Yzemaze 10:03, 9 July 2010 (UTC)

Done (r22420) --Bk 16:34, 22 July 2010 (UTC)

... ... ...

About access=official

I noticed that you use 'official' instead of 'designated'. I think it is confusing to have different Tagging on the wiki, my tool and your JOSM tool. I am not opposed to 'official', however I think it should be used in all places. --Driver2 23:01, 25 June 2010 (UTC)

The author of such a tool shouldn't try to push personal preferences, but rather document current usage. On the other hand I don't like to add things I consider harmful. Either because they water down the meaning of established tags or because the documentation is so poor it leads to multiple interpretations.
The issue with signs 237-241 is highly political and there have been numerous long discussions on the topic. Basically I see the following fractions: (a) Why can't we simply use highway=cycleway? It is short and simple. (b) *=designated is clear enough, no need for yet another variant. (c) *=official is needed to solves a fundamental inconsistency problem.
The arguments I heard against *=official are:
  • It is a one man project by User:Nop and is not widely used.
    • True, although it has its supporters.
  • It does not solve the problem but pushes it to the next level.
    • I don't think this is true. The tag is properly documented and will not be used for other things than officially designated ways.
  • "I generally don't like highway=path & foot=* & bicycle=* combination, because ..."
    • Sad, but we also gain from the additional complexity.
  • Yet another variant for basically the same thing, which can be annoying for mappers and software developers.
    • True.
So from my point of view the advantages outweigh the problems and I'd prefer to keep it as default. But probably, it would be a good idea to mention it on the relevant wiki pages. (However I don't think I'm tactful enough to do these changes :) ) --Bk 09:38, 26 June 2010 (UTC)

Now 6 years later, is it the right for reconsideration? I started a push to deprecated *=official.--Jojo4u (talk) 13:20, 1 October 2016 (UTC)

Tags would be different depending on whether they are applied to isolated node or way they influence


While translating the file to reflect the situation in Belgium, there is something I'm missing. Maybe this is because previously we weren't tagging the actual signs, but only the effect they have on the ways.

I think the plugin should behave differently when an isolated node is selected, than when a node on the way or the way itself is selected. Ideally, it should do the right thing if a combination of such node (for the sign itself) and the way are selected.

This means that the XML file should support different tags for the nodes of the traffic sign itself and for the way it affects. --Polyglot (talk) 08:30, 31 January 2015 (UTC)

Yes, tagging actual signs as nodes is not supported by the plugin at the moment. (I wasn't aware this is a thing now...) --Bk (talk) 08:40, 31 January 2015 (UTC)
It may not be, I was experimenting with your plugin and the one of Scoutsigns. For mapping the effect of a sign on the way next to it, I don't really need a plugin. I know most of those tags by heart, by now. For adding the nodes with the codes as they are used in Belgium, that is another matter. That's where I need the help of a plugin.
Do you think it would be possible to extend the xml format and the code to support setting the proper tags depending on whether the selected object is an unconnected node, or a part of a way?
I started on the conversion in this file
If you like, I can give you an example of how I would extend the XML format.--Polyglot (talk) 21:51, 31 January 2015 (UTC)
The JOSM trac page would be a better place to discuss this enhancement request. Why do you need to extend the XML format? Anyway, I don't see this as a priority, but patches are welcome. --Bk (talk) 07:40, 1 February 2015 (UTC)
I'll move over to TRAC soon ː-) I'll try to experiment a bit with extending your plugin. I need the practice anyway, I'd like to create plugin to integrate Mapillary in our workflow. I created an example of a possible way to extend the xml schemaː --Polyglot (talk) 13:14, 1 February 2015 (UTC)
After another succesful GSoC project (pt_assistant and mapillary went before) I'm considering to propose improvements to this plugin for next summer. It would only be part of it, pt_assistant would also be extended so it works for bicycle and foot routes as well. There are some other things I'd like a student to work on, like the wikipedia plugin, but I'll write a proper proposal in a few months.
For this plugin, I'd like to have the possibility to add both a traffic sign node, or tags on such existing node and its consequences on the ways, nodes and sometimes relations it applies to.
So the country specific code would go on the node for the traffic sign (pole/fixture). Its implications will usually be applied to one or more ways, sometimes a node (crossing, traffic_calming) and sometimes a relation (turn_restrictions for example).
It shouldn't be too hard to determine automatically which primitives in a selection would be the traffic sign and which would be the other OSM data.
Let me know if you see problems with extending the plugin in that direction, --Polyglot (talk) 06:30, 2 October 2016 (UTC)