Re: [Tagging] Tunnels and bridges
On Thu, Jan 31, 2013 at 11:14 AM, Martin Koppenhoefer dieterdre...@gmail.com wrote: 2013/1/31 Martin Vonwald imagic@gmail.com: In my opinion this is a rather obvious approach therefore I'm not surprised that someone already came up with it earlier. But I am definitively surprised that we don't have any documentation in the wiki for it. there are real examples, e.g. these two: http://www.openstreetmap.org/browse/way/42922473 http://www.openstreetmap.org/browse/way/44097288 which started with bridge=area and name=* but were fixed in the meantime (fix nonconforming uses of bridge tag) ;-) My sincere apologies. At the time, I was rooting through the long tail of bridge= values trying to figure out what values were being used and should be supported by a new proposal, fixing typos (bridge=ye) and so on; I really shouldn't have removed that. IIRC, it was only two bridges I saw in Italy that were tagged that way, so I haven't been going around removing large numbers of bridges marked up this way. It was neither a common nor a documented usage, which is probably why I was overbold in removing the markup. I have no objection to a good system for dealing with outlining bridge area, multiple ways sharing a span, and so forth, but as I haven't any particularly good ideas to offer, I haven't really engaged the problem. -- Chris Hoess ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
On 01.02.2013 07:22, Martin Vonwald (imagic) wrote: We have a spatial database so if all features are within a closed way there is no need for a relation. Why is there a different reasoning for a bridge? Because it is usually _not_ the case that all the features within the bridge outline polygon belong to the bridge. There are other reasons - for one, not all sides of the outline polygon are created equal, as some connect to the ground and others are bridge edges. This is actually an important distinction for rendering. Still, the most clear difference is likely the one mentioned above. Tobias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
2013/2/1 Pieren pier...@gmail.com: On Fri, Feb 1, 2013 at 11:06 AM, Tobias Knerr o...@tobias-knerr.de wrote: - ways must be split at the beginning and end of the bridge Not necessarily. layer can be set on the highway before and after the bridge (if it is done carefully and not interfer with other crossings). What I like in this modeling is that we could avoid splitting if no attribute of the road is affected by the bridge (or tunnel). IMHO we shouldn't avoid splitting as it will tend to make our data less consistent. Think about ways under the bridge. Also we are already splitting the ways for lots of reasons (routes and turn_restrictions, changing attributes like maxspeed, surface, width, lanes, oneway, lit, etc.), there is really no point in not splitting at bridges (IMHO). It would require everyone to do expensive ST_Within queries to determine simple stuff like where on the road is a bridge and which object is above which. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
2013/2/1 Martin Koppenhoefer dieterdre...@gmail.com: 2013/2/1 Pieren pier...@gmail.com: On Fri, Feb 1, 2013 at 11:06 AM, Tobias Knerr o...@tobias-knerr.de wrote: - ways must be split at the beginning and end of the bridge Not necessarily. layer can be set on the highway before and after the bridge (if it is done carefully and not interfer with other crossings). What I like in this modeling is that we could avoid splitting if no attribute of the road is affected by the bridge (or tunnel). IMHO we shouldn't avoid splitting as it will tend to make our data less consistent. Think about ways under the bridge. Also we are already splitting the ways for lots of reasons (routes and turn_restrictions, changing attributes like maxspeed, surface, width, lanes, oneway, lit, etc.), there is really no point in not splitting at bridges (IMHO). It would require everyone to do expensive ST_Within queries to determine simple stuff like where on the road is a bridge and which object is above which. Correct. Not only would it be more difficult for consumers it would also be different from the way we tag right now. What I have in mind is a tagging scheme that starts simple and allows to add more details while maintaining the original (simple) tagging. Imagine a bridge as it is mapped now: a OSM-way with bridge=yes and layer=1 (just an example). The way is split right at both ends of the bridge, because the tag bridge=yes should only be on the bridge itself. Now imagine there is not a single way representing the bridge but two. One now wants to improve the tagging be indicating that these two ways are in fact one bridge. This now can be done quite easily but just adding a way describing the outline of the bridge and tagging it with man_made=bridge and layer=1. At the intersection of the outline with the ways those ways should have connecting nodes, because right at this point the ways - according to the simple current tagging scheme are split so that bridge=yes and layer=1 can be tagged. So we reuse those nodes and connect them to the new outline. We do NOT have to change any existing tagging! Now imagine that this bridge also has a second level. Again we add a way for the outline, again we tag it with man_made=bridge. So again no change to the existing ways/tags. As we have two levels now we need the relation which we use the combine the ways of the two levels (with different layer tags) and the outline. I referred only to bridge-related keys in the statements above. Tags like e.g. name usually have to be adapted but that's just because they are usually tagged incorrect. Common example: the name tag of the ways on a bridge contains the name of the bridge instead of the name of the road. Now we can put the name of the road AND the name of the bridge where it belongs. regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
On Fri, Feb 1, 2013 at 12:46 PM, Martin Vonwald imagic@gmail.com wrote: are split so that bridge=yes and layer=1 can be tagged. So we reuse those nodes and connect them to the new outline. We do NOT have to change any existing tagging! By consumer, we all think about renderer (which is in my knowledge the only consumer looking for bridges in OSM atm). If you keep the bridge tag on the multiple highways, it is duplicating the information. And you don't fix the rendering issue because Mapnik will continue to draw one bridge per highway. To avoid the duplicate rendering, we need the bridge tag only on the polygon. But then, the rendering software will have to decide to draw the polygon itself. Or like today, draw some symbols along the line. In both cases, if you want a correct rendering (draw only one bridge) wihtout simply drawing the bridge polygon, the software will need some spatial requests anyway (to determin the group of highway segments that belong to the same bridge). Pieren ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
2013/2/1 Pieren pier...@gmail.com: If you keep the bridge tag on the multiple highways, it is duplicating the information. yes, this is fundamental if you want to keep current renderers working (it also ensures that filtering e.g. just the highway-network will still retain the bridge information). And you don't fix the rendering issue because Mapnik will continue to draw one bridge per highway. this will entirely depend on your rendering style, it is not a mapnik issue. To avoid the duplicate rendering, we need the bridge tag only on the polygon. But then, the rendering software will have to decide to draw the polygon itself. also, you would have to do more complex analysis this way because areas are commonly rendered with their real width while highways are rendered with augmented width (the lower the zoom level the more). So for a bridge in (e.g.) zoom 15 you would have to take care that the bridge outline isn't hidden underneath the rendered road. Or like today, draw some symbols along the line. In both cases, if you want a correct rendering (draw only one bridge) wihtout simply drawing the bridge polygon, the software will need some spatial requests anyway (to determin the group of highway segments that belong to the same bridge). +1, yes, if you want to evaluate the bridge polygons you will have to do spatial analysis, but if you don't want to you can simply continue like you did (noone would be forced to do that analysis) cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
Am 01.02.2013 13:30, schrieb Martin Koppenhoefer: 2013/2/1 Pieren pier...@gmail.com: And you don't fix the rendering issue because Mapnik will continue to draw one bridge per highway. this will entirely depend on your rendering style, it is not a mapnik issue. and it might be a non-issue: without rendering the bridge it's none - everything keeps the same as before if you ignore the polygon. with rendering the bridge in the right position at the rendering layer-stack, it will be correct, as long as no transparent/semi-transarent bridge-area-fill is used: - draw bridge way - draw bridge area - draw highway I didn't look into the code, but it looks like it's done this way already (without the bridge area drawing of course), compare some bridges as examples: http://www.openstreetmap.org/?lat=52.604488lon=10.028806zoom=18layers=M http://www.openstreetmap.org/?lat=52.606703lon=10.026162zoom=18layers=M http://www.openstreetmap.org/?lat=52.42302lon=10.737998zoom=18layers=M http://www.openstreetmap.org/?lat=52.425467lon=10.738626zoom=18layers=M http://www.openstreetmap.org/?lat=52.430711lon=10.799646zoom=18layers=M the way I propose above would - hide the bridge way if and only if there's a bridge area - keep the old style if there's no bridge area To avoid the duplicate rendering, we need the bridge tag only on the polygon. But then, the rendering software will have to decide to draw the polygon itself. Not necessarily, see above. also, you would have to do more complex analysis this way because areas are commonly rendered with their real width while highways are rendered with augmented width (the lower the zoom level the more). So for a bridge in (e.g.) zoom 15 you would have to take care that the bridge outline isn't hidden underneath the rendered road. let's look deeper into it: case 1: the legacy style (road with bridge casing) is painted thinner than the bridge areas width. That's the case you don't refer to here, but it's the easiest case as it's the one I described above: the old bridge casing is completely hidden behind the bridge area, everything is fine. case 2: the legacy style of at least one bridge highway is painted that wide that it's outer line(s) is/are outside of the bridge area (including casing). This way the legacy styles bridge casing is visible where the bridge area or it's casing is drawn on top of it, and the bridge area is covered by the highway on top. To summarize: If the bridge outline is hidden underneath the rendered road, the old bridge casing is not hidden (as it's per definition outside of the rendered road). Therefore it's not a problem. regards Peter ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
2013/2/1 Peter Wendorff wendo...@uni-paderborn.de: case 2: the legacy style of at least one bridge highway is painted that wide that it's outer line(s) is/are outside of the bridge area (including casing). This way the legacy styles bridge casing is visible where the bridge area or it's casing is drawn on top of it, and the bridge area is covered by the highway on top. To summarize: If the bridge outline is hidden underneath the rendered road, the old bridge casing is not hidden (as it's per definition outside of the rendered road). Therefore it's not a problem. Yes, it is not a real show stopper, but the rendering result in this way would be somehow coincidental (there could for instance be interferences from the casing and the polygon leading to quite ugly artifacts). The cleaner solution would be to suppress rendering of casings when there is an outline polygon. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
Am 01.02.2013 14:19, schrieb Martin Koppenhoefer: 2013/2/1 Peter Wendorff wendo...@uni-paderborn.de: case 2: the legacy style of at least one bridge highway is painted that wide that it's outer line(s) is/are outside of the bridge area (including casing). This way the legacy styles bridge casing is visible where the bridge area or it's casing is drawn on top of it, and the bridge area is covered by the highway on top. To summarize: If the bridge outline is hidden underneath the rendered road, the old bridge casing is not hidden (as it's per definition outside of the rendered road). Therefore it's not a problem. Yes, it is not a real show stopper, but the rendering result in this way would be somehow coincidental (there could for instance be interferences from the casing and the polygon leading to quite ugly artifacts). The cleaner solution would be to suppress rendering of casings when there is an outline polygon. Sure, but this would occur only in case a renderer - renders the bridge-area - renders the old bridge casing - and does not calculate the conflict in it's preprocessing. of course we could add a rendering hint like part_of_a_bridge_area=yes to make it easier for renderers to determine that case, but on the other hand it's a reasonable preprocessing step to calculate these conflicts (sharing nodes between ways having bridge=* and ways having the bridge-area-tag = remove the bridge=yes tag for rendering). regards Peter ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
2013/2/1 Peter Wendorff wendo...@uni-paderborn.de but on the other hand it's a reasonable preprocessing step to calculate these conflicts (sharing nodes between ways having bridge=* and ways having the bridge-area-tag = remove the bridge=yes tag for rendering). I think that's harder than you think. What if you have the next example: http://i.imgur.com/ETBsfSQ.png How does the renderer preprocesor know if the middle line is inside the bridge area? It has to make some difficult calculations for that. And the blue line is outside, although it shares two nodes with the bridge. (I know it would rarely happen, but it will happen.) And I don't know why you guys think black borders on the street over a bridge look ugly. We have examples: http://osm.org/go/0BOd2GJhP-- Which look good to me, and if you zoom out, those black borders are needed again: http://osm.org/go/0BOd2B4U-- because the street outgrows the bridge area. Janko Mihelić ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
Am 01.02.2013 um 15:01 schrieb Janko Mihelić jan...@gmail.com: I think that's harder than you think. What if you have the next example: http://i.imgur.com/ETBsfSQ.png How does the renderer preprocesor know if the middle line is inside the bridge area? It has to make some difficult calculations for that. And the blue line is outside, although it shares two nodes with the bridge. (I know it would rarely happen, but it will happen.) If I'm not mistaken it could work like this: If a way with bridge=yes is connected to a way with man_made=bridge follow the way with bridge=yes and all connected ways until you reach a way without bridge=yes. All those ways belong to the bridge marked with man_made=bridge. Regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
Am 01.02.2013 15:01, schrieb Janko Mihelic': 2013/2/1 Peter Wendorff wendo...@uni-paderborn.de mailto:wendo...@uni-paderborn.de but on the other hand it's a reasonable preprocessing step to calculate these conflicts (sharing nodes between ways having bridge=* and ways having the bridge-area-tag = remove the bridge=yes tag for rendering). I think that's harder than you think. What if you have the next example: http://i.imgur.com/ETBsfSQ.png How does the renderer preprocesor know if the middle line is inside the bridge area? It has to make some difficult calculations for that. And the blue line is outside, although it shares two nodes with the bridge. (I know it would rarely happen, but it will happen.) Sure it will happen. And yes, that's more complicated to achieve, but look at the renderings in many ordinary streets on all common osm renderings: As soon as was are divided into pieces, you likely get very dense lables as mapnik renders labels on every part of the street individually. Examples: http://osm.org/go/0BOdPbE~N-- http://osm.org/go/0GPCAb0oG-- (Ostenallee near the intersection) http://osm.org/go/0GlK2S06_-- (Liboriberg: two parts bridge (as the bus routes use the bridge Kasseler-Tor-Brücke), two labels left and right for the non-bridge-part of the street. So that's a general problem of renderers, yet - but it should be solved imho, and this might be done independent of concrete tags or features, to combine features sharing the matching properties for a particular style. Other use cases for something like that: - dashed line patterns now interfere when coming together on different ways as there occur shorter or longer dashes or spaces at the connection node - labels (see above) could be rendered after combining more parts of the street, if they are skipped due to their size on the short single way parts - the bridge example of course And I don't know why you guys think black borders on the street over a bridge look ugly. We have examples: http://osm.org/go/0BOd2GJhP-- I personally never said this looks ugly. I didn't even look into what would happen in the current style with these casings, but for any style using mapnik the way I described should work to not interfere with a possibly more verbose bridge casing than in the mapnik style in more or less any case. Which look good to me, and if you zoom out, those black borders are needed again: http://osm.org/go/0BOd2B4U-- because the street outgrows the bridge area. That's why I promoted to keep bridge=yes nevertheless (see previous posts) regards Peter ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
Am 01.02.2013 um 15:33 schrieb Peter Wendorff wendo...@uni-paderborn.de: That's why I promoted to keep bridge=yes nevertheless (see previous posts) We definitively should keep bridge=yes! Regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
Thanks for the conclusion, Martin. I have no problem to change my building=bridge into man_made but we have to straighten our definition of building=*. Same is also true for bridge and tunnel as for a tunnel you need a certain length to call it tunnel (think it is 80m), everything else is a bridge. In Germany more and more bridges are built for animal crossing often without any highway. Think we are missing some points though: In my opinion the major problem is that without the relations (type=bridge/tunnel) we do not have any connection between a way crossing under a bridge/above a tunnel. Especially for waterways this might be really useful information not only for boot traffic but also in case of high water and flood. I know bridges with on name but several parallel independent structures. The type=tunnel is not wide spread probably due to missing information and no working routing without GPS, but we really need it. * For sure to add the proper name and ref as it has nothing to do with the highway/railway/powerline leading through the tunnel * to group the different tubes as for example on Swiss motorways they often belong together and there are also connections between them and escape tubes. * to add all the escape ways, kilometre signs and maybe the air conditioning system. My conclusion is: 1. We can introduce man_made=bridge in favour of building=bridge. 2. We either need a relation for almost every bridge/tunnel or a new subtagging system on the highway/railway etc like bridge:name, bridge:ref ... 3. Rendering might be one problem but the data should also be useful for other task like: Tell me all bridges crossing a waterway/highway within a certain distance or along a route. 4. Not only a problem of this thread but we need to get much more developers to support relations (eg. renderes, editors, search engines and other consumers). This includes evaluating existing relations and adjusting them to be useful. cu fly ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
2013/2/1 fly lowfligh...@googlemail.com: straighten our definition of building=*. Same is also true for bridge and tunnel as for a tunnel you need a certain length to call it tunnel (think it is 80m), This is a misconception, there are actually no international (unified) standards for this, it depends on the country (or locally valid standards) and the 80 meter limit (in Germany) is not a general minimum limit for tunnels but is an exception for tunnels not drilled into the ground but created by excavating from above and covering succesively (the latter are also considered tunnels by the German DIN 1076 if longer than 80 meters). Think we are missing some points though: In my opinion the major problem is that without the relations (type=bridge/tunnel) we do not have any connection between a way crossing under a bridge/above a tunnel. Especially for waterways this might be really useful information not only for boot traffic but also in case of high water and flood. I wouldn't add the ways below into a bridge relation, astonished that this is proposed. The relevant information for boat traffic below the bridge is the clearance (that depends other than on the bridge also on the water level) and should be tagged on the way it applies to (the part of the waterway below the bridge). The relation between the crossing way below and above is given by the geometry (and layer tags). I know bridges with one name but several parallel independent structures. yes, clearly the common name shouldn't be the only criterium cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
On 01/02/2013 15:02, fly wrote: 4. Not only a problem of this thread but we need to get much more developers to support relations (eg. renderes, editors, search engines and other consumers). This includes evaluating existing relations and adjusting them to be useful. +1 A relation explicitly establishes an intended association between features, whereas shared nodes do not. Many features share nodes, but have no intended association. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
By consumer, we all think about renderer (which is in my knowledge the only consumer looking for bridges in OSM atm). If you keep the bridge tag on the multiple highways, it is duplicating the information. I believe there's no obvious reason not to think that bridge=yes on a highway could be said to mean is on a bridge (attribute), and not this is a bridge (and a highway) (object). Then, it's no longer duplicate information. So far the tools have just deduced that there must be the (undrawn) bridge along the road, and would continue to do so if they do not bother themselves with the exact shape of the bridge deck. -- Alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
there and so on - so: keep them splitted and it's less work with more backwards compatibility. If they are not, it's up to you as a mapper if you want outdated renderers to use the old scheme or not. Most renderers and conversion tools work internally without a database (even if they first fetch the data for the area in question from a database) - many consumers of the data take an osm extract, and work on the ways one by one, one or multiple times, and draw them as such in appropriate order (say, mkgmap included). There's work going on to have mapnik draw the road name labels only once where a road has been split several times. Not by me, but see the SOTM slides linked to on page http://wiki.openstreetmap.org/wiki/State_Of_The_Map_2012/Saturday Parking map – make and break stuff Mappers split ways a lot, for a lot of reasons, so avoiding the split for a bridge and at the same time hiding the attribute in a) other, connected ways or b) a relation only or c) the spatial data seems ... making things unnecessary complex for the consumers. -- Alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
On Fri, Feb 1, 2013 at 11:21 PM, Pieren pier...@gmail.com wrote: By consumer, we all think about renderer (which is in my knowledge the only consumer looking for bridges in OSM atm). If you keep the bridge tag on the multiple highways, it is duplicating the information. And you don't fix the rendering issue because Mapnik will continue to draw one bridge per highway. I think any renderer that supports bridge relations will be smart enough to not also draw bridges on the highways. That is, if you have: highway=secondary bridge=yes layer=1 and a relation type=bridge and a bridge structure: man_made=bridge layer=1 Then any renderer that supports the relation and man_made=bridge will also not draw a bridge casing on the highway. (This is another example of why relations are much easier to process than using geospatial inferencing.) Steve To avoid the duplicate rendering, we need the bridge tag only on the polygon. But then, the rendering software will have to decide to draw the polygon itself. Or like today, draw some symbols along the line. In both cases, if you want a correct rendering (draw only one bridge) wihtout simply drawing the bridge polygon, the software will need some spatial requests anyway (to determin the group of highway segments that belong to the same bridge). Pieren ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Tunnels and bridges
Hi! I'm looking for some alternatives to map tunnels and bridges that contain several ways. I'm not really happy with the proposed relation [1]. Is there any other approach for this? I'm asking myself why don't we simply map the outline of the bridge/tunnel (the latter may be more difficult to obtain), tag it with something like structure=bridge (or similar, maybe even building=bridge), bridge=type (if necessary) and layer=x. Connect the ways running over the bridge to this structure, use the same layer tag and you're set. It is after all a physical object, so why don't we map it as such? I simply don't see any reason for a relation here. regards, Martin [1] http://wiki.openstreetmap.org/wiki/Relations/Proposed/Bridges_and_Tunnels ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
2013/1/31 Martin Vonwald imagic@gmail.com Hi! I'm looking for some alternatives to map tunnels and bridges that contain several ways. I'm not really happy with the proposed relation [1]. Is there any other approach for this? I'm asking myself why don't we simply map the outline of the bridge/tunnel (the latter may be more difficult to obtain), tag it with something like structure=bridge (or similar, maybe even building=bridge), bridge=type (if necessary) and layer=x. Connect the ways running over the bridge to this structure, use the same layer tag and you're set. It is after all a physical object, so why don't we map it as such? I simply don't see any reason for a relation here. +1, I like building=bridge. Wikipedia says that a building is, a structure used or intended for supporting or sheltering any use or continuous occupancy In this case, it is supporting a road (and in case of Ponte Vecchio, it supports a footway and houses) But tunnel isn't a building, so maybe man_made=tunnel? I like this better than relations too. Janko Mihelić ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
2013/1/31 Martin Vonwald imagic@gmail.com: Hi! I'm looking for some alternatives to map tunnels and bridges that contain several ways. I'm not really happy with the proposed relation [1]. Is there any other approach for this? I'm asking myself why don't we simply map the outline of the bridge/tunnel (the latter may be more difficult to obtain), tag it with something like structure=bridge (or similar, maybe even building=bridge), bridge=type (if necessary) and layer=x. Connect the ways running over the bridge to this structure, use the same layer tag and you're set. It is after all a physical object, so why don't we map it as such? I simply don't see any reason for a relation here. +1, drawing the outline seems a good approach as it permits to group visually (and topologically) different carriageways running over the same bridge (as opposed to two parallel bridges). Actually a classic bridge will often have several outlines when the abutments are mapped separately, and then you would use layer-tags and maybe would want to also add the abutments to the bridge-object (in this case a relation might be needed). For tunnels I am not sure if there are situations with several carriageways in the same tube (in this case a common outline made sense IMHO, while 2 parallel tubes should be (IMHO) considered 2 tunnels. Tunnels also have the practical problem that you can't see their inside on aerial imagery and GPS doesn't work inside, but this is a different issue aside from tagging. Whether building is a nice key might be disputable (a bridge technically isn't a building, but a technical structure, on the other hand I have always argued that building in OSM is a generic tag for all kind structures and not only those intended for humans to live inside), but personally I'd approve it. If we decide to use building=* for bridges the * should be always the same value (e.g. bridge) and not building=draw_bridge etc. (these details like bridge typology would go into subtags, allowing easy filtering of the bridges if you don't want to render them as buildings). These bridge-objects would also allow us to tag in an easy and standard way stuff like ref-numbers and bridge names (i.e. with ref and name and not requiring stuff like bridge_name...), have a common object to link WP-articles, etc. Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
On 31.01.2013 12:06, Martin Vonwald wrote: I'm looking for some alternatives to map tunnels and bridges that contain several ways. I'm not really happy with the proposed relation [1]. Is there any other approach for this? I'm asking myself why don't we simply map the outline of the bridge/tunnel (the latter may be more difficult to obtain), tag it with something like structure=bridge (or similar, maybe even building=bridge), bridge=type (if necessary) and layer=x. Connect the ways running over the bridge to this structure, use the same layer tag and you're set. For starters, the relation means that you do not have to rely on layer tags to find out which elements are on the bridge/tunnel (or even on which bridge/tunnel in the case of intersecting bridges or tunnels). I do not really have faith that mappers will reliably add correct layers... The relation at least makes the relationship explicit and works just the same way e.g. for multi-level bridges. But then the relation is also a lot more flexible. As you already hinted at, it makes knowing the outline optional, which is useful for tunnels where you cannot easily see it from aerial imagery. It also lets you map the edges instead of or in addition to an outline. This makes it potentially a lot easier to achieve the desired rendering. The flexibility would further extend to possible future additions. For example individually mapped bridge piers, as have been proposed in the bridge types proposal, could be easily associated with the bridge by the relation. Association by layer wouldn't really work as these are _under_ the bridge. So I think that this is a case where a relation is actually a good representation. With a decent preset instead of our (unfortunately) massively-overcomplex relation editors, editing this could be pretty intuitive even for beginners. In my opinion, the fact that a bridge is a physical entity actually makes understanding the relation easier. Tobias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
On 31.01.2013 13:24, Janko Mihelić wrote: I like building=bridge. Not a good choice imo. According to a recent discussion, mappers might want to use that tag specifically to map buildings built into bridges - like these: http://ampelmann-restaurant.de/content/images/1a162245ce191485484b155c6eae79b9.jpg Bridges also have to be handled completely differently in code than normal buildings for any remotely sophisticated rendering. So even if you want to avoid bridge relations (which I don't necessarily agree with, see my other mail), please choose a new, unambiguous key for the bridge outlines. Tobias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
2013/1/31 Tobias Knerr o...@tobias-knerr.de: On 31.01.2013 13:24, Janko Mihelić wrote: I like building=bridge. Not a good choice imo. According to a recent discussion, mappers might want to use that tag specifically to map buildings built into bridges - like these: http://ampelmann-restaurant.de/content/images/1a162245ce191485484b155c6eae79b9.jpg I wouldn't call this a bridge, it is a vault, but the bridge (or viaduct) if you wanted to map it would (IMHO) be the structure as a whole, not just a single segment. Bridges also have to be handled completely differently in code than normal buildings for any remotely sophisticated rendering. So even if you want to avoid bridge relations (which I don't necessarily agree with, see my other mail), please choose a new, unambiguous key for the bridge outlines. Yes, probably you would want to add a special treatment in rendering for bridges, but it wouldn't be necessary missleading or confusing to have them rendered the same way than a ordinary building. If there was a key building=bridge with a common usecase I won't see any ambiguity. There are bridge buildings, which don't carry roads or rails, like these: http://www.spiegel.de/pics/92/0,1020,1536992,00.jpg http://www.gropar.ch/typo3temp/pics/41b05acade.jpg http://www.schoendorfer.de/neu/baustellen/zollamt_walserberg/bilder/01.jpg and every building built on stuilts might structurally be a bridge but I still don't see the problem, you would distinct these by looking whether there is a road going over them on the same layer (ok, there might be a bridge-like building with a road on top of it, in this case you'd probably need the relation, but the relation would be useful anyway, this is not necessarily an alternative to relations in all situations, but could make them unneccesary in many cases)). cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
On Thu, Jan 31, 2013 at 2:06 PM, Martin Koppenhoefer dieterdre...@gmail.com wrote: I wouldn't call this a bridge, it is a vault, but the bridge (or viaduct) if you wanted to map it would (IMHO) be the structure as a whole, not just a single segment. Instead of building=bridge, you might choose man_made=bridge_deck or simply bridge=deck ? Btw, the idea is not new. Check this bridge I traced in march 2010: http://www.openstreetmap.org/browse/way/53582123/history I used the tags combination highway=bridge + area=yes. Then it was replaced by bridge=yes + area=yes and finally by building=bridge. I guess the building=* tag is used for rendering purpose. Which is not correct. Pieren ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
On 31/01/2013 12:37, Martin Koppenhoefer wrote: drawing the outline seems a good approach as it permits to group visually (and topologically) different carriageways running over the same bridge (as opposed to two parallel bridges). This is approach is used by IHO for marine chart data. Where a bridge has more than span, they further divide the bridge outline into two or more butted polygons, one for each span, so that each span can have its own height width attributes. They also map bridge piers as separate objects. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
Am 31.01.2013 14:44, schrieb Martin Vonwald: In my opinion this is a rather obvious approach therefore I'm not surprised that someone already came up with it earlier. But I am definitively surprised that we don't have any documentation in the wiki for it. I see a lot of bridges with many ways running over it (two footways, two cycleways, two carriageways) and on the map it just looks AWFUL! But the renderer can not display it any better because it doesn't have the appropriate information. So I would suggest that we decide which tag would be good for the bridge, document it and start tagging it this way to get things going ;-) Let's first concentrate on bridges. In my opinion we need the following tags: * bridge=type : use this tag just like it is used at the moment. If the value would be yes it should be optional. +1 for using bridge=type, -1 for defining it as optional. * layer=x : this should get the same layer as the ways running over it. One could argue that this should get a layer below the ways, but I find this rather counter-intuitive. See comment below! +1 for setting it the same layer as the ways running over it. Using even more layers would increase the confusion when using more than one layer (two if you count the default one), as it would double the layers. Especially it would require changes to existing layers when extending existing bridges with the bridge-building-area proposed here. One remark where you don't provide a solution, but where I don't have any solution either is the other way around: You/we propose here a way to define these ways share one bridge structure, but it's plugged in to the existing osm database, so there are already many bridges where the bridge area would fit, but is missing (as it wasn't defined/proposed up to now). If we would propose a solution to state this is single-way-bridge as it is mapped here currently, QA tools could check both variants for completeness instead of asking ever and ever again something like these n bridges run approximately in parallel near to each other. If the ways share the same structure, please add a [bridge-area] for the area covered by the bridge structure. To solve that probably an additional tag for single bridges would be useful: standalone_bridge=yes (I don't like the wording here, but you get the point). As a second remark I would like to ask how to define the bridges pillars (in the middle or at both ends of the structure). Being able to map them would allow 1) better 3D rendering 2) interpreting them as barriers under the bridge 3) more or less calculate an estimated space width for driving through under the bridge regards Peter 2013/1/31 Pieren pier...@gmail.com: On Thu, Jan 31, 2013 at 2:06 PM, Martin Koppenhoefer dieterdre...@gmail.com wrote: I wouldn't call this a bridge, it is a vault, but the bridge (or viaduct) if you wanted to map it would (IMHO) be the structure as a whole, not just a single segment. Instead of building=bridge, you might choose man_made=bridge_deck or simply bridge=deck ? Btw, the idea is not new. Check this bridge I traced in march 2010: http://www.openstreetmap.org/browse/way/53582123/history I used the tags combination highway=bridge + area=yes. Then it was replaced by bridge=yes + area=yes and finally by building=bridge. I guess the building=* tag is used for rendering purpose. Which is not correct. Pieren ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
On 31/01/2013 13:44, Martin Vonwald wrote: * bridge=type : use this tag just like it is used at the moment. If the value would be yes it should be optional. Again, borrowing from IHO, they define the following bridge types: fixed opening swing lifting bascule pontoon drawbridge transporter foot viaduct aqueduct suspension ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
2013/1/31 Pieren pier...@gmail.com: On Thu, Jan 31, 2013 at 2:44 PM, Martin Vonwald imagic@gmail.com wrote: * something=bridge : this is the tag we should decide one. I guess the value bridge is unchallenged. My 2 cents: - area=bridge - area:bridge=yes - man_made=bridge - amenity=bridge (I'm joking) All fine, but think about my comment about different levels of a bridge. We already have a supported tagging scheme for this, why not reuse it? And if I'm not mistaken this would lead to building=bridge . We really should get some help from the 3D experts here. I'm not a fan of reinventing the wheel ;-) ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
On 31/01/2013 13:44, Martin Vonwald wrote: * something=bridge : this is the tag we should decide one. I guess the value bridge is unchallenged. -1 If the primary tag is bridge=type, then why do we need the above tag at all? ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
2013/1/31 Malcolm Herring malcolm.herr...@btinternet.com: On 31/01/2013 13:44, Martin Vonwald wrote: * something=bridge : this is the tag we should decide one. I guess the value bridge is unchallenged. -1 If the primary tag is bridge=type, then why do we need the above tag at all? The key bridge is currently used to specify that something else is on a bridge, e.g. highway=motorway + bridge=yes. The value of the key bridge specifies the type of the bridge. We should try not to change the meaning of a tag too much. Therefore I would suggest: * something=bridge --- this is a bridge * bridge=type --- this is a bridge of type type (same meaning as now) Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
Martin, Maybe I am missing something from your proposal. I had understood it to mean that bridges should be mapped as distinct features, separate from the ways that pass over and under. Therefore, bridge=... tags on the ways would become redundant and remove the ambiguity and messy rendering that they cause when more than one way crosses the same bridge. Also, wheat exactly did you mean by Connect the ways running over the bridge to this structure? This implies a relation to make the connections, but you then go on to deprecate the use of relations. So I am confused! Malcolm ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
On Thu, Jan 31, 2013 at 3:51 PM, Malcolm Herring malcolm.herr...@btinternet.com wrote: Maybe I am missing something from your proposal. I had understood it to mean that bridges should be mapped as distinct features, separate from the ways that pass over and under. Therefore, bridge=... tags on the ways would become redundant and remove the ambiguity and messy rendering that they cause when more than one way crosses the same bridge. Yes. Use bridge=* only once, either on the highway way (linear) or on a polygon (surface). But it's preferable to use a second tag to distinguish the linear vs the surface modeling. Otherwise we don't know if an OSM closed way tagged bridge=yes is the surface or something really linear where the highway tag is missing. Also, wheat exactly did you mean by Connect the ways running over the bridge to this structure? This implies a relation to make the connections, but you then go on to deprecate the use of relations. I guess it's just about a node put on the intersection between the highway(s) and the polygon. But I'm not sure if this is really required (the same question raises when a highway is crossing an administrative boundary or a landuse). Pieren ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
2013/1/31 Malcolm Herring malcolm.herr...@btinternet.com: Martin, Maybe I am missing something from your proposal. No proposal - just ideas ;-) I had understood it to mean that bridges should be mapped as distinct features, separate from the ways that pass over and under. Therefore, bridge=... tags on the ways would become redundant and remove the ambiguity and messy rendering that they cause when more than one way crosses the same bridge. I would not do that. I would keep the bridge=xxx tags for backward compatibility. Also, wheat exactly did you mean by Connect the ways running over the bridge to this structure? This implies a relation to make the connections, but you then go on to deprecate the use of relations. I meant: at the edges of the structure connect the OSM ways of the roads/ways to the OSM way of the structure. As you already need to split the roads at the edges of the structure, because you need to add the layer (and bridge) key within the structure, there are already nodes present - just connect them with the OSM way of the structure. regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
On Thu, Jan 31, 2013 at 4:17 PM, Martin Vonwald imagic@gmail.com wrote: I would not do that. I would keep the bridge=xxx tags for backward compatibility. Bad idea. I like the principle one feature, one OSM element. Solve rendering issues in the rendering toolchain. Pieren ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
Am 31.01.2013 16:57, schrieb Janko Mihelić: Well, having building=bridge and bridge=yes isn't two features. First one is the feature (bridge) and the second one is the road with an attribute (it is on a bridge). They are redundant, but I wouldn't call them duplicated. They are duplicated if you follow the old scheme, where bridge=yes in fact was this is a bridge - or part of a bridge. But on the other hand if you follow the old scheme (and we don't use building=bridge for the area, as stated dangerous above because of the nearly-free-text-character of building=*) you would completely ignore the bridge area, and thus you don't get a duplicate again. For the future that would mean: man_made=bridge (or whatever) means, that this area is a bridge (analogon: building) bridge=yes means, if you are going/driving on that way, you go/drive over a bridge Please note: The second sentence was true in the past, too. For data consumers not dealing with the new scheme it follows: nothing changed (except probably naming, which was a problem already with the name-conflict between highways and bridges name). For data consumers supporting the new it follows: If there's no bridge-area (e.g. man_made=bridge) defined, but there's a bridge=yes, I have to assume an error, I might report that as such and/or I should fall back to assume a bridge-area at/around the way, which is simple by creating a rectangle with the assumed bridge width around the way. regards Peter ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
2013/1/31 Martin Vonwald imagic@gmail.com: In my opinion this is a rather obvious approach therefore I'm not surprised that someone already came up with it earlier. But I am definitively surprised that we don't have any documentation in the wiki for it. there are real examples, e.g. these two: http://www.openstreetmap.org/browse/way/42922473 http://www.openstreetmap.org/browse/way/44097288 which started with bridge=area and name=* but were fixed in the meantime (fix nonconforming uses of bridge tag) ;-) cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
I read a bit about 3D buildings, and it's pretty compatible. Here is an article about simple 3D buildings: http://wiki.openstreetmap.org/wiki/Simple_3D_Buildings Here is a picture that shows the concept of building:parts: http://wiki.openstreetmap.org/w/index.php?title=File:Minlevel.svgpage=1 Those three are building parts (building:part=yes), and they are all in a relation that has type=building. A full area (building=yes) is also in the relation. So with a bridge, we could have the relation with type=building, in it would be the full area with building=bridge, and piers which would all have building:part=yes (or maybe building:part=pier). Each pier would have it's height (height=10). We should agree what to do with the height (and min_height) of the building=bridge area. If it goes over uneven terrain, there is no unique height. If it goes over sea, than we have tides that change the height. So we can agree to put in the maximum height the bridge has, or nothing. I see no other solution. Janko Mihelić ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
On Thu, Jan 31, 2013 at 5:13 PM, Peter Wendorff wendo...@uni-paderborn.de wrote: For data consumers supporting the new it follows: If there's no bridge-area (e.g. man_made=bridge) defined, but there's a bridge=yes, I have to assume an error, I might report that as such and/or I should fall back to assume a bridge-area at/around the way, which is simple by creating a rectangle with the assumed bridge width around the way. For me, it's clearly duplicates. Like keeping the amenity=parking node when you draw the parking polygon. Or keeping abutters=residential on the highway when you draw the landuse=residential polygon. Or it's just for backward compatibility, like keeping natural=water on waterway=riverbank until mapnik stylesheet rendered correctly riverbanks... Pieren ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
On 31/01/2013 15:17, Martin Vonwald wrote: As you already need to split the roads at the edges of the structure, because you need to add the layer (and bridge) key within the structure, there are already nodes present - just connect them with the OSM way of the structure. Why do you need split the road at the edges of the bridges? This is currently done because it is the only way of defining the bridge. If we are to split the two features, then this need disappears. If the bridge crossing ways have width or weight limits, these do not necessarily coincide with the structural limits of the bridges. They often apply to the approaches as well, so the section of the road where the restriction applies begins and ends beyond the bridge. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
+1 Not splitting the way for every bridge will make tagging a lot easier. Often when things such as speed limits on long sections of road, bridges get missed and then often the cause of extra routing instructions if a reference tag is missing. Phil (trigpoint) -- Sent from my Nokia N9 On 31/01/2013 17:14 Malcolm Herring wrote: On 31/01/2013 15:17, Martin Vonwald wrote: As you already need to split the roads at the edges of the structure, because you need to add the layer (and bridge) key within the structure, there are already nodes present - just connect them with the OSM way of the structure. Why do you need split the road at the edges of the bridges? This is currently done because it is the only way of defining the bridge. If we are to split the two features, then this need disappears. If the bridge crossing ways have width or weight limits, these do not necessarily coincide with the structural limits of the bridges. They often apply to the approaches as well, so the section of the road where the restriction applies begins and ends beyond the bridge. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
On 1/31/13 12:39 PM, Philip Barnes wrote: +1 Not splitting the way for every bridge will make tagging a lot easier. Often when things such as speed limits on long sections of road, bridges get missed and then often the cause of extra routing instructions if a reference tag is missing. it will make validation harder, though, when roads on different layers cross but one of them doesn't have a layer tag. not a lot harder, i think, but it will have an impact. richard ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
On 31.01.2013 17:31, Janko Mihelić wrote: I read a bit about 3D buildings, and it's pretty compatible. Here is an article about simple 3D buildings: http://wiki.openstreetmap.org/wiki/Simple_3D_Buildings I think you are overlooking several problems. To start with, building:part cannot do arcing structures - like many bridge decks. They can also not easily to structures that become wider or narrower towards the top - like some bridge piers. While you could probably model a crude bridge shape with building:part, I would not have imagined that they would be used for bridges. Maybe it's possible, but they were designed as volume shapes. That is, as blocks where the interesting stuff is inside, rather than on top. Also note that Simple 3D Buildings doesn't have an established solution for ways on top of the roof yet. With normal buildings, that's a niche use case that would be good for, say, gardens or parking areas on the roof. But if you think of bridges as buildings (a style of thinking I'm not particularly comfortable with), this is essential, as you almost always have highways/railways on top of the roof then. I'm wondering whether the approach you describe has some merit nevertheless - because after all, many bridges do incorporate towers or other building structures - but I feel it should not be used as the primary approach to modelling bridges. We should agree what to do with the height (and min_height) of the building=bridge area. If it goes over uneven terrain, there is no unique height. For the record, the height of a building mapped according to Simple 3D Buildings is always based off the point where terrain is the lowest. Tobias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
On 1/31/13 12:53 PM, Richard Welty wrote: On 1/31/13 12:39 PM, Philip Barnes wrote: +1 Not splitting the way for every bridge will make tagging a lot easier. Often when things such as speed limits on long sections of road, bridges get missed and then often the cause of extra routing instructions if a reference tag is missing. it will make validation harder, though, when roads on different layers cross but one of them doesn't have a layer tag. not a lot harder, i think, but it will have an impact. and it occurs to me that we need to account for cases like the George Washington Bridge between Manhattan and New Jersey, which has multiple decks carrying vehicle traffic. richard ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
On 31.01.2013 18:39, Philip Barnes wrote: Not splitting the way for every bridge will make tagging a lot easier. Won't anybody think of the poor renderers? :( Until now we could rely on the assumption that every way is *either* on the ground *or* above the ground. Which is pretty helpful imo. Tobias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
Am 31.01.2013 18:14, schrieb Malcolm Herring: On 31/01/2013 15:17, Martin Vonwald wrote: As you already need to split the roads at the edges of the structure, because you need to add the layer (and bridge) key within the structure, there are already nodes present - just connect them with the OSM way of the structure. Why do you need split the road at the edges of the bridges? This is currently done because it is the only way of defining the bridge. If we are to split the two features, then this need disappears. If the bridge crossing ways have width or weight limits, these do not necessarily coincide with the structural limits of the bridges. They often apply to the approaches as well, so the section of the road where the restriction applies begins and ends beyond the bridge. +0.5 I agree that this is nice in future, but for compatibility reasons I would propose a slow progress towards what you describe: if the bridge is already there the ways are splitted, the bridge highway is already there and so on - so: keep them splitted and it's less work with more backwards compatibility. If they are not, it's up to you as a mapper if you want outdated renderers to use the old scheme or not. regards Peter ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
On 31.01.2013 12:06, Martin Vonwald wrote: I'm looking for some alternatives to map tunnels and bridges that contain several ways. I'm not really happy with the proposed relation -1 The current method is used and well established since years and for my point of view works fine. So I clearly dislike to change it. Just my 2 cents, Michael. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
Am 01.02.2013 um 00:01 schrieb Michael Kugelmann michaelk_...@gmx.de: On 31.01.2013 12:06, Martin Vonwald wrote: I'm looking for some alternatives to map tunnels and bridges that contain several ways. I'm not really happy with the proposed relation -1 The current method is used and well established since years and for my point of view works fine. So I clearly dislike to change it. What current method do you refer to? The key bridge or the proposed relation? When reading through the responses in this thread I get the impression that there is need for a simple way to specify what OSM-ways belong to one, single bridge. Regarding the relation: there was a short discussion about a waterpark short time ago. It was asked if all the features should go into a site relation. The answer was (as I remember it): no. Only if the features are spread over different places. We have a spatial database so if all features are within a closed way there is no need for a relation. Why is there a different reasoning for a bridge? Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
Hi, A few problems with the current approach: 1) When several things pass over the same bridge (eg, highway=secondary, highway=cycleway and highway=footway; or even just two independent lanes), renderers currently draw multiple bridges. 2) In areas where structures (buildings, paved areas, piers, riverbanks) are mapped precisely, bridges can't be - they're assumed to be the width of a standard road. 3) Bridges have distinct properties (name, height, etc) that can't be modelled properly because bridges don't actually exist. Tags like bridge_name are a kludge that don't work in cases like 1). These are all problems worth fixing. The solution seems to be: a) (Optional Create a relation that can group things together (type=bridge, or something more general if there's something good) b) (Optional) Create a closed way for the bridge itself, and tag it with a new tag (probably man_made=bridge would be best, because it would be better rendered by naive renderers than say building=bridge) c) (Optional) Add the bridge, if mapped, to the relation. It seems that every time this topic comes up, people want to go too far, and find general solutions (eg, solving both bridges and tunnels at once with across and over relation memberships), and start solving other problems too (eg, 3D buildings, not splitting ways when they pass over bridges...). It all gets complicated, and everyone gives up. But the solution above is pretty simple, and doesn't require breaking anything, and is totally optional. Map the way you do currently if you want, or also map the bridge separately if you want, or use a relation, or both. Steve On Fri, Feb 1, 2013 at 10:01 AM, Michael Kugelmann michaelk_...@gmx.de wrote: On 31.01.2013 12:06, Martin Vonwald wrote: I'm looking for some alternatives to map tunnels and bridges that contain several ways. I'm not really happy with the proposed relation -1 The current method is used and well established since years and for my point of view works fine. So I clearly dislike to change it. Just my 2 cents, Michael. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
