Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

render the name of crossroads #374

Closed
sommerluk opened this Issue Mar 2, 2014 · 58 comments

Comments

Projects
None yet
8 participants
Collaborator

sommerluk commented Mar 2, 2014

In some countries it is important to see the name of crossroads in the map. This has been discutated for OSM for Japan and Korea here and there.

For Ivory Coast, this is also important. Here, most streets don’t have a name. The people orient themself with the name of the crossroads.

Following http://wiki.openstreetmap.org/wiki/Key:junction you can use “junction=yes” together with “name=foobar”. So, foobar should be rendered somehow.

Collaborator

sommerluk commented Mar 27, 2014

To be a little bit more detailed:

Crossroad names help to orient yourself in the local aerea. In my humble opinion the should be rendert starting with the same zoom level when “residential” highways are rendered with names.

Collaborator

sommerluk commented Mar 27, 2014

There is also a mapnik bug for this – I’m not sure where is the right place …

See trac at openstreetmap (ticket 4794). There is also an example image showing how Google Maps renders crossroad names.

http://trac.openstreetmap.org/ticket/4794
http://trac.openstreetmap.org/attachment/ticket/4794/crossroad.jpg

Collaborator

math1985 commented Mar 27, 2014

@sommerluk The right place to report bugs now is here on github. We are outfasing trac - we will still handle old issues on trac (we didn't get to migrating them yet), but new issues should be reported here.

Contributor

Rovastar commented Mar 27, 2014

I believe the french osm tile server does this.

http://layers.openstreetmap.fr/

Is that like what you want?

It has been discussed before buT I cannot find any discussion here and I thought GravityStorm did something with it for our style but maybe it was just discussed.

Collaborator

sommerluk commented Apr 6, 2014

@Rovastar On http://layers.openstreetmap.fr/ I can not find the crossroad names. An example could be http://www.openstreetmap.org/?mlat=5.30979&mlon=-4.10425#map=19/5.30979/-4.10425 which is a crossroad with a name. The name does not show up.

Maybe a solution similar the the solution of Google Maps would be fine: Render the crossroad names with a rectangle around them. See http://trac.openstreetmap.org/attachment/ticket/4794/crossroad.jpg to get an idea.

Crossroad names rendring should be no problem wordwide:

– Most countries do not use crossroad names. So there would be nothing tagged as junction=yes and nothing would show up, so everything stays as it is.

– These countries who use crossroad names would get a map that is much more useful.

@math1985 math1985 added the roads label Apr 14, 2014

Collaborator

sommerluk commented Apr 30, 2014

Google renders is this way, giving the crossroad names another color than the street names:

screen1

Bing does it this way – I would prefer the Bing style:

screen2

Collaborator

math1985 commented Jun 3, 2014

The simplest way to accomplish this would be to use the style we already use for highway junctions.

I created an example on math1985:crossroad-names.

Would someone be able to render this in an area with many names junctions, and post an example image?

Collaborator

pnorman commented Jun 3, 2014

Would someone be able to render this in an area with many names junctions, and post an example image?

What's such an area?

Collaborator

math1985 commented Jun 3, 2014

I'm not sure myself. Wasn't iy the Japanese who needed this the most?

Collaborator

pnorman commented Jun 3, 2014

Japan is too big. I just added Tokyo.

pnorman added a commit to osm-ca/mapproxy-config-faramir that referenced this issue Jun 3, 2014

Collaborator

pnorman commented Jun 3, 2014

Added as http://{s}.tile.paulnorman.ca/crossroad-names/{Z}/{X}/{Y}.png, but some font issue is going on, which is an issue in Japan.

Collaborator

math1985 commented Jun 3, 2014

Hmm, I can't find any instances in Tokyo. Do the Japanese mappers use a different tag, or is crossroad tagging not popular in Japan?

Collaborator

sommerluk commented Jun 3, 2014

Following http://taginfo.openstreetmap.org/tags/junction=yes#map it is more used in Korea than in Japan.

Try the region around 37.4812146, 126.8051383 There are some nodes with junction=yes combined with a “name” key.

hlaw commented Jun 4, 2014

For an area with junction names in Japan, see Hiroshima, where the city is mapped in detail. Junction names here are tagged with highway=traffic_signal nodes, without junction tags.
http://www.openstreetmap.org/#map=18/34.39495/132.47392

2014-06-04 10:27 GMT+02:00 hlaw notifications@github.com:

For an area with junction names in Japan, see Hiroshima, where the city is
mapped in detail. Junction names here are tagged with
highway=traffic_signal nodes, without junction tags.
http://www.openstreetmap.org/#map=18/34.39495/132.47392

if the name is the one of the junction and not the one of the traffic
lights, then the tagging should be changed IMHO, also because there will
probably be junctions without traffic lights as well.

Collaborator

sommerluk commented Jun 4, 2014

if the name is the one of the junction and not the one of the traffic lights, then the tagging should be changed IMHO, also because there will probably be junctions without traffic lights as well.

+1

junction=yes is documented on the wiki and it is also yet used. We should render this tag correctly and correct wrong tagging in the database.

(And yes, at least in Ivory Coast most crossroads doesn’t have any traffic signals.)

hlaw commented Jun 4, 2014

This may be the name for both in Japan - this is how junction names are displayed on the ground -
http://www.superstock.com/stock-photos-images/4034-118941

(Google map: https://maps.google.com.hk/maps?ll=35.676498,139.746845&z=17)

The co-occurrence of junction names with traffic lights in Japan is so common that most maps (with the exception of Bing) seem to position the junction labels as labels of traffic lights such that the two would not collide. An example is shown in the Google map captured above. Another example from a Japan map provider: http://www.mapion.co.jp/m/35.67337373375727_139.76773758421916_9/

In Bing, junction names are rendered at the middle of the junction, and the traffic lights there are not rendered due to collision.

As traffic lights are rendered in the standard OSM layer, this might need to be taken care of in positioning the label (assuming junction=yes are added to these traffic_light nodes).

@pnorman pnorman referenced this issue in mapzen/metroextractor-cities Jun 5, 2014

Closed

Add Hiroshima #14

Collaborator

sommerluk commented Jun 5, 2014

@hlaw

Okay, I understand. The problem is the collision.

To stay nevertheless with a clear tagging scheme, I would propose

1.) highway=traffic_signals
--> Meaning: Here is a traffic signal.
--> Rendering: traffic signal symbol (without any name / the name key(s) are ignored)

2.) junction=yes
--> Meaning: Here is a junction of roads AND this place has a name.
--> Rendering: The name (taken from the name key(s))

