It is the same code for preset and style too, there are identical.
We can find it and we can do it. It is a complex topic but I don’t want to heard to avoid mapping anything because is too complicated, when we have 3D building with indoor mapping.
I’m a teacher, I’m not a programmer. I can do that so so on JOSM or Mapcomplete but I don’t know who do that in iD or others. Without help is not possible for me and it is interesting that the basics can be done whoever who maps that with the tool they have chosen.
In my city one university teacher used OSM in his Accessibility class. The result was a set of keys and values in Spanish and Catalan from 20 newbie users spread all the city. We had two meetings with him to “teach” a little bit how it works OSM. These things happen.
But now we have Mapcomplete or similar to fix that. My father would have not any problem to identify Spanish Give Way if he had to do that. He does not speak English but Mapcomplete and the quest can be translated.
I do not. I have discovered I’m faster creating nodes rather than importing it. I do it at the same speed due to map is so plenty than you cannot upload anything automatically (if you won’t dupes, for example). Also you need to download the zone or the point you need to modify, to avoid put something layer after layer as a cake. Overpass-turbo is a great thing to do that topically.
Can you help me understand the alternative? The documentation for this key mentions a mailing list thread (continued) where it was pointed out that a subkey couldn’t serve as a primary feature key. That makes sense – sometimes mappers have used highway:forward, highway:backward, and highway:lanes in desperation, but not with any realistic expectation that it could be consumed correctly. The mailing list thread went off on a few tangents, but I see just as much aversion to the :2 scheme there as to traffic_signals:direction.
Anyhow, with the benefit of hindsight, would you contend that iD should’ve gone with traffic_sign:forward and traffic_sign:backward instead of traffic_sign, or that it should’ve tagged direction instead of traffic_sign:direction? Does your proposal cover both traffic sign nodes along the roadway and independent nodes at the physical sign locations? Does it apply to road markings and traffic signals that are codified in the applicable sign standard?
Probably major part is mine, not totally. Yes , more of those are changes of tags between subkeys for direction and direction itself, for example. Give way in a segregate way of a roundabout will be always forward, things like that. You check it, and go on. I can stay days before I upload the data. Then, when I don’t have free time sometime I can upload in pieces while I’m do other no pc stuff. I can forget someone to check between these processes but it is not my intention. In Maproulette I spend 5 minutes, In JOSM I spend seconds (it’s good? Check) , with PNOA imagery 1:5000. I like to work with big zoom. I’m only working with few kind of traffic sign per editor wave and I have try not to mix, to go faster. I have started some months ago. I’m saving lot of time not uploading every change as Maproulette does.
Oh, so we will have to leave the use of name:xx if makes that problems.
The real problem is not the use of traffic_sign:direction (I would use direction because in a traffic_sign you can use it in a similar way,but OK), the “problem” is the lack of consensus in this idea. This is the last message of the discussion [Tagging] Traffic sign direction tagging.. It is not my intention to summarize every message of that topic to reflect after 2 months of mails there is no approval consensus for traffic_sign:direction.
But then you request me all the perfect consensus about an existing tag.
If my memory serves me righ :forward and :backward created/are more used/you could find in the wiki by the German Community. I have try to adopt it because you save one tag in any traffic sign with same information (not bad idea),and also because I want no one have problem using the tools I have created specially traffic sign preset DE by one of the most powerful community in OSM.
My surprise is that you cannot map for the render…but you can map for iD .Traffic sign is a serious thing, and if you mess with national id’s is complex, as hydrants,etc. So probably, if iD have problems to handle this, like bus route relations, probably your best option is JOSM, not iD to edit that. You don’t have any problem to inverse ways with JOSM…but yes with iD. iD can only work with a value and not with a key with subkey? OK. Make better iD. Should we do another tag to make working iD? Make traffic_sign:direction .
What does it win with that? Anything. You have to make one more key , not direction but traffic_sign:direction (to make the same effect as traffic_signals:direction) OK, you win , iD. (pa’ ti la perra gorda, iD).
My proposal was made after these kind of discussions through years and years and without arriving far away than traffic sign in the highway, using Finnish system to the positions, with some modification and using German system to the directions, because I wanted an agreement with all. And in OSM this is very difficult, but not impossible. Independent nodes can be tagged with traffic_sign…with direction point to cardinal points (one of the possible uses of direction)
In many countries road markings have their own national id so it is easy to use it in ways and areas too (people from Dutch community preferred tagging traffic signs as a way, I’m not agree with that…but I will not avoid any way of mapping traffic signs if they consider it). To map these kind of traffic signs you have the tag side with the values up and down. The scheme is so wide to fit in all OSM, from Nepal to Australia, from Portugal to Ukraine, from South Africa to Japan.
Each community will know how to do their own traffic signs, also we can help it.
The problem is not that you used something like overpass, but how you used it.
At a speed at wich you are able to check every object for corectness. So many that they are in the same area - georafically and thematically.
I never said that any of your edits are incorrect. I just said that we should discuss such mass edits before doing them. It is possible that your proposal gets approved. After that, it is possible that you can find consensus on a mass edit. And maybe that mass edit is exactly what you already did, but maybe it is not.
If a tag gets used thousands of times from a lot of different, independent people, then there is some kind of consensus - otherwise this tagging scheme would not have evolved. If I see it right you took about 25000 objects tagged in one way and changed it to a different tagging style. I don’t know how many different people added the objects you edited. Probably Hundrets, maybe thousands of people decided to use one tagging style. And one person (you) decided that ther is a better way.
Of course, I have started in Catalonia and follow roads and cities linked until I will travel around the country. And as I explained here I have only modify in JOSM one kind of item, adding missing direction and assuring the tags in use are in it.
If we are talking about the leader of editors for OSM we need only to add this “feature” to the system et voilà: crossing=marked, traffic_sign:direction and whatever you want (they want to put inside the presets) used “de facto”.
Who decides which preset in which way should work in iD ?
No, I’m only add the information it lacks. It’s like when you upgrade a ptv1 to ptv2. Or when you take Osmose and fix all errors of same kind. My intention is maintain all the information and not loose or change anything. With traffic:id or something like that. What about your proposals in this question?
About direction topic my favorite option were :forward (65389) :backward (48985). We’ve lost. And traffic_sign:direction is 53030. We have a winner. Direction has 283122 items, at first sight. I’m doing in majority way. In my land. In my country.
This is a false equivalence. A primary feature key or tag answers the question, “What is it?” A name tag never does, which is why all the major validators flag elements that have names without primary feature tags. “What is it?” is an important question. In any editor other than JOSM, the user selects a feature and the editor indicates which preset (feature type) it is, hiding the raw tags by default. The idea of a primary feature key or tag goes well beyond the editor. There are references to this concept all over the wiki, and the OSMF’s interpretation of the ODbL even depends on it.
traffic_sign=* is used by itself, rather than to refine some other top-level feature tag like highway=traffic_sign, so traffic_sign:forward and traffic_sign:backward amount to saying: this OSM element corresponds to two things in reality. Personally I think it runs counter to the “One feature, one element” principle. But most likely its proponents are OK with that contradiction because traffic signs tend to be flat and upright, meaning they can occupy almost exactly the same physical space when seen from above. Moreover, some mappers aren’t even mapping them in their physical locations to begin with, instead preferring to place them at a theoretical point along the roadway.
Here’s where it gets interesting. The most common combination of traffic signs in the U.S. and Canada, by far, includes signs pointing in four directions simultaneously, affecting two different streets:
How would you propose to model this assembly at the physical location? As multiple nodes, each with a different direction tag? Or a single node with traffic_sign:direction, traffic_sign:2:direction, and traffic_sign:3:direction? (Let’s let bygones be bygones?)
I map these R1-1+D3-1 assemblies very frequently in order to clarify a situation where a street name is signposted inconsistently and an armchair mapper is likely to overwrite the street’s name with the less common value based on an external source. It isn’t possible to tag this assembly on the affected roadway. The stop sign affects one street at the stop line, but the street name signs affect both streets at the intersection node, which might be as much as 20 meters away.
Probably the second most common sign assembly in any U.S. city would involve parking signs. Most parking signs are positioned at the curb but angled 45 to 90 degrees to face the centerline of the street. Both the arrows in this example apply to the same side of the street, traveling in the same direction, but one applies before the sign and the other applies after the sign:
Signs like these cannot be mapped on the roadway without losing information. Maybe we can reuse your proposed side key to indicate the arrows’ directions?
Perhaps not, but by the same token, there clearly isn’t a consensus yet for traffic_sign:2:id and whatnot. It’s unfortunate, because I agree with the part of your proposal that would eliminate the complex syntax with brackets and such. I can’t predict what would happen if you were to take your proposal to a vote, but some compromise is always a part of that process.
On the other hand, if your intention is to fragment the tagging so that a national community can unilaterally decide on a different tagging scheme, then your proposal, presets, etc. should reflect that. And maybe I’ll get to work on a U.S.-centric proposal that uses layers due to these stop sign–street name combinations.
I agree that a single editor’s arbitrary limitations shouldn’t necessarily constrain OSM tagging. However, sometimes an editor’s limitations expose a potential usability issue. Editors that use id-tagging-schema (including but not limited to iD) place presets front and center and hide the complexities of raw tags from the user by default.
As an engineer by training, I know that of course it would be possible for iD to introduce a UI for traffic signs similar to what you’ve implemented for JOSM, but this would come with some tradeoffs. One of those tradeoffs is a messier UI that misses some opportunities for bringing more mappers into traffic sign mapping.
If you prefer the raw tags or a repetitive 1-2-3 form, by all means, use JOSM. But the default editor for OSM is not a Web-based clone of JOSM’s UI because that would hamper the project’s adoption. If you think traffic sign mapping should be limited to the elite experts who know their way around JOSM, I must disagree with you. Ordinary mappers like me map traffic signs in iD, and it’s thanks to us that coverage is not limited to the places where there are external datasets and tech-savvy mappers.
Not responding to the above, I do find traffic_sign= weird as a feature. (Even if there is a highway=traffic_sign feature for it, it has to solve the conflict in physical standalone point vs functional point on the highway= road line, similarly encountered in =speed_camera ) Cf traffic_calming= is a feature too, but this causes problem when a device is only installed on a direction or certain lanes. The mitigating factor in traffic_sign= is it can be drawn at its physical position, perhaps including back-to-back signs by offsetting them slightly to precisely the plate itself from the pole. Ultimately, the issue is still unavoidable for vertical superposition, though OSM can be said as bad in 3D in general.
To be fair, features normally should not have multivals either. The usage in shop= , and office, is an outlier. But this is done in traffic_sign= extensively, with both semicolon or comma delimiting different or supplementary plates. Worse, freeform text is added to the mix in square brackets. It’s a mess.
To clarify my view, moving the country prefix in vals to keys suffix is a optional personal ideal. I would aim to not touch traffic_sign= at least in a transition period if any change is accepted.
As traffic signs affect one specific way you need two nodes, each with its direction. One should be on the road with the US:R1-1 and other with D3-1. Forward or backward depends on the way it is. If you choose mapping in the place, and not on the road that affects , two nodes , one next to another would be a good option also. Probably render is not exactly the same as reality but it has the same effect.
Like you have in some big cities of Europe, but saving signs. Here you have Barcelona street signs
Or ref in a highway Mapillary cookie policy use . Probably you have the same sign on the other side of the road, so you will have two signs and, as the reality , in the map would keep it clear in which way are you (like city_limit).
It’s easier than that. For example in Spain we have lots of these, combined with other secondary signs
Also these can be combined to forward or backward even if they are located on the wall. As yours. Every traffic sign has its code and its second traffic sign with the conditions. I think it is better use side to signs attached to a way and direction to refer the direction it is. If the direction is 90 degrees or 45 you can put in the tag.
Can be complicated because to fit in every country scheme has to be adaptable but here it is , more or less my proposal for these two nodes.
node 1
traffic_sign=information
traffic_sign:id=US:R7-1
information=parking
direction=90
side=right
(new tag to MUTCD, here in Spain we have one code to left, and one code to right) applies=right
node 2
traffic_sign=information
traffic_sign:id=US:R7-21
information=parking
direction=90
side=right
(use the same tag scheme to conditional parking to reflect what it says the traffic sign)
parking:right:maxstay:conditional=8 hour @ (Mo-Sa 08:00-16:00;PH off)
applies=left
OK, you can use US:R7-200 but it will be more difficult to define all the parameters. And the use is the same.
With an agreement everything is possible but side should be for the nodes on the way to reference the position to this.
It is difficult to pass anything if the start of a message for a teacher is “pointed me to a seven year old, never finished proposal by him”. My proposal would not have any possibility. It is better working with a draft than with a rejected with objections proposal.
I think my proposal and the system should be in OSM should be worldwide and more or less it has to be the same. But inside the system you can adapt whenever you need, whatever you want. When you have the position for the plate, the code for the plate, the human readable value for the plate (it’s type, minimum) you can write in this sign whatever you need, because in OSM we are able to define anything with more or less difficulty.
It would be interesting to make a MUTCD way to tag , and preset and style that respect the general scheme and can be adapted to the reality of the land, as crossing=unmarked does, for example (in my country all crossings are uncontrolled minimum, if you want to consider crossing, in others traffic law say you can cross 10 meters after turn the street)
In my proposal you have a nationals code option but also you can use human readable values. Nowadays it is not a problem to map traffic signs about conditions of the way, hazards should be? information should be? complementary should be?
Probably MUTCD has lots of codes than Vienna convention simplifies in second position/layer traffic sign…but are the same, the meaning are the same and their use if applicable are the same. In 40 different presets I have found more or less same kind of traffic law conditions (maxspeed, avoid turns, wrong way…) with similar codes (it is why for me was possible to do that presets)
I’m totally agree with you in that. Traffic signs will be massive so someone has to be able to add it and to edit it in the map. But there is solutions that can be in the middle between iD or JOSM. What about Mapcomplete? What about Deriviste? What about Mapillary or Karta View collaboration software? Tagging scheme should work also in it.
For this reason traffic_sign:id should exist, one mapper can edit the human readable value and other can add the national code. I will not mess which one maps better, it is not the aim for spread traffic signs all over the world, it has to be affordable.
Why can reproduce Mapillary’s traffic sign game with real situation at the street? And all for OSM.
I’m not agree with you, you can use direction key or lanes key to locate that without problems.
Because the use of tagging is not correct. Why can’t you use in the node maxspeed= to show the speed of ES:R301 or DE:274 ? Why can’t you use traffic_sign:2=FR:M6c or traffic_sign:2=FI:H2.1 and the information you have inside the sign in its key (the same you will put along the way)?
To be honest, I stopped reading this discussion at some point. But I like the idea to just finish the proposal and let people vote on it as described in the Proposal process. If the proposal gets accepted in the next few weeks and is completely matching the automated edit, I could accept that. If the proposal gets not accepted soon or the automated edits are not matching the proposal, the mass edit should get reverted. And every possible future automated edit should get discussed before the edit as described in the Automated Edits code of conduct.
The example I gave has three signs. Two of them are double-sided and serve all the incoming streets, because they’re posted on only one corner. I would map it as three nodes at the same position, separated by layer, but if they aren’t centered over each other, then I might nudge them a small distance apart. In general, we haven’t solved the problem of how to render multiple unrelated things hanging off a vertical pole in 3D, so I haven’t been worrying very much about it.
Usually the street name signs are only posted in one corner. Sometimes these signs do even more work: this single double-sided street name sign is typical in New Orleans. It sits in the middle of a traffic island, serving two inbound streets and four inbound sidewalks in four adjacent intersections. This doesn’t account for the fact that people sometimes need to look sideways at a street name sign to confirm the street they’re on. Pedestrians in New Orleans must have very good eyesight!
By the way, when you map a sign as a standalone node in iD, the Direction field sets direction, not traffic_sign:direction, since there isn’t the potential for ambiguity between a traffic_sign and a highway=stop or highway=traffic_signals in the same location. In the U.S., direction is being tagged on traffic signs 12 times more often than traffic_sign:direction, so either your JOSM presets have been a smashing success here, or we have a very strong unspoken consensus to map the signs at their physical locations.
I’m looking forward to seeing your proposal develop further. There are other aspects that may need to be internationalized a bit, but I’ll save that for a separate RfC thread.
Result of doing this kind of thing vastly increases risk of edit conflict and results in you edit looking exactly like a bot edit.
Why not save edits daily? If you were editing it manually over months then mass upload like this does not help with anything. I am really curious what is benefit of doing it this way.
(and yes, you edit looks exactly like mass edit done without actual review of each situation - based on my experience with making such edits you need at least 5-10 second per object to actually look at data, review+edit process can be clustered but clusters of several thousand objects are extremely weird)
Basically I save time, lot of time and I can use lost times. Nowadays I’m a newbie father, so I don’t have time to lose. Let’s see a comparative of times with Maproulette.
Actions I have to do with every result of Maproulette
Click on start (I don’t talk anything about prepare a mission in Maproulette, spending lot of time)
Loads RapiD
See the point
Click on tags
Check it
Click on more
Write direction (with suggestions)
Write forward/backward (with suggestion) if it is missing
Write highway=give_way if it is missing
Write traffic_sign:id=ES:R1 if it is missing
Click on save
Check changeset sentence
Click on upload
Click on fixed it
Click on send
(1 or 2 minutes each)
All I do I have to do it sequentially, I cannot reorder steps. One by one . As my new personal situation make when I went in front of the screen probably I will not remember edited before, nor the tags, etc, I have to re read, sometimes.
My way, with JOSM
Download traffic_sign=ES:R1 without direction (via Download Overpass in JOSM) for all Spain (2 minutes - 1 time in October I did it , I think.)
-Load Imagery PNOA Spain
-Select all items nodes
-Force highway=give_way
-Search traffic_sign=ES:R1
-Add :id to traffic_sign key
(To do forward) (fractions of the day ,10-15 minutes, when I have some good quality free time, then pc hibernate)
-Use to_do list plugin.Zoom the item
-Check which direction is the way.All correct
-(only forwards) paste tag direction=forward
-Next. Sometimes 350 items, sometimes 150. When I’m tired or my free time is finished, hibernate
(To do backward) (fractions of the day,10-15 minutes when I have some good quality free time, then pc hibernate)
-Use to_do list plugin
-Check which direction is the way.All correct
-(only backwards) paste tag direction=backward
-Next. Sometimes 350 items, sometimes 150. When I’m tired or my free time is finished, hibernate
(1 minute to execute…? minutes or hours or days to return in front of the pc to see the result)
-Upload clusters of items I have finished. I can upload yesterday and today’s, next to the river, of one city,along one road…whatever. This task uses my loose time (while I’m cooking, before changing diapers,while breakfast, pub tv time, doing popcorn for the movie… I click upload that and leave pc alone…)
-If there are any conflict. Update all data set and list to re do with to do plugin (some day I will re do it).
If not, purge. (10 seconds)
If you put together all my effective working time, What time I can spend by item… 1 or 2 seconds?
And that’s it. My fault: Be too efficient? Optimize the process to save 25000 downloads one by one? Be organized and methodical to upload? Revert if you want, but my work is not mechanic…is as is.
