[Tagging] How to tag severely destroyed forest track?
I recently came across a track that was severely destroyed by heavy foresting machinery. (KNee-deep mud with tire tracks over a meter deep and wide.) How to tag this? It was no longer usable on foot or for any normal sized vehicle except maybe tanks or said heavy machinery under normal conditions. It may be usable on foot if dried out over a long time or if frozen. tracktype does not offer a solution for this, as worse grades are described as being closer to undisturbed nature, while the opposite is the case here. sac_scale comes to mind, but this is a track not a path and it has nothing to do with alpine hiking. track_visibility does also not cover this, as these tracks are if anything MORE visible now. Even surface or smoothness can't describe this, as simply tagging this bumpy and muddy does not do the situation justice. (And they are not picked up by enough renders/routers, for which we of course do not tag.) I wouldn't mind kicking them out of the highway= namespace altogether, as they are no longer suitable for any travel at all, but I don't want to delete them completely. They are still major landmarks / prominent features and they may still be part of hiking routes or tagged with names/refs. Also, they might become usable again and I don't want to lose the actual position data. Any ideas? Thanks Chaos ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] highway=speed_camera equivalent for non-speed enforcement types
Why don't you just add anotd tag? note=This traffic light enforcement camera mapped as relation. Only edit if you are an experienced mapper! At the moment I've done exactly that, but in addition to the highway=speed_camera tag. (note=actualy a red-light camera; mapped with enforcement relation) While the note alone would work for humans, it might be unneccessary hard for machines (QA tools, bots, renderers) to find out what those single nodes are and it still doesn't get a prominent icon in the editor. (With the last part probably qualifying as 'tagging for the editor'). Regards, Ronnie ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] highway=speed_camera equivalent for non-speed enforcement types
I've mapped some traffic light enforcement cameras lately and stumbled across the somehow missfitting tag highway=speed_camera. It was obvioisly invented for cameras enforcing only speed limits. Now the actual enforcement can be quite flexibly tagged by the enforcement relation and technically, the node used as 'device' role in the relation does not have to have tags of its own. But nodes without tags (and just relation membership) are prone to accidental deletion. I know of the surveilance tags in the man_made=* group, but they seem to be tailored to continuously recording cameras, not the set-off-by-a-sensor types I want to tag. The real world camera is (in my case) exactly the same as a speed camera, including the housing. I hesitate to just invent a new highway=*_camera tag, beause I don't actually like it to be under the highway key (something accepted for the speed_camera probably only of historical reasons) and I don't want to create another special tag just for one type of device. So any ideas for a general traffic rule enforcement device tag to be used with the enforcement relation? Regards, Chaos ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] noexit=yes on ways ?
2014-04-09 10:47 GMT+02:00 Pieren pier...@gmail.com: On Tue, Apr 8, 2014 at 6:38 PM, André Pirard a.pirard.pa...@gmail.comwrote: 1. noexit cannot be used on ways because that does not show what end cannot pass eeh, what what end ? Either the highway line is linked to another highway at both ends, then noexit is a tagging mistake. Or the highway line is not linked to another highway on both ends and then the noexit can be helpful (confirming tha'ts really an isolated highway and not some connection missing) There can be a way that IS connected on both ends and still is a dead end. A road can end in a wall or a fence, where on the other side the road continues. There may be other tags there (barrier=*), but still it would be hard to quickly spot the dead end side with noexit=yes tagged only on the way instead of the node. Regards, chaos ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] noexit=yes on ways ?
There can be a way that IS connected on both ends and still is a dead end. A road can end in a wall or a fence, where on the other side the road continues. There may be other tags there (barrier=*), but still it would be hard to quickly spot the dead end side with noexit=yes tagged only on the way instead of the node. No. In such cases, only the barrier tag is important. No additional tag required. A noexit=yes tag is still a good idea to communicate to the next mapper that there really is no exit for any transportation mode. A second mapper may suspect a wall/fence/exotic barrier type/whatever being still passable by bikes or pedestrians. Also the barrier=* might still be missing, because the first mapper only cared to map highways. same goes for the access:*=* tag. It might still be missing. Mapping doesn't only come in nothing vs. perfect. As a means to communicate an intention from one mapper to the next, it simply is more clear when mapped on the node than on the way. I simply gave an example where the end of the dead-end way can not simply be deduced by its geometry. Regards, chaos ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Pre-proposal - Photography
I used so far: shop=photo For shops that sell cameras, equipment and related services (cleaning, repair), offer printing (either off- or on-site) and maybe simple portrait photos for use on ID documents shop=photo_studio For shops that offer, in addition to the above, artistic photo services like portraits, group pictures, wedding/child photography, nude, object photographie etc. and also sell those pictures and other products related to (bigger) photo-prints like canvas, mounts, easels, etc. A shop like this will usually have an on-site studio. I would probably use craft = photographer if there was no shop selling things but only the services and maybe the studio from the above. Chaos 2014/1/29 Matthijs Melissen i...@matthijsmelissen.nl Dear all, We currently have the following tags for photography: - shop=photo (1870x) - craft=photographer (806x) - shop=photo_studio (329x) - shop=photography (117x) - shop=photographer (58x) To what kind of entities do these tags correspond? There seem to be some redundant tags. As far as I know, most photo shops would offer the following services: - Taking pass photos - Printing photos from film roll or digital files - Sale of emory cards, batteries, and maybe even cameras Perhaps not all shops offer all of these services. Then there are also photographers that don't have a real shop, but offer their services for wedding photography etc. Or perhaps some of them are also based in a regular photo shop. How would (or should) the tags that we use correspond to the type of entities that exist? Kind regards, Matthijs ___ 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] Multiple amenities inside shared area
2014/1/28 Janko Mihelić jan...@gmail.com I would make two multipolygon relations, not site, and put no tags on the area. Could you explain why? A multipoligon relation with just one outer member is not common practice (at least not here in my region.) Regards, Chaos ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Multiple amenities inside shared area
2014/1/28 Janko Mihelić jan...@gmail.com I would make two multipolygon relations, not site, and put no tags on the area. Could you explain why? A multipoligon relation with just one outer member is not common practice (at least not here in my region.) Regards, Chaos ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Multiple amenities inside shared area
2014/1/28 Peter Wendorff wendo...@uni-paderborn.de Hi Ronnia, as the use case was an outer area shared by two amenities in different building, it's a multipolygon with one outer and one inner member, and that should be fairly common around the world, as it's the most simple case for an osm multipolygon, right? As far as I have understood multipolygons, an inner member is removed from the area represented by the moltipolygon. (Like a lake that is not part of a larger landcover=grass or a courtyard not part of a larger building.) So setting the role of the building as inner, this would mean that the amenity is just the outside area WITHOUT the building, which is not what I want to tag. The building IS PART OF the amenity. Regards, Chaos ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Multiple amenities inside shared area
2014/1/28 Peter Wendorff wendo...@uni-paderborn.de one building (b1) and the outer space (s) are used by a kindergarten, the second building (b2) and the outer space (s) are used by a primary school. Our proposal for the tagging was: 1) use a multipolygon with outer s and inner (b1) and tag it as primary school (so the primary school is the whole space inclunding building b1 WITHOUT b1) 2) use a multipolygon with outer s and inner b2 and tag it as kindergarten (same the other way around). I think there is a mixup in the example here, but I got it nevertheless: You want me to exclude the OTHER building with the multipolygon. fence as outer, b1 as inner, tag as b2 was before and fence as outer, b2 as inner, tag as b1 was before. Which makes much more sense. Of course this comes with all the downsides of relations (maintainability by newbies, pickup by renderers, routing, search..) but still seems to be the most correct solution. Thanks Chaos ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - trafficability
I would also tag these things as free text. The problem space is just too big to encode this in standard tags with a fixed set of values. If you can express the problem more specific and even with less words in free text then in key-value pairs, I would clearly vote for the former. Especially as a lot of those tags would be quite unique and lack data consumer support anyway.f It is just not possible to tag e.g. the whole of Iceland in a way so that you can reliably say which roads are passable by you vehicle and which not. Even when you flood the database with 40+ tags per highway (which makes them almost unmaintainable by mere humans), input all your vehicle information into the router (which will take you the whole day) and there is a precise machine readable weather forcast, there are STILL factors you can't know, that change on a daily basis or depend in chance alone (5cm of water level on a river crossing can make the difference). And even one of those will mean that your calculated route could change completely. You may get a 'forecast' that's about 50% sure to the cost of having almost destroyed OSM for manual editing. If you really think routing based on chances is a goal worth pursuing, than you may also want to tag just that. chance_of_passability = 34%. Yes, this is a completly subjective value based on no deterministic algorithm (and therefore start edit-wars), but the effect on routing will be exactly the same while being easy to edit and maintain. And in the end, that is exactly what you get when some local tells you that the road might be passable or not. You can ask your router to give you a route with a risk (= 100% - combined chance) less than e.g. 2% and you will be routed on primary roads, accept e.g. 20% and you might fail when it's muddy, accept 90% and you might only pass on best of conditioins if you come well prepared. Again: imho even with a myriad of different special tags, in the big picture the reliability of routing will not get much better than this. So why bother? If you really really want to be more precise, I think weather conditions have a value set that is almost managable in size. So chance_of_passability:wet = 10%; chance_of_passability:dry = 80% might be possible. with a fixed (and therefore machine-evaluatable) set of subkeys. But imho you can never achive this for vehicle specifications or physical road condition. The set of possibilities is just to large. A free text note might help to judge the chance a little bit better and is easy to maintain and render. So: why not? If translation is the only problem, I think we might be able to handle this over time. my 2 (more of 200) cents Chaos ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] hazards (was: Feature Proposal - RFC - trafficability)
2014/1/17 Gerald Weber gwebe...@gmail.com But why only roads? So why not a more generic tag to alert people about all sorts of problems? Oh please restrict that to official warnings! I can already see thousands of hazard tags of concerned citizens warning me about every ditch in the road, cold weather in the mountains, darkness at night, passages that are slightly to small for THEIR car, explicit grafiti content on their favorite bus stop I really don't want to see OSM filled with their personal commented edition of the world. So if you think that the pebbles on the beach are a bit to pointy for bare feet - go to tripadvisor If there is a warning sign about undercurrents or shark attacks - OSM welcomes your addition. my ranty 2 cents, Chaos ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - trafficability
In contrast, if the information that the road can be passed by off road vehicles is given by local people then it is probably very reliable. It is not interpretation, it is experience. If these local people are somewhat responsible, their answer could only be: It depends. As mentioned numerous times in this thread already, the '' trafficability depends a great deal on the exact specifications of your vehicle as well as other, external factors. As we can't have a tag for every vehicle (and yes, the exact height of the air intake alone can make the difference), and hopefully are also never trying to tag for every weather condition, we simply CAN'T tag trafficability. The only thing we can tag is physical properties of the road. Anectotal evidence: while driving around Iceland in a Suzuki Jimny (technically a 4x4), I was allowed to use any road. Asking locals if I would be actually able to take those roads always involved a very critical look to my car, half an our of explanation about the dangers of the road ahead, an impromtu weather forecast an a final Just try how far you can get. I would never try to tag that half hour of prose into an OSM key. Chaos ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - bicycle=use_cycleway
Robert argued here that country-specific restrictions should be always expressed by tags so that routers don't need to know those specific rules/laws. He gave the maxspeed tags as an example, which we explicitly tag even if they are based on implicit laws. I think this generalization is goes too far. For the access tags (and we do discuss access tags here), it is common practice to have country-specific defaults on certain highway types as listed in the wiki [1] and only tag what contradicts those defaults. I don't see why it would be needed to switch that to explicitly tagged values. Opposed to maxspeed, we are talking a large set of different tags here where both tagging as well as legislation is in constant change. Based on these asumptions, I would argue that it would be enough to specify if a compulsory exist or not and leave the details of which type of vehicle can under which conditions use the road or not to the router, which should implement those based on national defaults. So at least the legislation changes can be implemented at a central point. (This is already the default, so no additional change needed for that.) I would prefer an additional tag over a replacement for bicycle=no, as this would allow an easier migration due to not breaking older routers. (This is why I would vote 'no' on the proposal.) I would also say that stating that there IS a compulsory cycleway is a first step, but not enough. To check for certain conditions (width, direction, reachable destination, obstacles, surface), the router would need to know WHICH way is the compulsory cycleway. We can either do this with a relation combining the highway and the cycleway(s) or with tags and self-created references. I would clearly prefer the first. I think neither storing all the information needed for those decissions in the highway tags (instead of the cycleway tags) would be a doable workaround nor pre-interpreting them by the mapper and tagging the result on the highway. As stated above, those interpretations would be based not only on (ever changing) local administration but also on very subjective opinions. As a user, I'd rather have those opinions baked into the routers I can chose, not in the map data all routers have to use. My 2 cents, Chaos [1] https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#Germany ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] tag proposal for soft play centres
There are centers like this in Germany, mostly just called indoor playground. (I haven't seen one so far, but I heard awful stories from parents all around.) The term soft play wasn't known to me and I didn't think of child's entertainment when I read it (actually, I thought the opposite). There is also no wikipedia entry for this. After reading the proposal, I knew what was meant and I have a clear idea what to tag and what not. But I still find the focus on the quality of material used (both in the name and in the definition) a bit odd. What if there is a toy not made of soft stuff? Like an old-fashioned merry-go-round? Does this mean the place is called (and tagged) differently? I would propose to keep the name (because it seems to be a fixed UK term fair enough), but to ditch the soft play toys stuff from the definition to allow all indoor playgrounds to be tagged with this and to make this understandable to non-UK mappers. (I would also be OK with indoor_playground or simply indoor=yes for normal leisure=playground tags, but I'm sure the original poster wants to keep the similarity of UK name and tag). my 2 cents Chaos 2013/10/23 Philip Barnes p...@trigpoint.me.uk My understanding of a soft play area would not work outdoors, at least not in Northern Europe where it rains. Phil (trigpoint) -- Sent from my Nokia N9 On 23/10/2013 13:22 Matthijs Melissen wrote: On 23 October 2013 14:01, Jonathan Bennett jonobenn...@gmail.com wrote: In the UK a Soft Play is a well-recognised and well-defined concept. If that concept doesn't exist elsewhere, fine, but don't stop this mapper from recording information because you don't like what colour the bikeshed is. I think that's too much of a UK-centric way of thinking, which we should avoid. I agree that for the UK, a precise definition is not necessary, because we can simply tag everything leisure=soft_play that is called 'soft play'. However, it seems that the US does not use this term, let alone non-English speaking countries. Other countries might have similar (but perhaps not entirely equivalent) concepts. I believe we need some kind of definition that makes clear how the English concept 'soft play' maps to the variety of playgrounds other countries have. In the Netherlands, for example, there are paid and staffed outdoor playing grounds. Currently, I have no idea whether such playgrounds would fall under the English definition of 'soft play'. -- Matthijs ___ Tagging mailing list jonobenn...@gmail.com 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] tag proposal for soft play centres
2013/10/23 Dominic Hosler dominichos...@gmail.com I think in my opinion the distinction between a playground and a soft play centre is that a playground generally has a hard ground (or sometimes rubbery), whereas a soft play centre (in the play area) has a padded ground. In a soft play centre all the equipment to climb on is padded and soft. A playground, most of the equipment is hard (wood, metal or fibreglass). For me, this is the main distinction. Thanks for the clarification. So the material used *really* makes the differences. Ok. This will most definitely limit the number of use cases, at least here in Germany. offtopic I really don't get the concept. Why would you want to create a thing like that? Why would you go there instead of a real playground? I can imagine a thousand injuries that can happen even *if* everything around you is padded. Especially if two or more children are involved. There are always some hard bits. They are called skull, bone and teeth. And there are a lot of injuries that don't involve hard impacts at all, like dislocations, strangulations etc.. So if there is risk anyway, why don't have some fun with it? Go out, climb a try, fall from one, climb up again .. grumpyoldmanshakescane / /offtopic more like 142 cents Chaos ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] turn:lanes vs. turnlanes:turn
Hi, I'm in the process of adding more detail to the major junctions in terms of lane counts, turn lanes, width, etc. There seem to be two tagging schemes in parallel: - the turn:lanes[1] scheme which adds lane descriptions as tags to way segments. - the turnlanes:turn[2] scheme which adds lane connections via relations to the junction nodes They don't mach exactly in the kind of information the record. The turn:lanes scheme describes the lanes and lane markings leading to the junction (with only fuzzy information on where the lanes lead). The turnlanes:turn relation then describes how each lane is connected to an outgoing direction (without stating how they are marked). But they also encode the same information in two ways, for example the length of the turn lanes (by way segment length with turn:lanes, as numerical tag value with turnlanes:turn). Both are nicely supported by a JOSM style (turnlanes) [3] and a JOSM plugin (turnlanes:turn). According to taginfo, turn:lanes is used approx. 47k times, turnlanes:turn is used approx. 10k times. I personally don't like the turnlanes:turn scheme very much because it introduces quite a lot of extra relations per junction which probably make it less maintainable then tag-based schemes or a single-relation-per-junction scheme, but that is more a question of taste than anything. This topic was briefly discussed already on the German and Austrian talk-lists with mostly the opinion to use the newer and more elegant turn:lanes scheme. But I see no easy way of enhancing the turn:lanes scheme to include the missing connection information without bloating it up and making it unusable. So my questions: - Are these schemes both still actively used? Are there data consumers who use these already? - What are the pros and cons of using them both in parallel? - Are there better ways of getting *all* of the information across without the redundancy introduced by using both schemes? Thanks, Chaos [1] http://wiki.openstreetmap.org/wiki/Key:turn:lanes [2] http://wiki.openstreetmap.org/wiki/Relations/Proposed/turn_lanes [3] http://josm.openstreetmap.de/wiki/Styles/Lane_and_Road_Attributes ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Utility corridor mapping
The proposed tagging scheme doesn't sound too bad to me. It's easily expandable for those who want to map more detail utilities:sewage=underground utilities:electricity=overhead utilities:communications=underground But I would vote for just mapping what is somewhat verifiable on the ground. (Overhead wires can be seen, water may have signs and plates, sewage may be verified by canal entry points ...) You only problem is that you can't distinguish the three possible states - a street with no utilities present - a street with no overhead but unknown underground utilities - an unmapped street If you just want to specify that there are no overhead lines, you could do a utilities:overhead = no But this defies the logic given above and may lead to others mapping utilities:overhead = electricity; communications which would not be advisable imho. It may still be an option if documented clearly. Just my 2 cents, Chaos ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] funny tags: turning_radius
2013/8/30 Frederik Ramm frede...@remote.org Hi, On 29.08.2013 16:07, André Pirard wrote: This tag was created for the specific needs of logging [to tell which timbering vehicle can pass a bend] More background here: http://wiki.openstreetmap.org/wiki/Round_wood_transport_in_the_forest This site interprets access:xxx=* keys as possibility instead of legal restriction. I though it was general understanding that access=* restrictions always meant legality , not practicability (because the later is highly subjective not verifiable). That's also what I can find on the key:access page. I've changed the wiki page accordingly. Let's see what the original author thinks about it. Regards, Chaos ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] incline default unit ?
Imho the original question was not about the scientific details of what is a unit or how to represent inclines, but simply if the % sign should be included in the tag value or not. Especially in the case where it is set by an editor template. Could we get some opinions on THAT point? Regards, Chaos ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] incline default unit ?
2013/8/12 André Pirard a.pirard.pa...@gmail.com Imagine seeing on a shop poster 10 OFF or 0.1 OFF and you've got the answer to THAT point. Can I extract from your snippy comment, that in your opinion we should omit the % sign because one can clearly distinguish between a pure ratio and a percent-scaled ratio? What about the distinction between the percent-value and a value in degrees? Regards, Chaos ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting Open - toilets, toilets:disposal, pitlatrine
2013/7/24 Andrew Chadwick (lists) a.t.chadwick+li...@gmail.com
As described in the proposal, inquiry is partly about practical
locking mechanisms so a better way which factors out those concerns is
access=private
locked={yes|mechanism}[1] (or some other tag)
While I can see your intention here, that is the most counter-intuitive way
to tag this I've ever seen.
You would tag a PUBLIC toilet with access=PRIVATE just because you have to
ask for a key first?
This is better because access=private already carries the you must
inquire meaning. As the Key:access page states, access=private means
only with permission of the owner on an individual basis. And how
does one acquire permission? One inquires.
There is a subtle difference between enquiring for permission to enter/use
and to inquire for the key/code/token.
We won't tag access=private at all, because we only want public toilets to
be in the database.
Access=permissive would be the most limited value I would tag at all.
A toilet at a gas station might be for anyone to use (access right)
(access=public? access=yes?), but you still
may have to inquire within for the key (access method).
For your example, one needn't inquire as to whether one may use the
toilets if one is a customer. Merely after a code, for example. So a
better way would be to use
access=customers
locked=code[1] (or some other tag)
So maybe we mean the same thing after all. The access restriction has
nothing to do with inquiring for a code.
I still think its more helpful to tell that you have to ask the staff
instead of just saying it is locked with a code.
I object to muddling the access=* key with yet more values having the
same meaning as existing ones, especially without discussion on the
access tagging page. access=* describes legal access, and should have
nothing to do with practical access (except for barriers, sigh). In
short: if you need to ask before each use, then it's an existing
restrictive access value, either customers, or more probably private.
I see your concerns about using the access key here. I'm fine with access=*
having a different meaning depending on the main tag. We have that for
other tags as well (type=* is probably the best example). But if others
also see this problem, we better might move it to toilet::access to avoid
confusion. Not all the access=* values make sense anyway. (access=hgv
anyone?)
Regards,
Chaos
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Are addresses ... objects vs attributes
On 24 Jul 2013 16:44, Janko Mihelić jan...@gmail.com wrote I don't think we should be so inflexible with the object vs attribute. It depends on the context. If you are a data consumer, and are making a list of all addresses in a town, then the addr:housenumber + addr:street is your object, and building=yes is your attribute that says there is a building at this address. If you are making a list of all buildings, then it's the other way around. If you are making a list of restaurants, then the amenity=restaurant is your object, with attributes building and address. +1 Chaos ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] leisure=swimming_pool for the pool or the complex?
I used to tag the area as leisure=water_park and the pools within as leisure=swimming_pool (with sport = swimming for those that are deep and long enough for competitive swimming). Usually there are other things withing the area like leisure=playground or leisure=pitch. I found no suitable tag to represent the grass area that is usually used to lay down around the pool, sun-bath, play or make a small picnic. Neither landcover nor landuse seem to fit. regards, Chaos 2013/7/23 Gerhard Hermanns gerhard.herma...@uni-due.de Hi, I don't agree with the use of the landuse-key. Landuse should be used for larger areas where you need a (generic) term for a conglomerate of objects (like landuse=residential for an area with houses, garages, gardens, streets - each of which can also be mapped seperately), but not for single objects like a pool. Am 23.07.2013 05:23, schrieb John F. Eldredge: I am saying that the land_use tag makes sense for in-ground pools, since they greatly reduce the odds of the land subsequently being used for some other purpose. In that case it would also be valid to use landuse=building or something like that because the same argument holds here. I don't think that the landuse-key should be used in such way. In short, I'm a bit concerned about the increasing use of the landuse-key for everything that covers a relatively small space, since the key is intended for large areas. Seoman Yes, I know such reuse does happen on rare occasions; the city of Nashville, TN, closed all of its public pools in the 1960's rather than obey a court order to integrate them, and turned at least one of the pools into a sunken garden. Bryce Nesbitt bry...@obviously.com bry...@obviously.com wrote: On Mon, Jul 22, 2013 at 7:04 PM, John F. Eldredge j...@jfeldredge.comwrote: You state The pool after all is a man-made object that just sits on the ground. Some pools sit on the surface of the ground, and so could potentially be moved from one location to another. Others are built into an excavation, and can't be moved without demolishing them. They are a permanent change to the landscape, unless you fill them in. Surely you don't mean to suggest we need to map a distinction between movable and unmovable pools? Last week I watched a building getting moved. As a kid my parents went to the low rent ski area. The lift poles were different colors, sometimes two or three to a pole. The lift had been assembled from the parts of other lifts decommissioned at other areas. Everything in the man_made category can be moved, including at unsustainable cost, the in-ground pools. -- Tagging mailing listTagging@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/tagging -- John F. Eldredge -- j...@jfeldredge.com Reserve your right to think, for even to think wrongly is better than not to think at all. -- Hypatia of Alexandria ___ Tagging mailing listTagging@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] foot=yes or bicycle=yes on track without other limitations?
Yes, highway=path or =track normally allow foot access by default. You can still add the foot=yes tag to show that you have actively verified the fact that indeed access is granted on that way. For example when other ways around have foot=no or the Bing layer looks like it's not accessible etc... Regards, Chaos 2013/7/10 Maarten Deen md...@xs4all.nl Is there a deeper meaning of adding foot=yes or bicycle=yes to highway=track or highway=path without adding other limitations? I thought track and path are by default routable for foot and bicycle, so IMHO they add nothing. Examples: http://www.openstreetmap.org/**browse/way/53561813http://www.openstreetmap.org/browse/way/53561813 http://www.openstreetmap.org/**browse/way/68796031http://www.openstreetmap.org/browse/way/68796031 http://www.openstreetmap.org/**browse/way/195440134http://www.openstreetmap.org/browse/way/195440134 Regards, Maarten __**_ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.**org/listinfo/tagginghttp://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] tagging of sticker
How On 05/lug/2013, at 04:28, Shu Higashi higa...@gmail.com wrote: amenity=restaurant sticker=yes image:sticker=http://www.heartbarrierfree.com//image/logo.png website:sticker=http://www.heartbarrierfree.com/ name:sticker=Heart Barrier Free Project How about an even more generic tag? Nobody would know what 'heartbarrierfree' would mean as a value to any tag without doing additional research. Also the same service could be organized by another group. it surely will in other countries. wheelchair:trained_staff = yes Would be my suggestion. Regards, Chaos ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] When was barrier=entrance abandoned ?
Nothing wrong but different as said the second one is just a gap in a linear barrier where you can pass while the first one is an entrance to something. So you won't use entrance=* if you can't define an inside and outside? Well, at least that's an easy to follow rule. I'm not exactly sure if the definition of entrance=* is rely limited in that way (or meant to be), but I see your point. Regards, Chaos ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] When was barrier=entrance abandoned ?
I do use the two tags in a different way. If it is an entrance leading to something (eg. building/amenity) I would use entrance=* but for a small opening within a wall/fence I use barrier=entrance. This way I do not have to cut the linear barrier. What's wrong with entrance=* in the second situation? Regards, Chaos ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Public transport zones
Am 06.03.2013 03:56 schrieb Steve Bennett stevag...@gmail.com: Fortunately there is no such thing as regional trams :) I learned very early on that there is no such thing as 'no such thing' in OSM. There are quite a few regional trams here in Germany alone: http://de.wikipedia.org/wiki/%C3%9Cberlandstra%C3%9Fenbahn (German link, as the English page is about historic trams. Please use Google translate) Regards, Chaos ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] As the crow flies
2013/2/26 A.Pirard.Papou a.pirard.pa...@gmail.com The specification I'm trying to suggest is exactly that. There is a gap in an OSM route and the sole idea is to bridge it. We must indicate go from here to there in an unspecified way. It is just to - make sure that those who follow the route will go there and not somewhere else - indicate to validators that there is no mistake and that the route is connected and maybe looped That there are paths in between or not, what those possible parts are called, that the route may exist and just be unknown, that there should be paths but that there is a map bug, or any other reason for a gap, all that is very good for a note=literature but is totally irrelevant for the attempted specification. They were mentioned because the idea evolved from a path feature to a relation feature. Thanks for the clarification. Now I understand the problem. The order of ways in the relation is of course giving you a hint on where to continue after a gap, but a router might now now on which end of the next way to continue. The route might not follow the direction of the way in the OSM-sense. Nor is it always the 'unconnected' end, as it might be a gap on both ends of the next way. Also the nearest end might not always be the right one. Imagine a path below and on top of a steep cliff. They might be quite near, but you can't go there directly. When encountering a gap, routers will now probably switch to their standard routing algorithm (either 'follow road' or 'straight line') to lead you to the next point. What the next point is will be determined by the router or the conversion software that brings the OSM format into a format understandable by the router. I imagine it will mostly be 'nearest endpoint'. You now search for a way to give those tools a hint to influence their decision. One easy solution would be: include (of course in the correct order) the start- and endpoints of the ways in the relation. (Maybe with a different role.) That's all the information the router needs. Either their is a way between those points that's also included in the relation, then the router can use it, or there isn't, than the router can do it's standard routing between those points. The user can choose the type of standard routing on the routing device/software. Is this to much 'mapping for the router' or aceptable in the database? Best regards, Chaos ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Re : As the crow flies
This also doesn't differ very much from the practice used for pedestrian areas in cities. Usually the area/plaza/village square will be drawn as an area, but additionally some crossing highway=pedestrian ways are added to guide the router straight across instead of only along the edges. I'm not really comfortable with this, as it is clearly something only done just to work around a missing feature in the router software, but at least it already is in use. Especially for hiking paths there is the grade system which also denotes visibility. After you've crossed a meadow to get the gps track you usually already have a 'barely visible' hiking track. ;) Best regards, chaos 2013/2/22 Steve Bennett stevag...@gmail.com On Sat, Feb 23, 2013 at 12:05 AM, Volker Schmidt vosc...@gmail.com wrote: It happens often on mountain hiking routes. You have a signpost with the red-white sign of the Alpine Club that indicates the direction that you have to take across a meadow, for example. On the other side you have to find a corresponding sign. In between there may not be any visible path. In that case I would happily put a highway=path with surface=grass as a straight line across the meadow. IMHO that's a slightly different case - you also see it on beaches, and sometimes on rocky slopes. Basically there is a defined path, but its exact location is imprecise. Steve ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Re : Ski resort (once again)
2013/2/4 Janko Mihelić jan...@gmail.com 2013/2/4 Martin Koppenhoefer dieterdre...@gmail.com if they don't have a common operator and the resort doesn't have a border (i.e. it isn't an area but a mixture of areas and routes) you cannot map them? Btw.: the OP is asking for nordic pistes, so there won't necessarily be any lifts. Why not resort=L'Auberson on all nordic pistes? Yvecai says it's error prone, but so are names and operators of banks and atm machines. If you want to find errors, use tools like http://overpass-turbo.eu. I have made a small script to find all nordic pistes without the tag resort=L'Auberson or Les Fourgs or La Seigne or Jougne: http://overpass-turbo.eu/?q=PCEtLQpUaGlzIMSHIGFuIGV4YW1wbGUgT3ZlcnBhc8SIcXXEmXkuxIRyecSJdCBvdcSoYsSmcHJlxJ1pbmcgdGjElVJ1xI1ixKt0b8SNYWJvxJghClnEqiBjxIwgZsSzZCBtb8SwxI7EkMSSxJTEiHdpxLfEtsS4IExvYcWQxL9vbMSjCsWoxII-CjzEu2nFgMWrICA8xJ_EocS2eXBlPSJ3YXkixbHFssWzaMScLWt2IGvFu3DEh3RlOnTFuGUiIHbFu27Fk2RpYyIvxoHFsjzGhHPGhsaIxooixLBzxZN0xpTFkmTGliLGmMarxpXFu0wnQXVixJnGqW7GncafxoPGhcaHxonFu8aoxqrGrG_GrsaXb8ayxq9MxLEgRsSqcmdzxr0KxoLGv8ajx4HGpseEcsayxq3Gr8axxpTHjGEgU2VpZ27Gk8aex5bGgsahx4DGpceDxLHHhcWRx4fHoMeKx6LFu0rEqsepx6vGvjxixYN4LcW1xKUge3vIgW94fX3HrMagL8iFecaBPMSwY3Vyc8SVxpHFucW7xb15LcaYZMe-xawvxa7FsMWoPMSvxLN0xp4c=BMTyHuuaoOR Works exactly as long as no piste belongs to more than one resort. If anyone does, you still need to switch to relations. I don't know about nordic pistes, but there are definitely lifts for alpine pistes that are used by visitors of two ski resorts. Regards, Chaos ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Re : Ski resort (once again)
2013/2/4 Janko Mihelić jan...@gmail.com 2013/2/4 Ronnie Soak chaoschaos0...@googlemail.com Works exactly as long as no piste belongs to more than one resort. If anyone does, you still need to switch to relations. I don't know about nordic pistes, but there are definitely lifts for alpine pistes that are used by visitors of two ski resorts. There, I fixed it to work with semicolon delimited values: http://overpass-turbo.eu/?q=PCEtLQpUaGlzIMSHIGFuIGV4YW1wbGUgT3ZlcnBhc8SIcXXEmXkuxIRyecSJdCBvdcSoYsSmcHJlxJ1pbmcgdGjElVJ1xI1ixKt0b8SNYWJvxJghClnEqiBjxIwgZsSzZCBtb8SwxI7EkMSSxJTEiHdpxLfEtsS4IExvYcWQxL9vbMSjCsWoxII-CjzEu2nFgMWrICA8xJ_EocS2eXBlPSJ3YXkixbHFssWzaMScLWt2IGvFu3DEh3RlOnTFuGUiIHbFu27Fk2RpYyIvxoHFsjzGhHPGhsaIxooixLBzxZN0xpTFkmTGliLGmMarIMSwZ8avTCdBdWLEmcapbsadxp_Gg8aFxofGicW7xqjGqsasb8auxpdvxrLGtMa2xLEgRsSqcmdzxr8KxoLHgcajx4PGpseGcsayxq3Gr8axxpTHjsW7TGEgU2VpZ27Gk8aex5jGgsahx4LGpceFxLHHh8WRx4nHoseMx6RlxrXFu0rEqsetx6_HgDxixYN4LcW1xKUge3vIh294fX3HsMagL8iLecaBPMSwY3Vyc8SVxpHFucW7xb15LcaYZMiExawvxa7FsMWoPMSvxLN0xp4c=BMTwi4QbgOR You may want to read this wiki page: http://wiki.openstreetmap.org/wiki/Semi-colon_value_separator It gives you a lot of reasons not to use semicolon delimited values. But admittedly it doesn't give relations as an alternative. While I also see that skiing resorts are kind of geographically and therefore could be expressed as an area instead of a relation, I'm having trouble with how anyone would be able to determine where to put that border. They are, for the part I know, mostly defined by the pistes/lifts/amenities that belong to it instead of a border on the map. And I'm somehow not comfortable with an area which borders are defined by a mapper at his own discretion instead of a survey-able feature on the ground. My favorite therefore is still a relation, but I'm cutting out of this argument now, as skiing definitely isn't my area of expertise. Regards, Chaos ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] water parks and swimming pools
Maybe I explained that wrong. I didn't want a 'background' tag just for the rest of the area, but one for the well kept green used as recreational area, taking a sun bath, let the children play etc. (As opposed to additional unkept green, bushes, trees and areas not meant for public access.) In some unfortunated urban water parks those areas might not even be green at all, but made of concrete or paved. Hmm... how about landuse=meadow + meadow=recreation ? I remember the landuse/landcover guys being very special about a meadow being something that is deliberately mown to use the cut grass e.g. for feeding animals. Whereas my type of area is deliberately mown to NOT use the cut grass but the area the grass was cutted from. But with the new subkey, it doesn't sound that bad. regards, Chaos ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] water parks and swimming pools
2013/1/15 Martin Vonwald imagic@gmail.com To me landuse=meadow means an area where grass is grown for some purpose. One purpose may be grazing/pasture. Another may be to lay on it. If a meadow is really used for grazing I add meadow=pasture. Beware! Off-topic: So technically, we could also use it for football fields? Chaos ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Comments wanted: Placement
Hi Martin, I surely get the intention of enabeling renderers of any kind to draw more precice representations of lanes on a way. But I have two comments for you: 1. I think it PARTLY IS about position. Your tag does two things: allowing the renderers to position the lanes correctly in reference to the way and it allows the renderes to know which lanes continue and which start/end if the lanes count changes. You may be only interested in the second part, but the first part is still a valid use of it. 2. I have problems with the tag because it is (to my knowledge) the first 'meta-tag' to be actively used by consumers. It doesn't describe a feature of the real world but how a feature is described by our tagging. I much rather would like to see this information embedded in the existing tags like e.g. the lanes=* tag itself or by one of the various lane connection schemes. This would also fullfil the second use-case mentioned above. Imho introducing a tag that says how other tags work will make it more complicated for for data contributors, especially if this is introduces to other schemes where more than one possibility of tagging exists (public transportation, house numbers, etc.). It also has the chance of getting out of sync if some one changes the original tag (or in your case the relative position of the way) but doesn't change the meta-tag accordingly. (Actually, I'm in favor of drawing the lanes seperately and even using areas, putting them into a relation to form the actual highway and letting the editors handle them just as one way in every but the closest zoom level. But I know that this is opposed to by the majority, so I'm mentioning this very very quietly.) Best regards, Chaos 2012/12/21 Martin Vonwald imagic@gmail.com: 2012/12/20 Pieren pier...@gmail.com: I guess it's purely for rendering. Why not (like 'label'). But it's only useful if you render lanes which is something I've not seen so far (for nano mapping ?). Think of a navigation system with lane assistance - it's just a renderer with a very high zoom level. ;-) The point about car navigation systems is incorrect. It does not care about the highway way position (and no GPS device is accurate enough to determine on which lane you are). You got me wrong: the exact position is irrelevant. This tagging is about the position and course of the lanes within(!) the outline of the road. The navigation system should present you with a representation of the road ahead that is as realistic as possible. Especially the course of the lanes is very important, because drivers strongly rely on the geometry of the road: they should recognize it in the lane assistance. It's all about representation! I most certainly have to create an example (for consumers) which shows how to estimate the course of the lanes. Thanks for your feedback. Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Comments wanted: Placement
Hi Martin, 2. I have problems with the tag because it is (to my knowledge) the first 'meta-tag' to be actively used by consumers. It doesn't describe a feature of the real world but how a feature is described by our tagging. I much rather would like to see this information embedded in the existing tags like e.g. the lanes=* tag itself or by one of the various lane connection schemes. This would also fullfil the second use-case mentioned above. How would you do that? The problem is: the OSM-way is drawn somewhere. Some people draw in the middle of the road most of the time, others as often as possible. Others draw the OSM-way between the two driving directions which is not the middle of the road if we have a different number of lanes in both directions. Some prefer to draw the OSM-way straight even on junctions/exits (see second example in Motorway exit). We will never be able - and we don't want to - force everyone to use some specific mapping style. This tagging should gracefully solve this problem: allow people to use their preferred mapping style but also allow somehow to identify the style. We don't force anybody to use a certain style. But we still say: If you don't use the style we use, your work will neither be rendered nor used by other consumers. Well, let's say we just use use a very mild form of force, ok? I think everybody who is willing to use your additional tag would also be willing to follow a certain 'convention' when it comes to the placement of the way. The only task would be to design that convention in a way that works well with all the roads that doesn't follow it. 'Line between directions' for single-way highways will probably only be off by half a lane in most instances. The same for 'middle of middle lane' (odd lanes) or 'line between middle lanes' (even lanes) on two-way highways. I see that without an extra tag, a consumer can't decide if the way follows the convention or not. But that is the reason we kept the possible error at a minimum. Neither the lanes-key nor any lane connection scheme can solve this. Again - for example - look at the second image of Motorway exit. It is assumed that you know the lane count and the lane connectivity, but without the information about the placement of the OSM-way in section 3 a consumer has no mean determining the course of the lanes. I remember a proposal (or at least a discussion) where the lanes=* key had values for 'starting lane left' or 'ending lane right' etc. This, together with the lanes count before and after and a consistent convention on where the way is placed in reference to the lanes is enough to give you a rendering of which lanes continue and which end. (I think this was shot down because it needs so much splitting of the ways. But so does placement=*.) Imho introducing a tag that says how other tags work will make it more complicated for for data contributors, especially if this is introduces to other schemes where more than one possibility of tagging exists (public transportation, house numbers, etc.). It also has the chance of getting out of sync if some one changes the original tag (or in your case the relative position of the way) but doesn't change the meta-tag accordingly. Absolutely correct - as with nearly all other tags. Someone moves a node for any reason. But on that node a traffic sign is mapped. Or its a connection between two ways and the maxspeed changes. Or the lane count. Or anything else. Information is now out of sync. All the same. I would not put 'changing the beginning of a maxspeed zone by 4m' and 'completely destroying the lanes rendering' in the same category though. But both will happen if I move a single node by a mere 4m without looking at the tags. (Actually, I'm in favor of drawing the lanes seperately and even using areas, putting them into a relation to form the actual highway and letting the editors handle them just as one way in every but the closest zoom level. But I know that this is opposed to by the majority, so I'm mentioning this very very quietly.) I didn't hear you ;-) My silent opinion: much to much effort for much to less gain (except on complex junctions). You get nearly(!) the same result with just a bunch of tags on one single way. But I didn't say anything ;-) So I whisper: there isn't so much effort if the tool support is good and you stay above max zoom level. But if you WANT to add that much detail, it is possible and will give good gain. Also it will solve a lot of problems with one scheme instead of several ones like your placement, the junction discussions, the trunk/accelearation/decelaration lines discussion, the legal/physical lane seperation discussion etc... But now I better shut up. Regards, Chaos ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Status of maxspeed:wet
Of course
It's not the first time I see such process : propose a new tag, do not
say it would deprecate anything until vote is accepted (or - if you
don't like vote : consensus is reached, or no more complains), wait
few months, change the wiki from do not deprecate to recommend to
deprecate, wait few months, remove recommend from the wiki to just
deprecated. This remembers me the bus_stop and platform
discussions. Or the second user account for imports.
These are unfair and sneaky methods to change things in OSM.
Are you against changing things in general or do you like to always
cut off old schemes completely without legacy support?
Because the described way is about the best solution I could come up
with that both allows change and gives the crowd enough time to adapt.
The only thing that is missing is that the wiki changes should be
backed up by taginfo data to support the claim.
It even allows hardliners to keep tagging the old way indefinably.
('Deprecated' doesn't mean 'forbidden'.)
So: how would you change things in OSM?
Regards,
Chaos
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fwd: Door to door routing to buildings with multiple occupants
2012/12/4 Martin Koppenhoefer dieterdre...@gmail.com: if you see the address as feature it should be an area and not a node, but if you add it to a POI I'd see it as an attribute and there is no problem in adding it multiple times. Putting an address-node on a building-outline to mark an entrance seems odd, why not tag the entrance with entrance and put the address on the whole building outline (or even on the whole site it applies to if you have this information)? We are running in circles here. Putting it on the building outline or the site outline/relation seems right, but doesn't work for multiple addresses on the same building/site. If there are multiple addresses for the same area one can simply create multiple address-objects. You just said above that addresses are not features, but attributes. So what is an 'address object' and how can I create multiple of them? If you mean to create multiple building outlines to tag an address on each, we are clearly in the realm of 'one feature, one OSM element'. May I also add that, at least in theory, we are talking about a spacial database which should have no problem in determine which element lies within which other element. So an amenity node inside a building has an implicit relation to that building and could 'inherit' its address. So there is, again: in theory, no need for repeating the address on each POI. In the real world, we should of course just add that little but of redundancy because most data consumers and even our database are not that 'spacial aware'. I tried to find out what an address really points to here in Germany. I wasn't successful. You get a house number for a parcel of land, even without a house on it, but only if it is already connected to a street. When you build a house you definitely get one. Or the house inherits the number from the parcel. But you can get more than one number if you build multiple houses. (Or you can build additional houses without a number.) You can also get more numbers if you have multiple entrances to a building. But it is no problem for several flats in the same building to share the same number too. I couldn't find out on who's discretion this happens. And then there is the postal service, which some times even defines its own scheme when it for instance give a whole postal code range to a company, sets the address of a building to some street/city it isn't located at/in or delivers to mailboxes that are not in the same street then the buildings they belong to. my 2 cents, Chaos ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fwd: Door to door routing to buildings with multiple occupants
Hi Rob, We already had this discussion some time ago. There wasn't a complete consensus on the matter, but here is how I tag now: One amenity per building: the addr: tags and the amenity tags on the building outline. One or multiple entrance nodes on the outline. Several amenities per building, but each with it's own entry: addr: on the building outline, multiple entrance nodes on the outline, amenity tags on the entrance nodes. Several amenities per building with more than one amenity per door: addr:* on the building outline, several entrance nodes along the outline, amenity tags on extra nodes near the entrances inside the building outline. Several addresses per building: addr:* tags on entrance nodes along the building outline. Some also prefer to put amenities and building into a site relation. Pros: scales the solution with the complexity of the problem. Cons: not very consistent, renders poorly Regards, Chaos Am 30.11.2012 23:42 schrieb Rob Nickerson rob.j.nicker...@gmail.com: -- Forwarding message from talk as more appropriate to tagging list -- Hi, A mapper who is new to my area is interested in mapping disabled access at a micro level. Specifically he would like to achieve door-to-door mapping for key shops and amenities, and has made a good start by adding entrance doors to several buildings. My Question: Where should amenity=* and addr:*=* be tagged? One suggestion was to add all the detail to the entrance node, but this seems odd to me. For single occupancy buildings I suggested tagging the building as amenity=*, etc as the entrance node on the building can be easily matched with these. But what about a building with multiple occupants and entrances. For example 2 shops in one building. One option is to tag the building with building=yes and then add the amenity tags to individual nodes, but then how would door to door routing work? An alternative is to just split the building in to 2 areas (but technically its 1 building). Can we use some form of indoor mapping (e.g. room=yes, amenity=*)? Is there a better solution? All ideas welcome. Regards, Rob ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Zones 30 in Belgium (from [talk-be] )
If you have a data set of nodes representing street signs, why don't you import them as such? traffic_sign=BE:C43 maxspeed=30 source=? Of course you still need to manually match those to the ways and tag the maxspeed=* to them. But you can use the traffic_sign=* nodes to create a josm filter or even ask someone from OSMI or keepright to do a check based on a matching way in close proximity to such sign. You could list all imported nodes on a wiki page, so they can be reviewed by actual humans. I suppose they are not precise enough to 'really' denote the sign post, right? my 2 cents. Chaos 2012/11/21 Martin Koppenhöfer dieterdre...@gmail.com: Am 21/nov/2012 um 11:25 schrieb A.Pirard.Papou a.pirard.pa...@gmail.com: created_by=(erased) note=temporary node until nearby way speed limit is set maxspeed=30 source:maxspeed=http://www.gpspassion.com/forumsen/topic.asp?TOPIC_ID=123619 FIXME:tag same maxpeed and source:maxspeed onto the span of nearby way, then delete this node name[as of source]=states town and street so that incorrect coordinated can be detected. If these nodes do not represent sign positions you shouldn't import them into osm IMHO, better put them into open street bugs or similar. There is no point in having them in osm in this case, as you can't infer from just a point position where the limit applies to, and therefor these nodes are more or less useless (they might be a hint where the mapper should make a survey but not more). Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Exclusive access rights
Try to see it from a data consumer point of view. Let's say you are a bicycle routing engine and want to know if you are allowed to drive here. With the current scheme you see an access = no. so you assume you don't have access. Then you look if there are special permissions for bikes (because, after all, you are a bike routing engine) and find nothing like bicycle=yes. So you know what to do: deny access. With you proposal, you'll find no access = no (just a valid highway tag). So you assume you are allowed there. There is no other key for bikes. So how do you know bikes are not allowed? You'll have to check every possible transportation mode, if maybe one of them has EXCLUSIVE access to this stretch of road. Maybe psv? Maybe hasmat? Who knows.. If you group this under a general key like exclusive_access= psv, you'll at least have a chance (if something is listed, but it's not bike, then deny access). But you'll have to look for it for every d*** road there is, not just those with access = no. So in my opinion, there is no way around first specifying the general case (access = no) and then the special case (psv=yes). Regards, Chaos 2012/10/29 Martin Vonwald imagic@gmail.com: Hi! I'm looking for a possibility to tag exclusive access rights. What I mean by this is a way to specify that one specific vehicle is allowed and everything else is forbidden. If I specify e.g. hgv=yes it only means (at least in my understanding) that hgv are allowed there. I'm not sure about the meaning of access=hgv: is this a valid tag? What is its meaning? I am aware of the combination access=no and xxx=yes, but I'm looking for a nicer solution. The background of my question is the following demand: specify that the rightmost lane (of three lanes) can only be accessed by psv and hgv. Right now I only know this solution: vehicle:lanes=yes|yes|no psv:lanes=yes|yes|yes hgv:lanes=yes|yes|yes Three tags for such a simple thing. What I'm looking for is something like this: somenicekey:lanes=vehicle|vehicle|psv;hgv If access=hgv means that only hgv are allowed, I could use that. But as I wrote: I'm not sure if this tag is valid and if it is I am not sure about its meaning. Any hints/comments/recommendations? Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] designation=* is a mess in Germany
Hi, I've recently stumbled upon some confusing usages of the key designation=* in my area, so I tried to find out what it really means and how it is used correctly. I haven't succeeded. Of course there is the wiki page [1] at http://wiki.openstreetmap.org/wiki/Key:designation which explains that it is used for the local classification of roads in the UK. But on the same page the usage as a descriptive tag for nature reserves is also documented. Looking at taginfo [2] seems to harden the case for road classification, but also shows 'shed' in 5th rank. But I was curious about how this is actually used outside of the UK. So I did a OverPass-Api query for 500 ways on designation=* with a bounding box of Germany [3] and fed that through a 'grep designation' which gave me a horrifying list [4]. Seems like I can delete my fresh wiki page translation [5] and replace it with a 'just tag anything you want with it'. Now this might be unfair, as OverPass sorts by way ID which might be a bad choice for a random sample. But I actually didn't find even one correct example of usage in there. I'm so baffled by this, I don't even have a decent question to ask. Where to start? Modify the wiki according to usage? To what usage? Modify the tags? All of them? To what? (I said 'decent'. Not that I don't have questions ...) Or just slowly walk away from that topic? Regards, Chaos [1] http://wiki.openstreetmap.org/wiki/Key:designation [2] http://taginfo.openstreetmap.org/keys/designation#values [3] http://overpass.osm.rambler.ru/cgi/interpreter?data=%5Bout:json%5D;way%5Bdesignation%5D%2846%2E845703125%2C5%2E185546875%2C55%2E634765625%2C15%2E46875%29%3Bout%20500%3B [4] http://pastebin.com/raw.php?i=ymViH17J [5] http://wiki.openstreetmap.org/wiki/DE:Key:designation ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] designation=* is a mess in Germany
Can we at least slow down the effect? I just checked with my original problem, a newbie mapper plastering the map with POIs that contained their name also in the designation=* tag. He used Potlatch 2. And now I found it. Potlatch offers a field for 'Official classification', with a help text that reads: 'The official classification or designation (if any). Only use this if the organization that runs it has its own classification system.' This translates to the designation=* tag for things like supermarkets or shops. Of course the mapper didn't follow that help text, but even if done so, the tag would still be kind of wrong, at least according to the wiki page. There even is a Potlatch ticket for this [1], but it was marked as closed 2 moths ago by Richard. I've just added a comment their asking why it is still in there. Regards, Chaos [1] https://trac.openstreetmap.org/ticket/4231 2012/10/23 Richard Mann richard.mann.westoxf...@gmail.com: Slowly walk away. The usage in the UK should be shifted to a new key (maybe something like path_type), and the rest probably ignored. The choice of name for the key stemmed from access=designated, and (with 20:20 hindsight) was a mistake. There are some people who prefer to have multi-purpose key names, but this is just a meaningless bucket. Richard ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Hiking trail marker
If it fits, you might also add highway=emergency_access_point [1] Actually, this is a perfect match for the emergency=* key, but for historical reasons, it is tagged as highway=*. (Feel free to be the first to switch over) regards, Chaos [1] http://wiki.openstreetmap.org/wiki/Tag:highway%3Demergency_access_point ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] how to tag: water enclosure beneath fountains
Hi, recently someone mapped a lot of fountains here, so tried to find out how they should be tagged. But I failed. I found both natural=water or landuse=basin to be in use for those features, but both have their flaws. natural=water - wiki page doesn't specify, but details, examples and name imply the use for a natural feature - but it is used for all kinds of water features, man made or natural (more of a landcover-like tag) - not able to get specific usage figures from taginfo due to variety of uses. landuse=basin - wiki page doesn't specify, but key and sub-types seem to fit for large stormwater/rainwater installations only - not that much in use according to taginfo Do you know any other tag fitting small scale, urban, man made enclosures of water (possibly fed by a fountain or well)? I can see this equally well in the amenity= or man_made= namespace. Or just keeping it with amenity=fountain mapped as an area? Or tag both? Opinions? Best regards, Chaos ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] how to tag: water enclosure beneath fountains
2012/10/1 Martin Koppenhoefer dieterdre...@gmail.com: natural=water - wiki page doesn't specify, but details, examples and name imply the use for a natural feature IMHO natural=water is flawed, for several reasons: it is not a geographical feature (that would be natural=lake, etc.), but it is also practically used for all kinds of superficial water (and if one insists on natural=from mother nature: water is almost always natural, the rare cases of artificial water aren't probably something that will be tagged in OSM). There is an attempt to further specifiy natural=water with a key water=? (where one of the values is reflection_pool IIRR) Of course there is no 'artificial' water. But following this logic, we can also tag a pedestrian area with natural=cobble_stones. It's the enclosure of the water that is man made and mostly even the existence of water in that spot. I would rather use a man_made=reflection_pool without the natural=* addition. Do you know any other tag fitting small scale, urban, man made enclosures of water (possibly fed by a fountain or well)? if you want to be generic like this, natual=water is your tag IMHO. If you are interested in a particular feature, additionally tag this (e.g. amenity=fountain, water_well, ...) Or just keeping it with amenity=fountain mapped as an area? Or tag both? well, a fountain might consist of parts covered with water and others made of rock, metal or s.th. else, and there might even be no water at all (any more), e.g. here is a nice monumental fountain by famous architect Bernini in a small town that was destroyed (and remained ruins since then) in 1799 by the French: http://it.wikipedia.org/wiki/File:Canale_Monterano_Bernini.JPG I can't follow you here: You say that natural=water is flawed, that there might be fountains without water and that a fountain might consist of several materials besides water. And still you recommend to tag the whole area as natural=water, amenity=fountain? Regards, Chaos ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Announcement: Voting ongoing for proposed access tagging Conditional restrictions
Eckhart, Ich habe gerade eine Spalte für das Extended Conditions Schema zur Beispieltabelle auf der Diskussionsseite des Conditional Restriction Schemas hinzugefügt. [1] (Warum hat das Extended Conditions Schema eigentlich keine Beispiele?) Würdest du mir helfen die Lücken zu füllen? Du scheinst mehr Erfahrung damit zu haben als ich. (Obwohl mich das zum besseren Versuchskaninchen macht ..) Andere dürfen natürlich auch ... Gruß, Chaos [1] http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Conditional_restrictions#Pictorial_examples ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Announcement: Voting ongoing for proposed access tagging Conditional restrictions
I'm sorry. Here it is again in English: Eckhart, I've added a column for the Extended Conditions scheme to the examples table on the discussion page of the Conditional Restriction scheme. [1] (Why doesn't have the Extended Conditions scheme it's own examples?) Would you please help me fill in the blanks? You seem more experienced in this scheme than me. (Although that would make me more suited as a test candidate.) All others are invited too, of course. Regards, Chaos [1] http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Conditional_restrictions#Pictorial_examples ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] name of river/admin area
In Germany, this question is easier to answer. There actually are streams and creeks that have the word stream or creak in the name, just that Germans pull the words together, making it more obvious that its part of the actual name. Also it is almost exclusively used for smaller water features, like in 'Breitstrom' (broad stream) or 'Klettbach' (Klett brook). It's almost never used for really big rivers. (Rhine, Oder) For cities, the situation is similar. Often the equivalent of town, city or village is part of name name (like: part of the same word). This again is more often true for smaller towns. But we have some exceptions: 'Lutherstadt Wittenberg' (City of Luther, Wittenberg) is actually the full, official name of that city. How do we know? Well as everything else in Germany, this is tightly regulated and we just need to look at the official sign at the city border. That what makes it easier here: The simple rule is 'Just look at the official sign'. No city would dare to use different versions of it's name on official signs or documents. Best regards, Chaos ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] drinkable vs. drinking_water
Another anecdotal example: I'm a non-native speaker (being German) and I don't know a word in french. But I did know the term 'potable' very well. And so will everybody else who ever went camping in either New Zealand, Canada and probably many other English-speaking countries. Camp sites and also local authorities regularly use the term to describe the use of certain public water sources. (You don't want to fill your water bottle on the tap or hose others use to clean their portable loo) I remembered it this way: 'potable' means that I can put it in a (cooking-) pot to prepare my food with. Back to OSM: I do understand 'potable' and I believe others can do too. You either use translated presets or need to look it up in the wiki/taginfo anyway. I also expect anyone smart enough to use an osm editor can also use a translation tool. BUT: I don't think migrating existing tags helps anyone. As long as the alternative is as understandable as 'drinking_water', my vote is for keeping the existing term. Chaos ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Ref tag
What about ref:DE= or ref:UK= for the national and just ref= for the international ID? best regards, Chaos 2012/6/19 Martin Vonwald imagic@gmail.com Hi! What value would you put into the ref tag if national and international reference differs? I seems to me that mostly the national ref is used, which also makes sense imo. Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] (Mini)Roundabout: examples
2012/5/15 Colin Smale colin.sm...@xs4all.nl On 15/05/2012 16:30, Anthony wrote: I hope not...OSM currently has no way of reflecting priority at junctions. Introducing this distinction just for circular junctions is a bit pointless. Well there IS highway=give_way. Not that I tagged it so far. But almost 9000 hits at taginfo means it's at least 'in use'. (Also highway=stop). Best regards, Chaos99 ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Business being operated out of a home?
If he operates an 'office' where public customers or partners might want to go to: Yes, why not? But take a look at http://wiki.openstreetmap.org/wiki/Verifiability If he has no sign on the door, he probably shouldn't be mapped. I just ask myself when mapping businesses: How likely is it that somebody wants to enter that into their satnav to find the place? If it's just the owner itself and maybe some direct partners/customers, I don't tag it. my 2 cents, Chaos99 2012/3/14, Nathan Edgars II nerou...@gmail.com: http://www.openstreetmap.org/browse/node/1584729508 This is a residential apartment building. Is it appropriate for one of the residents to add a digital marketing business he owns? ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Business being operated out of a home?
2012/3/14, Pieren pier...@gmail.com: On Wed, Mar 14, 2012 at 9:41 AM, Ronnie Soak chaoschaos0...@googlemail.com wrote: But take a look at http://wiki.openstreetmap.org/wiki/Verifiability If he has no sign on the door, he probably shouldn't be mapped. You might verify in different ways. A sign on the door is not the only one. Just took a close look at my own link. On the 'Good practice' page it says '[a second mapper could] come to the same place and collect the same data ', but on the 'Verifiability' page it doesn't mention being physically there. So maybe it's ok if you can get the information from elsewhere (like for historic features no longer visible or abstract concepts like administrative borders), but I think for businesses it is quite a good practice to require some sort of physical sign/logo/label. Regards, Chaos99 ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Preventing traffic signs - Invitation to discussion
This is a complex matter. Verbose names are good. Looking up numeral codes is tedious for the human mapper and hinders wider usage of the tag. Also the country prefix is redundant, as this can be determined out of the location of the sign. Also linking together signs of the same meaning in different countries is a good idea in general. But there is missing a key element to the (original) proposal: There are signs for both point features (traffic light ahead, railway crossing) and signs for conditions in effect for a stretch of way (maxspeed, gravel). Sometimes it's ambiguous (no u-turn, dead end street). We would need a definitive list for what is what and if it's tagged on a node on the way or an the way itself. Also the meaning of some signs already has a tag of its own. A traffic_sign=maxspeed is tagged as maxspeed=* on the way. A traffic_sign=oneway is tagged as oneway=yes, a traffic_sign=cycleway is tagged as access=no; bicycle=designated. What do we do about that? Do we translate every sign into an existing tag combination/invent new ones? Then why think about the traffic_sign tag at all? Do we tag the sign in addition to the existing information? Do we replace the old information? (Surely not!) Any Ideas? Regards, Chaos99 ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Preventing traffic signs - Invitation to discussion
Please also see http://wiki.openstreetmap.org/wiki/Proposed_features/Hazard_warning What about a combination of both? Tagging the traffic_sign=* at the node on the way roughly where the sign is, then tag the hazard=* along the way or on the node where the actual danger is. Regards, Chaos99 ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Preventing traffic signs - Invitation to discussion
I think most points are adressed on the proposal or talk pages, but here we go: Putting lots of traffic signs on nodes on the way would result in a lot of new nodes on the ways, which will need optimising out by routers/mkgmap etc. The node count will increase anyway, the tools need to scale accordingly. Probably mapping one smooth corner adds about as much complexity as all the signs on that road. You could put the nodes for the signs beside the road, where they are located in reality. But then the connection with the road needs to be established by other means, possibly a relation. This also adds complexity. And this kind is hard on the mapper, not just on some script. Also tagging the hazard on the road will introduce new road splits and nodes. The sign is not really an attribute of the road. Putting a tag on the road segment to which the warning applies would seem to me a more logical way of indicating these semantics, and a whole lot more usable for the routers. An indicative node for the sign itself (so then we are mapping street furniture i.e. the post itself with the signs attached to it, not the characteristics of the road) would be fine IMHO although I do wonder if this level of micromapping would be productive in the long run. That's what I proposed some mails ago: tagging the hazard on the road segment or node where it belongs, then adding the sign as a node on its physical location. Will it carry any useful information? Well, I also think the hazard is more important than the sign itself, but who knows what use it may be to some people. I myself once needed to know the locations of all city limit signs of one town. The answer was one XAPI call away. Also the sign position serves as a kind of verification and source reference for the hazard tag. If there are multiple signs on a single post, we will get (I assume) constructions like traffic_sign=sign1;sign2;**sign3. As we know multiple-valued tags are currently poorly supported by the available tooling (correct me if I'm wrong) I think there is no tooling yet which uses traffic signs at all. Signs often have sub-signs qualifying the main sign, e.g. slippery road when wet. This will need a place in the tagging as well. How would we handle multiple signs on a post, each with its own sub-sign? Same goes for textual signs. No idea. There are schemes for opening hours which also could apply to signs. The extent of the hazard has already been mentioned (e.g. sharp bends for 5km). Often a warning sign gives advance notice of the hazard (e.g. low bridge in 2 km) so the sign's location differs from the location of the hazard it is indicating. Most of those information is already contained in the hazard tagging of the road segment. Both the position and the extend of the hazard are given there. For tagging the sign itself (for the sake of completeness alone), see above: no idea so far .. just my 2 cents Chaos99 ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] dispute about center island in a turning circle
2012/3/13 Josh Doe j...@joshdoe.com: Ah, another UK peculiarity. I guess I've been misapplying As far as I know it is the same e.g. in Hungary. In Germany, here is no difference in law, sign or language between a mini-roundabout and roundabout. highway=mini_roundabout; but if so, we need to change this language on the wiki page: The mini-roundabout _usually_ does not have a physical island (emphasis added) The German Wiki (probably translated from the English original) states that the difference is exactly (and only) the form of the central island and the tagging should be done according to this feature. Just for you further consideration.. Chaos99 ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] dispute about center island in a turning circle
May I ask were the definition of 'turning_cycle' comes from? (I'm not a native English speaker) As far as I've read on the wiki, it's a standing term in the UK describing the 'widened end of a road intended to enable easier turning of vehicles' and does not necessarily have to be of a circle shape. So, when even the shape is not fixed, isn't the overall intention of the term to describe something the eases turning? Where does the 'does not have a central island' come from? It's just another shape. Call it 'toroid' if you will. Isn't the intention the same? By the way: I would also just draw it as a circular way, but would at least think about tagging the whole thing as 'turning_cicle'. Regards, Chaos99 ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