These two possibilities can be used seperately or together. If they are used together, it is rendered with both the traffic signal symbol AND the name.

Reason: This way we have a clear and simple meaning for each of these two key-value-combinations and a clear rendering.

(For Japan we would have to add junction=yes to the corresponding nodes. In Korea this thems to be done yet.)

Collaborator

sommerluk commented Jun 5, 2014

About the visual appearance: I think the idea to base this on the existing style for highway junctions (I suppose this means "motorway junctions") is fine.

Google Maps draws a border around the name (and the traffic signal symbol), but I think this is too heavy and to conspicuous.

hlaw commented Jun 5, 2014

In Japan the junction names are indeed more important than road names for orientation. The rendering gives precedence to junction names when they collide with road names.

While I agree that it would be more tidy to require the use of the junction tag for the junction name rather than rendering for the existing tagging, I am not part of the mapping community in Japan (though being there from time to time). I am trying to invite them through the ja mailing list to give their views.

Collaborator

math1985 commented Jun 5, 2014

As said, junction=yes is the established tag. I suspect that if we implement rendering junction=yes, the Japanese community will be quick to add the missing tags.

Should we tag junction=roundabout in the same way? In most cases, the roundabout name will not fit in the way.

hlaw commented Jun 5, 2014

Back link to osm talk-ja list for reference -
https://lists.openstreetmap.org/pipermail/talk-ja/2014-June/008281.html

As junction=roundabout is used to tag an OSM way, the name may well be that of the road rather than the roundabout. Rendering it as the name of the roundabout may not be correct.

e.g. http://www.openstreetmap.org/way/252489266#map=19/22.30837/114.26377

Some "intelligence" in distinguishing what the name refers to might be needed (say by comparison with neighbouring road names), which may be a bit beyond the present scope?

Another complication is that in areas where route relations (bus routes etc) are mapped, or say where part of the roundabout is a bridge, the roundabout would be cut into several segments. This might again require some preprocessing to group the segments for correct treatment of the junction name. (A similar problem exists for the traffic lights / junctions when double carriage ways are mapped and junction names are given to every crossing node in the junction, but they are close to each others and are more likely to collide and result in a single label).

Collaborator

sommerluk commented Jun 5, 2014

Hm, maybe we can do the following:

The key “junction” is only rendered when it is applied to nodes. When it is applied to ways, aereas or relations it will not be rendered at all.

Explication:

This would mean that we can still tag ways with junction=roundabout and highway=* and optionally name=* and get the expected behaviour (= a road is rendered, optionally with its name). The name is the name of the circle road itself.

When we want to mark the name of the roundabout in terms of a junction of roads which has a name, we can create use a single (unconnected) node in the center of the roundabout.

So, the community has still the possibility to choose if the want to represent the name of the circle road or the name of the junction.

A road name has always the same visual appearance (when used on a way with highway=* and name=, but also when used with junction=roundabout and highway= and name=*).

A junction name has always the same visual appearance (when used on a node with junction=yes and name=*.

If we render the junction name only when it is applied on a node (and never when it is applied on a way), we could maybe even render it for all values of the key “junction” (not only for the values “yes” and “roundabout”)?

Contributor

Rovastar commented Jun 6, 2014

Here is one discussion On this last year.
http://gis.19327.n5.nabble.com/Display-names-of-crossroads-td5749239.html some here were involved.
I am sure there was another where they mention that Christian did a mock up for the osm French site. I might hunt it down if it exists.

Collaborator

pnorman commented Jun 6, 2014

http://bl.ocks.org/pnorman/raw/f748047317ceca699212/#14.00/37.5039/-233.2401

I'm not convinced about the styling. We're also getting line breaks on place names, but not these. A lot of the place names in the region are not the place name in the local language, but a strange combination of names that ends up being quite long.

Collaborator

sommerluk commented Jun 6, 2014

A lot of the place names in the region are not the place name in the local language, but a strange combination of names that ends up being quite long.

Yes, but I would say that this is problem of the tagging. The tagging should use “name” for the original name and “name:en” for the english transliteration, shouldn’t it?

Collaborator

sommerluk commented Jun 6, 2014

http://bl.ocks.org/pnorman/raw/f748047317ceca699212/#14.00/37.5039/-233.2401

Wouldn’t it make sense to not render the crossroad/junction names on this zoom level, but starting with this at the same zoom level at which the names of highway=residential get rendered?

nyampire commented Jun 7, 2014

Hi from Japan :)
I've summarized & translated this discussion into Japanese, and told JP community if we could respond "junction=yes" adding.
Personally, I favor "highway=traffic_signals to Icon", and "junction=yes to name tag text symbolizer".

Hence, although very rare case, there are traffic signals with name and no junction. (traffic signals on straight road, for pedestrian crossing.) In this case, I would hesitate to add "junction" tag to that node.
So if possible, I think it is my best that same rendering rule to following 3 combinations.

  • "highway=traffic_signals" + "name=XX"
  • "junction=yes" + "name=XX"
  • "highway=traffic_signals" + "junction=yes" + "name=XX"
Collaborator

math1985 commented Jun 8, 2014

Rendering junctions from z13 seems indeed too early, I think it would be best to render them from either z14 or z15. What do you think?

@nyampire If I understand you correctly, there exists traffic signals on straight roads that are named? In that case, I agree that rendering names on highway=traffic_signals even without junction=yes tag makes sense.

