Re: [Tagging] Tram tracks running in a road
Sorry I meant the railway tag. just added a note on the map 2015-02-09 8:54 GMT+01:00 Luca Sigfrido Percich : > Hi Jo, > > I was looking closely at your example, and noticed that maybe the highway > tag is missing from this way: http://www.openstreetmap.org/way/40283536 > because the tram line looks interrupted there. > > Sig > > 2015-02-07 1:12 GMT+01:00 Jo : > >> The reason to use separate ways for trams can be seen in the other tram >> tracks I mapped: >> >> http://www.openstreetmap.org/#map=18/50.83181/4.33280 >> >> You can clearly see that very often the rails don't follow the asphalt >> where the cars drive. Cars can make 90 degree turns, the tram rails need to >> follow smoother curves. >> >> So it's only in situations where buses follow the tram bedding: >> >> http://www.openstreetmap.org/#map=19/50.82432/4.33561 >> >> that one can have common ways for the tram and that service road. >> >> * For normal streets we draw 2 ways for the tracks and 1 for the asphalt >> road. >> * For dual carriageways we draw 2 ways for the tracks and 2 for each side >> + sometimes a service way between the tracks, when the buses use it too. >> >> It's rather exceptional that the service road and the tram rails can use >> the same OSM way. >> >> Keep in mind it's only a model to represent reality. A model which uses >> lines for what in reality are areas, so whatever we do, it will never be a >> perfect fit. >> >> >> I'm sure André won't agree with me, but to implement the solution he >> proposes, we'd have to restart OSM from scratch. And even though it may >> simplify and solve some things, it would make other stuff a lot harder. >> >> Jo >> >> 2015-02-07 0:31 GMT+01:00 Janko Mihelić : >> >>> 2015-02-06 17:29 GMT+01:00 Luca Sigfrido Percich >> >: >>> We could also user a lanes modifier: lanes=3 lanes:backward=2 tram:lanes:backward=yes|no tram:forward=yes >>> I think this is the best way to tag this. There's a great map paint >>> style for seeing roads in towns in JOSM, and it helps a lot with tagging >>> lanes. It's called Lanes and road attributes. Unfortunately, it doesn't >>> show trams, but if we start tagging them, it will probably start rendering >>> them. Right now, I use psv:lanes:forward=designated|no, because psv means >>> all public service vehicles. >>> >>> http://wiki.openstreetmap.org/wiki/Key:lanes:psv >>> >>> And in my town those lanes are reserved for trams, buses and taxis. >>> >>> Janko Mihelić >>> >>> ___ >>> 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] Tram tracks running in a road
Hi Jo, I was looking closely at your example, and noticed that maybe the highway tag is missing from this way: http://www.openstreetmap.org/way/40283536 because the tram line looks interrupted there. Sig 2015-02-07 1:12 GMT+01:00 Jo : > The reason to use separate ways for trams can be seen in the other tram > tracks I mapped: > > http://www.openstreetmap.org/#map=18/50.83181/4.33280 > > You can clearly see that very often the rails don't follow the asphalt > where the cars drive. Cars can make 90 degree turns, the tram rails need to > follow smoother curves. > > So it's only in situations where buses follow the tram bedding: > > http://www.openstreetmap.org/#map=19/50.82432/4.33561 > > that one can have common ways for the tram and that service road. > > * For normal streets we draw 2 ways for the tracks and 1 for the asphalt > road. > * For dual carriageways we draw 2 ways for the tracks and 2 for each side > + sometimes a service way between the tracks, when the buses use it too. > > It's rather exceptional that the service road and the tram rails can use > the same OSM way. > > Keep in mind it's only a model to represent reality. A model which uses > lines for what in reality are areas, so whatever we do, it will never be a > perfect fit. > > > I'm sure André won't agree with me, but to implement the solution he > proposes, we'd have to restart OSM from scratch. And even though it may > simplify and solve some things, it would make other stuff a lot harder. > > Jo > > 2015-02-07 0:31 GMT+01:00 Janko Mihelić : > >> 2015-02-06 17:29 GMT+01:00 Luca Sigfrido Percich >> : >> >>> >>> We could also user a lanes modifier: >>> lanes=3 >>> lanes:backward=2 >>> tram:lanes:backward=yes|no >>> tram:forward=yes >>> >>> >> I think this is the best way to tag this. There's a great map paint style >> for seeing roads in towns in JOSM, and it helps a lot with tagging lanes. >> It's called Lanes and road attributes. Unfortunately, it doesn't show >> trams, but if we start tagging them, it will probably start rendering them. >> Right now, I use psv:lanes:forward=designated|no, because psv means all >> public service vehicles. >> >> http://wiki.openstreetmap.org/wiki/Key:lanes:psv >> >> And in my town those lanes are reserved for trams, buses and taxis. >> >> Janko Mihelić >> >> ___ >> 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] courtyards
On 08.02.2015 22:17, Warin wrote: >> >From a technical point of view they are typically associated with fire >> >protection (way to leave the building, access for firefighters), > > If the courtyard is fully enclosed by buildings or by one building .. they > are not part of a fire escape (protection), those require exit to an open > area - not one that is fully enclosed. So the use as fire protection will > depend on the courtyard. And my thinking is that a true 'courtyard' is > fully enclosed? We need to be able to map partially enclosed courtyards as well, e.g.: https://www.openstreetmap.org/#map=19/48.17839/16.34189 (The courtyards are named Hof 1 ... Hof 7.) But I agree that a courtyard *typically* is fully enclosed by buildings, thus not an emergency feature. There's an approved tag entrance=emergency for emergency exits, and I'd suggest a tag like emergency=access for spots and alleys designed to be accessible for fire fighters. I think that, from a technical point view, the main function of a courtyard is to yield sunlight to building rooms that are not adjacent to the building's outer margin. All other uses, such as recreation, parking or emergency access, are subsequent. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tram tracks running in a road
On 8 February 2015 at 22:32, Jo wrote: > is it one asphalt way with one track? Then I agree. Or is it one asphalt way > with two tracks, one for each direction of the tram lines? Then I'd draw 3 > ways, 2 for the tracks, and 1 for the highway. Fair enough, but that doesn't quite correspond to the truth on the ground. The road isn't between the tracks. In my opinion it's better to have two ways, one in each direction with highway and railway tags on both. /Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - key:rubbish=
On Mon, 2015-02-09 at 09:15 +1100, Warin wrote: > A proposal for a new high level tag of .. Rubbish :-) Sigh ... . OK, its a good solution but before I'd vote for it, I'd like someone to explain a few things to me - Firstly, how is rubbish= a better solution than the slight redefinition of waste= ?? I mean declare waste= to be that higher level key, no longer requiring amenity=waste_disposal. There are already 5K uses, I'd be very surprised if any of those uses would be broken by the redefinition. Secondly, if we approve rubbish=, do we then mark the waste= approach as obsolete, less preferred or whatever ? Having two ways of tagging the same thing is bad IMHO. Thirdly, dare I say this, will someone argue rubbish= indicates that there is rubbish there, on that spot ? preferable to say rubbish_disposal or something similar. I do believe we need a high level key for rubbish, trash, waste whatever Hmm, rubbish_receptacle perhaps ? And definitely not rubbish_receptacle_desk !! (sorry) David > > https://wiki.openstreetmap.org/wiki/Proposed_features_key%3Drubbish > > At present there as a number of 'waste' values under the amenity key. > Some people say the amenity key is being over used. There are people > thinking of adding more waste values to the amenity key. So there is a > case for a high level new key for waste facilities. The number of > possible values of this is key I estimate at 27. Don't fixate on the > values of this key - the ones shown are examples only .. and would need > there own separate proposals. > > Unfortunately the key waste= is already in use, so to avoid conflicts > and mistakes a new name should be used - thus 'rubbish'. > > > Is there a better way? So far the choices look to be; > > A) More values under the key amenity such as amenity=waste_dump_station? > B) More values under amenity=waste_disposal in the key waste=? > OR > C) New top level key rubbish= with new values under that? > > Any other options? > And what one do you prefer? May be a why would be good. > > Personally .. I don't know. I think a new top level tag would be good in > that it does separte it out from hte others and provides a clear path > for new rubbish tags. But I also acknowledge the problems/work that this > would introduce. On htewhole I'd go with the neew top level tag, I like > a good structure, but any other good ideas or arguments can easily sway > my present view. > > - > I'd like to leave the comments open for 3 weeks .. unless there is a > vast amount of comments made and changes/additions to the different > choices that could be made. > So possible closure on 2 march? > > ___ > 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] Tram tracks running in a road
I'm afraid joggers may want to start training on those train:lanes... Do you mean rail:lanes? or tram_track:lanes? or tram_rails:lanes? 2015-02-09 0:08 GMT+01:00 Paul Johnson : > train:lanes=* might be a tag worth inventing for the highway way, giving > it more thought. > > On Sun, Feb 8, 2015 at 5:02 PM, Luca Sigfrido Percich < > luca.perc...@gmail.com> wrote: > >> Hi all, >> >> many thanks for all your feedback! It will take me a week to sort it all >> out! :) >> >> In Milano we already have (nearly) all the tram traks drawn as distinct >> ways, so switching back to the "single way for highway and railway" model >> wouldn't be a good option - it would mean losing detail. >> >> I understand that drawing the road as a precise centerline and giving it >> correct width tags has a value of its own and would allow us to dynamically >> establish the relationship between roads and railway, not to mention a >> better rendering and modeling. >> >> But for the sake of "explicit is better than implicit" I still have the >> impression that we should also use a tag or two for saying that there is a >> tram track in a road. >> >> Sig >> >> >> >> >> >> >> 2015-02-08 23:18 GMT+01:00 Janko Mihelić : >> >>> 2015-02-08 19:57 GMT+01:00 Jo : >>> I don't like to reuse the same ways for both railway and highway. The shape of the railways follow smooth curves for obvious reasons, whereas cars can make 90 degree turns. So I'll always keep using separate ways for the tram rails. One for each direction of travel. And a way in the middle (on the straight parts) for the highway. An exception to that are dual carriageways, with the rails embedded, but usually the rails are between the carriageways in that case. >>> >>> I agree, railway=tram should be separate. Tags on the highway only >>> describe lanes, they do not represent the railway. Tag >>> tram:lanes:forward=no|designated only says that the outer lane has a >>> railway track on it. >>> >>> Janko Mihelić >>> >>> >>> ___ >>> 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 > > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tram tracks running in a road
train:lanes=* might be a tag worth inventing for the highway way, giving it more thought. On Sun, Feb 8, 2015 at 5:02 PM, Luca Sigfrido Percich < luca.perc...@gmail.com> wrote: > Hi all, > > many thanks for all your feedback! It will take me a week to sort it all > out! :) > > In Milano we already have (nearly) all the tram traks drawn as distinct > ways, so switching back to the "single way for highway and railway" model > wouldn't be a good option - it would mean losing detail. > > I understand that drawing the road as a precise centerline and giving it > correct width tags has a value of its own and would allow us to dynamically > establish the relationship between roads and railway, not to mention a > better rendering and modeling. > > But for the sake of "explicit is better than implicit" I still have the > impression that we should also use a tag or two for saying that there is a > tram track in a road. > > Sig > > > > > > > 2015-02-08 23:18 GMT+01:00 Janko Mihelić : > >> 2015-02-08 19:57 GMT+01:00 Jo : >> >>> I don't like to reuse the same ways for both railway and highway. The >>> shape of the railways follow smooth curves for obvious reasons, whereas >>> cars can make 90 degree turns. So I'll always keep using separate ways for >>> the tram rails. One for each direction of travel. And a way in the middle >>> (on the straight parts) for the highway. An exception to that are dual >>> carriageways, with the rails embedded, but usually the rails are between >>> the carriageways in that case. >>> >> >> I agree, railway=tram should be separate. Tags on the highway only >> describe lanes, they do not represent the railway. Tag >> tram:lanes:forward=no|designated only says that the outer lane has a >> railway track on it. >> >> Janko Mihelić >> >> >> ___ >> 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] Tram tracks running in a road
Hi all, many thanks for all your feedback! It will take me a week to sort it all out! :) In Milano we already have (nearly) all the tram traks drawn as distinct ways, so switching back to the "single way for highway and railway" model wouldn't be a good option - it would mean losing detail. I understand that drawing the road as a precise centerline and giving it correct width tags has a value of its own and would allow us to dynamically establish the relationship between roads and railway, not to mention a better rendering and modeling. But for the sake of "explicit is better than implicit" I still have the impression that we should also use a tag or two for saying that there is a tram track in a road. Sig 2015-02-08 23:18 GMT+01:00 Janko Mihelić : > 2015-02-08 19:57 GMT+01:00 Jo : > >> I don't like to reuse the same ways for both railway and highway. The >> shape of the railways follow smooth curves for obvious reasons, whereas >> cars can make 90 degree turns. So I'll always keep using separate ways for >> the tram rails. One for each direction of travel. And a way in the middle >> (on the straight parts) for the highway. An exception to that are dual >> carriageways, with the rails embedded, but usually the rails are between >> the carriageways in that case. >> > > I agree, railway=tram should be separate. Tags on the highway only > describe lanes, they do not represent the railway. Tag > tram:lanes:forward=no|designated only says that the outer lane has a > railway track on it. > > Janko Mihelić > > > ___ > 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] Tram tracks running in a road
On Sun, Feb 8, 2015 at 2:35 PM, Markus Lindholm wrote: > On 8 February 2015 at 19:57, Jo wrote: > > I don't like to reuse the same ways for both railway and highway. The > shape > > of the railways follow smooth curves for obvious reasons, whereas cars > can > > make 90 degree turns. > > I don't understand why that is a problem. If the road is such that the > vehicles drive on top of the tracks, then the obvious solution is to > have just one way with both highway and railway tags. At corners and > otherwise where the track for the tram diverges from the road create a > separate way for the tracks. A better way would be to have a region of landuse=highway or an associated street relation. The roadway and the tracks have different centerlines, and these things *absolutely do *matter for certain applications. The way should be in the centerline of the roadway or between the rails in a track. Each track should have it's own way. Rail and public transit fans absolutely do care about this distinction. Especially virtual railroaders, who could easily recreate fullscale models of real world systems easily if they have accurate and precise data on where the tracks are. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tram tracks running in a road
2015-02-08 19:57 GMT+01:00 Jo : > I don't like to reuse the same ways for both railway and highway. The > shape of the railways follow smooth curves for obvious reasons, whereas > cars can make 90 degree turns. So I'll always keep using separate ways for > the tram rails. One for each direction of travel. And a way in the middle > (on the straight parts) for the highway. An exception to that are dual > carriageways, with the rails embedded, but usually the rails are between > the carriageways in that case. > I agree, railway=tram should be separate. Tags on the highway only describe lanes, they do not represent the railway. Tag tram:lanes:forward=no|designated only says that the outer lane has a railway track on it. Janko Mihelić ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - RFC - key:rubbish=
A proposal for a new high level tag of .. Rubbish :-) https://wiki.openstreetmap.org/wiki/Proposed_features_key%3Drubbish At present there as a number of 'waste' values under the amenity key. Some people say the amenity key is being over used. There are people thinking of adding more waste values to the amenity key. So there is a case for a high level new key for waste facilities. The number of possible values of this is key I estimate at 27. Don't fixate on the values of this key - the ones shown are examples only .. and would need there own separate proposals. Unfortunately the key waste= is already in use, so to avoid conflicts and mistakes a new name should be used - thus 'rubbish'. Is there a better way? So far the choices look to be; A) More values under the key amenity such as amenity=waste_dump_station? B) More values under amenity=waste_disposal in the key waste=? OR C) New top level key rubbish= with new values under that? Any other options? And what one do you prefer? May be a why would be good. Personally .. I don't know. I think a new top level tag would be good in that it does separte it out from hte others and provides a clear path for new rubbish tags. But I also acknowledge the problems/work that this would introduce. On htewhole I'd go with the neew top level tag, I like a good structure, but any other good ideas or arguments can easily sway my present view. - I'd like to leave the comments open for 3 weeks .. unless there is a vast amount of comments made and changes/additions to the different choices that could be made. So possible closure on 2 march? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] courtyards
On Sun, Feb 8, 2015 at 10:40 AM, Martin Koppenhoefer wrote: > > in architecture you'd definitely consider a courtyard part of a building, > and volumes are distinguished in fully closed, open at the top and closed > on top but open at the sides (at least in German building codes aka DIN), > but if we have clear definitions for OSM that volumes open on one or more > sides aren't to be considered building parts, I'll take that back. > A very common pattern in the USA is an interior courtyard at the pedestal level: meaning above the parking garage. There's typically one or more underground levels. The ground floor is parking perhaps with shallow depth retail stores. There are zero or more additional parking levels. Then a central courtyard surrounded by apartments. The courtyard is open to the sky. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tram tracks running in a road
is it one asphalt way with one track? Then I agree. Or is it one asphalt way with two tracks, one for each direction of the tram lines? Then I'd draw 3 ways, 2 for the tracks, and 1 for the highway. Jo 2015-02-08 21:35 GMT+01:00 Markus Lindholm : > On 8 February 2015 at 19:57, Jo wrote: > > I don't like to reuse the same ways for both railway and highway. The > shape > > of the railways follow smooth curves for obvious reasons, whereas cars > can > > make 90 degree turns. > > I don't understand why that is a problem. If the road is such that the > vehicles drive on top of the tracks, then the obvious solution is to > have just one way with both highway and railway tags. At corners and > otherwise where the track for the tram diverges from the road create a > separate way for the tracks. > > /Markus > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] courtyards
On 9/02/2015 1:47 AM, Martin Koppenhoefer wrote: From a technical point of view they are typically associated with fire protection (way to leave the building, access for firefighters), If the courtyard is fully enclosed by buildings or by one building .. they are not part of a fire escape (protection), those require exit to an open area - not one that is fully enclosed. So the use as fire protection will depend on the courtyard. And my thinking is that a true 'courtyard' is fully enclosed? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tram tracks running in a road
On 8 February 2015 at 19:57, Jo wrote: > I don't like to reuse the same ways for both railway and highway. The shape > of the railways follow smooth curves for obvious reasons, whereas cars can > make 90 degree turns. I don't understand why that is a problem. If the road is such that the vehicles drive on top of the tracks, then the obvious solution is to have just one way with both highway and railway tags. At corners and otherwise where the track for the tram diverges from the road create a separate way for the tracks. /Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tram tracks running in a road
I don't like to reuse the same ways for both railway and highway. The shape of the railways follow smooth curves for obvious reasons, whereas cars can make 90 degree turns. So I'll always keep using separate ways for the tram rails. One for each direction of travel. And a way in the middle (on the straight parts) for the highway. An exception to that are dual carriageways, with the rails embedded, but usually the rails are between the carriageways in that case. Jo 2015-02-08 19:45 GMT+01:00 Janko Mihelić : > 2015-02-08 17:48 GMT+01:00 fly : > >> Actually, I use an even more general approach: >> railway:forward=tram >> railway:lanes:backward=tram|no >> >> together with access I also use train >> access:lanes:backward=no|yes >> train:lanes:backward=designated|no >> > > I don't understand why you would use railway:forward=* and > railway:lanes:forward=*. Aren't those two redundant? > > Also, why train and not tram? > > I like railway:lanes:forward/backward=* because sometimes you can have > rails on the street which are not used by anything, so using tram/train > doesn't make sense. But if you say tram:lanes:forward/backward=* than that > implies that there are rails there, so no other tags are needed anymore. > > Janko > > ___ > 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] Tram tracks running in a road
2015-02-08 17:48 GMT+01:00 fly : > Actually, I use an even more general approach: > railway:forward=tram > railway:lanes:backward=tram|no > > together with access I also use train > access:lanes:backward=no|yes > train:lanes:backward=designated|no > I don't understand why you would use railway:forward=* and railway:lanes:forward=*. Aren't those two redundant? Also, why train and not tram? I like railway:lanes:forward/backward=* because sometimes you can have rails on the street which are not used by anything, so using tram/train doesn't make sense. But if you say tram:lanes:forward/backward=* than that implies that there are rails there, so no other tags are needed anymore. Janko ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] courtyards
> Am 08.02.2015 um 16:14 schrieb Tobias Knerr : > > No, it definitely wouldn't. The building:part key has a clear definition > e.g. in the context of 3D rendering that does not fit for courtyards at > all. All building:part elements need to represent filled-out volumes > rather than empty volumes like a courtyard. in architecture you'd definitely consider a courtyard part of a building, and volumes are distinguished in fully closed, open at the top and closed on top but open at the sides (at least in German building codes aka DIN), but if we have clear definitions for OSM that volumes open on one or more sides aren't to be considered building parts, I'll take that back. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tram tracks running in a road
2015-02-08 17:48 GMT+01:00 fly : > > Let me know if there's a place with a lot of such tags and I try to > update > > the style. (Please contact me directly via martin (the usual) vonwald > > (dot.) info for this) > > +1 > Keep your +1 until I tried AND succeeded ;-) And yes: some consistent tagging scheme would be fine. Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tram tracks running in a road
Am 07.02.2015 um 11:19 schrieb Martin Vonwald: > 2015-02-07 0:31 GMT+01:00 Janko Mihelić : >> 2015-02-06 17:29 GMT+01:00 Luca Sigfrido Percich : >>> >>> We could also user a lanes modifier: >>> lanes=3 >>> lanes:backward=2 >>> tram:lanes:backward=yes|no >>> tram:forward=yes Actually, I use an even more general approach: railway:forward=tram railway:lanes:backward=tram|no together with access I also use train access:lanes:backward=no|yes train:lanes:backward=designated|no >> I think this is the best way to tag this. There's a great map paint style >> for seeing roads in towns in JOSM, and it helps a lot with tagging lanes. >> It's called Lanes and road attributes. Unfortunately, it doesn't show >> trams, but if we start tagging them, it will probably start rendering them. +1 but we need to find some consistent tagging system. > Let me know if there's a place with a lot of such tags and I try to update > the style. (Please contact me directly via martin (the usual) vonwald > (dot.) info for this) +1 Cheers fly ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] courtyards
2015-02-08 15:47 GMT+01:00 Martin Koppenhoefer : > > maybe building:part=courtyard would be a good tag semantic wise (but > unlikely to be rendered on the main style) > +1 That's the first one that came to my mind. That is a part of the building. When I was mapping manors I would put building=manor on the multipolygon, and historic=manor + name=* on the outer way, precisely because I thought that the courtyard was a part of the manor. In the same vein, courtyard is in a way part of the building. If you remove the building, you effectively remove the courtyard. I think this is a great solution that removes the need to make multipolygons for buildings that have a courtyard. Although I'm sure it will meet a lot of resistance. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] courtyards
On 08.02.2015 15:47, wrote Martin Koppenhoefer: > I am not in favour of place (neither locality nor courtyard), maybe > building:part=courtyard would be a good tag semantic wise No, it definitely wouldn't. The building:part key has a clear definition e.g. in the context of 3D rendering that does not fit for courtyards at all. All building:part elements need to represent filled-out volumes rather than empty volumes like a courtyard. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] courtyards
I appreciate that you bring this up, and share the analysis that neither highway pedestrian nor leisure=* are describing a courtyard (it might be accessible to cars, not accessible at all, could have a leisure related aspect but doesn't have to, etc.). From a technical point of view they are typically associated with fire protection (way to leave the building, access for firefighters), ventilation and natural illumination, building access (also to lateral and underground building parts) and also parking. Whether or not they exist depends a lot on the depth of the block. In some cases they have names, rich decoration, ref numbers etc., so a dedicated tag to say "courtyard" is indeed needed/desirable IMHO. I am not in favour of place (neither locality nor courtyard), maybe building:part=courtyard would be a good tag semantic wise (but unlikely to be rendered on the main style), alternative values might be backyard or court (the latter could be confused with courthouse so I'd not recommend it). If we'd to choose from currently imported keys I'd suggest man_made. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
I have to admit I admire the problem but do not have an answer. What I would like to suggest that dropping the "desk" part and just using "reception" could make it more conducive to the various applications being discussed. It could then be added as a subcategory to the area/building such as reception=desk...reception=area...reception=kiosk.. and would accommodate the problem of more than one type of reception within a complex such as an hotel (reception=tourism...reception=hotel). Or at an airport complex where multiple receptions exist such as hotel, car hire,etc. Using this would then also not clash with the amenity tag. Hope I am not adding more confusion to the problem. Ralph (RAytoun) On 8 February 2015 at 10:33, Andreas Goss wrote: > As >>> >this tag is always going to be used within another entity I think we >>> should >>> >rather look towards something like indoor tagging or other subtags. In >>> >addition using amenity for reception desk would for example prevent you >>> from >>> >placing it on the node of the amenity and use one node for both. >>> >> Not to defend the amenity key, but I wonder if there is a need to tag >> the reception if the whole object (including the reception) deserves >> just a single node. >> > > Well, you could have an amenity inside a very large bulding where you have > multiple entrances. Then you could use the amenity node to indicate that > it's actually placed at a certain spot, because the reception is there. In > addition it makes it clear to which amenity the reception desk belongs, as > a different amenity in the same building could have the reception desk at > the other side of the bulding. > __ > openstreetmap.org/user/AndiG88 > wiki.openstreetmap.org/wiki/User:AndiG88 > > > > ___ > 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 - Reception Desk
As >this tag is always going to be used within another entity I think we should >rather look towards something like indoor tagging or other subtags. In >addition using amenity for reception desk would for example prevent you from >placing it on the node of the amenity and use one node for both. Not to defend the amenity key, but I wonder if there is a need to tag the reception if the whole object (including the reception) deserves just a single node. Well, you could have an amenity inside a very large bulding where you have multiple entrances. Then you could use the amenity node to indicate that it's actually placed at a certain spot, because the reception is there. In addition it makes it clear to which amenity the reception desk belongs, as a different amenity in the same building could have the reception desk at the other side of the bulding. __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging