Re: [Tagging] default value for oneway
Am 28.08.2014 um 23:02 schrieb Xavier Noria: On Thu, Aug 28, 2014 at 10:39 PM, Peter Wendorff wendo...@uni-paderborn.de wrote: No, it isn't. The interpretation of the database, and the meaning, restricted to the fact of the streets oneway-ness is the same, but no value at all does not say this is no oneway street, it says nothing more than we don't know if it's oneway or not. That is the generic interpretation of a NULL value in programming (I am a programmer), absence of value. But your contract is that unset implies no for streets. So there you go. Got no value? I *have* to assume no. And since that's the case, the de facto usage pattern seems to be to leave oneway unset. The database has millions of NULLs for which the users mean an actual no. They didn't bother, but it is NULL for no. And that is a consequence of the design of the data model for that attribute. If this was 0-day of OSM and the attribute had possible values one-way, two-way, reversible, with an active default of two-way preselected in UIs, then you could in practice say NULL means unknown. +0.5, as UIs are decoupled from the data in OSM. You may write your own editor with a completely different UI, even one that doesn't know about oneway at all, so reasoning on UI preferences may help to get the best default, but not to derive rules from. regards Peter ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] default value for oneway
On Fri, Aug 29, 2014 at 9:43 AM, Peter Wendorff wendo...@uni-paderborn.de wrote: +0.5, as UIs are decoupled from the data in OSM. You may write your own editor with a completely different UI, even one that doesn't know about oneway at all, so reasoning on UI preferences may help to get the best default, but not to derive rules from. Agreed. That was a way to say: if you reset the values in the database to have no NULLs, and change the semantics of NULL to mean strictly unknown, not all is lost regarding convenience of data entry. iD (to put an example) can still choose to preselect no for streets. Nowadays it has a list of stuff for which yes is assumed: https://github.com/bhousel/iD/blob/master/js/id/core/oneway_tags.js And you increase certainty. If a UI does not include oneway and creates streets, then oneway remains unknown for them, fine. The user said nothing, so fine to write a NULL meaning don't know. Nevertheless, all this is a theoretical exercise just for the sake of thinking about the attribute. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] default value for oneway
Am 29.08.2014 um 09:58 schrieb Xavier Noria: On Fri, Aug 29, 2014 at 9:43 AM, Peter Wendorff wendo...@uni-paderborn.de wrote: +0.5, as UIs are decoupled from the data in OSM. You may write your own editor with a completely different UI, even one that doesn't know about oneway at all, so reasoning on UI preferences may help to get the best default, but not to derive rules from. Agreed. That was a way to say: if you reset the values in the database to have no NULLs, and change the semantics of NULL to mean strictly unknown, not all is lost regarding convenience of data entry. iD (to put an example) can still choose to preselect no for streets. Nowadays it has a list of stuff for which yes is assumed: https://github.com/bhousel/iD/blob/master/js/id/core/oneway_tags.js And you increase certainty. I fear you don't. For the list you linked this is true as most ways are oneways, but in general it is dangerous. A user must be aware that he explicitly states this way is oneway (that is the case already due to the small arrows iD paints on the ways) or this way is no oneway (which is invisible, as it is the same visual appearance than no oneway tag at all). If you don't set the tag as a default, everything is fine as nobody accidentally sets it to a wrong value. If you set it to oneway=no by default, people will start to accidentally tag oneway=no, which results in wrong information in contrast to missing inforation we have no. Of course: if you could make people aware of the tag and make sure 99% of the ways are intentionally (!) tagged with yes or no, then it's fine, but I doubt it. regards Peter ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Unification of google-plus links
Hi, I would like to unify the keys for google-plus-pages of objects in the Database. In TagInfo I found this variants: contact:google+ contact:google_plus link:google_plus contact:google Google + Google Plus Google+ contact:googleplus contact:google + GooglePlus googleplus contatc:google+ google business [https://taginfo.openstreetmap.org/search?q=google] I would like to change the Keys in contact:google_plus [http://wiki.openstreetmap.org/wiki/Key:contact]. I found also some Facebook-keys (with uppercase F). I would like to change them in contact:facebook [http://wiki.openstreetmap.org/wiki/Key:contact]. The same with Twitter (- contact:twitter). And I would like to move the social-network-links link:[facebook|twitter] in the contact-namespace. Andreas -- sorry for my bad english... Andreas Neumann http://map4Jena.de http://Stadtplan-Ilmenau.de signature.asc Description: OpenPGP digital signature ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Unification of google-plus links
It can be done easily with JOSM, you just need to download all nodes/ways/relations, select them all and rename the offending tags in one go. On Fri, Aug 29, 2014 at 11:39 AM, Andreas Neumann andr-neum...@gmx.net wrote: Hi, I would like to unify the keys for google-plus-pages of objects in the Database. In TagInfo I found this variants: contact:google+ contact:google_plus link:google_plus contact:google Google + Google Plus Google+ contact:googleplus contact:google + GooglePlus googleplus contatc:google+ google business [https://taginfo.openstreetmap.org/search?q=google] I would like to change the Keys in contact:google_plus [http://wiki.openstreetmap.org/wiki/Key:contact]. I found also some Facebook-keys (with uppercase F). I would like to change them in contact:facebook [http://wiki.openstreetmap.org/wiki/Key:contact]. The same with Twitter (- contact:twitter). And I would like to move the social-network-links link:[facebook|twitter] in the contact-namespace. Andreas -- sorry for my bad english... Andreas Neumann http://map4Jena.de http://Stadtplan-Ilmenau.de ___ 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] Unification of google-plus links
Am 29.08.2014 um 11:48 schrieb Éric Gillet: It can be done easily with JOSM, you just need to download all nodes/ways/relations, select them all and rename the offending tags in one go. I know, how to do it: 1. Download via Overpass 2. Open the file in JOSM 3. Change the keys But I have to ask on Tagging or Talk, if I'll make a global change. Andreas -- Andreas Neumann http://map4Jena.de http://Stadtplan-Ilmenau.de signature.asc Description: OpenPGP digital signature ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Unification of google-plus links
This all seems sensible, with the exception that I can only ever recall seeing the former referred to as Google +, and I think most people will use the + sign. On Aug 29, 2014 10:39 AM, Andreas Neumann andr-neum...@gmx.net wrote: Hi, I would like to unify the keys for google-plus-pages of objects in the Database. In TagInfo I found this variants: contact:google+ contact:google_plus link:google_plus contact:google Google + Google Plus Google+ contact:googleplus contact:google + GooglePlus googleplus contatc:google+ google business [https://taginfo.openstreetmap.org/search?q=google] I would like to change the Keys in contact:google_plus [http://wiki.openstreetmap.org/wiki/Key:contact]. I found also some Facebook-keys (with uppercase F). I would like to change them in contact:facebook [http://wiki.openstreetmap.org/wiki/Key:contact]. The same with Twitter (- contact:twitter). And I would like to move the social-network-links link:[facebook|twitter] in the contact-namespace. Andreas -- sorry for my bad english... Andreas Neumann http://map4Jena.de http://Stadtplan-Ilmenau.de ___ 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] Unification of google-plus links
I would like to unify the keys for google-plus-pages of objects in the Database. I think that's usually fine. I would like to change the Keys in contact:google_plus change them in contact:facebook I'm not in support of this though. contact: is not commonly used and I don't think is has that much support either. For addresses most people use addr:, phone= and website= are much more popular than contact:phone/website=. So I really don't see a reason why we should use contact: for social media. facebook=*, google_plus=* works just fine in my opinion and it's also what a lot of mappers use. __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] default value for oneway
To suggest that we now have to include every possible tag with an explicit value on every element is just ridiculous: the logical consequence of an explicit oneway on all ways. Where there really is a need to remove ambiguity, surely something like an area or perhaps relation (less obvious to the casual mapper) is needed within which the default value(s) for a tag(s) is defined. Now I start worrying about new ways crossing the area, so maybe a relation is better after all. Just a suggestion which needs refinement if anyone here thinks this is sensible. But the current argument: shall we or not? isn't going anywhere and normal mappers just won't add explicit tags in normal circumstances. You need a different approach and maybe what I say above can start the ball rolling. ael ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Unification of google-plus links
The problem is the + and the space sign. Both are bad chars for a key. Maybe someone can tell why. [http://taginfo.openstreetmap.org/keys/contact%3Agoogle%20%2B] Andreas On 29.08.2014 11:57, Andy Mabbett wrote: This all seems sensible, with the exception that I can only ever recall seeing the former referred to as Google +, and I think most people will use the + sign. On Aug 29, 2014 10:39 AM, Andreas Neumann andr-neum...@gmx.net mailto:andr-neum...@gmx.net wrote: Hi, I would like to unify the keys for google-plus-pages of objects in the Database. In TagInfo I found this variants: contact:google+ contact:google_plus link:google_plus contact:google Google + Google Plus Google+ contact:googleplus contact:google + GooglePlus googleplus contatc:google+ google business [https://taginfo.openstreetmap.org/search?q=google] I would like to change the Keys in contact:google_plus [http://wiki.openstreetmap.org/wiki/Key:contact]. I found also some Facebook-keys (with uppercase F). I would like to change them in contact:facebook [http://wiki.openstreetmap.org/wiki/Key:contact]. The same with Twitter (- contact:twitter). And I would like to move the social-network-links link:[facebook|twitter] in the contact-namespace. Andreas -- sorry for my bad english... Andreas Neumann http://Map4Jena.de http://Stadtplan-Ilmenau.de signature.asc Description: OpenPGP digital signature ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Unification of google-plus links
The character plus (+) is an unusual character for keys indeed. I believe it's because people usually say x=y + a=b when talking about a combination of two tags. 2014-08-29 11:36 GMT-03:00 Andreas Neumann andr-neum...@gmx.net: The problem is the + and the space sign. Both are bad chars for a key. Maybe someone can tell why. [http://taginfo.openstreetmap.org/keys/contact%3Agoogle%20%2B] Andreas On 29.08.2014 11:57, Andy Mabbett wrote: This all seems sensible, with the exception that I can only ever recall seeing the former referred to as Google +, and I think most people will use the + sign. On Aug 29, 2014 10:39 AM, Andreas Neumann andr-neum...@gmx.net mailto:andr-neum...@gmx.net wrote: Hi, I would like to unify the keys for google-plus-pages of objects in the Database. In TagInfo I found this variants: contact:google+ contact:google_plus link:google_plus contact:google Google + Google Plus Google+ contact:googleplus contact:google + GooglePlus googleplus contatc:google+ google business [https://taginfo.openstreetmap.org/search?q=google] I would like to change the Keys in contact:google_plus [http://wiki.openstreetmap.org/wiki/Key:contact]. I found also some Facebook-keys (with uppercase F). I would like to change them in contact:facebook [http://wiki.openstreetmap.org/wiki/Key:contact]. The same with Twitter (- contact:twitter). And I would like to move the social-network-links link:[facebook|twitter] in the contact-namespace. Andreas -- sorry for my bad english... Andreas Neumann http://Map4Jena.de http://Stadtplan-Ilmenau.de ___ 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] key:destination Signpost question
Good Day, I am writing to receive additional clarity with regards to using the 'destination%' tag in the context of signposts. For a while now, the status quo was to use the 'exit_to' tag on the node where the signpost would be (bifurcation points typically) when representing a signpost location and information. This tag is being deprecated (hence this wiki page). Using the destination tag on the ways (e.g., motorway_link) can provide one with the signpost information, but how would one easily identify the signpost? Are we going to use the 'destination%' tags in conjunction with the highway=motorway_junction tags on the nodes where the bifurcation point is? This isn't clear in the main article for 'Key:destination'. My thoughts are that tagging both node (bifurcation point) and way(s) (downstream from node representing bifurcation point) would make it easy for downstream OSM data users to identify the signpost locations and the relevant signage information. An existing example (not edited by me!!) is along the lines of what I'm thinking: · node 140772317http://www.openstreetmap.org/node/140772317, represents the bifurcation point · way 14406219http://www.openstreetmap.org/way/14406219, represents the right part of the fork/bifurcation · way 293468020http://www.openstreetmap.org/way/293468020, represents the left part of the fork/bifurcation Here is a visual example of the bifurcation with the OSM ways and node cited above: · http://wiki.openstreetmap.org/wiki/File:Bifurcation_example.PNG Please note, I also posted here: · http://wiki.openstreetmap.org/wiki/Talk:Key:destination#Identifying_Signpost_Location.28s.29_In_Conjunction_with_ways_tagged_with_.27destination.25.27_tag Best, Kristen --- Kristen Kam OSM Profile -- http://www.openstreetmap.org/user/KristenK ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Unification of google-plus links
I note that the domain name for Google+ is plus.google.com, so there is no objection to substituting 'plus' for '+' in some way. Steve On 29/08/2014 15:36, Andreas Neumann wrote: The problem is the + and the space sign. Both are bad chars for a key. Maybe someone can tell why. [http://taginfo.openstreetmap.org/keys/contact%3Agoogle%20%2B] Andreas On 29.08.2014 11:57, Andy Mabbett wrote: This all seems sensible, with the exception that I can only ever recall seeing the former referred to as Google +, and I think most people will use the + sign. On Aug 29, 2014 10:39 AM, Andreas Neumann andr-neum...@gmx.net mailto:andr-neum...@gmx.net wrote: Hi, I would like to unify the keys for google-plus-pages of objects in the Database. In TagInfo I found this variants: contact:google+ contact:google_plus link:google_plus contact:google Google + Google Plus Google+ contact:googleplus contact:google + GooglePlus googleplus contatc:google+ google business [https://taginfo.openstreetmap.org/search?q=google] I would like to change the Keys in contact:google_plus [http://wiki.openstreetmap.org/wiki/Key:contact]. I found also some Facebook-keys (with uppercase F). I would like to change them in contact:facebook [http://wiki.openstreetmap.org/wiki/Key:contact]. The same with Twitter (- contact:twitter). And I would like to move the social-network-links link:[facebook|twitter] in the contact-namespace. Andreas ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Unification of google-plus links
Hi, I disagree. Example: https://plus.google.com/+ConciergeCleanersCo is the same like https://google.com/+ConciergeCleanersCo And there are a lot of other URL-schema. Andreas On 29.08.2014 19:49, Steve Doerr wrote: I note that the domain name for Google+ is plus.google.com, so there is no objection to substituting 'plus' for '+' in some way. Steve On 29/08/2014 15:36, Andreas Neumann wrote: The problem is the + and the space sign. Both are bad chars for a key. Maybe someone can tell why. [http://taginfo.openstreetmap.org/keys/contact%3Agoogle%20%2B] Andreas On 29.08.2014 11:57, Andy Mabbett wrote: This all seems sensible, with the exception that I can only ever recall seeing the former referred to as Google +, and I think most people will use the + sign. On Aug 29, 2014 10:39 AM, Andreas Neumann andr-neum...@gmx.net mailto:andr-neum...@gmx.net wrote: Hi, I would like to unify the keys for google-plus-pages of objects in the Database. In TagInfo I found this variants: contact:google+ contact:google_plus link:google_plus contact:google Google + Google Plus Google+ contact:googleplus contact:google + GooglePlus googleplus contatc:google+ google business [https://taginfo.openstreetmap.org/search?q=google] I would like to change the Keys in contact:google_plus [http://wiki.openstreetmap.org/wiki/Key:contact]. I found also some Facebook-keys (with uppercase F). I would like to change them in contact:facebook [http://wiki.openstreetmap.org/wiki/Key:contact]. The same with Twitter (- contact:twitter). And I would like to move the social-network-links link:[facebook|twitter] in the contact-namespace. Andreas -- Andreas Neumann http://Map4Jena.de http://Stadtplan-Ilmenau.de signature.asc Description: OpenPGP digital signature ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Unification of google-plus links
On 29.08.2014 12:44, Andreas Goss wrote: I would like to unify the keys for google-plus-pages of objects in the Database. I think that's usually fine. I would like to change the Keys in contact:google_plus change them in contact:facebook I'm not in support of this though. contact: is not commonly used and I don't think is has that much support either. For addresses most people use addr:, phone= and website= are much more popular than contact:phone/website=. So I really don't see a reason why we should use contact: for social media. facebook=*, google_plus=* works just fine in my opinion and it's also what a lot of mappers use. OK, I don't want to change the addr:-, website-, phone-, fax- or email-key!!! I never said it. The contact-namespace associate, that the defined facebook- or googleplus-page are a medium to communicate with the defined object. I know a lot facebook-pages, who are created from fans or generated from a wikipedia-pages. That are mostly not a communication channel. Andreas -- Andreas Neumann http://Map4Jena.de http://Stadtplan-Ilmenau.de signature.asc Description: OpenPGP digital signature ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Unification of google-plus links
That's as may be. But the widget Google gives you to switch between their various apps uses a URL beginning https://plus.google.com to switch to Google+. At least, it does for me. Steve On 29/08/2014 19:07, Andreas Neumann wrote: Hi, I disagree. Example: https://plus.google.com/+ConciergeCleanersCo is the same like https://google.com/+ConciergeCleanersCo And there are a lot of other URL-schema. Andreas On 29.08.2014 19:49, Steve Doerr wrote: I note that the domain name for Google+ is plus.google.com, so there is no objection to substituting 'plus' for '+' in some way. Steve On 29/08/2014 15:36, Andreas Neumann wrote: The problem is the + and the space sign. Both are bad chars for a key. Maybe someone can tell why. [http://taginfo.openstreetmap.org/keys/contact%3Agoogle%20%2B] Andreas On 29.08.2014 11:57, Andy Mabbett wrote: This all seems sensible, with the exception that I can only ever recall seeing the former referred to as Google +, and I think most people will use the + sign. On Aug 29, 2014 10:39 AM, Andreas Neumann andr-neum...@gmx.net mailto:andr-neum...@gmx.net wrote: Hi, I would like to unify the keys for google-plus-pages of objects in the Database. In TagInfo I found this variants: contact:google+ contact:google_plus link:google_plus contact:google Google + Google Plus Google+ contact:googleplus contact:google + GooglePlus googleplus contatc:google+ google business [https://taginfo.openstreetmap.org/search?q=google] I would like to change the Keys in contact:google_plus [http://wiki.openstreetmap.org/wiki/Key:contact]. I found also some Facebook-keys (with uppercase F). I would like to change them in contact:facebook [http://wiki.openstreetmap.org/wiki/Key:contact]. The same with Twitter (- contact:twitter). And I would like to move the social-network-links link:[facebook|twitter] in the contact-namespace. Andreas ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] key:destination Signpost question
On Fri, Aug 29, 2014 at 12:26 PM, Kam, Kristen krist...@telenav.com wrote: For a while now, the status quo was to use the 'exit_to' tag on the node where the signpost would be (bifurcation points typically) when representing a signpost location and information. This tag is being deprecated (hence this wiki page). Using the destination tag on the ways (e.g., motorway_link) can provide one with the signpost information, but how would one easily identify the signpost? Are we going to use the 'destination%' tags in conjunction with the highway=motorway_junction tags on the nodes where the bifurcation point is? This isn't clear in the main article for 'Key:destination' Destinations are supposed to be relations, and the members are pretty clear. http://wiki.openstreetmap.org/wiki/Relation:destination_sign#Members For the sign itself, I pick the centroid of the sign location (which isn't necessarily linear to the other members, especially when the sign is not overhead!). The important (and only required) member is to. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] cobblestone, sett and surface=*
FWIW, in my area (northeastern US), sett is referred to as Belgian block, but most people would indiscriminately refer to both surfaces as cobblestone. -- Chris Hoess On Sat, Aug 23, 2014 at 2:57 AM, Mateusz Konieczny matkoni...@gmail.com wrote: How one should tag surfaces: - paved with equally sized, flat stones ( https://www.google.pl/maps/@50.061304,19.938305,3a,30y,270.75h,72.93t/data=!3m5!1e1!3m3!1sBcAaihLoEYmtOQbTnOlxWA!2e0!3e5?hl=pl ) - paved with roughly shaped stones, only partially flattened ( https://www.google.pl/maps/@50.059029,19.940113,3a,30y,276.76h,68.16t/data=!3m4!1e1!3m2!1sJiyUyJYQx9Fqv_dC1-18_A!2e0?hl=pl ) I tag in the first situation as surface=sett and in the second as surface=cobblestone. Bur according to https://wiki.openstreetmap.org/wiki/Key:surface both should be tagged as surface=cobblestone. cobblestone:flattened is mentioned (without any description). To further complicate situation it seems that both surfaces should be described as sett - see http://en.wikipedia.org/wiki/Sett_%28paving%29 Meanwhile, on taginfo - https://taginfo.openstreetmap.org/keys/surface#values : - cobblestone 119 216 - sett 6 261 - cobblestone:flattened 2 176 Cobblestones, sett mistaken for cobblestone and flat sett are clearly different and I hope for way to differentiate between these, better than using smoothness. ___ 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] aeroway=taxiway as area
Why the value description table of http://wiki.openstreetmap.org/wiki/Tag:aeroway%3Dtaxiway states that aeroway=taxiway should not be used on areas? Is there a valid point for this? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] aeroway=taxiway as area
On 08/29/2014 10:38 PM, Nelson A. de Oliveira wrote: Why the value description table of http://wiki.openstreetmap.org/wiki/Tag:aeroway%3Dtaxiway states that aeroway=taxiway should not be used on areas? Is there a valid point for this ? If you are going to perform airport routing (now that would be quite exotic), my understanding is that typical routing engines don't take surfaces into account in their calculations. Otherwise, just make sure that you are not confusing aeroway=taxiway with aeroway=apron - most airport surfaces that you might be tempted to model as surfaces are actually aprons rather than taxiways. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] leisure=common
On 08/28/2014 10:49 AM, Dave F. wrote: I've just looked up common on taginfo I'm very surprised to see virtually all are tagged with leisure= (39348). If I ever used it ( I'm unsure I have) I would have used landuse= (123). I genuinely believe this is an example of where it being the majority doesn't make it correct. In Britain a common is an area of land, usually grass, which is open for all to use, where any number of leisure activities could occur (sports, picnics, playgrounds etc), which is why I think it's vague. It needs a separate tag to able to map the leisure activities with the area. Again, I'm really surprised by the number of landuse= tags. Was there a mass edit? Dave F. On 28/08/2014 16:31, Pieren wrote: On Thu, Aug 28, 2014 at 5:17 PM, Dave F. dave...@madasafish.com wrote: I believe it was withdrawn as it vague. You logic is stated on one of the pages you posted. It was in the map features page for years : An area where the public can walk anywhere (UK) I guess it is also used in US. I found some examples : https://www.google.fr/search?safe=offhl=frsite=imghptbm=ischsa=1q=village+commonoq=village+commongs_l=img.3...11667.13247.0.13578.8.7.0.0.0.0.476.476.4-1.1.00...1c.1.52.img..8.0.0.cFS7KjyXTyo If you don't know what village common is then don't use it. If we start to delete all vague definitions in the wiki, we should better start with smoothness :-) The description an area where the public can walk anywhere fits many other things besides village commons. I agree that this is an overly-vague definition. -- 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. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] key:destination Signpost question
I'm using the motorway_junction node on exits, with the ref and the name as tags. Reasons: it has been done since the early days of OSM, and it looks nice on Mapnik. I'm also using the motorway_junction up to four times per interchange to have the name of the interchange appear on Mapnik (example: http://www.openstreetmap.org/#map=15/51.8726/4.5695). An example of tagging the exact locations of all signposts is shown here: http://wiki.openstreetmap.org/wiki/Lane_assist/Examples/Destination#Sophisticated_variant. Personally, I think that's a bit difficult to map, so I prefer the simple variant For motorways it's not necessary to know the location of the signposts, since every split is signposted (except for some very few exceptions maybe). However any router supporting lane assist, like TomTom, shows the lane a driver should take. It's at that point where 'obvious connectivity' in conjunction with relations come in. I'm personally no fan of relations, since it's almost undoable for a newbie to edit relations. And in a lot of situations they are not necessary (like a standard motorway exit, in which a 1 lane motorway_link departs from a 2 lane motorway). Sometimes relations can't be avoided. I've written a text on obvious connectivity in conjunction with relations which you can find here: http://wiki.openstreetmap.org/wiki/User:It%27s_so_funny#Lane_connectivity Cheers, Johan 2014-08-29 21:16 GMT+02:00 Paul Johnson ba...@ursamundi.org: On Fri, Aug 29, 2014 at 12:26 PM, Kam, Kristen krist...@telenav.com wrote: For a while now, the status quo was to use the 'exit_to' tag on the node where the signpost would be (bifurcation points typically) when representing a signpost location and information. This tag is being deprecated (hence this wiki page). Using the destination tag on the ways (e.g., motorway_link) can provide one with the signpost information, but how would one easily identify the signpost? Are we going to use the 'destination%' tags in conjunction with the highway=motorway_junction tags on the nodes where the bifurcation point is? This isn't clear in the main article for 'Key:destination' Destinations are supposed to be relations, and the members are pretty clear. http://wiki.openstreetmap.org/wiki/Relation:destination_sign#Members For the sign itself, I pick the centroid of the sign location (which isn't necessarily linear to the other members, especially when the sign is not overhead!). The important (and only required) member is to. ___ 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] Unification of google-plus links
On 29.08.2014 20:09, Andreas Neumann wrote: I don't want to change the addr:-, website-, phone-, fax- or email-key!!! I never said it. But we have to look at these to decide whether it's better to move towards the contact namespace as a whole or move away from it. It makes little sense to move a couple keys toward contact: when the general trend is to avoid its use. In a similar discussion recently, I summed up the popularity of the keys with and without contact: prefix. As of the 25th of July, the taginfo numbers were: no contact prefix: 1033228 contact prefix: 154241 The contact-namespace associate, that the defined facebook- or googleplus-page are a medium to communicate with the defined object. I know a lot facebook-pages, who are created from fans or generated from a wikipedia-pages. That are mostly not a communication channel. There is no difference in meaning between contact:website and website, both do _not_ allow fan-made pages. This should make it obvious that the contact namespace does not imply a different meaning, it is simply a way of organizing keys. One that most mappers don't use. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Unification of google-plus links
I don't want to change the addr:-, website-, phone-, fax- or email-key!!! I never said it. As Tobias pointed out, we have to look at the bigger pucture. Why use contact: here, when it's not used by the majority anywhere else. The contact-namespace associate, that the defined facebook- or googleplus-page are a medium to communicate with the defined object. I know a lot facebook-pages, who are created from fans or generated from a wikipedia-pages. That are mostly not a communication channel. But those unofficial (fan) pages should not be linked anyway. It would always be the official page. In addition even a lot of those pages are not really used for communication, so that seems even more like a argument against contact:, especially as mappers are not going to first figure out which company replies on google+ and which doesn't. __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] key:destination Signpost question
On Fri, Aug 29, 2014 at 6:46 PM, Johan C osm...@gmail.com wrote: For motorways it's not necessary to know the location of the signposts, since every split is signposted (except for some very few exceptions maybe). There have been some rather notorious examples where this has not always been the case. There's a sign on Caltrans gantry 21300 that stood for eight years, until Caltrans finally stopped dragging ass about numbering exits for the first time and the sign was rebuilt, that an LA artist had added indicating that yes, you can indeed, get to I 5 North from CA 110 East on the left exit just after the tunnel. http://magazine.good.is/articles/the-fake-freeway-sign-that-became-a-real-public-service Similar situations exist with almost every bicycle route in Oregon that uses a freeway (ie, pretty much every freeway where the practice isn't banned, save for a token BIKES ON ROADWAY sign at the end of the ban and a BIKES MUST EXIT sign leading into a ban)...in most cases, there's nothing indicating where you should go to continue your route along that highway while you're not on the main roadway, but the designated bike route. You just have to know... ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] key:destination Signpost question
On Fri, Aug 29, 2014 at 6:55 PM, Tobias Knerr o...@tobias-knerr.de wrote: On 29.08.2014 21:16, Paul Johnson wrote: Destinations are supposed to be relations, and the members are pretty clear. http://wiki.openstreetmap.org/wiki/Relation:destination_sign#Members I believe Kristen was talking about Key:destination, which is what should replace exit_to. I honestly don't see how this fixes any problems exit_to had given that 1) I'd be surprised if there's not a major US city that doesn't have a bifurcated split of equal priority making two or more ramps in otherwise ambiguous directions, and 2) many large cities have left exits (Tulsa's interstate 244 has many on the eastside) and 3) there's even center exits. Westbound US 26 at OR 8 has OR 8 leaving the roadway from the number 3 lane, with lanes 1, 2 and 4(!) continuing through on 26, and a few miles east, US 26 East makes a hard right turn, where I 405 North and Market Street are a left and a center exit respectively... ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