Rendering names of roundabout junctions has some complications, so I will leave them out of the scope of this request.

The disadvantage of the current rendering, I think, is that it is not that easy to see what exactly the named crossing is, especially in more dense areas such as here. Do we need to do something about that, and if yes, what?

Collaborator

pnorman commented Jun 8, 2014

The disadvantage of the current rendering, I think, is that it is not that easy to see what exactly the named crossing is, especially in more dense areas such as here. Do we need to do something about that, and if yes, what?

It looks like you're offsetting them from the crossing. I don't like this when there's no icon or anything below it. Wrapping the lines would also help.

Collaborator

math1985 commented Jun 8, 2014

It looks like you're offsetting them from the crossing. I don't like this when there's no icon or anything below it.

True, we can detect if there is a traffic_signals tag, and if not, not offset them.

Collaborator

pnorman commented Jun 8, 2014

True, we can detect if there is a traffic_signals tag, and if not, not offset them

Well I think you're even offsetting them at zooms where traffic_signals isn't rendered

nyampire commented Jun 8, 2014

@math1985

there exists traffic signals on straight roads that are named?

correct.

hlaw commented Jun 8, 2014

In such case I agree that requiring the adding of junction=yes for the rendering would be encouraging tagging for the renderer. It appears that the nature of these names are labels along roads for orientation, just conveniently assigned to crossroads in most cases.

On the rendering, given that there is no bold nor italics styles for the hangul characters, they look identical to the train stations labeling (if not for the English part in the name). Perhaps a different color may better differentiate the two.

Collaborator

sommerluk commented Jun 8, 2014

In such case I agree that requiring the adding of junction=yes for the rendering would be encouraging tagging for the renderer.

+1

It isn’t good to assign it when it doesn’t reflect the reality. So, yes, we should render the names for “highway=traffic_signals” always. But we have to document this on the wiki. I can do this (after the discussion has finished here).

Putting in order what we have as far as I have understood:

–––––––––––––––

There are different approaches for peoples to orient themself:

1.) The roads (represented in OSM as ways) have names. This approach is the usual approach for instance in Europe.
[Tagging: On a node(!): “highway=residential;primary;secondary;…” and the name key(s)]

2.) There are points (represented in OSM as nodes) that have names. This approach is the usual approach for instance in Japan, Korea and de facto Ivory Coast.This points can be:

2.) a) Junctions: The name is the name of the junction itself.
[Tagging: On a node(!): “junction=*” and the name key(s)]

2.) b) Traffic signals: The name is the name of the traffic signal itself.
[Tagging: On a node(!): “highway=traffic_signals” and the name key(s)]

2.) c) Maybe more things to come in the future?

In OSM, it is possible, but not requiered, to combine 2.) a) and 2.) b) on the same node.

–––––––––––––––

Is this a correct description of what we want to have?

Particulary: Is it realistic to render the names always when the junction key is present (regardless of its value) as long it is a node (and not a way, aerea or relation)? This could make tagging more reliable, and as far I do not see any downside.

Collaborator

sommerluk commented Jun 8, 2014

Rendering junctions from z13 seems indeed too early, I think it would be best to render them from either z14 or z15. What do you think?

Yes, that would be fine. Maybe z14 is early, I’m not sure. The label on http://bl.ocks.org/pnorman/raw/f748047317ceca699212/#19.00/37.45785/-233.31055 isn’t visible any longer on z14, although it is on a primary road and therefore probably more important than the other crossroads around it, which are still displayed at z14.However, it would be difficult to detect this, as we assume that we can have the junction key also on nodes that aren’t connected to ways (likely if you have two roads crossing which are each composed of two oneways).

On the rendering, given that there is no bold nor italics styles for the hangul characters, they look identical to the train stations labeling (if not for the English part in the name). Perhaps a different color may better differentiate the two.

+1

Wrapping the lines would also help.

+1

Imaging an invisible rectangle around the label. Maybe we could try to wrap the lines (to the extend as the line wrap rules allow this) so that we get as close as possible to a rectangle with a ratio width:high of 2:1. This would concentrate the text really around its real place – which is a point, and not a line.

