Re: [Tagging] Wiki on amenity=waste_disposal Rewrite?
On 5/02/2015 12:04 PM, Dave Swarthout wrote: On Thu, Feb 5, 2015 at 7:10 AM, Warin 61sundow...@gmail.com mailto:61sundow...@gmail.com wrote: You mean a one step? Like highway= x ? To do that I'd think a new supper key waste= at the top level! And maybe that is what it needs! If there are enough different kinds then why not? waste=rubbish_bin waste=skip_bin waste=dump_point waste=chemical_toilet waste=dog_excrement waste=sharps waste=cigarettes waste=excrement What does it take to justify a top level tag? I think he means that if we use a top level amenity tag like amenity=waste_disposal we are forced to make another whole set of sub keys to describe the waste being disposed of. At least that's where my criticism comes from. If however we can agree on a tag of amenity=dump_point and define it as a facility where one can dump or discharge the waste tanks of an RV or recreational boat it can be understood and rendered by evaluating only that single tag. Whether the waste being dumped is from a chemical toilet or from a plastic bag on a porta-potty or cassette then becomes irrelevant. The facility will handle it. This new top level tag might make the approval process easier too. Standing alone as it would, it nicely separates garbage and trash, or recyclables, from sewage and doesn't require any other potentially lengthy approvals for new subkeys. The present sub tag already exists and is in use .. for oil, cigarettes, grey_water, drugs, dog_excrement, etc .. so they still have to be evaluated for a true render of the facility. If what is required is a one tag entry for each waste type then amenity= will be over loaded eg amenity=waste_dog_excrement amenity=waste_cigarettes amenity=waste_sharps Note the inclusion of waste in the name .. so people don't think that they are places that sell the stuff! :) about 8 + around 28! if you include waste recycling... and I think it then needs to be a top level tag .. like shop=, tourism=. sport= etc. as there are too many of them .. and that would be opposed as it is a lot of work to change the present data and a lot of work to change the renders... at least another category of amenity ... presently * 2.1 Sustenance http://wiki.openstreetmap.org/wiki/Key:amenity#Sustenance * 2.2 Education http://wiki.openstreetmap.org/wiki/Key:amenity#Education * 2.3 Transportation http://wiki.openstreetmap.org/wiki/Key:amenity#Transportation * 2.4 Financial http://wiki.openstreetmap.org/wiki/Key:amenity#Financial * 2.5 Healthcare http://wiki.openstreetmap.org/wiki/Key:amenity#Healthcare * 2.6 Entertainment, Arts Culture http://wiki.openstreetmap.org/wiki/Key:amenity#Entertainment.2C_Arts_.26_Culture * 2.7 Others http://wiki.openstreetmap.org/wiki/Key:amenity#Others Add '2.8 Waste'? I don't know.. just pointing out the possible future problems? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Whole planet flooded at main map?
Hi! Is it just me or is currently the whole planet flooded on the main map? At least at zoom level 1-6. Starting with 7 countries reappear. regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
Reception is used for tourists, but also is common for any large office complex or even a industrial plant. People visiting the plant (for work related activities) would go to reception, check in, and get a visitors badge. I think there is a difference between a person on vacation and a product rep having an appointment at a car parts plant, but both have reception. Since the object is part of another object - a hotel, office, etc - it is an amenity of the building, whose purpose is tourism. But people visiting a factory complex and looking for visitor check-in aren't really tourists, are they? I think amenity is the right key. Javbw On Feb 6, 2015, at 9:58 PM, Janko Mihelić jan...@gmail.com wrote: Why not tourism=reception_desk? We have tourism=hotel, tourism=camp_site, tourism=information, it's only logical to use the same key. 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
I think relation street applies to all the way segments of the whole street with the same name (if in the same municipality), but I didn't check to be honest. 2015-02-06 19:44 GMT+01:00 Luca Sigfrido Percich luca.perc...@gmail.com: Many thanks Jo! Volker also suggests that I should see how things are mapped in other major cities, and so I'll do. So you confirm that there isn't an established way of expressing the tram-in-road relationship? The use of the street relation has been suggested by a fellow member of the italian discussion group. It's not clear from the wiki, however, if this relation can be used for associating railways to highways for a single road segment (from crossroads to crossroads) or is meant for associating everything which belongs to a single street (so all the railways and highways which belong to the same street). I'll investigate further. Many thanks! Sig 2015-02-06 19:26 GMT+01:00 Jo winfi...@gmail.com: Ciao Luca, For an example of a road with many variations in how the tram tracks are embedded, you can have a look at this stretch I mapped a few months ago: http://www.openstreetmap.org/#map=16/50.8601/4.3117 To indicate how they belong together, maybe a street or associatedStreet relation makes sense? Jo 2015-02-06 17:29 GMT+01:00 Luca Sigfrido Percich luca.perc...@gmail.com : Hi all, first time I write to the list (after lurking for a while), so I introduce myself. I am from Milano - Italy, I work for the municipality's agency for environment and mobility, and we'we been working for the last months to integrate our road graph with OSM. Currently in Milano all tram tracks are mapped separately, so they are all oneway and no way has both highway=* and railway=tram tags (apart from some cases we're correcting). Now, we would like to store the information wether a certain railway track runs in a road sharing the same space with motor vehicles. I am referring to situations similar to this one: http://wiki.openstreetmap.org/wiki/File:Tram_Amadeo.jpg Which is here on the map: https://www.openstreetmap.org/#map=19/45.470987/9.236118 I searched the wiki for a tagging or relation scheme, but found none. I was thinking about a simple tagging scheme: tram=yes|forward|backward for the highway, and road=yes for the railway. From the previous example (the picture points at the opposite direction of the highway on which it was taken: For the center way (road): tram=yes (it's on both directions) and on the two railways: road=yes (the track lies on a road used by motor vehicles) We could also user a lanes modifier: lanes=3 lanes:backward=2 tram:lanes:backward=yes|no tram:forward=yes The tram tag should not be used for tracks which run separated from the road (they are tagged with railway=tram). The tram tag should go along with access tags, as we have lanes reserved for trams and buses/taxis: http://wiki.openstreetmap.org/wiki/File:Tram_xxii_marzo.jpg So the center way (carriageway reserved to psv with two tram tracks in shared space) would get tagged as: access=no bus=yes taxi=yes tram=yes We could also think about a relation, type=tram_on_road, it could be useful for sorting things out in complex multi-carriageway situations like this one: https://www.openstreetmap.org/#map=19/45.49833/9.19607 but would also be more difficult for users to mantain and for clients to consume. Any suggestions / impressions? Thanks! Sig ___ 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] Whole planet flooded at main map?
On Fri, Feb 6, 2015 at 6:50 PM, Martin Vonwald imagic@gmail.com wrote: Is it just me or is currently the whole planet flooded on the main map? At least at zoom level 1-6. Starting with 7 countries reappear. It's flooded, yes. (but tagging isn't the proper place to ask this :-)) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
On Fri, 2015-02-06 at 13:58 +0100, Janko Mihelić wrote: Why not tourism=reception_desk? We have tourism=hotel, tourism=camp_site, tourism=information, it's only logical to use the same key. I think the idea of =reception_desk could be applied much more widely than just tourism. Commercial sites, mining sites, the list would be quite long. So, I'd vote for amenity= David ___ 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 2015-02-06 21:11, Jo wrote : I think relation street applies to all the way segments of the whole street with the same name (if in the same municipality), but I didn't check to be honest. Those kinds of relations are made to unsplit what wouldn't have been split if what I presented as SEGMENT or OVERLAY and later revised as PATCH tags were used. One of the significant differences is that this tag is unique while there are as many types of unsplitting relations as types of ways that can be split. André. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] courtyards
Courtyards use to be mapped as inner members of building multipolygons. We can also use the multipolygon relation to assign a name to the bullding. If we want to assign a name to the courtyard, we must assign it to the way. But then we need some kind of physical tag in addition. Applications won't know what do do with the name when there aren't any other tags. Some courtyards are tagged place=locality or highway=pedestrian or leisure=park, but they all seem wrong. A place=locality wouldn't be that strictly delimited, and a park or pedestrian area need not occupy the entire courtyard. A courtyard really has nothing to do with leisure=*, and it is not a highway either. It's just a hole in a building. What key can we use for this? What about place=courtyard (an area spared by a buildng), analogous to place=island (an area spared by the ocean)? -- 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] Wiki on amenity=waste_disposal Rewrite?
On Fri, 2015-02-06 at 19:31 +1100, Warin wrote: reasoned arg against (eg) amenity=waste_dog_excrement Yes, Warin, you are probably right, while a more sensible syntax, it will be resisted as too big a change. An alternative might be to declare that (eg) waste=waste_dog_excrement is on a par with amenity=, so waste= can be used without amenity=waste_disposal. In other words, bumping waste= up to a higher lever key. While a big change in principle, its technically trivial, existing tags in the database will still be valid, no changes needed, just in future, taggers can leave out the redundant amenity=waste_disposal The problem there is treating waste= as a high level tag. Considering just how big an issue waste disposal is to humanity, I cannot help but think its justified. But won't be surprised if there are dissenters David On 5/02/2015 12:04 PM, Dave Swarthout wrote: On Thu, Feb 5, 2015 at 7:10 AM, Warin 61sundow...@gmail.com wrote: You mean a one step? Like highway= x ? To do that I'd think a new supper key waste= at the top level! And maybe that is what it needs! If there are enough different kinds then why not? waste=rubbish_bin waste=skip_bin waste=dump_point waste=chemical_toilet waste=dog_excrement waste=sharps waste=cigarettes waste=excrement What does it take to justify a top level tag? I think he means that if we use a top level amenity tag like amenity=waste_disposal we are forced to make another whole set of sub keys to describe the waste being disposed of. At least that's where my criticism comes from. If however we can agree on a tag of amenity=dump_point and define it as a facility where one can dump or discharge the waste tanks of an RV or recreational boat it can be understood and rendered by evaluating only that single tag. Whether the waste being dumped is from a chemical toilet or from a plastic bag on a porta-potty or cassette then becomes irrelevant. The facility will handle it. This new top level tag might make the approval process easier too. Standing alone as it would, it nicely separates garbage and trash, or recyclables, from sewage and doesn't require any other potentially lengthy approvals for new subkeys. The present sub tag already exists and is in use .. for oil, cigarettes, grey_water, drugs, dog_excrement, etc .. so they still have to be evaluated for a true render of the facility. If what is required is a one tag entry for each waste type then amenity= will be over loaded eg amenity=waste_dog_excrement amenity=waste_cigarettes amenity=waste_sharps Note the inclusion of waste in the name .. so people don't think that they are places that sell the stuff! :) about 8 + around 28! if you include waste recycling... and I think it then needs to be a top level tag .. like shop=, tourism=. sport= etc. as there are too many of them .. and that would be opposed as it is a lot of work to change the present data and a lot of work to change the renders... at least another category of amenity ... presently * 2.1 Sustenance * 2.2 Education * 2.3 Transportation * 2.4 Financial * 2.5 Healthcare * 2.6 Entertainment, Arts Culture * 2.7 Others Add '2.8 Waste'? I don't know.. just pointing out the possible future problems? ___ 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
I didn’t know that courtyards have their own name ;-) In general, it seems a good idea to have a tag (apart from name=*) on the inner line of the multipolygon. But I would avoid the key place=* because this key is rather used for bigger features and seems to not fit well. Maybe there is another key *=courtyard that fits better? 2015-02-06 22:14 GMT, Friedrich Volkmann b...@volki.at: Courtyards use to be mapped as inner members of building multipolygons. We can also use the multipolygon relation to assign a name to the bullding. If we want to assign a name to the courtyard, we must assign it to the way. But then we need some kind of physical tag in addition. Applications won't know what do do with the name when there aren't any other tags. Some courtyards are tagged place=locality or highway=pedestrian or leisure=park, but they all seem wrong. A place=locality wouldn't be that strictly delimited, and a park or pedestrian area need not occupy the entire courtyard. A courtyard really has nothing to do with leisure=*, and it is not a highway either. It's just a hole in a building. What key can we use for this? What about place=courtyard (an area spared by a buildng), analogous to place=island (an area spared by the ocean)? -- 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 -- Lukas Sommer ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
On February 6, 2015 4:10:23 PM CST, David Bannon dban...@internode.on.net wrote: On Fri, 2015-02-06 at 13:58 +0100, Janko Mihelić wrote: Why not tourism=reception_desk? We have tourism=hotel, tourism=camp_site, tourism=information, it's only logical to use the same key. I think the idea of =reception_desk could be applied much more widely than just tourism. Commercial sites, mining sites, the list would be quite long. So, I'd vote for amenity= David ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging Agreed. The amenity tag is better, as otherwise we would need a separate tag for each industry. -- John F. Eldredge -- j...@jfeldredge.com Darkness cannot drive out darkness: only light can do that. Hate cannot drive out hate: only love can do that. -- Martin Luther King, Jr. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
On Fri, 2015-02-06 at 11:16 +, Dan S wrote: However it occurs to me that it would be useful to have some way of indicating _what_ it is the reception for. In a lot of cases, we'd probably see a larger area mapped as something, be it caravan park, mine, whatever. Then a single node within that space would represent the reception_desk. Clearly the larger area would not be tagged =reception desk would it ? The usefulness here it to identify where, in the larger area, the reception desk is. Hmm David For example, if it was part of a site relation*, then a role like role=reception would connect it to the larger entity in a meaningful way. That might be a suggested tagging option... Best Dan * http://wiki.openstreetmap.org/wiki/Relations/Proposed/Site 2015-02-06 2:03 GMT+00:00 Warin 61sundow...@gmail.com: Hi, Request for comment on new tag 'amenity=reception_desk' https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dreception_desk This comes out of the tag ON HT E tourism=camp_site WIKI PAGE which has a sub key of camp_site=reception. As 'Receptions' are numerous outside of camp sites I think it is best to have them available for use under other things - like hotels. So the new tag. 'reception_desk' .. should separate it from other types of receivers .. like radio receivers. Amenity is the best fit so amenity=reception_desk. what do you think? ___ 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
imho a courtyard is related to leisure. why for: because a courtyard matters to people with leisure time and it is a luxury of sorts. why against: perhaps a courtyard is a sequestered area/way as it is often tagger highway designated footpath as an area, an area that is a Very big way for foot traffic, and so not leisure at all, just a big highway with special rules. I would like to hear more from others. I think courtyards are important, and they are disappearing, so , if we map them, maybe they will lget more attention, and their numbers will increase. I have never tagged a courtyard as a POI, perhaps because I didn't know how. I hope this conversation can help lots of people. Thanks for bringing it up! -- Alex On Sat, Feb 7, 2015 at 6:47 AM, Lukas Sommer sommer...@gmail.com wrote: I didn't know that courtyards have their own name ;-) In general, it seems a good idea to have a tag (apart from name=*) on the inner line of the multipolygon. But I would avoid the key place=* because this key is rather used for bigger features and seems to not fit well. Maybe there is another key *=courtyard that fits better? 2015-02-06 22:14 GMT, Friedrich Volkmann b...@volki.at: Courtyards use to be mapped as inner members of building multipolygons. We can also use the multipolygon relation to assign a name to the bullding. If we want to assign a name to the courtyard, we must assign it to the way. But then we need some kind of physical tag in addition. Applications won't know what do do with the name when there aren't any other tags. Some courtyards are tagged place=locality or highway=pedestrian or leisure=park, but they all seem wrong. A place=locality wouldn't be that strictly delimited, and a park or pedestrian area need not occupy the entire courtyard. A courtyard really has nothing to do with leisure=*, and it is not a highway either. It's just a hole in a building. What key can we use for this? What about place=courtyard (an area spared by a buildng), analogous to place=island (an area spared by the ocean)? -- 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 -- Lukas Sommer ___ 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
That's how it was initially done in most places, before we started mapping those tracks in more detail, which became possible thanks to improved resolution of the aerial imagery (and in the case of Brussels, thanks to UrbIS opening the data) Jo 2015-02-07 4:02 GMT+01:00 James Mast rickmastfa...@hotmail.com: Here's how we have done this in the Pittsburgh, PA area where the 'light rail' line shares the pavement with the normal road lanes. They normally only use this line during the rush hours unless they have to close the tunnel @ Station Square and divert the light rail traffic along this route. https://www.openstreetmap.org/#map=16/40.4260/-79.9990 https://www.openstreetmap.org/way/294921081 And here's a link to what it looks like on the ground level via Google StreetView since I don't have any pictures of it since I normally don't go on that road when I'm in that area of Pittsburgh unless the Liberty Tubes are closed and they are forcing traffic this way (which is very rare). http://goo.gl/maps/ittiG Anyways, this is our only example of 'active' tracks in the road here. However, there is still a segment of road on the North Side of Pittsburgh that still has the old streetcar tracks from when that line was decommissioned in the 1980's still embedded in it, and is a brick road to boot. I don't think we have any other examples like that, but I haven't tried to do any research on all the old streetcar routes from before I was born here in Pittsburgh. -James ___ 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] Lifecycle concepts, REMOVED
On Mon, Feb 2, 2015 at 7:53 AM, Janko Mihelić jan...@gmail.com wrote: But what if hikers still refer to the spot? Like Let's go to the burnt alpine hut, and then go left. That is a pretty important landmark, even if there is no sign of the hut any more. Maybe we can tag it as place=locality. Clearly, that's a http://wiki.openstreetmap.org/wiki/Key:ruins ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tram tracks running in a road
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ć jan...@gmail.com: 2015-02-06 17:29 GMT+01:00 Luca Sigfrido Percich luca.perc...@gmail.com: 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
Re: [Tagging] Whole planet flooded at main map?
Nelson A. de Oliveira wrote on 2015-02-06 21:52: On Fri, Feb 6, 2015 at 6:50 PM, Martin Vonwald imagic@gmail.com wrote: Is it just me or is currently the whole planet flooded on the main map? At least at zoom level 1-6. Starting with 7 countries reappear. It's flooded, yes. (but tagging isn't the proper place to ask this :-)) This is usually caused by the Diluge, some uncorked coastline, or a rendering issue. Being discussed everywhere ;-) https://github.com/gravitystorm/openstreetmap-carto/issues/1294 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tram tracks running in a road
2015-02-06 17:29 GMT+01:00 Luca Sigfrido Percich luca.perc...@gmail.com: 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
Re: [Tagging] Tram tracks running in a road
Here's how we have done this in the Pittsburgh, PA area where the 'light rail' line shares the pavement with the normal road lanes. They normally only use this line during the rush hours unless they have to close the tunnel @ Station Square and divert the light rail traffic along this route. https://www.openstreetmap.org/#map=16/40.4260/-79.9990 https://www.openstreetmap.org/way/294921081 And here's a link to what it looks like on the ground level via Google StreetView since I don't have any pictures of it since I normally don't go on that road when I'm in that area of Pittsburgh unless the Liberty Tubes are closed and they are forcing traffic this way (which is very rare). http://goo.gl/maps/ittiG Anyways, this is our only example of 'active' tracks in the road here. However, there is still a segment of road on the North Side of Pittsburgh that still has the old streetcar tracks from when that line was decommissioned in the 1980's still embedded in it, and is a brick road to boot. I don't think we have any other examples like that, but I haven't tried to do any research on all the old streetcar routes from before I was born here in Pittsburgh. -James ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
I think this proposal is very relevant for some larger hotel and resorts. I've been myself a few times in a situation when I had to search for the reception over a large area. It can be a trouble if you simultaneously have to get rid of your car in a parking restricted area. Same for multi-entrance campuses where only one door can be used by guests (has a reception). On Fri, Feb 6, 2015 at 6:18 AM, Paul Johnson ba...@ursamundi.org wrote: This seems to have a bit of overlap with information to a large extent. Most have tourism information for the area they're located and vicinity and can provide a lot of the same stuff as a general tourism information office would. They just also rent space to park an RV (or even an RV or cabin), or throw up a tent. On Feb 5, 2015 8:07 PM, Warin 61sundow...@gmail.com wrote: Hi, Request for comment on new tag 'amenity=reception_desk' https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dreception_desk This comes out of the tag ON HT E tourism=camp_site WIKI PAGE which has a sub key of camp_site=reception. As 'Receptions' are numerous outside of camp sites I think it is best to have them available for use under other things - like hotels. So the new tag. 'reception_desk' .. should separate it from other types of receivers .. like radio receivers. Amenity is the best fit so amenity=reception_desk. what do you think? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
Hi, No big objections from me, sounds useful. However it occurs to me that it would be useful to have some way of indicating _what_ it is the reception for. For example, if it was part of a site relation*, then a role like role=reception would connect it to the larger entity in a meaningful way. That might be a suggested tagging option... Best Dan * http://wiki.openstreetmap.org/wiki/Relations/Proposed/Site 2015-02-06 2:03 GMT+00:00 Warin 61sundow...@gmail.com: Hi, Request for comment on new tag 'amenity=reception_desk' https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dreception_desk This comes out of the tag ON HT E tourism=camp_site WIKI PAGE which has a sub key of camp_site=reception. As 'Receptions' are numerous outside of camp sites I think it is best to have them available for use under other things - like hotels. So the new tag. 'reception_desk' .. should separate it from other types of receivers .. like radio receivers. Amenity is the best fit so amenity=reception_desk. what do you think? ___ 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 - temperature
If we're going to have a temperature key - there should be some qualitative values in human understandable ranges. Yes, they are subjective. Cool/ cold / frozen / danger-cold Warm / hot / boiling / danger-hot Mild (human range comfortable, both hot and cold) This allows tagging for objects / pipes / buildings with unexpected temperatures. there are refrigerators (cold) sub-zero freezers (danger-cold) and exposed steam pipes (Danger-hot) which have very different temperatures from their ambient environment - and knowing the exact temp of the freezer, or the range it operates in is not so useful, but knowing that it is someplace where if you stayed there, it could kill you is very useful. There could also be a sublet value to define class of method, if the object itself isn't the source of the temperature (aka a steam pipe is inherently hot, but a room is made hot by a device or method) temperature=mild temperature:hvac=controlled (heatedcooled) temperature=warm temperature:hvac=heated temperature=warm temperature:fire=heated temperature=danger-cold temperature:hvac=cooled temperature=-20 (c) temperature:hvac=cooled (freezer warehouse where the value is constant and known) Filing all the different man made heating options (radiator, electric heater, oil boiler) it all gets filed under HVAC (heating ventilation air conditioning), as method might be very hard to determine how something is kept warm, but it could be filed in the hvac subkey. Temperature:hvac=kerosene_heater Temperature:fire=wood_fireplace Just my ideas, not sure how well they fit - but having some kinds of qualitative values is important, as the range is more useful than the exact number most of the time. Javbw On Feb 6, 2015, at 9:22 AM, Bryce Nesbitt bry...@obviously.com wrote: There are cases where an approximate temperature is more useful than a single scalar number. For example a drinking fountain may be chilled, but not operating at a single fixed temperature. Similarly there's a big difference in a tropical climate between a building with A/C and one without. And a mountain hut with a fireplace, compared to one without. Neither can be expressed well as a temperature=. In many cases what matters is the ability to warm or cool from ambient. A/C give you the ability to make a room cooler than ambient, but not hotter. A fireplace the opposite. Thus perhaps instead: heated=yes cooled=no Could apply to pools, spas, hotel rooms, water taps. ___ 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 - temperature
1) +1 to drop Kelvins. 2) heated/cooled is a nice idea, but I wouldn't like seeing too many top level tags. temperature=heated temperature=cooled would be my preferred way to go. I don't like :hvac too much either, because then what do I do if I have AC + fireplace + central heating and use all of them for heating? I would rather, if needed, use temperature=heated temperature:heated=fireplace|HVAC 3) +1 for having mild added. It is not the same as ambient and is useful. Cheers, Kotya On Thu, Feb 5, 2015 at 9:14 PM, Warin 61sundow...@gmail.com wrote: On 5/02/2015 1:02 AM, fly wrote: Am 04.02.2015 um 10:56 schrieb Kotya Karapetyan: Hi, +1 for the proposal as such. I have suggestions for some parts of the proposal though. 1) I would discourage specification of the temperature without the scale indication. I have never lived in the US but I see from the Web that Americans like specifying temperature in degrees Fahrenheit without mentioning it (the same way as we in Europe use centigrade without underlying it). Taking into account the international nature of the OSM community, I foresee a significant risk that the map will get populated with invalid values. Warin is right about SI units, but SI is not even strictly followed in the technical and scientific community, not to mention the general public. Obviously, Americans in general ignore it by using inches, miles and degrees Fahrenheit :) I am afraid many people will not have heard about SI guidelines and will not have read the wiki page in significant detail. Therefore, for the sake of clarity, I suggest always specifying F or C with the temperature value. +1 Units for temperature are really wired and obviously Kelvin which I would suspect to be the default is not really used in real live as Celsius has the better scale for real life usage. I'm inclined to drop the Kelvin. Unlikely to be used, anyone using the Kelvin can easily convert it to degrees Celsius. 2) I suggest clarifying the verbal specification of the temperature. - Replace chilled with cool (by analogy with warm) and also because chilled actually assumes that I know that the object was purportedly cooled down, which adds yet another uncertainty and is usually not very relevant; - remove the definition of substantially colder etc., because it doesn't add any clarity. I agree that it is important to distinguish between safe and unsafe situations, so let's just do that: I put that in to cover the 'chilled water' that some might have or come across. Maybe more of a hot climate thing? I think the users may include it anyway so I covered it in the documentation. freezing cold — may be unsafe to handle cool warm hot — may be unsafe to handle boiling adjustable — the object temperature can be changed by consumer/user variable — the object temperature can vary on its own ambient — the object always remains at ambient temperature (note that this may include the object being cold and warm, including being unsafe to handle, depending on the ambient temperature; think about water in Siberia rivers in January) Only two values I could live with are cold and hot. Generally these values are too ambiguous and an estimated value is much better. I think I said this .. but here it is again with some more thoughts? The proposal only tags 3 conditions; adjustable - box outline around the originally rendered symbol - red at the top fading to blue at the bottom hot - box outline around the originally rendered symbol - red cold -box outline around the originally rendered symbol - blue For the numerical data rendered as above for hot if over 55 C and blue if under 0 C ?? 3) For the numeric specification, I suggest adding: - above/below options - approximate value - range of temperatures (using above/below) E.g. temperature:circa = 80 C temperature:above[:circa] = 300 C temperature:below[:circa] = 1000 C I would add this in the value like: temperature = 10 C temperature = 300 C Nice idea. But; How many object in OSM need that kind of information? If the usage is low then it probably wont be rendered. How many data entry people will know the max/mins for an OSM object? And how would it be rendered? Possibly a better tag for this would be temperature_maximum= and temperature_minimum= ___ 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
On February 6, 2015 9:37:20 AM CST, Tobias Knerr o...@tobias-knerr.de wrote: On 06.02.2015 12:16, Dan S wrote: However it occurs to me that it would be useful to have some way of indicating _what_ it is the reception for. For example, if it was part of a site relation*, then a role like role=reception would connect it to the larger entity in a meaningful way. That might be a suggested tagging option... I believe this is not necessary as long as the reception is contained in only one outline of a relevant feature (hotel, motel etc.), which will cover almost all cases. Of course, for the special cases you could use a relation, but that should be limited to those cases. What I consider a bit odd, by the way, is the amenity key. Receptions are usually not amenities by themselves, but instead part of an amenity. Perhaps a new key for this kind of sub-feature would be in order? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging One circumstance where the relation would be useful would be if you were mapping an office building, and wanted to map both the reception desk for the entire building, and also reception desks for individual office suites within that building. This is a common circumstance when a building contains offices for several different companies. -- John F. Eldredge -- j...@jfeldredge.com Darkness cannot drive out darkness: only light can do that. Hate cannot drive out hate: only love can do that. -- Martin Luther King, Jr. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
On Feb 6, 2015, at 2:18 PM, Paul Johnson ba...@ursamundi.org wrote: This seems to have a bit of overlap with information to a large extent. Most have tourism information for the area they're located and vicinity and can provide a lot of the same stuff as a general tourism information office would. They just also rent space to park an RV (or even an RV or cabin), or throw up a tent. -1 information is a place to get information, usually tourist information. Where to actually go to register for your space / hotel room / name badge / visitor check-in / visitor-checkout is a very different concept than an info kiosk or tourist info desk. Most large train stations have information booths. but its different than the ticketing window. Most hotels have a large reception desk. the information booth outside for tourists passing by is a information point. a reception desk at a hotel also has the ability to order food, but we would not confuse that with a restaurant. considering the phase “reception” is so widely used int he hospitality industry, and it can also be used for check-in at a motel, camp, or other corporate facility that handles visitors along with the working staff (like a big company office or complex where one building or space is designated reception for the visitors. It seems like a good idea to have the amenity. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Access restrictions for shoulder lanes?
In the USA occasional sections of even Interstate highways are open to bicycles, where no equivalent route exists. There's some argument to tag these as bike paths to avoid the tag soup of lanes, and ensure the (unusual) situation is perfectly clear. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
Why not tourism=reception_desk? We have tourism=hotel, tourism=camp_site, tourism=information, it's only logical to use the same key. Janko Mihelić ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Access restrictions for shoulder lanes?
Am 06.02.2015 um 14:00 schrieb Bryce Nesbitt: In the USA occasional sections of even Interstate highways are open to bicycles, where no equivalent route exists. There's some argument to tag these as bike paths to avoid the tag soup of lanes, and ensure the (unusual) situation is perfectly clear. Why is bicycle=yes and motorroad=no not enough ? Please no separate ways, as you loose the information that you are using a motorway and might looking forward to find a nice bicycle path. cu fly ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
On 06.02.2015 12:16, Dan S wrote: However it occurs to me that it would be useful to have some way of indicating _what_ it is the reception for. For example, if it was part of a site relation*, then a role like role=reception would connect it to the larger entity in a meaningful way. That might be a suggested tagging option... I believe this is not necessary as long as the reception is contained in only one outline of a relevant feature (hotel, motel etc.), which will cover almost all cases. Of course, for the special cases you could use a relation, but that should be limited to those cases. What I consider a bit odd, by the way, is the amenity key. Receptions are usually not amenities by themselves, but instead part of an amenity. Perhaps a new key for this kind of sub-feature would be in order? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tram tracks running in a road
Ciao, hai guardato come l'hanno fatto altre città che hanno tram su strada? Mi vengono in mente: Strasbourg, Muenchen, Karlsruhe, San Francisco, Basel, ... Cari saluti Volker Padova, Italy On 6 February 2015 at 17:29, Luca Sigfrido Percich luca.perc...@gmail.com wrote: Hi all, first time I write to the list (after lurking for a while), so I introduce myself. I am from Milano - Italy, I work for the municipality's agency for environment and mobility, and we'we been working for the last months to integrate our road graph with OSM. Currently in Milano all tram tracks are mapped separately, so they are all oneway and no way has both highway=* and railway=tram tags (apart from some cases we're correcting). Now, we would like to store the information wether a certain railway track runs in a road sharing the same space with motor vehicles. I am referring to situations similar to this one: http://wiki.openstreetmap.org/wiki/File:Tram_Amadeo.jpg Which is here on the map: https://www.openstreetmap.org/#map=19/45.470987/9.236118 I searched the wiki for a tagging or relation scheme, but found none. I was thinking about a simple tagging scheme: tram=yes|forward|backward for the highway, and road=yes for the railway. From the previous example (the picture points at the opposite direction of the highway on which it was taken: For the center way (road): tram=yes (it's on both directions) and on the two railways: road=yes (the track lies on a road used by motor vehicles) We could also user a lanes modifier: lanes=3 lanes:backward=2 tram:lanes:backward=yes|no tram:forward=yes The tram tag should not be used for tracks which run separated from the road (they are tagged with railway=tram). The tram tag should go along with access tags, as we have lanes reserved for trams and buses/taxis: http://wiki.openstreetmap.org/wiki/File:Tram_xxii_marzo.jpg So the center way (carriageway reserved to psv with two tram tracks in shared space) would get tagged as: access=no bus=yes taxi=yes tram=yes We could also think about a relation, type=tram_on_road, it could be useful for sorting things out in complex multi-carriageway situations like this one: https://www.openstreetmap.org/#map=19/45.49833/9.19607 but would also be more difficult for users to mantain and for clients to consume. Any suggestions / impressions? Thanks! Sig ___ 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] Tram tracks running in a road
Hi all, first time I write to the list (after lurking for a while), so I introduce myself. I am from Milano - Italy, I work for the municipality's agency for environment and mobility, and we'we been working for the last months to integrate our road graph with OSM. Currently in Milano all tram tracks are mapped separately, so they are all oneway and no way has both highway=* and railway=tram tags (apart from some cases we're correcting). Now, we would like to store the information wether a certain railway track runs in a road sharing the same space with motor vehicles. I am referring to situations similar to this one: http://wiki.openstreetmap.org/wiki/File:Tram_Amadeo.jpg Which is here on the map: https://www.openstreetmap.org/#map=19/45.470987/9.236118 I searched the wiki for a tagging or relation scheme, but found none. I was thinking about a simple tagging scheme: tram=yes|forward|backward for the highway, and road=yes for the railway. From the previous example (the picture points at the opposite direction of the highway on which it was taken: For the center way (road): tram=yes (it's on both directions) and on the two railways: road=yes (the track lies on a road used by motor vehicles) We could also user a lanes modifier: lanes=3 lanes:backward=2 tram:lanes:backward=yes|no tram:forward=yes The tram tag should not be used for tracks which run separated from the road (they are tagged with railway=tram). The tram tag should go along with access tags, as we have lanes reserved for trams and buses/taxis: http://wiki.openstreetmap.org/wiki/File:Tram_xxii_marzo.jpg So the center way (carriageway reserved to psv with two tram tracks in shared space) would get tagged as: access=no bus=yes taxi=yes tram=yes We could also think about a relation, type=tram_on_road, it could be useful for sorting things out in complex multi-carriageway situations like this one: https://www.openstreetmap.org/#map=19/45.49833/9.19607 but would also be more difficult for users to mantain and for clients to consume. Any suggestions / impressions? Thanks! Sig ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tram tracks running in a road
Ciao Luca, For an example of a road with many variations in how the tram tracks are embedded, you can have a look at this stretch I mapped a few months ago: http://www.openstreetmap.org/#map=16/50.8601/4.3117 To indicate how they belong together, maybe a street or associatedStreet relation makes sense? Jo 2015-02-06 17:29 GMT+01:00 Luca Sigfrido Percich luca.perc...@gmail.com: Hi all, first time I write to the list (after lurking for a while), so I introduce myself. I am from Milano - Italy, I work for the municipality's agency for environment and mobility, and we'we been working for the last months to integrate our road graph with OSM. Currently in Milano all tram tracks are mapped separately, so they are all oneway and no way has both highway=* and railway=tram tags (apart from some cases we're correcting). Now, we would like to store the information wether a certain railway track runs in a road sharing the same space with motor vehicles. I am referring to situations similar to this one: http://wiki.openstreetmap.org/wiki/File:Tram_Amadeo.jpg Which is here on the map: https://www.openstreetmap.org/#map=19/45.470987/9.236118 I searched the wiki for a tagging or relation scheme, but found none. I was thinking about a simple tagging scheme: tram=yes|forward|backward for the highway, and road=yes for the railway. From the previous example (the picture points at the opposite direction of the highway on which it was taken: For the center way (road): tram=yes (it's on both directions) and on the two railways: road=yes (the track lies on a road used by motor vehicles) We could also user a lanes modifier: lanes=3 lanes:backward=2 tram:lanes:backward=yes|no tram:forward=yes The tram tag should not be used for tracks which run separated from the road (they are tagged with railway=tram). The tram tag should go along with access tags, as we have lanes reserved for trams and buses/taxis: http://wiki.openstreetmap.org/wiki/File:Tram_xxii_marzo.jpg So the center way (carriageway reserved to psv with two tram tracks in shared space) would get tagged as: access=no bus=yes taxi=yes tram=yes We could also think about a relation, type=tram_on_road, it could be useful for sorting things out in complex multi-carriageway situations like this one: https://www.openstreetmap.org/#map=19/45.49833/9.19607 but would also be more difficult for users to mantain and for clients to consume. Any suggestions / impressions? Thanks! Sig ___ 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
Many thanks Jo! Volker also suggests that I should see how things are mapped in other major cities, and so I'll do. So you confirm that there isn't an established way of expressing the tram-in-road relationship? The use of the street relation has been suggested by a fellow member of the italian discussion group. It's not clear from the wiki, however, if this relation can be used for associating railways to highways for a single road segment (from crossroads to crossroads) or is meant for associating everything which belongs to a single street (so all the railways and highways which belong to the same street). I'll investigate further. Many thanks! Sig 2015-02-06 19:26 GMT+01:00 Jo winfi...@gmail.com: Ciao Luca, For an example of a road with many variations in how the tram tracks are embedded, you can have a look at this stretch I mapped a few months ago: http://www.openstreetmap.org/#map=16/50.8601/4.3117 To indicate how they belong together, maybe a street or associatedStreet relation makes sense? Jo 2015-02-06 17:29 GMT+01:00 Luca Sigfrido Percich luca.perc...@gmail.com: Hi all, first time I write to the list (after lurking for a while), so I introduce myself. I am from Milano - Italy, I work for the municipality's agency for environment and mobility, and we'we been working for the last months to integrate our road graph with OSM. Currently in Milano all tram tracks are mapped separately, so they are all oneway and no way has both highway=* and railway=tram tags (apart from some cases we're correcting). Now, we would like to store the information wether a certain railway track runs in a road sharing the same space with motor vehicles. I am referring to situations similar to this one: http://wiki.openstreetmap.org/wiki/File:Tram_Amadeo.jpg Which is here on the map: https://www.openstreetmap.org/#map=19/45.470987/9.236118 I searched the wiki for a tagging or relation scheme, but found none. I was thinking about a simple tagging scheme: tram=yes|forward|backward for the highway, and road=yes for the railway. From the previous example (the picture points at the opposite direction of the highway on which it was taken: For the center way (road): tram=yes (it's on both directions) and on the two railways: road=yes (the track lies on a road used by motor vehicles) We could also user a lanes modifier: lanes=3 lanes:backward=2 tram:lanes:backward=yes|no tram:forward=yes The tram tag should not be used for tracks which run separated from the road (they are tagged with railway=tram). The tram tag should go along with access tags, as we have lanes reserved for trams and buses/taxis: http://wiki.openstreetmap.org/wiki/File:Tram_xxii_marzo.jpg So the center way (carriageway reserved to psv with two tram tracks in shared space) would get tagged as: access=no bus=yes taxi=yes tram=yes We could also think about a relation, type=tram_on_road, it could be useful for sorting things out in complex multi-carriageway situations like this one: https://www.openstreetmap.org/#map=19/45.49833/9.19607 but would also be more difficult for users to mantain and for clients to consume. Any suggestions / impressions? Thanks! Sig ___ 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
