Re: [Tagging] Feature Proposal - RFC - goods_conveyor
Thanks for picking up on this. I used the tag a while ago to tag a coal conveyor here in Thailand. Of course it doesn't render on OSM and I'll need to come up with a way to render it for my GPS at some point. Seeing as there are so many existing man_made=good_conveyor tags I agree with your thinking on that item. The resource=* tag is for specifying the material or goods that are being transported.That seems fine to me. Dave On Wed, Feb 25, 2015 at 8:13 PM, Friedrich Volkmann b...@volki.at wrote: http://wiki.openstreetmap.org/wiki/Proposed_features/Goods_conveyor I resurrected this old draft, because we need a tag for this and I know of no alternative tag currently in use. I wonder if goods may be misleading, because I think of goods as finished products, while many conveyors carry raw materials. Anyway, there are 589 uses of man_made=goods_conveyor, so we better stick with it. -- 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 -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Breakdown bays?
Hi! I obviously forgot how to tag breakdown bays (lay-bys, german: Pannenbucht), something like this: http://binged.it/1LCYpoM Couldn't find anything in the wiki or taginfo. Any tips? Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Canopy radius for natural=tree
On 25.02.2015 11:47, Martin Koppenhoefer wrote: it is using the natural language notation with space (underscore) rather than diameter:crown. I feel that this differentiation became blurry due to the random use of : and _ for _type and :type suffixes. -- 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] Breakdown bays?
2015-02-25 15:20 GMT+01:00 Martin Vonwald imagic@gmail.com: I obviously forgot how to tag breakdown bays (lay-bys, german: Pannenbucht), something like this: http://binged.it/1LCYpoM Couldn't find anything in the wiki or taginfo. could be something for the emergency key? Or highway. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - goods_conveyor
2015-02-25 14:13 GMT+01:00 Friedrich Volkmann b...@volki.at: http://wiki.openstreetmap.org/wiki/Proposed_features/Goods_conveyor I resurrected this old draft, because we need a tag for this and I know of no alternative tag currently in use. I wonder if goods may be misleading, because I think of goods as finished products, while many conveyors carry raw materials. Anyway, there are 589 uses of man_made=goods_conveyor, so we better stick with it. is this for belt conveyors and roller conveyors? There are also pneumatic conveyors (with tubes, e.g. postal pneumatic tubes) and there are chain conveyors. Not sure if a general goods conveyor tag is the right approach to this (semantically), or if we better distinguish already on the primary tag, the name goods conveyor implies a more general usage than what actually seems within the scope of this proposal. Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - RFC - goods_conveyor
http://wiki.openstreetmap.org/wiki/Proposed_features/Goods_conveyor I resurrected this old draft, because we need a tag for this and I know of no alternative tag currently in use. I wonder if goods may be misleading, because I think of goods as finished products, while many conveyors carry raw materials. Anyway, there are 589 uses of man_made=goods_conveyor, so we better stick with it. -- 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] Feature Proposal - RFC - addrN:*
2015-01-23 8:55 GMT+01:00 Swen Wacker swen.wac...@gmail.com: 2015-01-22 19:44 GMT+01:00 fly lowfligh...@googlemail.com: In Germany the address always belongs to the plot and not to the building and they are assigned in advance. This is not correct. The decision is up to the local government. In most local Hausnummer-Satzung (by-law about housenumber) that I've looked at there is a preference for buildings. German-speaking might look huere: http://forum.openstreetmap.org/viewtopic.php?pid=472337#p472337 If you look for Hausnummernsatzung it is clear you'll find likely building related stuff ;-) Have a look for Grundstücksnummerierung to find plot related information. There is national law (BauGB) that clearly states that the basis for all numbering is the plot (§126): (3) Der Eigentümer hat sein Grundstück mit der von der Gemeinde festgesetzten Nummer zu versehen. Im Übrigen gelten die landesrechtlichen Vorschriften. The lower admin entities (Land and Gemeinde) can and typically will have regulation how to reduce ambiguities (e.g. numbering of buildings, staircases, entrances, etc. if needed), and often details about shape, size and illumination of the numbers and where to put them exactly and how the system is working (consecutive numbering or even / odd numbers per street side, etc.). E.g. the Nummerierungsverordnung Berlin: http://www.stadtentwicklung.berlin.de/service/gesetzestexte/de/download/geoinformation/Vorschriftensammlung/7_1.pdf In the case of Baden-Württemberg, there are no regulations on Landes-level concerning housenumbers (AFAIK), but the municipalities have their own laws (Gemeindesatzung). E.g. this is the regulation that states that in Karlsruhe you have to put housenumbers on your _plot_, if it is used for residential or commercial purposes: http://web1.karlsruhe.de/Stadt/Stadtrecht/s-6-1-3.php I have not yet found any text that doesn't state that the plot is the main unit for numbering (and I doubt it exists, because it would conflict with federal law). Clearly, if there are numbers for several entrances (and often there are), you should consider mapping them there. Maybe our current scheme is not sufficient for mapping all those subtleties. I could imagine having 2 entities: an area which has a certain address, and an entrance node by which you can access this area. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] AddrN
2015-01-21 13:00 GMT+01:00 Andrew Shadura and...@shadura.me: But that's not precisely true. The scope of an address node inside a building outline is this building. If you want to specify an address for a part of a building only, just split that building. no, you seem to extrapolate from your experience to different situations in other countries and fail. In Italy you'll get a housenumber for every building access, it is really common to see a store with several doors leading to the street and every door has it's own housenumber. These numbers are not valid for the whole building, but only for the area you can access through them. A node inside the building contour cannot tell you the actual extension of the housenumber. I have also seen cases where semi-underground stores (i.e. you'll take a dedicated stair from the street level to enter) have gotten their own housenumbers, different from the rest of the building. You shouldn't split the building if it's one building, but you could split it into building parts (still remains one building), but you won't get along with this approach if you continued tagging addresses on nodes, you will have to tag them on areas to define the scope. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Super-keys are evil
Though, I have to admit that introducing new categories nor moving tags from one to another is not easy and often bricks, like osm-carto will not support it for quite some time, are through between your legs. Still in favour of introducing some more categories. cu fly Am 24.02.2015 um 20:02 schrieb Frederik Ramm: On 02/23/2015 02:43 AM, Kurt Blunt wrote: Right now, tags serve two distinct purposes. There are attribute tags like name=Wall Street, and there are category tags like amenity=parking or aeroway=helipad. This works for many things but not all; the border can be blurred. You will not be able to fit every key into your category or attribute schema. Many tags don't even make sense. What does highway=track mean? Is it a highway that acts as a track? A track is clearly not a type of highway. A track is just a track. And if you travel along a dark track in the night then you might be robbed by a highwayman. A contributor is left to feel like an idiot for not understanding the logic behind this system. Woe betide all who mistake highway=unclasssified for a street that lacks classification. For these reasons, I believe there is a case to be made for an overhaul of category tags. My personal opinion is that we should get rid of super-keys altogether and instead promote all categories to keys with empty values: amenity=reception_desk becomes reception_desk=, highway=track becomes track=, aerialway=gondola becomes gondola=, barrier=city_wall becomes city_wall=, historic=city_gate becomes city_gate=, sport=volleyball becomes volleyball=, etc. And power=line becomes line= and barrier=line becomes, uh, wait a minute. It is not so simple, even leaving aside the fact that many programs would simply dismiss your empty values. Now, I don't actually think such an overhaul is currently feasible given the massive burden it would put on the database system. However, it might be something to think about for the future. I think that in theory what you call super keys is a good thing to have because it gives you a layered level of understanding. For example, if someone tags natural=water water=lake lake=turlough then you have a chance to understand this is a natural feature (and not man-made) even if you don't know what a lake is; you can understand this is a lake (and not a reservoir) even if you don't know what a turlough is; or you're so much into water bodies that you can actually understand the full message. If the tag was instead the space-saving turlough= then you'd be stumped without recourse to the giant tag dictionary that explains to your renderer that something tagged turlough= should perhaps be drawn in a blue-ish colour. Matter in a nutshell: Certainly the way we use these super tags has a lot of historical baggage but I don't think it is a stupid idea per se, *especially* if your goal is (like you're claiming yours to be) making tags easy for mappers. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Canopy radius for natural=tree
2015-02-25 14:23 GMT+01:00 Friedrich Volkmann b...@volki.at: On 25.02.2015 11:47, Martin Koppenhoefer wrote: it is using the natural language notation with space (underscore) rather than diameter:crown. I feel that this differentiation became blurry due to the random use of : and _ for _type and :type suffixes. there are other indications that diameter_crown is the odd one in our tagging systems: search for diameter in taginfo http://taginfo.osm.org/search?q=diameter and you'll find 168K fire_hydrant:diameter 145K diameter_crown 3,5 K hole:diameter 2 K rotor:diameter and a lot of not so much used other diameters, including 2 trunk:diameter but 0 trunk_diameter. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Breakdown bays?
2015-02-25 16:34 GMT+01:00 fly lowfligh...@googlemail.com: So what do you have in mind ? Tagging them as additional tag on the way with highway=*? Using lanes:-Tagging ? I don't think of them as lanes, so I wouldn't use some :lanes-tag. I thought that there is already a tag, that I simply put on the road for the length of the bay - just like e.g. sidewalk=right. But that's obviously not the case and it is not possible with highway=emergency_bay. When tagged as node I lose the length. Tagging as separate way seem counter-intuitive - there is no separate road. Tagging as area seems... strange ;-) Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - goods_conveyor
On Wed, Feb 25, 2015 at 02:13:34PM +0100, Friedrich Volkmann wrote: http://wiki.openstreetmap.org/wiki/Proposed_features/Goods_conveyor I resurrected this old draft, because we need a tag for this and I know of no alternative tag currently in use. I wonder if goods may be misleading, because I think of goods as finished products, while many conveyors carry raw materials. Anyway, there are 589 uses of man_made=goods_conveyor, so we better stick with it. there is aerialway=magic_carpet which is intended for human transport only but together with usage access keys could be used to tag that as well. The proposal looks good, add location=* to it. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Breakdown bays?
http://wiki.openstreetmap.org/wiki/Proposed_features/emergency_bay On 25 February 2015 at 15:33, Martin Koppenhoefer dieterdre...@gmail.com wrote: 2015-02-25 15:20 GMT+01:00 Martin Vonwald imagic@gmail.com: I obviously forgot how to tag breakdown bays (lay-bys, german: Pannenbucht), something like this: http://binged.it/1LCYpoM Couldn't find anything in the wiki or taginfo. could be something for the emergency key? Or highway. cheers, Martin ___ 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 - goods_conveyor
On 25.02.2015 15:42, Martin Koppenhoefer wrote: is this for belt conveyors and roller conveyors? There are also pneumatic conveyors (with tubes, e.g. postal pneumatic tubes) and there are chain conveyors. See the subtags section in the proposal. By proposal I mean the wiki page. -- 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] Feature Proposal - RFC - addrN:*
2015-02-25 15:09 GMT+01:00 Swen Wacker swen.wac...@gmail.com: I have not yet found any text that doesn't state that the plot is the main unit for numbering http://www.rosenheim.de/uploads/media/631f.pdf http://www.bad-doberan.de/uploads/media/Hausnummernsatzung.pdf http://www.grimmen.de/cgi-bin/homepage/grimmen/Satzung_Straszen-Hausnummern http://www.saalfeld.de/files/1097774A150/Satzung+ueber+Strassennamen+und+Hausnummern.pdf thank you for these references. I have noticed that all of them reference the BauGB §126, which seems to confirm that this is the legal basis for the numbering. So we can conclude that some Länder / Gemeinden (federal states / municipalities) will assign numbers to empty plots only as an exception (public needs or on request of the proprietor if he can prove a special requirement) and will assign numbers to every independently used building, while others (like the aforementioned Berlin) put the focus on the plot. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Breakdown bays?
Hm...had a quick look how they are tagged and I'm not really convinced. They are tagged as area beside the road (without any connection) or as individual roads. In my opinion both does not fit well :-/ Thanks anyway, Martin 2015-02-25 16:11 GMT+01:00 Volker Schmidt vosc...@gmail.com: http://wiki.openstreetmap.org/wiki/Proposed_features/emergency_bay On 25 February 2015 at 15:33, Martin Koppenhoefer dieterdre...@gmail.com wrote: 2015-02-25 15:20 GMT+01:00 Martin Vonwald imagic@gmail.com: I obviously forgot how to tag breakdown bays (lay-bys, german: Pannenbucht), something like this: http://binged.it/1LCYpoM Couldn't find anything in the wiki or taginfo. could be something for the emergency key? Or highway. cheers, Martin ___ 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] Breakdown bays?
Here in Italy they are tagged in some areas and as nodes: http://overpass-turbo.eu/s/7SA On 25 February 2015 at 16:19, Martin Vonwald imagic@gmail.com wrote: Hm...had a quick look how they are tagged and I'm not really convinced. They are tagged as area beside the road (without any connection) or as individual roads. In my opinion both does not fit well :-/ Thanks anyway, Martin 2015-02-25 16:11 GMT+01:00 Volker Schmidt vosc...@gmail.com: http://wiki.openstreetmap.org/wiki/Proposed_features/emergency_bay On 25 February 2015 at 15:33, Martin Koppenhoefer dieterdre...@gmail.com wrote: 2015-02-25 15:20 GMT+01:00 Martin Vonwald imagic@gmail.com: I obviously forgot how to tag breakdown bays (lay-bys, german: Pannenbucht), something like this: http://binged.it/1LCYpoM Couldn't find anything in the wiki or taginfo. could be something for the emergency key? Or highway. cheers, Martin ___ 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] Breakdown bays?
Am 25.02.2015 um 16:19 schrieb Martin Vonwald: Hm...had a quick look how they are tagged and I'm not really convinced. They are tagged as area beside the road (without any connection) or as individual roads. In my opinion both does not fit well :-/ So what do you have in mind ? Tagging them as additional tag on the way with highway=*? Using lanes:-Tagging ? I use lanes:-Tagging for bus_bays by the way. cu fly ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Breakdown bays?
Am 25.02.2015 um 16:41 schrieb Martin Vonwald: 2015-02-25 16:34 GMT+01:00 fly lowfligh...@googlemail.com: So what do you have in mind ? Tagging them as additional tag on the way with highway=*? Using lanes:-Tagging ? I don't think of them as lanes, so I wouldn't use some :lanes-tag. I thought that there is already a tag, that I simply put on the road for the length of the bay - just like e.g. sidewalk=right. But that's obviously not the case and it is not possible with highway=emergency_bay. Well, emergency=bay might interfere with access tagging and we should probably use left/right as you will find them not only on dual carriage roads. emergency_bay=both/left/right ? When tagged as node I lose the length. Tagging as separate way seem counter-intuitive - there is no separate road. Tagging as area seems... strange ;-) +1 How do we tag emergency lanes ? At least in cases of lanes the position of the phone is also important. Cheers fly ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Does oneway:bicycle apply to cycleway=track?
Hi all, I have a situation where a cycleway=track is not a oneway, while the highway itself is a oneway=yes. So I added oneway:bicycle=no to the way because it is true from at least one point of view. The same problem applies to cycleway=opposite_track. BTW: Neither graphhopper nor mapquest supports cycleway=opposite_track without oneway:bicycle=no. I also asked the question on the discussions page of wiki page about oneway: http://wiki.openstreetmap.org/wiki/Talk:Key:oneway#Does_oneway:bicycle_also_apply_to_cycleway.3Dtrack_or_cycleway.3Dopposite_track.3F Cheers Tobias ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Breakdown bays?
On 25/02/2015 16:41, Martin Vonwald wrote: I don't think of them as lanes, so I wouldn't use some :lanes-tag. I thought that there is already a tag, that I simply put on the road for the length of the bay - just like e.g. sidewalk=right. But that's obviously not the case and it is not possible with highway=emergency_bay. When tagged as node I lose the length. Tagging as separate way seem counter-intuitive - there is no separate road. Tagging as area seems... strange ;-) Well, we already have the approved feature http://wiki.openstreetmap.org/wiki/Tag:highway%3Dpassing_place for features of a very similar physical nature but for a different purpose. The consistent solution is to use highway=emergency_bay on nodes in the same way as for passing places. And why do you want that kind of details? If it is tagged as emergency_bay you know it is big enough for a broken down vehicle. That is the only information you really need if you are having car problems. And adding an attribute to a short section of highway just results in further (in my opinion unnecessary) fragmentation of highways. If you really want to add the length you could use maxlength=* for the maximum vehicle length fitting in the bay. That would also be easier for data consumers to process. Ole ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - goods_conveyor
On 25.02.2015 17:16, Richard Z. wrote: there is aerialway=magic_carpet which is intended for human transport only but together with usage access keys could be used to tag that as well. I don't think so, because: - goods conveyors are not really aerialways - goods conveyors are not called magic carpets - we cannot extend usage to goods while leaving out moving walkways (for which the conveying=* key has been approved) The proposal looks good, add location=* to it. I dislike location=* for various reasons. But you may use it if you like. This is another subject with no impact on the proposed man_made=goods_conveyor key. -- 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] Feature Proposal - RFC - addrN:*
2015-02-25 15:57 GMT+01:00 Martin Koppenhoefer dieterdre...@gmail.com: thank you for these references. I have noticed that all of them reference the BauGB §126, which seems to confirm that this is the legal basis for the numbering Are you kidding me? :-) 1. Neither http://www.rosenheim.de/uploads/media/631f.pdf nor http://www.bad-doberan.de/uploads/media/Hausnummernsatzung.pdf reference to BBauG. And there a lot of more. 2. Referencing to BBauG is meaningless, because every local law (Satzung) needs a landesrechtliche legislative http://www.dict.cc/englisch-deutsch/legislative.html basis. 2. Your thesis has been, that you not yet found any text that doesn't state that the plot is the main unit for numbering reason. That hav been the only reason for this list. 3. I have linked to an official http://www.dict.cc/englisch-deutsch/official.html headnote http://www.dict.cc/englisch-deutsch/headnotes.html (Leitsatz) which says the obviousness http://www.dict.cc/englisch-deutsch/obviousness.html The right to grant of house numbers based on ... [community law] We can conclude that (in Germany) it depends only on local law. We can conclude that there is no exception / general case plot/buildung We can conclude, that D.h., die Hausnummern beziehen sich in Deutschland grundsätzlich auf Grundstücke http://wiki.openstreetmap.org/wiki/DE:Karlsruhe_Schema#Rechtliche_Situation lacks any legal meaning. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - goods_conveyor
If all these goods conveyors could be consolidated under one tag, it would be far easier to gain rendering support. Subtags could be used for the infinite variety of types. Basically these are linear structures on the ground, which convey something (goods, passengers, mixed), and either do or don't allow crossing (magic carpets block crossing, chair lifts do not block crossing). So what's the generic tagging here? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Does oneway:bicycle apply to cycleway=track?
Hey Tobias. The implied problem in your question is how to interpret a (main) tag on an osm_way. Does it only apply to the carriageway/driving lanes or to the whole street which also includes cycleways, sidewalks, etc ? Just consider the width=* or lanes=* tags. Yet, I wouldn't go so far as to declare it wrong tagging, but I personally would not tag oneway:bicycle=no on such streets as describes by you. Instead I would add cycleway:oneway=no to the osm_way and avoid the issue. (On cycleway=opposite_track I'd use cycleway:oneway=-1) Just my quick thoughts, yours Hubert ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - RFC - (traffic signals group)
Hello. This is a request for comments for the proposal http://wiki.openstreetmap.org/wiki/Proposed_features/traffic_signals_group The original author is Sanderd17. With the consent of him, I did some supplementing. Thanks to Sanerd17! Unlike the proposal “Proposed features/Traffic Signals” of Lukas Schaus, this is _not_ about traffic light circuits, but just about grouping together all nodes with highway=traffic_signals that belong to a traffic signal system at one place. This could be useful in Japan, where traffic signal systems have namen. (Thanks to nyampire and javbw for suggestions and comments.) This could be useful for routing/turn-to-turn navigation engines to calculate better the time penalty for the traffic signal system. Best regards sommerluk ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Does oneway:bicycle apply to cycleway=track?
Am 25.02.2015 um 22:20 schrieb Hubert: The implied problem in your question is how to interpret a (main) tag on an osm_way. Does it only apply to the carriageway/driving lanes or to the whole street which also includes cycleways, sidewalks, etc ? Just consider the width=* or lanes=* tags. Is there any propsal for width? lanes=* is a good example. It does only count the number of lanes for cars, those for bicycles are not counted and at bicycle:lanes=* each bicycle lane is associated to a lane for motor vehicles. Yet, I wouldn't go so far as to declare it wrong tagging, but I personally would not tag oneway:bicycle=no on such streets as describes by you. Instead I would add cycleway:oneway=no to the osm_way and avoid the issue. I am using a tagging like cycleway:right:oneway=no if it was only applied to a single side. cycleway:oneway=no if it was applied to all cycleways. If there is only cycleway:right=track, the above cycleway:oneway=no would mean the same as cycleway:right:oneway=no. (On cycleway=opposite_track I'd use cycleway:oneway=-1) Sounds good, but may be there exists something like a default? I cannot find any combinations with taginfo. But may be this is interesting. For cycleway=opposite the majority of uses is without oneway:bicycle. So there may be that oneway case included as default, too. But if you think about the tagging, than oneway=* applies to everything of the highway except pedestrians. So if there is an exception to the way you would look in second instance for those oneway:*=* tags and make your decision. In the other case you have to check for each possibility what mappers may have tagged on the way e.g. cycleway:both:oneway cycleway:left:oneway cycleway:right:oneway cycleway:oneway cycleway=opposite cycleway=opposite_lane cycleway=opposite_track Whether it applies to the carriageway or a cycle track may be concluded from other tags, too. For example cycleway=opposite implies oneway:bicycle is applied to the carriageway and a penalty for cars. cycleway:freedom_of_choice=no or cycleway:obligatory=yes would imply that oneway:bicycle does not matter for cars. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Does oneway:bicycle apply to cycleway=track?
Am 26.02.2015 um 01:54 schrieb Martin Koppenhoefer: I'd say you have met the limits of cycleway=track. You can solve this by creating a proper osm object for what is a distinct way in the real world as well. Well, this is almost the same as cycleway=opposite_track, but that tag is obviously not the limit. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - (traffic signals group)
Hi, This could be confused with the coordination of traffic signals along a length of road or even a district wide coordination of traffic light signals. I think it needs some words that restrict it to a single intersection? And possibly some thought to where a length of road (many intersections) or a district wide coordination of traffic signals occurs? If the name 'traffic signals group' is taken what name would you give this? May be a different name for this 'group'? Such as ? traffic signals set? On 26/02/2015 8:59 AM, Lukas Sommer wrote: Hello. This is a request for comments for the proposal http://wiki.openstreetmap.org/wiki/Proposed_features/traffic_signals_group The original author is Sanderd17. With the consent of him, I did some supplementing. Thanks to Sanerd17! Unlike the proposal “Proposed features/Traffic Signals” of Lukas Schaus, this is _not_ about traffic light circuits, but just about grouping together all nodes with highway=traffic_signals that belong to a traffic signal system at one place. This could be useful in Japan, where traffic signal systems have namen. (Thanks to nyampire and javbw for suggestions and comments.) This could be useful for routing/turn-to-turn navigation engines to calculate better the time penalty for the traffic signal system. Best regards sommerluk ___ 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] Super-keys are evil
Matter in a nutshell: Certainly the way we use these super tags has a lot of historical baggage but I don't think it is a stupid idea per se, *especially* if your goal is (like you're claiming yours to be) making tags easy for mappers. I apologize for writing like a troll. I should have been more respectful of the work that's gone into designing the current tagging system. The real world is messy, so any tagging system will have pros and cons. It's easy for me as an outsider to come here and criticize past decisions, but it's not productive. To everyone who has contributed to it over the years, I say thank you for helping to create a free world map. FREE 3D MARINE AQUARIUM SCREENSAVER - Watch dolphins, sharks orcas on your desktop! Check it out at http://www.inbox.com/marineaquarium ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Does oneway:bicycle apply to cycleway=track?
I'd say you have met the limits of cycleway=track. You can solve this by creating a proper osm object for what is a distinct way in the real world as well. Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - goods_conveyor
On Wed, Feb 25, 2015 at 07:14:36PM +0100, Friedrich Volkmann wrote: The proposal looks good, add location=* to it. I dislike location=* for various reasons. But you may use it if you like. the proposal could be more detailed in this point. How do you tag conveyors above ground? As bridge? Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - goods_conveyor
The proposal looks good, add location=* to it. I dislike location=* for various reasons. But you may use it if you like. I first came across the location key when it was used to indicate whether the Trans-Alaska Pipeline was running underground or overground. At the time I thought it was a bad choice of words but it is fairly well established in the OSM schema by now (44K occurrences of over- or underground). Other important and potentially useful values of location are: overhead, indoors, outdoors, underwater. The one goods_conveyor I tagged was moving coal, as I said, and at several points it was running over a roadway on a bridge. I was unable to tag the bridge in a way that caused it to show up on the OSM slippy map. Any potential rendering solutions would need to take that into account somehow. On Thu, Feb 26, 2015 at 6:29 AM, Richard Z. ricoz@gmail.com wrote: On Wed, Feb 25, 2015 at 07:14:36PM +0100, Friedrich Volkmann wrote: The proposal looks good, add location=* to it. I dislike location=* for various reasons. But you may use it if you like. the proposal could be more detailed in this point. How do you tag conveyors above ground? As bridge? Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - goods_conveyor
Would layer work for this. A layer of zero for something you can't pass at ground level. A layer of -1 for pipelines. A layer of 1 for ski lifts and areoways. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - (traffic signals group)
If group is not a good word, then set is a good alternative. Javbw On Feb 26, 2015, at 8:33 AM, Warin 61sundow...@gmail.com wrote: Hi, This could be confused with the coordination of traffic signals along a length of road or even a district wide coordination of traffic light signals. I think it needs some words that restrict it to a single intersection? And possibly some thought to where a length of road (many intersections) or a district wide coordination of traffic signals occurs? If the name 'traffic signals group' is taken what name would you give this? May be a different name for this 'group'? Such as ? traffic signals set? On 26/02/2015 8:59 AM, Lukas Sommer wrote: Hello. This is a request for comments for the proposal http://wiki.openstreetmap.org/wiki/Proposed_features/traffic_signals_group The original author is Sanderd17. With the consent of him, I did some supplementing. Thanks to Sanerd17! Unlike the proposal “Proposed features/Traffic Signals” of Lukas Schaus, this is _not_ about traffic light circuits, but just about grouping together all nodes with highway=traffic_signals that belong to a traffic signal system at one place. This could be useful in Japan, where traffic signal systems have namen. (Thanks to nyampire and javbw for suggestions and comments.) This could be useful for routing/turn-to-turn navigation engines to calculate better the time penalty for the traffic signal system. Best regards sommerluk ___ 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 - goods_conveyor
The Trans-Alaska pipeline has many underground sections and these have no layer tag. Why that is, I don't know. It also uses a key type to specify what it carries. In this case type=oil See here: http://overpass-turbo.eu/s/7SZ On Thu, Feb 26, 2015 at 8:49 AM, John Willis jo...@mac.com wrote: Those (fixed position) conveyor belts that move gravel and whatnot at a mixing plant often are very high to let trucks under - sounds like a bridge to me, especially if it passes over roads or other buildings. There are conveyors at ground level that would block a vehicle or a person, so bridge=yes sounds appropriate in cases where access is possible under it. Javbw On Feb 26, 2015, at 8:29 AM, Richard Z. ricoz@gmail.com wrote: On Wed, Feb 25, 2015 at 07:14:36PM +0100, Friedrich Volkmann wrote: The proposal looks good, add location=* to it. I dislike location=* for various reasons. But you may use it if you like. the proposal could be more detailed in this point. How do you tag conveyors above ground? As bridge? Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - goods_conveyor
On 26/02/2015 12:28 PM, Dave Swarthout wrote: The proposal looks good, add location=* to it. I dislike location=* for various reasons. But you may use it if you like. I first came across the location key when it was used to indicate whether the Trans-Alaska Pipeline was running underground or overground. At the time I thought it was a bad choice of words but it is fairly well established in the OSM schema by now (44K occurrences of over- or underground). Other important and potentially useful values of location are: overhead, indoors, outdoors, underwater. The one goods_conveyor I tagged was moving coal, as I said, and at several points it was running over a roadway on a bridge. I was unable to tag the bridge in a way that caused it to show up on the OSM slippy map. Any potential rendering solutions would need to take that into account somehow. Usually the bridge is for safety .. if the conveyor brakes or something falls off it the bridge under it will catch it. Thus I'd do an area for the bridge .. layer=1 then the conveyor on top of that layer = 2 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - (traffic signals group)
On Wed, Feb 25, 2015 at 9:55 PM, John Willis jo...@mac.com wrote: If group is not a good word, then set is a good alternative. intersection_group= intersection_set= ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - (traffic signals group)
Looks like this has already been discussed .. in 2008 to 2011. http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Set_of_Traffic_Signals No outcome for that .. Past discussion looks to have pointed to a relation ... the relation contains each node of traffic_light and can have a name= tag. I use 'set' because that is how they are called here in Australasia .. and it looks to be used in the UK too ... http://www.tfgm.com/Corporate/Pages/UTC-fault-reporting-form.aspx On 26/02/2015 4:55 PM, John Willis wrote: If group is not a good word, then set is a good alternative. Javbw On Feb 26, 2015, at 8:33 AM, Warin 61sundow...@gmail.com mailto:61sundow...@gmail.com wrote: Hi, This could be confused with the coordination of traffic signals along a length of road or even a district wide coordination of traffic light signals. I think it needs some words that restrict it to a single intersection? And possibly some thought to where a length of road (many intersections) or a district wide coordination of traffic signals occurs? If the name 'traffic signals group' is taken what name would you give this? May be a different name for this 'group'? Such as ? traffic signals set? On 26/02/2015 8:59 AM, Lukas Sommer wrote: Hello. This is a request for comments for the proposal http://wiki.openstreetmap.org/wiki/Proposed_features/traffic_signals_group The original author is Sanderd17. With the consent of him, I did some supplementing. Thanks to Sanerd17! Unlike the proposal “Proposed features/Traffic Signals” of Lukas Schaus, this is _not_ about traffic light circuits, but just about grouping together all nodes with highway=traffic_signals that belong to a traffic signal system at one place. This could be useful in Japan, where traffic signal systems have namen. (Thanks to nyampire and javbw for suggestions and comments.) This could be useful for routing/turn-to-turn navigation engines to calculate better the time penalty for the traffic signal system. Best regards sommerluk ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org mailto:Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Canopy radius for natural=tree
This construct does not come from a natural language. It's rather computer programming style, like class::subclass (see maxwidth:physical=*, name:en=* etc.), and it's also in spirit of mathematical notation (functions, subscripts), like diameter(crown). On 23.02.2015 23:48, Colin Smale wrote: No adjectives here... Crown diameter is a compound noun composed of two nouns. More likely a germanic language where the juxtaposition implies a genitive - diameter crown -- diameter of the crown. Could certainly be Dutch or German - it's a very common construct. On 2015-02-23 23:22, John F. Eldredge wrote: True. English usually has an adjective followed by a noun. I would guess that diameter crown was probably written by someone more familiar with a language where adjectives follow nouns. -- 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. Dr. Martin Luther King, Jr. On February 23, 2015 3:17:33 PM Brad Neuhauser brad.neuhau...@gmail.com wrote: diameter crown also doesn't appear to be vernacular English, unfortunately. Crown diameter or crown spread seem to be more widely used. For example, see http://www.treeterms.co.uk/definitions/crown-diameter, and https://en.wikipedia.org/wiki/Tree_crown_measurement#Crown_Spread_Methodologies -- 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] Canopy radius for natural=tree
2015-02-25 11:41 GMT+01:00 Friedrich Volkmann b...@volki.at: This construct does not come from a natural language. It's rather computer programming style, like class::subclass (see maxwidth:physical=*, name:en=* etc.), and it's also in spirit of mathematical notation (functions, subscripts), like diameter(crown). yes. But it is using the natural language notation with space (underscore) rather than diameter:crown. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