Example without line wrap (too long):

Carrefour de la vie

Example 2:1 (fine):

Carrefour
de la vie

Example 1:1 (to extrem):

Carrefour
   de
    la
   vie
Collaborator

sommerluk commented Jun 8, 2014

It seems that highway=traffic_signals is rendered up from z17. Proposal: If (and only if) a name tag is present, it is rendered (together with the name tag) starting from the corresponding zoom level (14 or 15). When no name tag is present, it is rendered starting up from z17 (like currently).

Collaborator

sommerluk commented Jun 8, 2014

Rendering names of roundabout junctions has some complications, so I will leave them out of the scope of this request.

+1

In Ivory Coast, there are not only crossroads with names, but also many roundabouts with name (which help for orientation in the same way like the names of crossroads.) However, we can add a simple node (without connections) in the middle of the roundabout and put “junction=yes” and a “name” tag on it and we will get the expected rendering. I think this is okay.

Contributor

Rovastar commented Jun 8, 2014

Just to get back to this.

Here is more chat from a year ago

http://gis.19327.n5.nabble.com/Crossroad-names-td5754463.html
(Also a chat that it might be better to have place=* for these.)

As I thought the french OSM website does do this.

http://tile.openstreetmap.fr/?zoom=17&lat=37.40505&lon=127.12573

and for the area in the above link:
http://tile.openstreetmap.fr/?zoom=17&lat=37.45785&lon=-233.31055

For junction=yes and name=*
and
traffic signal =yes and name=*

So pretty much how we do it.

I might be worth comparing that style too as we can easily lookup code, etc.

I would be against junction=roundabout having this rendering as it currently displays it on the roads.

Collaborator

sommerluk commented Jun 12, 2014

I would be against junction=roundabout having this rendering as it currently displays it on the roads.

If we do so, it should be okay to add a (not connected) node at the middle of the roundabout and tag this node with junction=yes and name=* to get the desired behaviour in countries where this is necessary (Ivory Cost for example). Is this okay?

Contributor

Rovastar commented Jun 12, 2014

That sounds sensible rather than rendering it on the 93,000 junction=roundabout with names.

Collaborator

sommerluk commented Jun 22, 2014

At http://wiki.openstreetmap.org/wiki/Tag:junction%3Dyes I’ve tried to resume and to document what has been discussed here so far – concerning junction=yes. Did I resumed it correct? (And: Are there ortographic errors - my english is quite bad)?

hlaw commented Jun 22, 2014

Note: If you are not in a country like Japan, Korea… where junction names serves for orientation, you will not use junction=yes but add a name=* tag to the circled way.

Not sure if this is ok if the intention is for controlling whether junction names are to be rendered. There may be places where there are junction names while the roundabout is part of another road, and junction names are not used as prominently in orientation.

In general, please note that for routing, unless some pre-processing is done to relate the isolated node tagged with the junction name to the ways/nodes making up the junction, probably with some assumptions (eg intersection / roads tagged with "junction=yes" within XX meters are related to the isolated junction node), routers could not recognise the junction name and use it in navigation instructions.

The "formal" solution might be to use relations to link these up, but another type of relation might be a non-starter for many and too complicated for new users. For crossroad with separate carriageways, it might be simplier to just tag the related traffic signals with the junction=yes and the junction name (and let the renderer sort out the duplicates for display), such that routers would work right away.

Collaborator

sommerluk commented Jun 22, 2014

Not sure if this is ok if the intention is for controlling whether junction names are to be rendered. There may be places where there are junction names while the roundabout is part of another road, and junction names are not used as prominently in orientation.

Okay, I understand. If we want to have a solution to this, we need to distinguish 3 things:

  1. The name of the road that formes the roundabout
  2. An (independent) name for the roundabout itself, and the name is rendered small (most western countries…)
  3. An (independent) name for the roundabout itself, and the name is rendered big (Japan, Korea, Ivory Coast…)

