Proposal talk:Traffic signals set 2

Label

Mappers should not be expected (or allowed) to manually place labels. And different renderers need different label placement anyway Mateusz Konieczny (talk) 20:46, 13 February 2021 (UTC)

Along the same lines: what should be rendered how, is not data for the database about the real world, it is metainformation and whether traffic lights are rendered, and if yes, how it is done, is a decision of the rendering style sheet maintainer, not the mapper. As it is no geoinformation, it is also not verifiable in any way. --Dieterdreist (talk) 21:52, 13 February 2021 (UTC)

Though objective informance useful for guessing importance is mappable Mateusz Konieczny (talk) 23:03, 13 February 2021 (UTC)

I agree this is a proposal intended for rendering purposes. Not for data or data improvement. You should contact the rendering engine to request for rendering issues or proposals.

I do not agree with the remark that mappers should not be allowed to manually place labels. Renderer information where to place a label in some cases can be considered as data to where "the functional centre" of a topic should be located. One good example is where an administrative boundary is mapped but the actual label is placed "in the middle" where f.i. boundaries at shore lines, which extend far f.i. into a lake, would the name of the village be rendered somewhere in the middle of the lake. Not good. A label as defined in OSM should be considered in these cases as a data point to indicate where the "functional centre point" is to name the feature, something which is hard, maybe even impossible by a rendering engine to determine. But that is the only case to my knowledge where rendering related data is accepted in the OSM database.
To rostaman (on osm, edits, contrib, heatmap, chngset com.): good try and a lot of work and effort but not at the right place here.
If you target OSMcarto rendering, make a request at https://github.com/gravitystorm/openstreetmap-carto/issues, and above all don't be discouraged, keep on mapping and make proposals for improving OSM data.
Bert Araali (talk) 01:33, 14 February 2021 (UTC)

File:Traffic lights printed map example.jpg

How a map making use of traffic light placement could look

Yes I think the wording came out wrong, I didn't mean that this has to be rendered. Obviously e.g. OSM.org doesn't render pedestrian traffic lights and I didn't mean to pass a rule to force it to render them. I intended to help a renderer, if they choose to display a map with detailed-mapped traffic lights (at stop lines) merged into the intersection point (as I think they might choose to do on a medium zoom level), to position the icon accurately.

I don't know if any OSM data users bother to do that style of t.l. icon rendering at the moment - I doubt since it would entail some fallible heuristics/guesswork, especially on complex intersections - but there are print maps that do this. Hence I imagine map apps would render this if it could be done w/o heuristics. I have scanned a small segment of a print map as an example (please don't copy and upload elsewhere since the map is copyrighted). Rostaman (talk) 03:12, 14 February 2021 (UTC)

How this came to be: I was planning to propose a relation grouping traffic signals for routing purposes (long before I became aware of the earlier proposal), and also to suggest to an OSM data user to do the low-zoom t.l. icon rendering I described here. I then thought about it and realized that, even with traffic signal set data, choosing where to place the icons is a non-trivial job. However it's already performed by anyone mapping with the "tag all crossings method" here. This just lets mappers map both the "tag all crossings" and the "tag incoming ways" information for the same intersection, and lets the renderer choose. Rostaman (talk) 03:32, 14 February 2021 (UTC)

Regarding labels, I don't have a strong opinion on whether the placement should be specified. The earlier proposal used this, so I presumed it would be wanted. Rostaman (talk) 03:12, 14 February 2021 (UTC)

Stop signs

highway=stop is similar to highway=traffic_signals in that some people map it at stop lines while others map it at intersection nodes. From a mappers' point of view, highway=stop is just an unsignalized version of highway=traffic_signals, so the same arguments for grouping traffic light nodes in a relation would apply to stop sign nodes as well. Such a relation would help with ambiguity that could arise because some intersections between dual carriageways are actually four distinct intersections [1], while others only have four intersection nodes for mapping convenience. – Minh Nguyễn ^💬 23:20, 21 February 2021 (UTC)

@Minh Nguyen: Thank you for this idea, I didn't know there was a practice of mapping stop signs at intersection nodes. I agree that we can expand this relation to include stop-sign sets too. But it might be better to come up with a different name for the relation, since I think stop signs are usually classed under "traffic signals". Maybe something like type=intersection_signage_set? I don't know the correct term for this in English, can you help? Rostaman (talk) 12:31, 11 March 2021 (UTC)

@Rostaman: At least in American traffic engineering jargon, traffic signals, stop signs, and yield signs would all be considered traffic control devices for intersections. ("Traffic control device" is a very broad term encompassing any traffic sign or signal, but these are devices for intersections specifically.) If we're OK with coining neologisms, type=junction_control would recall both Proposed features/Junction and crossing=uncontrolled, but I don't know how recognizable it would be to non–American English speakers. – Minh Nguyễn ^💬 05:48, 16 March 2021 (UTC)

Note 3 years later as I come across here now when investigating route=junction Talk:Tag:junction=roundabout#On a relation : In UK, "method of control" is specifically used in the context of signal timing. In contrast, I would like to mention the US term "intersection control", as used in Intersection Control Evaluation, and Intersection Control Beacon. However, I don't find it or type=junction_control ideal for signalized mid-block crosswalks, or tram crossings.
Besides, type=junction has more about the physical layout. Proposal:Highway=junction area also needs to be considered. That's being partially advanced slowly by the junction=intersection attribute on highway=* roadways.
I have thought simply type=site can be used (similar to site=parking ), with an appropriate site=* or highway=* feature. No need to invent another type=* if you are only grouping them together as a whole, unless you are detailing more complicated functional relationships requiring specific roles and orders (eg Proposal:Traffic Signal Timings , cf restriction:bicycle=* , Proposal_talk:Wait#Except_when_turning_right ; also similar to type=enforcement , for which traffic light perhaps man_made=traffic_signals correspond to which stopping line, as bad as what Proposal:Relation:intersection attempted)
perimeter could be assigned to highway=junction + landuse=highway (that's how I would split them) , as area:highway=* intersection area is further smaller inside. label can be any suitable point.
—— Kovposch (talk) 08:29, 5 August 2024 (UTC)

Yielding to bikes

>A road user passing through a set of signals which are members of the same relation can always expect to have to stop at most once (if he/she encounters a red light at the beginning of the intersection), not counting yielding to pedestrians while turning.

In France at least, most of the time when bike crossings are next to pedestrian crossing, they have either the same signal or synchronized signals. I would generalize the end of the citation to "pedestrian and similar traffic" (bicycles for example).

Yes, that's true here too (in Croatia), I expect this is the practice in most western countries. I've amended the sentence, thank you for pointing this out. Rostaman (talk) 12:21, 11 March 2021 (UTC)