Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
No tags on the shared nodes - just shared nodes. What is IMHO a quite bad idea for two reasons: – It’s unlikely that there will be software supporting features when there is no tag. – You would introduce a concurrent solution to a node highway=traffic_signals. I do not think that it’s a good idea to have various ways to tag the same thing. Made a test to show you what I was thinking. https://www.openstreetmap.org/#map=18/36.32478/139.10396 And there, you see even more problems: – At https://www.openstreetmap.org/#map=19/36.32487/139.10370, you do not have a shared node between the highway and the area. But this would be necessary to have a reliably hint for routing/turn-to-turn navigation software, otherwise it will be hard to know there the area ends. This would make a working routing solution quite unlikely. – At https://www.openstreetmap.org/#map=19/36.32492/139.10357 you have the area nearly in parallel to the footway. There will be other situations, where it will be exactly parallel. This is not comfortable to edit. – At https://www.openstreetmap.org/#map=19/36.32492/139.10347 you do not have a shared node between the footway and the area. But footways are not oneway. So a routing engine does not know when you enter the area respectively when you leave it. – At https://www.openstreetmap.org/#map=19/36.32440/139.10395 the footway overlaps only slightly the area. There will be cases where it will not overlap at all. How to decide reliably for software if this footway passes through the junction or not? – At https://www.openstreetmap.org/#map=19/36.32440/139.10395 you have a shared node. But probably, when you are passing through the footway and go from south to est, you do not pass over the traffic signals. (You would to so only when you go from south to northwest, and the traffic signal node should be at the intersection between the footway and the highway: https://www.openstreetmap.org/#map=19/36.32445/139.10392 ) – The complicate roule when to share node and when not will in practice be prone to errors. It’s to difficult. – And: I still not see what you gain with this. – And overall: It would mean that you may not add any of these areas to OSM unless you know _exactly_ where the individual traffic signals are located. So, in practice, either the tagging will hardly be used, or (what I think is more likely) people will tag nevertheless the area, and just not comply with the rule of the shared nodes. – All in all, I do neither see this practicable nor do I see a gain. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
Wow, you really went over it very carefully, thanks for all the input. I will
go over your list of issues again, but can you fix it to as how you would see
this tag used? I'm very interested to see how you would properly tag it, as you
know the parsing methods much better than I do ('cause I have an idea of how
they work, but no exact knowledge, so I'm dangerous).
I only have one question so far-
– At https://www.openstreetmap.org/#map=19/36.32440/139.10395 you have a
shared node. But probably, when you are passing through the footway and go
from south to est, you do not pass over the traffic signals. (You would to so
only when you go from south to northwest, and the traffic signal node should
be at the intersection between the footway and the highway:
https://www.openstreetmap.org/#map=19/36.32445/139.10392 )
You may not pass through the signal, but it is still the (sometimes named)
signal that you would turn right at, correct?
-Javbw
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
So the nodes where the signals_area intersects the highways is where the signals would normally be mapped for complex intersections? Not exactly. It would be difficult to do so if you have really complex junctions with really many individual traffic signals and you want to catch all of them – a zickzack that is not easy to draw and not practical to maintain. The area is drawn just _around_ everything that is considered the junction. About the individual traffic signals. We recommand as current best-practice to not map them if you use the area. Means: Don’t do both things. (But maybe in the future this could be considered useful and it could be done without breaking the tagging scheme just like every other normal traffic signal with highway=traffic_signals on a node.) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
It should be pretty trivial to have the area share nodes with the highway ways where the signals would normally be mapped. Like drawing a square around a tic-tac-toe board, but the shared nodes are only on one side at a time. Also, I think It could also share nodes with the walkways and other pedestrian oriented ways, as the signal would be part of their routing as well. Javbw On Sep 21, 2014, at 3:48 PM, Lukas Sommer sommer...@gmail.com wrote: So the nodes where the signals_area intersects the highways is where the signals would normally be mapped for complex intersections? Not exactly. It would be difficult to do so if you have really complex junctions with really many individual traffic signals and you want to catch all of them – a zickzack that is not easy to draw and not practical to maintain. The area is drawn just _around_ everything that is considered the junction. About the individual traffic signals. We recommand as current best-practice to not map them if you use the area. Means: Don’t do both things. (But maybe in the future this could be considered useful and it could be done without breaking the tagging scheme just like every other normal traffic signal with highway=traffic_signals on a node.) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
It should be pretty trivial to have the area share nodes with the highway ways where the signals would normally be mapped. Like drawing a square around a tic-tac-toe board, but the shared nodes are only on one side at a time. Here, I strongly disagree. The defination on the proposal page is clear: We do not want to have tags on the shared nodes. Only this way it is clear what is within the area, and what is without. We should not give up this possiblility. And your idea actually would give up this possiblilty. Next problem with your idea: You need to have shared nodes not only for incoming, but also for the outgoing oneways. And mostly there is no real traffic signal _after_ you have passed a crossroad. Nevertheless you have there a node. So later you won’t be able to know if on a specific node there is really a traffic signal or not. We don’t have any need to represent the individual traffic signals in the border. It would make the usage far to complicate. And you would not gain anything. If you want to mark individual traffic signals, use the existing tagging. But don’t invent a new one – don’t make it unnecessarily complicate! Also, I think It could also share nodes with the walkways and other pedestrian oriented ways, as the signal would be part of their routing as well. Here, I agree. I assumed that people would do so automatically, but I’ll also add it on the wiki page. Lukas Sommer 2014-09-21 21:30 GMT+00:00 John Willis jo...@mac.com: It should be pretty trivial to have the area share nodes with the highway ways where the signals would normally be mapped. Like drawing a square around a tic-tac-toe board, but the shared nodes are only on one side at a time. Also, I think It could also share nodes with the walkways and other pedestrian oriented ways, as the signal would be part of their routing as well. Javbw On Sep 21, 2014, at 3:48 PM, Lukas Sommer sommer...@gmail.com wrote: So the nodes where the signals_area intersects the highways is where the signals would normally be mapped for complex intersections? Not exactly. It would be difficult to do so if you have really complex junctions with really many individual traffic signals and you want to catch all of them – a zickzack that is not easy to draw and not practical to maintain. The area is drawn just _around_ everything that is considered the junction. About the individual traffic signals. We recommand as current best-practice to not map them if you use the area. Means: Don’t do both things. (But maybe in the future this could be considered useful and it could be done without breaking the tagging scheme just like every other normal traffic signal with highway=traffic_signals on a node.) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
On Sep 22, 2014, at 6:48 AM, Lukas Sommer sommer...@gmail.com wrote: It should be pretty trivial to have the area share nodes with the highway ways where the signals would normally be mapped. Like drawing a square around a tic-tac-toe board, but the shared nodes are only on one side at a time. Here, I strongly disagree. The defination on the proposal page is clear: We do not want to have tags on the shared nodes. Only this way it is clear what is within the area, and what is without. We should not give up this possiblility. And your idea actually would give up this possiblilty. No tags on the shared nodes - just shared nodes. Next problem with your idea: You need to have shared nodes not only for incoming, but also for the outgoing oneways. And mostly there is no real traffic signal _after_ you have passed a crossroad. Nevertheless you have there a node. So later you won’t be able to know if on a specific node there is really a traffic signal or not. would the intersecting roads still have a shared (untagged) node in the center? We don’t have any need to represent the individual traffic signals in the border. It would make the usage far to complicate. And you would not gain anything. If you want to mark individual traffic signals, use the existing tagging. But don’t invent a new one – don’t make it unnecessarily complicate! I thought the shared nodes with the areas would easily represent what the signal_area is affecting, and when it is affecting it (before entering the intersection). Made a test to show you what I was thinking. https://www.openstreetmap.org/#map=18/36.32478/139.10396 Also, I think It could also share nodes with the walkways and other pedestrian oriented ways, as the signal would be part of their routing as well. Yea - at the intersection where the decision to change routes is made. Here, I agree. I assumed that people would do so automatically, but I’ll also add it on the wiki page. Lukas Sommer - Javbw ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
Am 20.09.2014 02:03, schrieb johnw: So the solution for a complex intersection is to have a signal_area area with an outline that intersects with all the nodes where the signal would affect the traffic? This would let the renderer use one icon, and still have the ways marked in the proper spot for the intersection, right? (assuming they will support signal_area). Not sure if the single traffic_signals node need to be parent of the area but they should be at least within the area as a hint for the renderer. Thanks for considering some extra tag(-combinations) for the area. cu fly ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
Okay, I’ve adapted the proposal wiki page. We can propose to tag complex traffic signal areas _only_ using the area, and not to tag the individual traffic signals. That makes it easier for renderers to display only one icon per traffic signal area. However, I feel we should not completly exclude for all time the possibility to tag also the individual traffic signals – it is at least a valid information, even if it is not necessary for traditional japanese maps. The individual traffic signals are simple nodes that are located within the area. We would not make it a rule, but just recommand to _not_ tag the individual traffic signals for Japan. As described in the proposal, the area is simply drawn around the approximative area that is affected by the traffic signals. It encloses everything, but shares nodes only with the incoming and outgoing highways. Lukas Sommer 2014-09-20 16:45 GMT+00:00 fly lowfligh...@googlemail.com: Am 20.09.2014 02:03, schrieb johnw: So the solution for a complex intersection is to have a signal_area area with an outline that intersects with all the nodes where the signal would affect the traffic? This would let the renderer use one icon, and still have the ways marked in the proper spot for the intersection, right? (assuming they will support signal_area). Not sure if the single traffic_signals node need to be parent of the area but they should be at least within the area as a hint for the renderer. Thanks for considering some extra tag(-combinations) for the area. cu fly ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
On Sep 21, 2014, at 5:13 AM, Lukas Sommer sommer...@gmail.com wrote: As described in the proposal, the area is simply drawn around the approximative area that is affected by the traffic signals. It encloses everything, but shares nodes only with the incoming and outgoing highways. So the nodes where the signals_area intersects the highways is where the signals would normally be mapped for complex intersections? Sounds like an even simpler solution. - Javbw___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
On Sep 19, 2014, at 5:59 AM, Lukas Sommer sommer...@gmail.com wrote: * Here, I still do not see your point. What would you gain in doing so? You have more tags, which means more work. But can you do anything that you can not do with the current, yet existing tagging? Differentiated tagging is needed for differentiated rendering. junction vs Signal. a single signal icon needs to be rendered in Japan for intersections. * highway=junction is impossible because the OSM database does not allow two tags with the same key on the same element * junction=traffic_signals would also be problematic because in Japan you can have named traffic signals on straight road, for pedestrian crossing , and there is not any road junction. is there a way to tell the renderer to not render it's icon if it is part of another area's way? that would allow the intersection tag to take over for the rendering of the signals for it's single icon. if that's the case: landmark=intersection ? Intersection=signals for Japan, intersection=junction for korea, or other named junctions. Javbw___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
Differentiated tagging is needed for differentiated rendering. junction vs Signal. a single signal icon needs to be rendered in Japan for intersections. But that is yet working perfectly with the current tagging! In Korea, we have yet thousands of nodes with junction=yes and name=*, and they are rendered just with their name (and without any icon) at osm.org. Example: http://www.openstreetmap.org/#map=17/37.48391/126.65874 In Japan, we have yet thousands of nodes with highway=traffic_signals and name=*, and they are rendered with their name together with the icon at osm.org. Example: http://www.openstreetmap.org/#map=17/34.43281/132.46446 (I know that the rendering style is not very “japanese”, but osm.org has worldwide coverage and has to render something that fits best at least a big part of the world. But this is a _rendering_ issue, not a _tagging_ issue.) There is only a problem when you have to tag complex junctions or traffic signal systems with dual carrigeways, because you want that the icon the the name show up only _once_ per junction/traffic signal system, and not _multiple_ times. That’s what is proposal is for. is there a way to tell the renderer to not render it's icon if it is part of another area's way? that would allow the intersection tag to take over for the rendering of the signals for it's single icon. I guess you want to say that we have to supress the rendering of individual traffic signals (nodes with highway=traffic_signals) if these node are located within the area element that marks the traffic signal system as a hole. So we render only the area element and we get only _one_ icon and name per traffic signal system. Indeed that is exactly what is necessary, and I’ve made my proposal based on this assumption. I assumed that this is tecnically easy, but I’ll check this again… if that's the case: landmark=intersection ? Intersection=signals for Japan, intersection=junction for korea, or other named junctions. Again, I do not see the point in introducing here a new tag. Using the existing junction=yes in Korea and the existing highway=traffic_signals in Japan – just not only on nodes but extending it also also on closed ways (=areas) – should be fine. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
Again, I do not see the point in introducing here a new tag. Using the existing junction=yes in Korea and the existing highway=traffic_signals in Japan – just not only on nodes but extending it also also on closed ways (=areas) – should be fine. Okay, here I have to correct myself. It may be useful to have a different tag for the area instead of using the same on the node, especially for editor software and checking software, but also other software. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
Some random thoughts about names for the area tags: junction=yes on nodes For areas: – something that contains “junction” and “area” – junction=area ? highway=traffic_signals on nodes For areas: – something that contains “traffic signal system” (also “system”!) and also “area” – maybe not traffic_signals=* which seems to have either another meaning – highway=traffic_signal_system_area (quite long)? Lukas Sommer 2014-09-19 18:27 GMT+00:00 Lukas Sommer sommer...@gmail.com: Again, I do not see the point in introducing here a new tag. Using the existing junction=yes in Korea and the existing highway=traffic_signals in Japan – just not only on nodes but extending it also also on closed ways (=areas) – should be fine. Okay, here I have to correct myself. It may be useful to have a different tag for the area instead of using the same on the node, especially for editor software and checking software, but also other software. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
After thinking more about the tag name question: It may be useful to use for the complex situation at least the same key as for their conterpart in simple situations. This is intuitive (usability), and at the same time the tags for the simple and for the complex situation are mutually exclusive, which can be practical. Means: Korea: – simple: junction=yes – complex: junction=junction_area Japan: – simple: highway=traffic_signals – complex: highway=traffic_signals_area I’ve updated the proposal page on the wiki. Lukas Sommer 2014-09-19 18:32 GMT+00:00 Lukas Sommer sommer...@gmail.com: Some random thoughts about names for the area tags: junction=yes on nodes For areas: – something that contains “junction” and “area” – junction=area ? highway=traffic_signals on nodes For areas: – something that contains “traffic signal system” (also “system”!) and also “area” – maybe not traffic_signals=* which seems to have either another meaning – highway=traffic_signal_system_area (quite long)? Lukas Sommer 2014-09-19 18:27 GMT+00:00 Lukas Sommer sommer...@gmail.com: Again, I do not see the point in introducing here a new tag. Using the existing junction=yes in Korea and the existing highway=traffic_signals in Japan – just not only on nodes but extending it also also on closed ways (=areas) – should be fine. Okay, here I have to correct myself. It may be useful to have a different tag for the area instead of using the same on the node, especially for editor software and checking software, but also other software. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
I don't know much about how the rendering system parses the tags. I thought t would be non-trivial for it to work out how to display signal icons without a new tag, so I thought a new tag might be necessary, and gave my suggestion. I'm aware the current system is in use a lot for simple 1 node intersections, but as the number of complex intersections increases (?micro-mapping?), so will the need for a solution. Javbw On Sep 19, 2014, at 11:32 PM, Lukas Sommer sommer...@gmail.com wrote: Differentiated tagging is needed for differentiated rendering. junction vs Signal. a single signal icon needs to be rendered in Japan for intersections. But that is yet working perfectly with the current tagging! In Korea, we have yet thousands of nodes with junction=yes and name=*, and they are rendered just with their name (and without any icon) at osm.org. Example: http://www.openstreetmap.org/#map=17/37.48391/126.65874 In Japan, we have yet thousands of nodes with highway=traffic_signals and name=*, and they are rendered with their name together with the icon at osm.org. Example: http://www.openstreetmap.org/#map=17/34.43281/132.46446 (I know that the rendering style is not very “japanese”, but osm.org has worldwide coverage and has to render something that fits best at least a big part of the world. But this is a _rendering_ issue, not a _tagging_ issue.) There is only a problem when you have to tag complex junctions or traffic signal systems with dual carrigeways, because you want that the icon the the name show up only _once_ per junction/traffic signal system, and not _multiple_ times. That’s what is proposal is for. is there a way to tell the renderer to not render it's icon if it is part of another area's way? that would allow the intersection tag to take over for the rendering of the signals for it's single icon. I guess you want to say that we have to supress the rendering of individual traffic signals (nodes with highway=traffic_signals) if these node are located within the area element that marks the traffic signal system as a hole. So we render only the area element and we get only _one_ icon and name per traffic signal system. Indeed that is exactly what is necessary, and I’ve made my proposal based on this assumption. I assumed that this is tecnically easy, but I’ll check this again… if that's the case: landmark=intersection ? Intersection=signals for Japan, intersection=junction for korea, or other named junctions. Again, I do not see the point in introducing here a new tag. Using the existing junction=yes in Korea and the existing highway=traffic_signals in Japan – just not only on nodes but extending it also also on closed ways (=areas) – should be fine. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
On Sep 20, 2014, at 6:37 AM, Lukas Sommer sommer...@gmail.com wrote: After thinking more about the tag name question: It may be useful to use for the complex situation at least the same key as for their conterpart in simple situations. This is intuitive (usability), and at the same time the tags for the simple and for the complex situation are mutually exclusive, which can be practical. Means: Korea: – simple: junction=yes – complex: junction=junction_area Japan: – simple: highway=traffic_signals – complex: highway=traffic_signals_area Great solution ^_^ Javbw ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
Yeah sadly it is fairly complex to display different icons in different locations. Not something we will doing in OSM carto for a good while. From: jo...@mac.com Date: Sat, 20 Sep 2014 07:07:56 +0900 To: tagging@openstreetmap.org Subject: Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named I don't know much about how the rendering system parses the tags. I thought t would be non-trivial for it to work out how to display signal icons without a new tag, so I thought a new tag might be necessary, and gave my suggestion. I'm aware the current system is in use a lot for simple 1 node intersections, but as the number of complex intersections increases (?micro-mapping?), so will the need for a solution. Javbw On Sep 19, 2014, at 11:32 PM, Lukas Sommer sommer...@gmail.com wrote: Differentiated tagging is needed for differentiated rendering. junction vs Signal. a single signal icon needs to be rendered in Japan for intersections. But that is yet working perfectly with the current tagging! In Korea, we have yet thousands of nodes with junction=yes and name=*, and they are rendered just with their name (and without any icon) at osm.org. Example: http://www.openstreetmap.org/#map=17/37.48391/126.65874 In Japan, we have yet thousands of nodes with highway=traffic_signals and name=*, and they are rendered with their name together with the icon at osm.org. Example: http://www.openstreetmap.org/#map=17/34.43281/132.46446 (I know that the rendering style is not very “japanese”, but osm.org has worldwide coverage and has to render something that fits best at least a big part of the world. But this is a _rendering_ issue, not a _tagging_ issue.) There is only a problem when you have to tag complex junctions or traffic signal systems with dual carrigeways, because you want that the icon the the name show up only _once_ per junction/traffic signal system, and not _multiple_ times. That’s what is proposal is for. is there a way to tell the renderer to not render it's icon if it is part of another area's way? that would allow the intersection tag to take over for the rendering of the signals for it's single icon. I guess you want to say that we have to supress the rendering of individual traffic signals (nodes with highway=traffic_signals) if these node are located within the area element that marks the traffic signal system as a hole. So we render only the area element and we get only _one_ icon and name per traffic signal system. Indeed that is exactly what is necessary, and I’ve made my proposal based on this assumption. I assumed that this is tecnically easy, but I’ll check this again… if that's the case: landmark=intersection ?Intersection=signals for Japan, intersection=junction for korea, or other named junctions. Again, I do not see the point in introducing here a new tag. Using the existing junction=yes in Korea and the existing highway=traffic_signals in Japan – just not only on nodes but extending it also also on closed ways (=areas) – should be fine. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
So the solution for a complex intersection is to have a signal_area area with an outline that intersects with all the nodes where the signal would affect the traffic? This would let the renderer use one icon, and still have the ways marked in the proper spot for the intersection, right? (assuming they will support signal_area). Javbw On Sep 20, 2014, at 8:10 AM, John Baker rovas...@hotmail.com wrote: Yeah sadly it is fairly complex to display different icons in different locations. Not something we will doing in OSM carto for a good while. From: jo...@mac.com Date: Sat, 20 Sep 2014 07:07:56 +0900 To: tagging@openstreetmap.org Subject: Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named I don't know much about how the rendering system parses the tags. I thought t would be non-trivial for it to work out how to display signal icons without a new tag, so I thought a new tag might be necessary, and gave my suggestion. I'm aware the current system is in use a lot for simple 1 node intersections, but as the number of complex intersections increases (?micro-mapping?), so will the need for a solution. Javbw On Sep 19, 2014, at 11:32 PM, Lukas Sommer sommer...@gmail.com wrote: Differentiated tagging is needed for differentiated rendering. junction vs Signal. a single signal icon needs to be rendered in Japan for intersections. But that is yet working perfectly with the current tagging! In Korea, we have yet thousands of nodes with junction=yes and name=*, and they are rendered just with their name (and without any icon) at osm.org. Example: http://www.openstreetmap.org/#map=17/37.48391/126.65874 In Japan, we have yet thousands of nodes with highway=traffic_signals and name=*, and they are rendered with their name together with the icon at osm.org. Example: http://www.openstreetmap.org/#map=17/34.43281/132.46446 (I know that the rendering style is not very “japanese”, but osm.org has worldwide coverage and has to render something that fits best at least a big part of the world. But this is a _rendering_ issue, not a _tagging_ issue.) There is only a problem when you have to tag complex junctions or traffic signal systems with dual carrigeways, because you want that the icon the the name show up only _once_ per junction/traffic signal system, and not _multiple_ times. That’s what is proposal is for. is there a way to tell the renderer to not render it's icon if it is part of another area's way? that would allow the intersection tag to take over for the rendering of the signals for it's single icon. I guess you want to say that we have to supress the rendering of individual traffic signals (nodes with highway=traffic_signals) if these node are located within the area element that marks the traffic signal system as a hole. So we render only the area element and we get only _one_ icon and name per traffic signal system. Indeed that is exactly what is necessary, and I’ve made my proposal based on this assumption. I assumed that this is tecnically easy, but I’ll check this again… if that's the case: landmark=intersection ? Intersection=signals for Japan, intersection=junction for korea, or other named junctions. Again, I do not see the point in introducing here a new tag. Using the existing junction=yes in Korea and the existing highway=traffic_signals in Japan – just not only on nodes but extending it also also on closed ways (=areas) – should be fine. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
So far, highway=traffic_signal is only defined for nodes and there are only few ways and fewer relations. Correct. Also in favour of separation I would prefer to use junction=* with name=* and only highway=traffic_signal with name if it is only a single light (e.g. the case with a named junction and different separate names for the lights) This way we could add an additional junction=* to the nodes with named traffic_signal and once all lights are tagged separately only use junction=* for ways. Additionally we have a better hint for the renderer what to render and diversify between a named junction and single named traffic_signals. cu fly Hm, I am not sure if I understand you correctly. You want to use junction=yes not on nodes anymore, but only on areas – and change the currently existing cases in OSM? If so, I would disagree here. We have a yet existing tagging that works well for both – named junctions and names traffic signals – as long as this are simple junctions like https://wiki.openstreetmap.org/wiki/File:Junction_yes_example_1.png My proposal keeps the existing tagging for simple junctions – and extends it also to complex junctions. I am not convinced in changing the current tagging practice for simple junctions and require changing a lot of yet existing data in OSM. Currently I do not know of any situation where we have at the same place on the ground a different junction name and a different traffic signal name. It seems to me a barely theoretical problem. Maybe that does not mean that such a situation is impossible to exist. However, we should create our tagging scheme starting from the situation on the ground, and this seems to be either junction names or traffic signal names, but not both things at the same time. Replace an existing simple practice with a new complicate practice just to solve a problem that does probably not exist on the ground? However, I think it is nevertheless a good idea to think about this case. I would propose to leave the existing tagging for simple intersections as it is (with tagging on a node). Moreover, for the rare case that we have a junction and a traffic signal with different names, one of them could be represented by an area around the other one (and same thing on complex junctions/traffic signal systems). Thus, we keep a door open to tag two different names, just for the case that sometime we really need it. Nevertheless, we do not break compatibility with the current practice, and we do not make things unnecessarily complicate for the real-world cases. Lukas ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
in OSM we focus on ground truth and having a local (!) community taking care of the data and keeping it in shape. The expected iconography differs between countries, as they are shown on maps differently in the different countries. At least comparing Japan to America, what they expect to be displayed and how it is represented differs greatly. We have to be flexible enough to let the rendering of one country differ from one to the next, if if follows the societal conventions of their maps. If we can't designate a single signal icon for the complex intersections in japan, and offer named signals as well, we are choosing to make an inferior map for Japanese users because it doesn't conform to the groups opinion on what it should be outside Japan. So the sentiment about local users and whatnot is just puffery. Junctions naming in Korea happens to align better but ground truth is that people in Japan call them signals, publish maps with signals, show signals on signs, ads, billboards, and online - everything revolves around the consistent display of signals if we are going to render them. we will eventually have to clean up the multitude of signals rendered by OSM, and this is one reason why. This is a local tagging-rendering issue in search of a solution supported by the group - a single (horizontal?) signal icon is required to be displayed per junction with a signal, regardless of the number of actual signal nodes that are needed for a complex intersection, and it has to have an optional name rendered with it. Google conformed to this a few years ago, when they stepped up their mapping by importing and now improving zenrin's data. https://www.google.co.jp/maps/@36.4108183,139.3363032,17z?hl=en Apple's initial map was crap, mostly because it was based on old OSM data using imports that were never cleaned up. 3 months later, AppleMaps got a significant overhaul (they also imported and are now improving a local dataset), and every month they get better, even for me out here in the sticks. They also initially didn't support the signal icon, and now fully support it. PS - the Japanese post office icon is also used - another local custom we'll have to adapt to as well. Still waiting on the proper JR rail line rendering though. OSM will have to do it too. What other way do you suggest that this be accomplished? Pushing it off is an option, but this is something that a rendered map from OSM will eventually be *required to display this in this particular fashion* in Japan. Javbw On Sep 18, 2014, at 2:35 AM, fly lowfligh...@googlemail.com wrote: So far, highway=traffic_signal is only defined for nodes and there are only few ways and fewer relations. Also in favour of separation I would prefer to use junction=* with name=* and only highway=traffic_signal with name if it is only a single light (e.g. the case with a named junction and different separate names for the lights) This way we could add an additional junction=* to the nodes with named traffic_signal and once all lights are tagged separately only use junction=* for ways. Additionally we have a better hint for the renderer what to render and diversify between a named junction and single named traffic_signals. cu fly Am 17.09.2014 00:06, schrieb johnw: Correct me if I'm wrong, but it sounds like the end goal is: - to have junction names in korea, regardless of if they are traffic lights, and the symbol used there doesn't imply traffic lights, just a junction. - In Japan, the old junction system evolved to be named traffic signals, and the symbol used there a (horizontal) signal - so the end goal is to have the name and the signal icon shown over the intersection with it's name. so the complex solution is to map the the junction, (with different tags for Japan and Korea) with the area's way sharing nodes with the traffic signals. - in Japan's case, the complex solution must only render a single traffic icon, or it will ruin the purpose of using the intersection icon. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
Am 18.09.2014 16:07, schrieb Lukas Sommer: So far, highway=traffic_signal is only defined for nodes and there are only few ways and fewer relations. Correct. Also in favour of separation I would prefer to use junction=* with name=* and only highway=traffic_signal with name if it is only a single light (e.g. the case with a named junction and different separate names for the lights) This way we could add an additional junction=* to the nodes with named traffic_signal and once all lights are tagged separately only use junction=* for ways. Additionally we have a better hint for the renderer what to render and diversify between a named junction and single named traffic_signals. cu fly Sorry, was kind of confusing, try again: 1. simple solution with only one node junction=yes/traffic_signal/* highway=traffic_signal (if the junction has lights) name=* 2. area junction=yes/traffic_signal/* name=* Maybe also highway=junction [1] could be used. Renderer could use junction=* to determine the needed icon and we stay consistant with the use of traffic_signals. This makes detailed tagging possible while adding the information for renderers to Hm, I am not sure if I understand you correctly. You want to use junction=yes not on nodes anymore, but only on areas – and change the currently existing cases in OSM? No, no problem with junction=* on nodes but in long term only needed for rare situations and low detailed mapping If so, I would disagree here. We have a yet existing tagging that works well for both – named junctions and names traffic signals – as long as this are simple junctions like https://wiki.openstreetmap.org/wiki/File:Junction_yes_example_1.png My proposal keeps the existing tagging for simple junctions – and extends it also to complex junctions. I am not convinced in changing the current tagging practice for simple junctions and require changing a lot of yet existing data in OSM. Currently I do not know of any situation where we have at the same place on the ground a different junction name and a different traffic signal name. It seems to me a barely theoretical problem. Maybe that does not mean that such a situation is impossible to exist. However, we should create our tagging scheme starting from the situation on the ground, and this seems to be either junction names or traffic signal names, but not both things at the same time. Replace an existing simple practice with a new complicate practice just to solve a problem that does probably not exist on the ground? Well, I just followed this thread: Am 16.09.2014 16:49, schrieb Satoshi IIDA: 2014-09-16 23:38 GMT+09:00 fly lowfligh...@googlemail.com: The name belongs to the junction and not to the traffic_signal, am I wrong ? In Japan, Hokkaido region, there is 4 traffic_signals on 1 junction. Each traffic_signals and 1 junction has different name. Indeed it is rare case. But I think we need Lukas's idea to support it. However, I think it is nevertheless a good idea to think about this case. I would propose to leave the existing tagging for simple intersections as it is (with tagging on a node). Moreover, for the rare case that we have a junction and a traffic signal with different names, one of them could be represented by an area around the other one (and same thing on complex junctions/traffic signal systems). Thus, we keep a door open to tag two different names, just for the case that sometime we really need it. Nevertheless, we do not break compatibility with the current practice, and we do not make things unnecessarily complicate for the real-world cases. Ok, here we are common. Hope my thoughts are better understandable this time. Cheers fly ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
Am 18.09.2014 21:29, schrieb fly: Am 18.09.2014 16:07, schrieb Lukas Sommer: So far, highway=traffic_signal is only defined for nodes and there are only few ways and fewer relations. Correct. Also in favour of separation I would prefer to use junction=* with name=* and only highway=traffic_signal with name if it is only a single light (e.g. the case with a named junction and different separate names for the lights) This way we could add an additional junction=* to the nodes with named traffic_signal and once all lights are tagged separately only use junction=* for ways. Additionally we have a better hint for the renderer what to render and diversify between a named junction and single named traffic_signals. cu fly Sorry, was kind of confusing, try again: 1. simple solution with only one node junction=yes/traffic_signal/* highway=traffic_signal (if the junction has lights) name=* 2. area junction=yes/traffic_signal/* name=* Maybe also highway=junction [1] could be used. Renderer could use junction=* to determine the needed icon and we stay consistant with the use of traffic_signals. This makes detailed tagging possible while adding the information for renderers to Hm, I am not sure if I understand you correctly. You want to use junction=yes not on nodes anymore, but only on areas – and change the currently existing cases in OSM? No, no problem with junction=* on nodes but in long term only needed for rare situations and low detailed mapping If so, I would disagree here. We have a yet existing tagging that works well for both – named junctions and names traffic signals – as long as this are simple junctions like https://wiki.openstreetmap.org/wiki/File:Junction_yes_example_1.png My proposal keeps the existing tagging for simple junctions – and extends it also to complex junctions. I am not convinced in changing the current tagging practice for simple junctions and require changing a lot of yet existing data in OSM. Currently I do not know of any situation where we have at the same place on the ground a different junction name and a different traffic signal name. It seems to me a barely theoretical problem. Maybe that does not mean that such a situation is impossible to exist. However, we should create our tagging scheme starting from the situation on the ground, and this seems to be either junction names or traffic signal names, but not both things at the same time. Replace an existing simple practice with a new complicate practice just to solve a problem that does probably not exist on the ground? Well, I just followed this thread: Am 16.09.2014 16:49, schrieb Satoshi IIDA: 2014-09-16 23:38 GMT+09:00 fly lowfligh...@googlemail.com: The name belongs to the junction and not to the traffic_signal, am I wrong ? In Japan, Hokkaido region, there is 4 traffic_signals on 1 junction. Each traffic_signals and 1 junction has different name. Indeed it is rare case. But I think we need Lukas's idea to support it. However, I think it is nevertheless a good idea to think about this case. I would propose to leave the existing tagging for simple intersections as it is (with tagging on a node). Moreover, for the rare case that we have a junction and a traffic signal with different names, one of them could be represented by an area around the other one (and same thing on complex junctions/traffic signal systems). Thus, we keep a door open to tag two different names, just for the case that sometime we really need it. Nevertheless, we do not break compatibility with the current practice, and we do not make things unnecessarily complicate for the real-world cases. Ok, here we are common. Hope my thoughts are better understandable this time. Cheers fly forgot the link [1] https://wiki.openstreetmap.org/wiki/Proposed_features/highway=junction ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
Okay, if I get you right, you want to add to every element with the tag highway=traffic_signals and the tag name=* also another new tag, either – highway=junction or – junction=traffic_signals and the presence or absence of this tag shall influence the rendering? * Here, I still do not see your point. What would you gain in doing so? You have more tags, which means more work. But can you do anything that you can not do with the current, yet existing tagging? * highway=junction is impossible because the OSM database does not allow two tags with the same key on the same element. * junction=traffic_signals would also be problematic because in Japan you can have named traffic signals on straight road, for pedestrian crossing , and there is not any road junction. Lukas Lukas Sommer 2014-09-18 19:31 GMT+00:00 fly lowfligh...@googlemail.com: Am 18.09.2014 21:29, schrieb fly: Am 18.09.2014 16:07, schrieb Lukas Sommer: So far, highway=traffic_signal is only defined for nodes and there are only few ways and fewer relations. Correct. Also in favour of separation I would prefer to use junction=* with name=* and only highway=traffic_signal with name if it is only a single light (e.g. the case with a named junction and different separate names for the lights) This way we could add an additional junction=* to the nodes with named traffic_signal and once all lights are tagged separately only use junction=* for ways. Additionally we have a better hint for the renderer what to render and diversify between a named junction and single named traffic_signals. cu fly Sorry, was kind of confusing, try again: 1. simple solution with only one node junction=yes/traffic_signal/* highway=traffic_signal (if the junction has lights) name=* 2. area junction=yes/traffic_signal/* name=* Maybe also highway=junction [1] could be used. Renderer could use junction=* to determine the needed icon and we stay consistant with the use of traffic_signals. This makes detailed tagging possible while adding the information for renderers to Hm, I am not sure if I understand you correctly. You want to use junction=yes not on nodes anymore, but only on areas – and change the currently existing cases in OSM? No, no problem with junction=* on nodes but in long term only needed for rare situations and low detailed mapping If so, I would disagree here. We have a yet existing tagging that works well for both – named junctions and names traffic signals – as long as this are simple junctions like https://wiki.openstreetmap.org/wiki/File:Junction_yes_example_1.png My proposal keeps the existing tagging for simple junctions – and extends it also to complex junctions. I am not convinced in changing the current tagging practice for simple junctions and require changing a lot of yet existing data in OSM. Currently I do not know of any situation where we have at the same place on the ground a different junction name and a different traffic signal name. It seems to me a barely theoretical problem. Maybe that does not mean that such a situation is impossible to exist. However, we should create our tagging scheme starting from the situation on the ground, and this seems to be either junction names or traffic signal names, but not both things at the same time. Replace an existing simple practice with a new complicate practice just to solve a problem that does probably not exist on the ground? Well, I just followed this thread: Am 16.09.2014 16:49, schrieb Satoshi IIDA: 2014-09-16 23:38 GMT+09:00 fly lowfligh...@googlemail.com: The name belongs to the junction and not to the traffic_signal, am I wrong ? In Japan, Hokkaido region, there is 4 traffic_signals on 1 junction. Each traffic_signals and 1 junction has different name. Indeed it is rare case. But I think we need Lukas's idea to support it. However, I think it is nevertheless a good idea to think about this case. I would propose to leave the existing tagging for simple intersections as it is (with tagging on a node). Moreover, for the rare case that we have a junction and a traffic signal with different names, one of them could be represented by an area around the other one (and same thing on complex junctions/traffic signal systems). Thus, we keep a door open to tag two different names, just for the case that sometime we really need it. Nevertheless, we do not break compatibility with the current practice, and we do not make things unnecessarily complicate for the real-world cases. Ok, here we are common. Hope my thoughts are better understandable this time. Cheers fly forgot the link [1] https://wiki.openstreetmap.org/wiki/Proposed_features/highway=junction ___ Tagging mailing list Tagging@openstreetmap.org
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
On Tue, Sep 16, 2014 at 8:53 PM, Lukas Sommer sommer...@gmail.com wrote: For the junction! For a named junction with a (not named) traffic signal: junction=yes + highway=traffic_signals. (Quite common on Korea – on the ground, not in the database.) Ok, I improved the wiki about this :http://wiki.openstreetmap.org/wiki/Tag:highway%3Dtraffic_signals#Named_traffic_signals.2Ftraffic_signal_systems_.28Japan.E2.80.A6.29 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
Would it not be more straight forward to use junction=traffic_signal in Japan and only use highway=traffic_signal for the real lights ? Hm, I’m not sure. It could separete clearly the individual traffic signals from the traffic signal system/the covered area. The downside would be that we introduce a new tag, and if you are a contributer and you want just add such a name to OSM, you have to deal with two different taggings: – highway=traffic_signals + name=* for simple cases (as currently) – junction=traffic_signal + name=* for the complex cases. Not sure, but it seems to be more complicate? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
Am 16.09.2014 08:54, schrieb Lukas Sommer: Would it not be more straight forward to use junction=traffic_signal in Japan and only use highway=traffic_signal for the real lights ? Hm, I’m not sure. It could separete clearly the individual traffic signals from the traffic signal system/the covered area. The downside would be that we introduce a new tag, and if you are a contributer and you want just add such a name to OSM, you have to deal with two different taggings: – highway=traffic_signals + name=* for simple cases (as currently) – junction=traffic_signal + name=* for the complex cases. Not sure, but it seems to be more complicate? Simply use junction=traffic_signal as addition to highway=traffic_signal. In long terms, we will have two separate objects. The name belongs to the junction and not to the traffic_signal, or am I wrong ? cu fly ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
The name belongs to the junction and not to the traffic_signal, or am I wrong ? In Japan, Hokkaido region, there is 4 traffic_signals on 1 junction. Each traffic_signals and 1 junction has different name. Indeed it is rare case. But I think we need Lukas's idea to support it. 2014-09-16 23:38 GMT+09:00 fly lowfligh...@googlemail.com: Am 16.09.2014 08:54, schrieb Lukas Sommer: Would it not be more straight forward to use junction=traffic_signal in Japan and only use highway=traffic_signal for the real lights ? Hm, I’m not sure. It could separete clearly the individual traffic signals from the traffic signal system/the covered area. The downside would be that we introduce a new tag, and if you are a contributer and you want just add such a name to OSM, you have to deal with two different taggings: – highway=traffic_signals + name=* for simple cases (as currently) – junction=traffic_signal + name=* for the complex cases. Not sure, but it seems to be more complicate? Simply use junction=traffic_signal as addition to highway=traffic_signal. In long terms, we will have two separate objects. The name belongs to the junction and not to the traffic_signal, or am I wrong ? cu fly ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
On Tue, Sep 16, 2014 at 6:38 PM, Lukas Sommer sommer...@gmail.com wrote: Currently in OSM we use yet highway=traffic_signals for traffic signal names in Japan. And we use yet junction=yes for junction names in Korea. Sounds easy but... how do you tag a named junction with a traffic signal ? highway=traffic_signal + junction=yes + name=* means that name is for the junction or for the traffic signals ? And can we imagine a case where the junction and the traffic signals are both named (and possibly differently) ? Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
how do you tag a named junction with a traffic signal ? highway=traffic_signal + junction=yes + name=* means that name is for the junction or for the traffic signals ? For the junction! For a named junction with a (not named) traffic signal: junction=yes + highway=traffic_signals. (Quite common on Korea – on the ground, not in the database.) For a named traffic signal with a (not named) junction: simply highway=traffic_signals. And can we imagine a case where the junction and the traffic signals are both named (and possibly differently) ? Good point. That would be difficult… Currently I do not know of such a case. Further thoughts about this? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
Correct me if I'm wrong, but it sounds like the end goal is: - to have junction names in korea, regardless of if they are traffic lights, and the symbol used there doesn't imply traffic lights, just a junction. - In Japan, the old junction system evolved to be named traffic signals, and the symbol used there a (horizontal) signal - so the end goal is to have the name and the signal icon shown over the intersection with it's name. so the complex solution is to map the the junction, (with different tags for Japan and Korea) with the area's way sharing nodes with the traffic signals. - in Japan's case, the complex solution must only render a single traffic icon, or it will ruin the purpose of using the intersection icon. Note: I'm not sure about Korea, but because there is no such thing as street addresses in Japan - just lot numbers in (sometimes random) sequence across the section, the sections are somewhat in a grid (regardless of what street is adjacent to the property, or what street it gets accessed from), all maps are used in a relative fashion (Start at Matsu Station, go two lights down, turn left at the temple, and turn right at intersection named Honcho 3), not in an absolute way (here's the 300 block of Main street, and my goal is 322 Main St, so it will be right about here). named intersections may be named in sequence, (Honcho 1, Honcho 2, Honcho 3 in order) but this is not really reflected in the location address. Any ad for a business or shop has a tiny map printed on it to show you the way to the shop, and most neighborhoods have residential maps on fences to show you where people live, to use if you were visiting some location before the days of Google Maps. in the past, adverts always used the common starting point of a train station, showing you how many actual signals, any named signals, temples, gas stations, or schools that were the way to your destination. This relative mapping has added Motorway Junctions and Primary Road junctions as starting points as time has gone on. The gist of what I'm trying to say is that accurately rendering a single signal icon is paramount for using a rendered map in Japan, because counting the number of signals between you and your destination is a commonly used and commonly advertised method of navigation when not using a GPS/NAVI. The western way of using street addresses and road signs displaying names of roads means finding your way without landmarks is easy, and it is what OSM is built around, but it is not the way people use maps here in Japan. Since Residential, Unclassified, and Tertiary roads are not named in Japan, the iconography and labeling of things besides the roads themselves is much more important. Javbw On Sep 17, 2014, at 3:53 AM, Lukas Sommer sommer...@gmail.com wrote: how do you tag a named junction with a traffic signal ? highway=traffic_signal + junction=yes + name=* means that name is for the junction or for the traffic signals ? For the junction! For a named junction with a (not named) traffic signal: junction=yes + highway=traffic_signals. (Quite common on Korea – on the ground, not in the database.) For a named traffic signal with a (not named) junction: simply highway=traffic_signals. And can we imagine a case where the junction and the traffic signals are both named (and possibly differently) ? Good point. That would be difficult… Currently I do not know of such a case. Further thoughts about this? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
Okay, I’ve tried to work out more in detail idea 4. Please considere https://wiki.openstreetmap.org/wiki/Proposed_features/Tagging_for_complex_junctions_or_traffic_signals_that_are_named and make comments. Lukas Sommer 2014-09-02 4:50 GMT+00:00 Satoshi IIDA nyamp...@gmail.com: Hello from Japan, @Lukas are the names of the traffic signals/junctions actually used in addresses (and in principal would be a suitable value for addr:place in an address)? No. We realize the name of traffic signal only for routing and navigation on local district. It is very separated concept from place (residence of human kind) tag or addr:* (postal delivery) tag. The name of traffic signal is not used as addressing system. And if there are very dense traffic signals, occasionally the names are like... XZY Conter(Chuo), XZY North, XZY West, or so. # XZY is the name of place or district, like Roppongi or Akihabara. Following maybe off topic... Hence, some JP mappers had proposed place=locality for old/famous name for mountain path crossing. e.g. XZY tsuji (辻, crossing) or XZY Touge (峠, peak). They may be acceptable, because we realize them as old/famous place name. But I do not feel that it would not suite for modern traffic_signal system. 2014-08-26 6:34 GMT+09:00 Jean-Marc Liotier j...@liotier.org: On 08/25/2014 11:09 PM, Lukas Sommer wrote: In Ivory Coast, you have addresses like “in front of the XYZ crossroad” or “from XYZ crossroad 50 m towards the big fueling station”. Rather a sort of instructions for getting somewhere than an address in the european sense. Obviously “from XYZ crossroad 50 m towards the big fueling station” will be applied to various houses (usually, when you have arrived, you make a phone call to the person that you want to meet, and the person comes to the road to search you and help you with the last part of the way – I can guarantee you that this is very time-consuming ;-) That said, people in quite a few African countries have a postal address (PO box in most cases) distinct from the address of their residence, so the problem of shoehorning directions in the standard address fields of European-designed software is side-stepped more often than not. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
Hey Would it not be more straight forward to use junction=traffic_signal in Japan and only use highway=traffic_signal for the real lights ? Just my two ct fly Am 15.09.2014 19:24, schrieb Lukas Sommer: Okay, I’ve tried to work out more in detail idea 4. Please considere https://wiki.openstreetmap.org/wiki/Proposed_features/Tagging_for_complex_junctions_or_traffic_signals_that_are_named and make comments. Lukas Sommer 2014-09-02 4:50 GMT+00:00 Satoshi IIDA nyamp...@gmail.com mailto:nyamp...@gmail.com: Hello from Japan, @Lukas are the names of the traffic signals/junctions actually used in addresses (and in principal would be a suitable value for addr:place in an address)? No. We realize the name of traffic signal only for routing and navigation on local district. It is very separated concept from place (residence of human kind) tag or addr:* (postal delivery) tag. The name of traffic signal is not used as addressing system. And if there are very dense traffic signals, occasionally the names are like... XZY Conter(Chuo), XZY North, XZY West, or so. # XZY is the name of place or district, like Roppongi or Akihabara. Following maybe off topic... Hence, some JP mappers had proposed place=locality for old/famous name for mountain path crossing. e.g. XZY tsuji (辻, crossing) or XZY Touge (峠, peak). They may be acceptable, because we realize them as old/famous place name. But I do not feel that it would not suite for modern traffic_signal system. 2014-08-26 6:34 GMT+09:00 Jean-Marc Liotier j...@liotier.org mailto:j...@liotier.org: On 08/25/2014 11:09 PM, Lukas Sommer wrote: In Ivory Coast, you have addresses like “in front of the XYZ crossroad” or “from XYZ crossroad 50 m towards the big fueling station”. Rather a sort of instructions for getting somewhere than an address in the european sense. Obviously “from XYZ crossroad 50 m towards the big fueling station” will be applied to various houses (usually, when you have arrived, you make a phone call to the person that you want to meet, and the person comes to the road to search you and help you with the last part of the way – I can guarantee you that this is very time-consuming ;-) That said, people in quite a few African countries have a postal address (PO box in most cases) distinct from the address of their residence, so the problem of shoehorning directions in the standard address fields of European-designed software is side-stepped more often than not. _ Tagging mailing list Tagging@openstreetmap.org mailto:Tagging@openstreetmap.org https://lists.openstreetmap.__org/listinfo/tagging https://lists.openstreetmap.org/listinfo/tagging -- Satoshi IIDA mail: nyamp...@gmail.com mailto:nyamp...@gmail.com twitter: @nyampire ___ Tagging mailing list Tagging@openstreetmap.org mailto:Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
Hello from Japan, @Lukas are the names of the traffic signals/junctions actually used in addresses (and in principal would be a suitable value for addr:place in an address)? No. We realize the name of traffic signal only for routing and navigation on local district. It is very separated concept from place (residence of human kind) tag or addr:* (postal delivery) tag. The name of traffic signal is not used as addressing system. And if there are very dense traffic signals, occasionally the names are like... XZY Conter(Chuo), XZY North, XZY West, or so. # XZY is the name of place or district, like Roppongi or Akihabara. Following maybe off topic... Hence, some JP mappers had proposed place=locality for old/famous name for mountain path crossing. e.g. XZY tsuji (辻, crossing) or XZY Touge (峠, peak). They may be acceptable, because we realize them as old/famous place name. But I do not feel that it would not suite for modern traffic_signal system. 2014-08-26 6:34 GMT+09:00 Jean-Marc Liotier j...@liotier.org: On 08/25/2014 11:09 PM, Lukas Sommer wrote: In Ivory Coast, you have addresses like “in front of the XYZ crossroad” or “from XYZ crossroad 50 m towards the big fueling station”. Rather a sort of instructions for getting somewhere than an address in the european sense. Obviously “from XYZ crossroad 50 m towards the big fueling station” will be applied to various houses (usually, when you have arrived, you make a phone call to the person that you want to meet, and the person comes to the road to search you and help you with the last part of the way – I can guarantee you that this is very time-consuming ;-) That said, people in quite a few African countries have a postal address (PO box in most cases) distinct from the address of their residence, so the problem of shoehorning directions in the standard address fields of European-designed software is side-stepped more often than not. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
Am 24.08.2014 13:20, schrieb Lukas Sommer: Hello everyone. In some countries (Japan, Korea…), people orient themselves in the local area using the names of road junctions or traffic signals rather then the names of streets. I have documented the current tagging practice for simple junctions at the following new wiki pages: http://wiki.openstreetmap.org/wiki/Named_spots_instead_of_street_names http://wiki.openstreetmap.org/wiki/Tag:junction%3Dyes Furthermore, some more text has been added here: http://wiki.openstreetmap.org/wiki/Tag:highway%3Dtraffic_signals#Named_traffic_signals.2Ftraffic_signal_systems_.28Japan.E2.80.A6.29 Feedback and/or corrections are welcome. The current tagging practice works well for simple junctions, but makes problems on complex junctions. Therefore, the proposal http://wiki.openstreetmap.org/wiki/Proposed_features/Tagging_for_complex_junctions_or_traffic_signals_that_are_named has been created. Particularly if you are mapping in one of the concerned countries please participate at the discussion at http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Tagging_for_complex_junctions_or_traffic_signals_that_are_named Nice summary. Thanks Did you have a look at the three existing proposals about complex junctions ? All are linked under: https://wiki.openstreetmap.org/wiki/Proposed_features/Junction Note, that in Germany micromapping is mapping highway=traffic_sign + crossing=traffic_sign/* on a node at the crossing and not at the intersection node. I even have found highway=traffic_signal at the road marking and another highway=crossing for the pedestrian crossing both in advance of the intersection node. Personally, I did start to add direction=* to traffic_signals for only one direction. Cheers fly ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
Am 25.08.2014 16:46, schrieb fly: . Did you have a look at the three existing proposals about complex junctions ? .. IMHO one of the nice aspects of variant 4 (using an area) is that it really doesn't collide with however the routing aspects of the junction are mapped. @Lukas are the names of the traffic signals/junctions actually used in addresses (and in principal would be a suitable value for addr:place in an address)? Simon signature.asc Description: OpenPGP digital signature ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
@Simon are the names of the traffic signals/junctions actually used in addresses (and in principal would be a suitable value for addr:place in an address)? Hm, I’m not sure (I’m not familiar with the group of addr:* keys). At least they are places in the sense that they have a defined location. In Japan and in Korea, I’m not sure how this is handeled. In Ivory Coast, you have addresses like “in front of the XYZ crossroad” or “from XYZ crossroad 50 m towards the big fueling station”. Rather a sort of instructions for getting somewhere than an address in the european sense. Obviously “from XYZ crossroad 50 m towards the big fueling station” will be applied to various houses (usually, when you have arrived, you make a phone call to the person that you want to meet, and the person comes to the road to search you and help you with the last part of the way – I can guarantee you that this is very time-consuming ;-) Best regards Lukas Sommer 2014-08-25 15:21 GMT+00:00 Simon Poole si...@poole.ch: Am 25.08.2014 16:46, schrieb fly: . Did you have a look at the three existing proposals about complex junctions ? .. IMHO one of the nice aspects of variant 4 (using an area) is that it really doesn't collide with however the routing aspects of the junction are mapped. @Lukas are the names of the traffic signals/junctions actually used in addresses (and in principal would be a suitable value for addr:place in an address)? Simon ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
On 08/25/2014 11:09 PM, Lukas Sommer wrote: In Ivory Coast, you have addresses like “in front of the XYZ crossroad” or “from XYZ crossroad 50 m towards the big fueling station”. Rather a sort of instructions for getting somewhere than an address in the european sense. Obviously “from XYZ crossroad 50 m towards the big fueling station” will be applied to various houses (usually, when you have arrived, you make a phone call to the person that you want to meet, and the person comes to the road to search you and help you with the last part of the way – I can guarantee you that this is very time-consuming ;-) That said, people in quite a few African countries have a postal address (PO box in most cases) distinct from the address of their residence, so the problem of shoehorning directions in the standard address fields of European-designed software is side-stepped more often than not. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
Hello everyone. In some countries (Japan, Korea…), people orient themselves in the local area using the names of road junctions or traffic signals rather then the names of streets. I have documented the current tagging practice for simple junctions at the following new wiki pages: http://wiki.openstreetmap.org/wiki/Named_spots_instead_of_street_names http://wiki.openstreetmap.org/wiki/Tag:junction%3Dyes Furthermore, some more text has been added here: http://wiki.openstreetmap.org/wiki/Tag:highway%3Dtraffic_signals#Named_traffic_signals.2Ftraffic_signal_systems_.28Japan.E2.80.A6.29 Feedback and/or corrections are welcome. The current tagging practice works well for simple junctions, but makes problems on complex junctions. Therefore, the proposal http://wiki.openstreetmap.org/wiki/Proposed_features/Tagging_for_complex_junctions_or_traffic_signals_that_are_named has been created. Particularly if you are mapping in one of the concerned countries please participate at the discussion at http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Tagging_for_complex_junctions_or_traffic_signals_that_are_named Lukas Sommer ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