(This might be difficult if you want to use the current tagging practice. If we want to break tagging practice, we could introduce something like is_point_of_reference_for_local_orientation=yes to determine if we need a (big) rendring.)

For crossroad with separate carriageways, it might be simplier to just tag the related traffic signals with the junction=yes and the junction name (and let the renderer sort out the duplicates for display), such that routers would work right away.

But we would have a tagging system which is less clean – and we would break with the rule “One feature, one OSM element” - still not simple for beginners (but much simpler than relations).

For Japan, the names seem to be the names of the traffic signals, but for Ivory Coast the traffic signals have no name, but only the crossroad or roundabout itself – so we would have here a difference between what we have in the data base and what we have on the ground.

Nevertheless, I understand your doubt; and I see: It will be dificult to have a solution that
– respects the current tagging convention (without requiering changes in the database for yet tagged elements)
– is intuitive and simple for beginners
– has a clear tagging system
– works for routing software without pre-processing
– is easy for rendering and produced nicely rendered maps

Searching a little bit around, I found also this:
https://lists.openstreetmap.org/pipermail/tagging/2013-March/013257.html
http://wiki.openstreetmap.org/wiki/Proposed_features/highway%3Djunction
It’s about mapping bigger crossroads as areas. It is an approach that is simple to use also for beginners. (However, it will requiere pre-processing in routing software to know if a road passed through the area. For rendring, we would probably have to find the middle of the area and render the name there.)

Whatever we do, each solution will have its shortcomings.

Collaborator

sommerluk commented Jun 29, 2014

In the last days I’ve thought a bit about the tagging of complex junctions with names (outside of Japan – the name is the name of the junction, not of the traffic signal). I try to make a reflection that is as abstract as possible, but somehow my starting point is the situation in Ivory Coast. (Here, it is very common that you have very big junctions with dual carriageways – each of them with 2 or more lanes – and you don’t have any traffic signals and often you don’t even have road sign.)

What do you think about this idea?

– Simple crossroads and 3-way intersections (Y intersection or T intersection): The shared node is tagged with junction=yes and name=*.

– Complex junctions (applies for complex crossroads as for roundabouts as for throughabouts) are drawn as an area that shares nodes with the ways that enter/leave the area. The area is tagged with junction=yes and name=*.

Reasons: For simple intersections, we can stay with the tagging scheme that is yet in use without any changes – this is good. For complex junctions we have a solution that is easy to understand also for beginners (at least much easier than a relation is). We comply with the rule “One feature, one OSM element”. We avoid duplicate tagging (and thus reduce the risk of typing mistakes and the risk to forget to tag one of the nodes). We have a solution that works for both crossroads and roundabouts; that simplifies the work. The renderer is not forced to sort out the duplicates (something that currently also does not always work perfectly with motorway junctions at slippy map), but can render the name simply in the centre of the area. Routing software is not forced to rely on assumptions (like “isolated node with junction=yes in less than x meters of distance”) but the routing software really knows if a road/carriageway passes through a junction area.

What are the disadvantages? You will probably need to add more nodes to draw the area than you would to if you simply add nodes to the incoming carriageways. It is less elegant than a relation is. Maybe it is more difficult to process by routing software than a relation is. (@hlaw: Is this correct? It is just an assumption, as I do not know much about the algorithms of routing software.) At least routing software does not have to rely on assumptions, but can simply look for crossing ways (that share nodes) with “junction=yes”. For software developers, this should be reasonable.

Anyhow, I think that simplicity is a very, very important factor if we want that the mapping community accept this.

At taginfo we can see that junction=yes is currently used almost exclusively on nodes, so we are quite free to discuss an extension without breaking existing tagging conventions.

What are your thoughts about this? Do you agree or did I miss the point?

Il giorno 29/giu/2014, alle ore 18:06, sommerluk notifications@github.com ha scritto:

We comply with the rule “One feature, one OSM element”

I don't think this rule has any practical meaning, as it is quite clear what one OSM element is, but "one feature" in real life isn't at all, it is completely arbitrary and subject to interpretation

Collaborator

sommerluk commented Jul 22, 2014

Are there more opinions concerning tagging of complex junctions?

Collaborator

math1985 commented Jul 23, 2014

@sommerluk I think it would be best to discuss this on the tagging mailing list. Note that the problem is relatef to the tagging of junctions with more than one traffic light.

Collaborator

sommerluk commented Jul 23, 2014

Okay, I’ll discuss this on the tagging mailing list and will post the result here.

@math1985 About the tagging of junctions with more than one traffic light: After the discussion here, I thought that each traffic light gets its own name=* tag because (at least in Japan) normally this is the name of each traffic light – although the traffic lights of one crossroad have normally all the same name. Do you think that this should also be asked and discussed on the tagging mailing list to find another solution? Or was your comment simply about to mention this as well when asking for the crossroad problem on tagging mailing list?

2014-07-23 14:44 GMT+02:00 sommerluk notifications@github.com:

I thought that each traffic light gets its own name=* tag because (at
least in Japan) normally this is the name of each traffic light

are these really "name"s or are they maybe "ref"s?

Collaborator

sommerluk commented Jul 23, 2014

Ah, okay, it wasn’t here where this was posted, but at http://gis.19327.n5.nabble.com/Crossroad-names-td5754463.html

As theory, the names of Japanese traffic signals are given to each
signals, not to a junction.
(and basically, the signals on a same junction has same names)

I’ll discuss both questions at the tagging mailing list…

Collaborator

math1985 commented Jul 23, 2014

Do you think that this should also be asked and discussed on the tagging mailing list to find another solution?

I think that can't harm, having the name render multiple times on highzoom might be not that nice? On the other hand, we don't necessarily need to wait for that discussion.

How do we tag motorway crosssings?

Collaborator

sommerluk commented Jul 29, 2014

Okay. I’ve talked at the tagging mailing list (but there wasn’t much interest for this question) and also on the graphhopper mailing list to understand what is easy for routing/turn-to-turn navigation engines – thanks to Peter – and also about tagging in Japan – thanks to nyampire.

As explained, the tagging mailing list wasn’t too responsive. Peter from graphhopper made clear which solutions are easy to implement for routing engines and which are complicate – and pointed out that the solution with the area can be counterintuitive.

So I’ve tried to resume all pros and cons at https://wiki.openstreetmap.org/wiki/Tag:junction%3Dyes#Ideas_for_complex_situations. (Particulary I’m not sure about what is easy to render and what not – please correct if necessary).

nyampire pointed out that the different traffic signals on a junction are not isolated, but they are a unit with a common name – and particulary for rendering, the traffic signal icon and the traffic signal name should be rendered only once (not 4 times) for each junction.

As sorting out duplicates by the renderer doesn’t work very well for motorway junctions, I had the idea of a new, generic relation which groups multiple nodes that have all the same tags, but should be rendered only once. This could be an approach that could serve for both junction=yes and highway=traffic_signals and may also be useful for highway=motorway_junction in the rest of the world.

Collaborator

math1985 commented Jul 29, 2014

Wow, great work!

Am 29/lug/2014 um 11:52 schrieb sommerluk notifications@github.com:

I had the idea of a new, generic relation which group multiple nodes that have all the same tags, but should be rendered only once.

do we really need a relation for this? Seems as if the information is already in data but some of the renderers are not displaying it like you would like them to. My suggestion is to tackle this on the renderer side rather than modifying the data

Thank you @sommerluk . Excellent!
As sommerluk mentioned, this is not only render issue, but also routing topology issue. I prefer union/relation idea (5).

@math1985 math1985 referenced this issue Aug 2, 2014

Merged

Crossroad names #813

Really good write-up!
I'm not an expert in routing or anything, but you described the pros and cons well.

For me, the junction-area (idea 4) wins:
It is tagging a physical thing, not adding an abstract relation to the data. We need to define where a junction starts and ends, but if you make the area follow the physical shape of the roads, you add additional value, more than just the name and the info that these things belong together.

@gravitystorm gravitystorm closed this in #813 Sep 5, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment