Re: [Tagging] Feature Proposal - Voting - nudism
*Voting starts today* and will *end on 19.07.2014* with hopefully many votes from all of you I think you mean 19.09.2014 ;-) 2014-09-02 7:03 GMT-03:00 Heiko Wöhrle m...@heikowoehrle.de: Hi everybody, i would like to bring the tag nudism to vote Several issues of the discussion have been included in the proposal page https://wiki.openstreetmap.org/wiki/Proposed_features/Nudism *Voting starts today* and will *end on 19.07.2014* with hopefully many votes from all of you Best regards, Heiko Am 30.08.2014 14:24, schrieb Richard Z.: On Tue, Aug 19, 2014 at 01:08:25AM +0200, Heiko Wöhrle wrote: Hi, added a table to the page, maybe this way it is easier to see which additional cases should be added. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging -- Heiko Wöhrle Lierstrasse 20 80639 München m 0176 56202550 ___ 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
Why use contact: here, when it's not used by the majority anywhere else. +1 2014-08-29 22:46 GMT-03:00 Andreas Goss andi...@t-online.de: 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 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Ablution area
amenity=religious_ablution or similar would be better indeed. 2014-08-31 10:19 GMT-03:00 Dave Swarthout daveswarth...@gmail.com: I don't know about that. I only wanted to point out that there are other usages of that word. The religious context is only one of several so there might be some disagreement on dedicating any future tags to that use. On Sun, Aug 31, 2014 at 2:23 PM, Stephan Knauss o...@stephans-server.de wrote: On 31.08.2014 01:24, André Pirard wrote: On 2014-08-30 10:55, Dave Swarthout wrote : FWIW, I traveled extensively in New Zealand a few years ago and there an ablution block (or ablution area) is a place in a campground where one washes things — dishes, clothing, etc. That definition of ablution is also a sort of purification, I reckon. In French, ablution means hygienic body washing. Misleading. Purification is a secondary meaning. I think the intended use is for use in a religious context. The tag should be in a way that it's not used for dish-washing and ritual purification the same time. Do you think the word is too generic? or the amenity key not suitable for it? Stephan ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging 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
Re: [Tagging] default value for oneway
For a street, there is no practical difference nowadays between no and unset, which is a smell for me. Either way means no. For the software? No, there isn't a difference. For the mapper? Yes, there is a difference. Since nowadays NULL for a street means oneway=no a change in the semantics would be still be possible as far as the database is concerned. If you go today to the database and update all oneway attributes for streets which are blank to no, the meaning of the database is equivalent. Theorically speaking, yes, you could add oneway=no to every street, and get a functionally equivalent database (from the software's POV). But, in practice, people most likely wouldn't agree with that (this change would be reverted). 2014-08-28 12:33 GMT-03:00 Xavier Noria f...@hashref.com: On Thu, Aug 28, 2014 at 5:21 PM, Simon Poole si...@poole.ch wrote: In any case there are roughly 45 million highway segments on which a oneway tag could make sense, vs. roughly 6 million oneway=yes and 1.5 million oneway=no. I suspect that it is really -far- too late to change the semantics of this specific attribute. Since nowadays NULL for a street means oneway=no a change in the semantics would be still be possible as far as the database is concerned. If you go today to the database and update all oneway attributes for streets which are blank to no, the meaning of the database is equivalent. Same for motorways, replace all NULLs with yes. Equivalent database. For a street, there is no practical difference nowadays between no and unset, which is a smell for me. Either way means no. I believe the default is useful for the UI, to preselect a value for example so that the user has to do nothing in the majority of street creations, less useful as a way to interpret NULLs because then you don't know what has been confirmed. ___ 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] Map Features template
The purpose of such templates was to have the same list in all languages. If someone introduces a new entry, it's spread in all local pages. It's probably not translated immediately but it is by far much better to see it in English than to have to maintain manually separated pages/tables. [..] I don't see this as a big advantage nowadays. People still have to maintain manually separated pages/tables (and more pages than without these templates). And as far as I can see, the wiki translation is _mainly_ done for the sake of people that can't read english, so an entry in english doesn't really help. Also, if the original description is updated, the translated versions keep the old version unless updated manually. Soon the wiki will enable a rich text editor plugin to make the wiki easier to use (and consequently invite more participation), so I want to ask people to avoid using this kind of template, because they make some pages harder to edit, without considerable advantages. I think it has a good purpose in pages like the main Map Features page, so I'm not asking to replace it (while we don't have a better solution). The tag pages came later and probably many of them are even not listed in the Map Features where we only show the most popular and commonly agreed tags. We can also sort and group them differently from a simple alphabetic order or key string. Not something we can program easily. This kind of page I suggested would only show the tags from a list, and not every tag. Ideally it would allow the users to either let the wiki automatically query the metadata from that tag's page, or let the user specify what to show (useful when there isn't a tag page for that right now). But personally I don't intend to solve the redundancy problem with the main Map Features page right now. I just want people to avoid this kind of Map Features Template on normal pages. Cheers, John 2014-08-27 5:22 GMT-03:00 Pieren pier...@gmail.com: On Tue, Aug 26, 2014 at 7:36 PM, John Packer john.pack...@gmail.com wrote: Some people like these templates because it seems they can make new tag values appear in non-english pages by adding them in the english page. But this new value appears in english, so in my opinion it kinda defeats the purpose of the non-english page... The purpose of such templates was to have the same list in all languages. If someone introduces a new entry, it's spread in all local pages. It's probably not translated immediately but it is by far much better to see it in English than to have to maintain manually separated pages/tables. We don't have enough active wiki contributors for such solution. The tag pages came later and probably many of them are even not listed in the Map Features where we only show the most popular and commonly agreed tags. We can also sort and group them differently from a simple alphabetic order or key string. Not something we can program easily. Pieren ___ 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] Religious landuse
Hi, How did this topic turn out in the end? The wiki page Tag:landuse=religious [1] was translated to yet another language (japanese), and this tag is getting more uses (most likely due to being included as a preset in JOSM[2]), so I assume it's becoming de facto I'm not against landuse=religious, but I'm not satisfied with it's current description: The area surrounding a amenity=place_of_worship used for religious purposes I believe a tag such as landuse=religious is inevitably going to be used as indicating any kind of religious activity, not necessarily with amenity=place_of_worship. Also, I believe amenity=place_of_worship is enough for indicating the religious area in most cases. Cheers, John [1]: http://wiki.openstreetmap.org/wiki/Tag%3Alanduse%3Dreligious [2]: http://josm.openstreetmap.de/ticket/10262 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Map Features template
I'm not sure that's the right mailing list for talking about this, but it's probably the closest Am I the only one that dislikes the Map Features templates on the wiki? (example: [1]) I think they make it harder to edit the wiki. People can find it hard to find out how to edit the template. Also, it uses this ugly and highly redundant syntax not used anywhere else. It should eventually become a relic of the past, and be changed for some kind of smart page that reads a list of tags classified into sections and queries the metadata from their tag pages (avoiding any duplication of information). I wasn't complaining because I am not willing to learn how to program the wiki to do that, but it seems lately there is a trend to create these templates and replace them on some pages. Some people like these templates because it seems they can make new tag values appear in non-english pages by adding them in the english page. But this new value appears in english, so in my opinion it kinda defeats the purpose of the non-english page... Cheers, John [1]: http://wiki.openstreetmap.org/wiki/Template:Map_Features:contact ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reproposal of tourism=aquarium
And I feel like most of the values would better fit with a key like amusement _ride= or amusement _ride:xxx=yes. Now that you mentioned I just remembered. There is a proposal that uses the key attraction=* for describring objects from theme parks, zoos, etc. See http://wiki.openstreetmap.org/wiki/Proposed_features/Key:attraction So apparently the key attraction=* is already used for something else. 2014-08-25 7:40 GMT-03:00 Andreas Goss andi...@t-online.de: +1, tourism=attraction is a poor scheme from the early days, maybe we should deprecate it all together, either without alternative or in favor of a flag like attraction=yes (or level0 - level 3 etc), or tourist_attraction=* I also just see it ending up in 2x tagging everything. leisure=waterpark tourism=attraction + attraction=waterpark; amenity=restaurant tourism=attraction + attraction=restaurant etc. And I feel like most of the values would better fit with a key like amusement _ride= or amusement _ride:xxx=yes. http://en.wikipedia.org/wiki/Amusement_ride I mean for example a kiddie_ride you find at a supermarket is not a (tourist) attraction. __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reproposal of tourism=aquarium
I don't agree with the tourism=attraction argument. Isn't a museum a touristic attraction too? At least as much as an aquarium. Yet we don't tag it as tourism=attraction + attraction=museum As long as it is documented on the wiki, it shouldn't be a problem for people making queries in OSM. 2014-08-24 13:10 GMT-03:00 Volker Schmidt vosc...@gmail.com: The two-tag solution is definitely better Volker On 24 August 2014 12:00, Fabrizio Carrai fabrizio.car...@gmail.com wrote: Hi Lorenzo, my personal opinion is for tourism=attraction + attraction=acquarium. My rationale comes from a potential utilization of the tag and tags combinations. If I wants to query for all and only acquariums, a query on attraction=acquarium will work. Viceversa, if we rise one step above and querying for tourism=attraction, the acquarium tagged as tourism=acquarium would not be reported, that is obviously not correct (the acquarium is a touristic attraction). Ciao FabC 2014-08-24 3:18 GMT+02:00 Lorenzo Mastrogiacomi lomastr...@gmail.com: I would like to submit a new request to vote for the tag tourism=aquarium. The proposal was first considered approved and then excluded due to lack of feedback. http://wiki.openstreetmap.org/wiki/Approved_features/Aquarium Actually exists a very poor permanent page but it is non connected at any other but the proposal. I found also a german page http://wiki.openstreetmap.org/wiki/Tag:tourism%3Daquarium http://wiki.openstreetmap.org/wiki/DE:Tag:tourism%3Daquarium tourism=aquarium is actually used 186 times. It was 187 but someone moved the one I had put in a simple tourism=attraction and this is why I am here :) Other similar taggings i found: tourism=attraction + attraction=aquarium. 6 times tourism=zoo + zoo=aquarium. 3 times tourism=attraction + aquarium=yes. 1 time tourism=zoo + aquarium=yes. 1 time Several aquarium=yes have been used also for pet shops Look forward for comments before updating the proposal page and sending the request Lorenzo ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging -- *Fabrizio* ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - RFC - nudism
Heiko, yes i would like to bring that to vote.It is an attempt to unify the tagging for this purpose. Ok, but it's not clear in the proposal what you are trying to do. Do you want to deprecate the key naturism=* in favor of nudism=*? Do you want to use both of them? (in this case, please explain the differences more clearly As other mentioned, the default value of the key nudism=* would change depending on the region, therefore it would be advisable for this key to have no default value (unknown), as is common for most tags. 2014-08-19 3:44 GMT-03:00 Heiko Wöhrle m...@heikowoehrle.de: Hi John, yes i would like to bring that to vote.It is an attempt to unify the tagging for this purpose. I just changed the status to proposed and set a voting date. Best regards, Heiko Am 19.08.2014 01:18, schrieb John Packer: Heiko, You added the key naturism=* to the proposal. Is this also being voted on, or is the proposal just mentioning there are some uses of this other key ? 2014-08-18 20:08 GMT-03:00 Heiko Wöhrle m...@heikowoehrle.de: Hi everybody, i'd like to readdress an old draft from Xan, that has never been voted but is nevertheless in use. Please feel free to comment the slightly changed proposal: https://wiki.openstreetmap.org/wiki/Proposed_features/Nudism Best regards, Heiko ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging -- Heiko Wöhrle Lierstrasse 20 80639 München m 0176 56202550 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Wayside shrines that are not historic
Mateusz, You should use historic=wayside_shrine for wayside shrines, regardless of whether they are historic or not. Just like the tag amenity=place_of_worship is used even on grounds of gnostic or atheist religions. Cheers, John 2014-08-19 12:52 GMT-03:00 Mateusz Konieczny matkoni...@gmail.com: 2014-08-19 17:23 GMT+02:00 Tom Pfeifer t.pfei...@computer.org: Mateusz Konieczny wrote, on 2014-08-19 16:45: How one should tag wayside shrine that is not historic? http://wiki.openstreetmap.org/wiki/Wayside_shrine is not providing an answer. That question was asked 2010 already on the discussion page. I agree that 'historic' is ambiguous in the first place, since it does not specify if historic means old vs. recently built, or out of use vs. still being used. Secondly, they are certainly being used for acts of worshipping, historic or not, e.g. when sitting in a bus in Greece I see people worshipping even when the vehicle just passes by. Thus combining amenity=place_of_worship with the appropriate building tag building=wayside_[shrine|cross] appears plausible. Is is important here to give the renderer a clue at which zoom level to draw it, since amenity=place_of_worship is currently heavily used for buildings of significant size such as churches/temples/mosques (376000 as nodes and 232000 as ways, only 33% having a building tag). This would also emphasise to limit the use of amenity=place_of_worship to the actual place that is used for the worshipping, i.e. the weekly/daily congregation, and the individual praying; and not for larger areas/campuses around such places, where I prefer landuse=religious ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging As there is currently no clear tag, I would suggest man_made=wayside_shrine ___ 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] Synonymous values in the shop key
I'm not sure what is a gelateria. Couldn't this be tagged simply with amenity=cafe + cuisine=ice_cream ? 2014-08-18 8:23 GMT-03:00 Simone Saviolo simone.savi...@gmail.com: 2014-08-14 10:40 GMT+02:00 Frederik Ramm frede...@remote.org: Hi, On 08/14/2014 08:09 AM, Mateusz Konieczny wrote: shop=ice_cream (710, documented but difference between using amenity and shop keys is not documented) - amenity=ice_cream (4053) amenity=ice_cream sounds very strange to me. I can't imagine a lot of people actually coming up with that themselves - can it be a mass edit or an editor preset gone wrong? I mean, the amenity consists not in there being ice cream, but there being a place where you can get ice cream. That would like tagging amenity=bed for a hotel or amenity=food for a restaurant... Not really. A gelateria is a very different thing from a bar, and it's not a shop that sells ice cream. At most you could use ice cream parlour, but amenity=ice_cream_parlour seems worse to me than the current tag. Ciao, Simone ___ 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] Commons: mixed purposes
Perhaps such a category should only be tagged exactly when it's not linked on a wikidata page. Otherwise it seems unnecessary. As Andreas mentioned, if people can add this tag even when it's linked on the wikidata page, eventually people will start adding wikiquote=* wikivoyage=* and so on. Indeed, in most cases wikipedia=* can be redundant when there is already a wikidata=* key, but wikipedia=* is a well-established key, which is not the case of wikimedia_commons=* In other words, don't need to fix what ain't broken. 2014-08-18 3:20 GMT-03:00 Mateusz Konieczny matkoni...@gmail.com: 2014-08-17 20:45 GMT+02:00 Eugene Alvin Villar sea...@gmail.com: On Sun, Aug 17, 2014 at 7:45 PM, Andy Mabbett a...@pigsonthewing.org.uk wrote: What should we sue to link to Wikimedia commons categories like: https://commons.wikimedia.org/wiki/Category:St_Paul,_Birmingham I've previously used Wikimedia_Commons=, but that's verbose; and I seem to be alone in doing so. Wouldn't linking using the wikidata=* tag be better as the Wikidata entry for St Paul's Church in Birmingham should link to the appropriate page or category on Wikimedia Commons? So I would tag the OSM object representing St Paul's Church as wikidata=Q915614 Some minor objects may have category/image on Wikimedia Commons but have no wikidata and never will have - see https://www.wikidata.org/wiki/Wikidata:Notability ___ 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] separator for addr:housenumber=*
I believe comma is used instead of semi-colon because the key addr:housenumber frequently gets rendered, and comma is the common separator symbol for end users. 2014-08-18 11:04 GMT-03:00 fly lowfligh...@googlemail.com: Hey On the English wiki page [1] comma is the proposed separator for several values of addr:housenumber. This contradicts our rule of using semi-colon as separator of values and I do not have a clue why. I propose to deprecate comma and use semi-colon instead to harmonize our data structure and allow QA software to find problematic values. What do you think ? Cheers fly [1] https://wiki.openstreetmap.org/wiki/Addresses#Buildings_with_multiple_house_numbers ___ 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] Commons: mixed purposes
Some automatically evaluations to find tags with low numbers under main name space would be useful, as I find these kind of page quite often and it would ease administration. I think that's the closest to what you want: http://taginfo.openstreetmap.org/taginfo/apidoc#api_4_keys_all 2014-08-18 9:43 GMT-03:00 fly lowfligh...@googlemail.com: Am 18.08.2014 10:15, schrieb Mateusz Konieczny: 2014-08-18 9:25 GMT+02:00 Martin Koppenhoefer dieterdre...@gmail.com mailto:dieterdre...@gmail.com: Il giorno 18/ago/2014, alle ore 00:44, Andy Mabbett a...@pigsonthewing.org.uk mailto:a...@pigsonthewing.org.uk ha scritto: OK, how's this : http://wiki.openstreetmap.org/wiki/Key:wikimedia_commons as a start? +1, but could have been in the proposal address space, given that it is not in use... +1, and now it is in use. Come one, some few uses are no argument for an established tag in common use. Please, move it under the proposal name space. Some automatically evaluations to find tags with low numbers under main name space would be useful, as I find these kind of page quite often and it would ease administration. cu fly ___ 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] Commons: mixed purposes
Andy, Usually there is no problem in creating a page documented the key or tag you want to use. I don't think this case is an exception. The only thing is that a key/tag documented without a proposal is more likely to have a future merge/redefinition/deprecation/etc. 2014-08-18 18:57 GMT-03:00 Andy Mabbett a...@pigsonthewing.org.uk: On 18 August 2014 13:43, fly lowfligh...@googlemail.com wrote: Please, move it under the proposal name space. To what end? Is there a counter proposal that means this might not be used? Is there significant opposition, that means this might not be used? Or is this just needless bureaucracy? -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk ___ 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] Commons: mixed purposes
For example, I consider it problematic to duplicate the functionality of the image key by allowing links to individual images. And I guess there will be different opinions whether a wikidata link should always replace commons links or whether they should coexist. +1 2014-08-18 19:38 GMT-03:00 Tobias Knerr o...@tobias-knerr.de: On 18.08.2014 23:57, Andy Mabbett wrote: Is there significant opposition, that means this might not be used? The key itself is probably relatively uncontroversial, but the details need some discussion. For example, I consider it problematic to duplicate the functionality of the image key by allowing links to individual images. And I guess there will be different opinions whether a wikidata link should always replace commons links or whether they should coexist. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - RFC - nudism
Heiko, You added the key naturism=* to the proposal. Is this also being voted on, or is the proposal just mentioning there are some uses of this other key ? 2014-08-18 20:08 GMT-03:00 Heiko Wöhrle m...@heikowoehrle.de: Hi everybody, i'd like to readdress an old draft from Xan, that has never been voted but is nevertheless in use. Please feel free to comment the slightly changed proposal: https://wiki.openstreetmap.org/wiki/Proposed_features/Nudism Best regards, Heiko ___ 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] RENDER
- way: addr:housenumber=1; my_tag=nothing_known_elsewhere; render=pink - way: addr:housenumber=2; other_tag=known_only_by_me; render=yellow - way: addr:housebumber=3; my_private_tag=dont_use_it; render=violet - way: addr:housebumber=4; unique_tag=only_taginfo_knows_me; render=green Heck, we would be lucky if people were to add other tags besides render=* and maybe name=* 2014-08-15 12:05 GMT-03:00 Vincent Pottier vpott...@gmail.com: What a nice map we would get : - way: addr:housenumber=1; my_tag=nothing_known_elsewhere; render=pink - way: addr:housenumber=2; other_tag=known_only_by_me; render=yellow - way: addr:housebumber=3; my_private_tag=dont_use_it; render=violet - way: addr:housebumber=4; unique_tag=only_taginfo_knows_me; render=green - ... This map already exists : http://2.bp.blogspot.com/-1EYAKZQ31ck/T0iWNbp34wI/BIs/oBJMF_ViWFM/s1600/smarties.jpg -- FrViPofm Le 15/08/2014 16:12, André Pirard a écrit : Hi, It's a well known fact that many people complain to tag in vain because what they tag doesn't show on the map (e.g. mini-golf vs tennis pitch), because they're told to open a rendering ticket which replies that only official tags are supported, and because they open a vote for an official tag and nobody signs. As a result they are accused of tagging for the renderer instead of 'being forced to tag for the renderer. The solution is simple however. A RENDER tag that, typically, would assign a color to an area. I'll let the rendering specialists define what else it can do. ⚠ ⚠ ⚠ RENDER only requests *by default* rendering. As soon as rendering is defined for an element, it is used instead and RENDER is normally ignored. For a better map, André. ___ Tagging mailing listTagging@openstreetmap.orghttps://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] Mapping cave tunnels passable by human
One question. How would people map a cave? As far as I know, GPSes don't really work underground, and obviously there is no sattelite imagery for them. I imagine that's why there is no scheme right now. 2014-08-14 8:22 GMT-03:00 André Pirard a.pirard.pa...@gmail.com: On 2014-08-14 12:31, Martin Vonwald wrote : 2014-08-14 12:25 GMT+02:00 André Pirard a.pirard.pa...@gmail.com: On 2014-08-14 11:08, Janko Mihelić wrote : Well first, tunnel=yes is obviously wrong. We need to replace this with cave=yes. Other than that, I have no problems with this. If a cave has two cave entrances, then information that they are connected by footpaths is valuable information. Obviously? Regarding paths and waterways, especially ones fitted up for tourism, I wonder... Maybe not completely obvious, but I would agree with Janko. In my opinion, a tunnel is man-made, while a cave is not. tunnel is an attribute of an object called highway, including the paths in question. cave:NNN=* are attributes of objects natural http://wiki.openstreetmap.org/wiki/Key:natural=cave_entrance http://wiki.openstreetmap.org/wiki/Tag:natural%3Dcave_entrance, obviously speleology and not path oriented. cave=* is not defined. I know I still have to learn that OSM is fuzzy, but using cave=yes for paths would first need a definition of it in the highway=* page. This said, we could wait for years for a rendering of cave=yes, let alone routing support. Rendering and routing don't care if it's man-made or not. They just work or don't. Why not use the well established tunnel=yes and layer=-n? And cope with the subjective, cultural, etc. strangeness with an adorning cave or whatever made up tag? André. ___ 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] Mapping cave tunnels passable by human
Forget routing in caves. There's no GPS. And those who get lost without routing apps will get lost in a cave anyway. +1 2014-08-14 12:32 GMT-03:00 Friedrich Volkmann b...@volki.at: On 14.08.2014 13:18, Dan S wrote: I think that it is an obvious idea, but wiki claimed that At the moment there just a tag to map the entrance to a cave. despite fact that existing tags fit well. No, they do not fit. Caves are complex three-dimenional structures. In most caves there are no paths. You go or climb or rope down whereever you feel like. This is the same as with a pedestrian square - there's no specific route in the square and you go wherever you feel. However it's useful to make them part of the OSM database, both for showing their existence and to help with various routing applications. Pedestrian squares are 2-dimensional. Caves are 3-dimensional. Many cave rooms overlap themselves a couple of times in the z-axis. Forget routing in caves. There's no GPS. And those who get lost without routing apps will get lost in a cave anyway. I'm afraid layer=-1 does not express that a feature is underground. It expresses that a feature is lower than all features at layer=0+, but there's no guaranteed relationship with ground level. In central Europe it is, but habits may vary around the word. Much chaos these days... In my opinion, there is some misconception by people who are used to image editing software such as Photoshop, Adobe illustrator, Gimp, Corel Draw, Inkscape, etc., as well as CAD software. In all of these applications, layers stand for rendering order. In OSM we need to think in physical layers. Caves are just an example. There are many more underground objects which are not tunnels. E.g. I used to go to school over a landfill for 8 years without knowing, because it was covered with soil and grass. The only way for renderers to know is by eveluating the layer tag. Of course you could set some additional tag like underground=yes, but having two concurrent tags for the same thing is just a mess. You'll soon get a lot of inconsistencies. There are quite a few objects with the implicit layer=0 but which are not at ground level (e.g. tunnel=culvert items: http://overpass-turbo.eu/s/4zE). Therefore we need to tag them all with layer0. There was a proposal for implicit default layer=1 for bridges and -1 for tunnels, but unfortunately it was voted down, so we are damned to set it manually every time. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] bridge movable vs swing vs swinging
Just noticed that some mappers resort to adding building=yes or similar to make it render at all. Note that bridges that are buildings actually exist. [1] But adding building=* to a bridge when it's not the case would be tagging (incorrectly) for the renderer. [1]: http://wiki.openstreetmap.org/wiki/Tag:building%3Dbridge 2014-08-13 9:09 GMT-03:00 Richard Z. ricoz@gmail.com: On Wed, Aug 13, 2014 at 09:12:07AM +0200, Martin Vonwald wrote: Hi! 2014-08-12 22:57 GMT+02:00 Richard Z. ricoz@gmail.com: what else can I do? Maybe it's time to open up a change request for the main map style? The tag man_made=bridge seems to be used worldwide [1] in some - more or less - consistent way. It provides useful data, is simple to tag, it should be easy to render and it solves some ugly rendering issue. yes I think it is about time that man_made=bridge is rendered. Is there a place where someone could take the main style, change it and see the difference in rendering? So we could not only open a ticket but also provide a patch. have no idea. Just noticed that some mappers resort to adding building=yes or similar to make it render at all. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Bitcoin: Distinction of purchase through website and cash register/Point of sale
I think it should be website:payment:bitcoin=yes instead of payment:website:bitcoin=yes 2014-08-13 9:20 GMT-03:00 Janko Mihelić jan...@gmail.com: I'm ok with that. A shop that has online Bitcoin paying: shop=computer + payment:website:bitcoin=yes + website=http://www.shop.com An office of a website without a cash register: office=e-commerce + e-commerce=computer + payment:website:bitcoin=yes + website=http://www.shop.com A shop with Bitcoin payment at the point of sale: shop=computer + payment:bitcoin=yes I think this is an ok scheme. 2014-08-13 13:57 GMT+02:00 Anita Andersson cc0c...@gmx.com: Janko Mihelić wrote: If you are going to tag online payment methods (and I'm not 100% sure that's ok for this database) then I would use payment:online:bitcoin=yes instead of payment:bitcoin=yes. Payment:xxx=* is a tag reserved for offline payment methods, so you can look at it as though it already has the offline tag. One idea that came up at the CoinMap thread was payment:website:bitcoin=yes After that payment is made you pick up the goods at a location. If that location is a normal store where you get to the cash registers/Points of sale like everybody else does to get their products for whatever currency they chose to pay with then I think that place should be tagged with payment:website:bitcoin=yes The payment goes through the website, then I get my products at the company's cash registers/Points of sale.(as mentioned above, like everybody else does) What do you all think about payment:website:bitcoin=yes? That payment is then tied to the shop's physical store/stores in contrast to stores where the payment is not tied to any location at all(in case of delivery=only) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] bridge movable vs swing vs swinging
Richard, Perhaps these cases in which the outline of the bridge was drawn is related to this proposal: http://wiki.openstreetmap.org/wiki/Proposed_features/man_made%3Dbridge I believe it's main purpose is to solve a known rendering problem in bridges. Nowadays, when two or more parallel ways are in a bridge/viaduct, they are drawn as separate bridges. Drawing the area of the bridge would solve that. Cheers, John 2014-08-12 6:26 GMT-03:00 Richard Z. ricoz@gmail.com: On Tue, Aug 12, 2014 at 12:23:35AM -0400, Christopher Hoess wrote: On Mon, Aug 11, 2014 at 7:57 PM, SomeoneElse li...@mail.atownsend.org.uk wrote: For the benefit of anyone looking at taginfo stats in this thread, it's worth mentioning that there's some non-survey-based editing going on: http://www.openstreetmap.org/changeset/24690099 All bridge=drawbridge to bridge=movable bridge:movable=drawbridge. The bigger problem is that many of these bridges, whether originally tagged by local surveyors or not, are probably strictly speaking bascule bridges, drawbridge being used casually for any sort of movable bridge. it was a test to see what can go wrong during such conversion. There were quite some odd cases, like bridge=drawbridge used to draw the outline of the bridge. Some time in the future I would like to review all bridge=swing and fix at least those which are not movable at all but hanging rope bridges instead. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] bridge movable vs swing vs swinging
PS: If you removed these 'bridges as area', you probably should fix that. 2014-08-12 9:02 GMT-03:00 John Packer john.pack...@gmail.com: Richard, Perhaps these cases in which the outline of the bridge was drawn is related to this proposal: http://wiki.openstreetmap.org/wiki/Proposed_features/man_made%3Dbridge I believe it's main purpose is to solve a known rendering problem in bridges. Nowadays, when two or more parallel ways are in a bridge/viaduct, they are drawn as separate bridges. Drawing the area of the bridge would solve that. Cheers, John 2014-08-12 6:26 GMT-03:00 Richard Z. ricoz@gmail.com: On Tue, Aug 12, 2014 at 12:23:35AM -0400, Christopher Hoess wrote: On Mon, Aug 11, 2014 at 7:57 PM, SomeoneElse li...@mail.atownsend.org.uk wrote: For the benefit of anyone looking at taginfo stats in this thread, it's worth mentioning that there's some non-survey-based editing going on: http://www.openstreetmap.org/changeset/24690099 All bridge=drawbridge to bridge=movable bridge:movable=drawbridge. The bigger problem is that many of these bridges, whether originally tagged by local surveyors or not, are probably strictly speaking bascule bridges, drawbridge being used casually for any sort of movable bridge. it was a test to see what can go wrong during such conversion. There were quite some odd cases, like bridge=drawbridge used to draw the outline of the bridge. Some time in the future I would like to review all bridge=swing and fix at least those which are not movable at all but hanging rope bridges instead. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Synonymous values in the shop key
I think a place should be tagged amenity=fast_food depending on the structure of the place. From the description on the wiki page: Is for a place concentrating on very fast counter-only service and take-away food. It might have tables for seating. Someone on the Talk page suggested used the undocumented key seating=* to indicate whether there are seats available, which seems to have a good number of uses. We could start a separate thread if needed, but personally I don't think this needs to be solved right now. I documented the current state of affairs in the wiki[1], so we don't have to rediscuss everything later. [1]: http://wiki.openstreetmap.org/w/index.php?title=Tag:amenity%3Dice_creamdiff=1068150oldid=969545 2014-07-30 21:50 GMT-03:00 Martin Koppenhoefer dieterdre...@gmail.com: Am 31/lug/2014 um 02:13 schrieb John Packer john.pack...@gmail.com: As far as I can see, you could easily use amenity=fast_food with cuisine=ice_cream instead of amenity=ice_cream or shop=ice_cream I believe we are talking about different places. FWIW, I am Not proposing to retag or warn from fast food with cuisine=ice_cream cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Synonymous values in the shop key
I think you shouldn't merge the *=ice_cream variantes. People never reached a consensus over which one to use (personally I think it's compelling to use shop=* instead of amenity=*), and there is another variant, which is amenity=cafe/fast_food/restaurant with cuisine=ice_cream, and is used even more than amenity=ice_cream. 2014-07-30 15:42 GMT-03:00 Mateusz Konieczny matkoni...@gmail.com: To summarize: shop=fish, shop=fishmonger and shop=seafood are not synonyms as fish may also apply to pet fish and seafood is not covering freshwater fish shop=winery, shop=wine (shop=wine is a wine seller, where shop=winery is a winer maker selling his own production) shop=delicatessen, shop=deli I am not understanding difference but there is some There were no objections to following changes: shop=jewellery (139) - shop=jewelry (13299, documented) shop=bags (201) - shop=bag (409, documented) shop=antique (110) - shop=antiques (1394, documented) shop=pets (162) - shop=pet (5393, documented) shop=pharmacy (1591) - amenity=pharmacy (115759, documented) shop=ice_cream (710, documented but difference between using amenity and shop keys is not documented) - amenity=ice_cream (4053) 2014-07-19 0:42 GMT+02:00 Andreas Goss andi...@t-online.de: Am 7/16/14 23:32 , schrieb Bryan Housel: Oddly we have the mostly standard `craft=brewery`: http://wiki.openstreetmap.org/wiki/Tag:craft%3Dbrewery … but winery tagging is fragmented. It was probably created before the craft key got much usage. I think there should be shop=wine and craft=winery. If you have a winery that sells wine then that should just be an additional key indicating that (Is there actually a global key for that? Seems somthing that you could apply for a lot of different POIs) __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Synonymous values in the shop key
I use them like this amenity=cafe cuisine=ice_cream there is a waiter / service amenity=ice_cream they sell take away ice cream, but also have at least some tables to sit down (no service) shop=ice_cream you can only buy ice cream (no seats) This seems a little inconsistent. As far as I can see, you could easily use amenity=fast_food with cuisine=ice_cream instead of amenity=ice_cream or shop=ice_cream (in the cases mentioned). Whether the place have seating or not could be tagged separetely. 2014-07-30 20:45 GMT-03:00 Martin Koppenhoefer dieterdre...@gmail.com: Am 30/lug/2014 um 20:42 schrieb Mateusz Konieczny matkoni...@gmail.com : There were no objections to following changes: shop=jewellery (139) - shop=jewelry (13299, documented) yes there were, this should be BE spelling shop=bags (201) - shop=bag (409, documented) shop=antique (110) - shop=antiques (1394, documented) shop=pets (162) - shop=pet (5393, documented) wouldn't it be nice to have either all singular or all plural? shop=pharmacy (1591) - amenity=pharmacy (115759, documented) I don't know shop=pharmacy but Id have a look and ask a few of the mappers shop=ice_cream (710, documented but difference between using amenity and shop keys is not documented) - amenity=ice_cream (4053) I use them like this amenity=cafe cuisine=ice_cream there is a waiter / service amenity=ice_cream they sell take away ice cream, but also have at least some tables to sit down (no service) shop=ice_cream you can only buy ice cream (no seats) cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Religious landuse?
I don't know how common this practice is, but sometimes I see things like landuse=commercial and landuse=residential applied to a relatively large area. 2014-07-25 13:38 GMT-03:00 Martin Koppenhoefer dieterdre...@gmail.com: 2014-07-25 3:33 GMT+02:00 johnw jo...@mac.com: But for a majority of the buildings I'm mapping here in rural/suburban Japan, there isn't as much mixed use or repurposed use as you would imagine - most homes are purpose-built 2 story, single family detached homes with a wall around them. It is very easy to designate their use. yes, this is simple. You draw one, tag it and copy paste to bigger configurations and then cp all over the place ;-) ..., a cemetery, a buddhist temple, a 7-11, and ~10 detached homes. this is all within around 300m of my house in rural Japan. but every one of those has an easily defined border associated with the buildings - and an easily understood landuse tag to go with them. 500m away is an elementary school, with no landuse value. it depends on amenity=school for **some unknown reason** to define it's landuse. Until recently, the temple also had no landuse value to define the area the temple grounds occupy, but now landuse=religious exists. Maybe those landuse values haven't been proposed so far because the main mapnik map didn't need them, the style painted these amenity areas already ;-) e.g. amenity=school/university implies landuse=education. In case of religious things you will also have a religion attribute. You could of course add additional landuse tags, but how would that bring a benefit? The civic landuse sounds more interesting, because the list of possible building types and users can be quite long and there is no religion-like common attribute (or is it?). Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Aerodrome types
It is kind of a proposal, but it isn't in the sense that I don't want to be
responsible for it.
I know little beyond the basics of aerodrome, and currently do not have the
interest of researching this much further.
If anyone thinks this should be a proposal, and know enough about
aerodromes to do so, feel free to make one.
I want this issue to progress to the point of having at least the basics
well-defined, that's why I'm pushing it by editing the wiki.
Note that I'm doing so while making the wiki page look clearly draft-y
and marked as a {{Stub}}, so others feel invited to edit it or add comments.
2014-07-24 5:38 GMT-03:00 Martin Koppenhoefer dieterdre...@gmail.com:
Am 23/lug/2014 um 21:43 schrieb Christian Quest cqu...@openstreetmap.fr:
Have you looked at taginfo ?
http://taginfo.openstreetmap.org/keys/?key=aerodrome#overview
aerodrome=international is already in use, it is even the first in
quantity (157)
+1, I think the wiki page should become a proposal and current usage
should be reflected (if there are some values that are in use but currently
discouraged this should also be mentioned for example)
cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Aerodrome types
Martin, Sorry, I should have talked a little about the history behind this before. Initially aeroway=aerodrome used the key type=* to further classify it's type. Nowadays, the key type=* is infamous because it is the de facto way of especifying relation's types, and therefore shouldn't be used for anything else. Consequently, people started moving away from using type=* to using either aerodrome:type=* or aerodrome=*. But type=* it still used much more than both aerodrome=* and aerodrome:type=* together. Probably it was used on earlier imports of airport data. Below you can see values of the key type=* when used together with aeroway=aerodrome around the globe: public: 2349 multipolygon: 284 military: 281 civil: 232 private: 173 military/public: 68 public;military: 38 non-public: 37 destination_sign: 30 joint (civil and military): 25 civil / military: 22 joint: 13 public/military: 13 civilian: 10 public / military: 10 airstrip: 8 To make this list shorter, I removed from this list all values that appeared less than 6 times, and merged the values when all that changed was some letter's case or white. I am working on the key's aerodrome in the hope it can substitute the key type=* on classifying an aerodrome, because it conflicts with relations like multipolygon (as shown above). I will also include this information in the wiki page Key:aerodrome 2014-07-24 11:23 GMT-03:00 Martin Koppenhoefer dieterdre...@gmail.com: 2014-07-24 14:11 GMT+02:00 John Packer john.pack...@gmail.com: If anyone thinks this should be a proposal, and know enough about aerodromes to do so, feel free to make one. thing is that right now it looks as if this was state of the art, i.e. an established scheme, what it surely isn't, also compared to actually used values for this key. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Aerodrome types
I updated the wiki page Key:aerodrome[1]. One of the issues that are still not decided is how to tag international airports. Should we use international_flights=yes ? Or could we use something like flights_range=international/domestic/regional ? [1]: http://wiki.openstreetmap.org/wiki/Key:aerodrome 2014-07-08 16:07 GMT-03:00 John Packer john.pack...@gmail.com: There already exists a key military=*. Now that I took a better look, it seems that there already is a key for aerodromes exclusively used in military operations: military=airfield http://wiki.openstreetmap.org/wiki/Key:military. The questions remains as to how to mark an aerodrome that is not used exclusively in military operations (e.g. a public use airport with a militar base). 2014-07-06 19:29 GMT-03:00 Richard Welty rwe...@averillpark.net: On 7/6/14 3:41 PM, Fernando Trebien wrote: How about using aerodrome=* to express how the aerodrome is used by civilians and then add military=yes when the airport is also used for military operations? you could potentially broaden it a bit, with military=yes being the generic i have no more data tag: military=reserve military=nationalguard military=militia military=air_force military=army military=navy (in the US national guard is not automatically redundant with militia; NY state for example has militia units that are distinct from the guard units.) richard -- rwe...@averillpark.net Averill Park Networking - GIS IT Consulting OpenStreetMap - PostgreSQL - Linux Java - Web Applications - Search ___ 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] Kindergarten, Childcare and Preschool
Christian, We added a school:FR=* tag to match all our classifications (maternelle, élémentaire, collège, lycée). As we have schools were these levels are mixed we also have primaire which equals to maternelle+élémentaire and secondaire equals to collège+lycée). I think this is nice, and I was thinking for a while to do something like this in Brazil. Nice to see school:FR=* is even documented. I think this kind of thing should be encoraged in other countries. Following this pattern of school:Uppercase Country Code=*, and with some extensive discussion of the community seems to be the way to go. The key isced:level=* is also nice, but it would probably be easy to convert school:XY=* to isced:level=* (if made by that country's mappers). 2014-07-23 16:57 GMT-03:00 Christian Quest cqu...@openstreetmap.fr: For info, the french wikipedia school page has a nice summary table (missing in the english page): https://fr.wikipedia.org/wiki/%C3%89cole In France we decided to use amenity=school where school becomes mandatory (age of 6). Before that amenity=kindergarten We added a school:FR=* tag to match all our classifications (maternelle, élémentaire, collège, lycée). As we have schools were these levels are mixed we also have primaire which equals to maternelle+élémentaire and secondaire equals to collège+lycée). -- Christian Quest - OpenStreetMap France ___ 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] Aerodrome types
I'm aware of aerodrome=international. To be honest I'm not too against it The issue with it is that AFAIK international doesn't imply public use, which can be an important information. I'm not sure I know what aerodrome=airfield means. Could you explain? Something like aerodrome=airport can be ambiguous, as mentioned in the beginning of this thread. 2014-07-23 16:43 GMT-03:00 Christian Quest cqu...@openstreetmap.fr: Have you looked at taginfo ? http://taginfo.openstreetmap.org/keys/?key=aerodrome#overview aerodrome=international is already in use, it is even the first in quantity (157) FYI, the OSM-FR rendering is using it, as well as aerodrome=airport/airport/continental/military/airfied 2014-07-23 19:56 GMT+02:00 John Packer john.pack...@gmail.com: I updated the wiki page Key:aerodrome[1]. One of the issues that are still not decided is how to tag international airports. Should we use international_flights=yes ? Or could we use something like flights_range=international/domestic/regional ? [1]: http://wiki.openstreetmap.org/wiki/Key:aerodrome 2014-07-08 16:07 GMT-03:00 John Packer john.pack...@gmail.com: There already exists a key military=*. Now that I took a better look, it seems that there already is a key for aerodromes exclusively used in military operations: military=airfield http://wiki.openstreetmap.org/wiki/Key:military. The questions remains as to how to mark an aerodrome that is not used exclusively in military operations (e.g. a public use airport with a militar base). 2014-07-06 19:29 GMT-03:00 Richard Welty rwe...@averillpark.net: On 7/6/14 3:41 PM, Fernando Trebien wrote: How about using aerodrome=* to express how the aerodrome is used by civilians and then add military=yes when the airport is also used for military operations? you could potentially broaden it a bit, with military=yes being the generic i have no more data tag: military=reserve military=nationalguard military=militia military=air_force military=army military=navy (in the US national guard is not automatically redundant with militia; NY state for example has militia units that are distinct from the guard units.) richard -- rwe...@averillpark.net Averill Park Networking - GIS IT Consulting OpenStreetMap - PostgreSQL - Linux Java - Web Applications - Search ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging -- Christian Quest - OpenStreetMap France ___ 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] Kindergarten, Childcare and Preschool
Since amenity=childcare is already present in the iD editor presets, I went
ahead and compared the translations of these presets on most locales. To
me, they verify that amenity=childcare is indeed different than
amenity=kindergarten.
I'm attaching them to this message.
I have to say that I removed the translations of locales that didn't have
*both* translations.
Here in Brazil, it would be similar to France, a school-like place that
kids can go before mandatory school begins is a kindergarten (usually a
Centro de Educação Infantil or Jardim de Infância), while pretty much
everything else would be amenity=childcare.
There might be some places that fall into a gray area, but I don't think
they are a show-stopper
2014-07-23 17:49 GMT-03:00 John Packer john.pack...@gmail.com:
Christian,
We added a school:FR=* tag to match all our classifications (maternelle,
élémentaire, collège, lycée). As we have schools were these levels are
mixed we also have primaire which equals to maternelle+élémentaire and
secondaire equals to collège+lycée).
I think this is nice, and I was thinking for a while to do something like
this in Brazil.
Nice to see school:FR=* is even documented.
I think this kind of thing should be encoraged in other countries.
Following this pattern of school:Uppercase Country Code=*, and with some
extensive discussion of the community seems to be the way to go.
The key isced:level=* is also nice, but it would probably be easy to
convert school:XY=* to isced:level=* (if made by that country's mappers).
2014-07-23 16:57 GMT-03:00 Christian Quest cqu...@openstreetmap.fr:
For info, the french wikipedia school page has a nice summary table
(missing in the english page): https://fr.wikipedia.org/wiki/%C3%89cole
In France we decided to use amenity=school where school becomes mandatory
(age of 6).
Before that amenity=kindergarten
We added a school:FR=* tag to match all our classifications (maternelle,
élémentaire, collège, lycée). As we have schools were these levels are
mixed we also have primaire which equals to maternelle+élémentaire and
secondaire equals to collège+lycée).
--
Christian Quest - OpenStreetMap France
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
ca.json:amenity/kindergarten: {
ca.json-name: Terrenys de Jardí d'infància,
ca.json-terms: Parc infantil
--
cs.json:amenity/kindergarten: {
cs.json-name: Dětské Hriště
cs.json-},
--
da.json:amenity/kindergarten: {
da.json-name: Børnehaveområde,
da.json-terms: Børnehaveområde
--
de.json:amenity/kindergarten: {
de.json-name: Kindergartengelände,
de.json-terms: Kindergarten, Spielplatz, Sandkasten
--
en.json:amenity/kindergarten: {
en.json-name: Kindergarten Grounds,
en.json-terms: nursery,preschool
--
es.json:amenity/kindergarten: {
es.json-name: Jardín de infancia,
es.json-terms: preescolar, parvulario, guardería, kinder,
educación infantil, educación inicial
--
fa.json:amenity/kindergarten: {
fa.json-name: محیط کودکستان
fa.json-},
--
fi.json:amenity/kindergarten: {
fi.json-name: Päiväkotialue,
fi.json-terms: päiväkoti, piha, ulkoilualue, lastentarha
--
fr.json:amenity/kindergarten: {
fr.json-name: Espace de jeux pour enfants
fr.json-},
--
hr.json:amenity/kindergarten: {
hr.json-name: Teren oko vrtića,
hr.json-terms: vrtić, jaslice, dječji vrtić
--
hu.json:amenity/kindergarten: {
hu.json-name: Óvoda
hu.json-},
--
is.json:amenity/kindergarten: {
is.json-name: Leikskólalóð
is.json-},
--
it.json:amenity/kindergarten: {
it.json-name: Area della Scuola dell'infanzia,
it.json-terms: scuola d'infanzia,scuola di
infanzia,asilo,assistenza all'infanzia,asilo d'infanzia,scuola materna,scuola
dell'infanzia,asilo nido
--
ja.json:amenity/kindergarten: {
ja.json-name: 幼稚園の敷地,
ja.json-terms: 幼稚園の敷地, 保育園の敷地
--
pl.json:amenity/kindergarten: {
pl.json-name: Teren przedszkola,
pl.json-terms: zerówka, żłobek, opieka nad dzieckiem, teren,
przedszkole,
--
pt-BR.json:amenity/kindergarten: {
pt-BR.json-name: Escola Infantil,
pt-BR.json-terms: Creche, Pré-escola, Cuidados infantis,
Bebês, Centro de Educação Infantil, CEI
--
pt.json:amenity/kindergarten: {
pt.json-name: Jardim Infantil / Infantário,
pt.json-terms
[Tagging] Kindergarten, Childcare and Preschool
Friends, I've had this in my to-do list for a while, and the recent discussion about min_age and age_group prompted me to bring attention to this issue. We should review the way kindergartens are being tagged. From what I have seen, one thing seems clear: there is demand for differentiating between places where kids are simply taken care of, and places where kids have basic education, but not at school level. First, some history I discovered looking in the wiki: * amenity=preschool[1] was proposed in the past to differentiate between places where kids go learn things(preschool) and places where kids are simply cared for (kindergarden). It was rejected in the voting process. (it has ~220 uses currently [2]) * one alternative way of tagging a preschool would be to tag it as amenity=school + isced:level=0, while kindergarten becomes simply the place where kids are taken care of. One problem with this is that it seems an ISCED level might not fit so well with all countries's education system (some people mentioned it doesn't with Germany's [3]). * amenity=childcare [4] was proposed in the past to differentiate between places where kids go learn things(kindergarten) and places where kids are simply cared for (childcare). It was rejected in the voting process. But turns out that nowadays amenity=childcare is supported by the iD editor [5] and consequently has around 1400 uses. My humble opinion is that Kindergarten seems to be defined as the place where kids get some basic education [7], and it's probably used like that, so it should remain that way (even if it may have some overlap with isced:level=0). While amenity=childcare (that has already gained traction) should be representative of the Day Care or Child Care [8]. As far as I saw, amenity=childcare is simply an rejected feature according to the wiki, and we should fix that. Cheers, John [1]: http://wiki.openstreetmap.org/wiki/Proposed_features/Pre-School_%28early_childhood_education%29 [2]: http://taginfo.openstreetmap.org//search?q=amenity%3Dpreschool [3]: http://wiki.openstreetmap.org/wiki/Key:isced:level#Germany [4]: http://wiki.openstreetmap.org/wiki/Proposed_features/childcare [5]: https://github.com/openstreetmap/iD/blob/874a3e2ad67e77e8896ff9580d40bf990eaed974/dist/locales/en.json#L1136 [6]: http://taginfo.openstreetmap.org/search?q=amenity%3Dchildcare [7]: https://en.wikipedia.org/wiki/Kindergarten [8]: https://en.wikipedia.org/wiki/Day_care ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] min_age vs. minage
My first impression is that minage should be used only for admission into the place. It seems using minage for usage is not very different from admission in case of a playground. In case of a school, it would be better to describe the school teaching level using isced:level=* or some country-specific tag. 2014-07-19 14:43 GMT-03:00 Florian Schäfer flor...@schaeferban.de: Both variants (compound spelling and underscore) exist. See min_height or building:min_level for example, which are used in (esp. 3D-)building-tagging. The highway-related tags minspeed, maxspeed and maxheight use the compound spelling indeed, but they are way more readable than minage in my opinion, as explained in my previous mail. Cheers, Florian Am 19.07.2014 18:57, schrieb Andrew Shadura: Hi, I'm for minage. Compare with minspeed and maxspeed, for example. -- Cheers, Andrew ___ 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] shop=scuba_diving and shop=dive
shop=scuba_diving seems like the kind of thing you can add without looking at the wiki, so I think that's a plus though that's the kind of thing you are better off asking the users that introduced this tag, so they can tell whether there is a difference between those two. shop=dive seems like a fusion of shop=scuba_diving and amenity=scuba_diving_center 2014-07-17 18:28 GMT-03:00 Andreas Goss andi...@t-online.de: Sorry, just saw that sport=scuba_diving is pretty well established, so maybe we should use shop=scuba_diving. What do you think? http://wiki.openstreetmap.org/wiki/Tag:sport%3Dscuba_diving __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] British English Spelling shop=jewelry
I still think shop=jewelry shouldn't be changed, because it seems well-established, so it simply isn't worth it to change them. It might be some inconsistency, but it's a really small one. About vending=news_papers, personally I don't object to changing it, but preferably make this deprecation explicit on the wiki by mentioning how it was tagged before. 2014-07-17 5:39 GMT-03:00 Martin Koppenhoefer dieterdre...@gmail.com: Am 16/lug/2014 um 21:37 schrieb Andreas Goss andi...@t-online.de: The differences already exist, no matter what we choose. +1, all spellings in British is making life easier for everybody on the long run (besides the Americans maybe, but also for them clear rules are easier than an arbitrary mix). FWIW this is not a new rule but a rule from the beginning so these misspelled tags shouldn't have been introduced at first cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Relations are not categories excepted for type=network ?
Kugelmann, It's true we should delete these relations, but not without adding the appropriate tags to it's members (else we would be throwing data away). 2014-07-16 8:20 GMT-03:00 Michael Kugelmann michaelk_...@gmx.de: Am 16.07.2014 05:23, schrieb Marc Gemis: In Belgium and The Netherlands a network-relation is used to group together all nodes and routes of a walking network. relations are NO CATEGORIES in OSM, that's agreed since years! Please delete these relations. BTW: it's not possible to keep such a relation up to date if it has a reasonable amount of objects = any new node or way of the network has to be included. But e.g. I didn't know about that relation = I wouldn't include a new node or way = would be missing. So I don't see any chance to have all objects within a relation. = another argument against a relation used as category. Best regards, Michael. ___ 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] Religious landuse?
Hi, I saw on the wiki there was some changes on pages related to religious landuse. It seems there is this tag that was documented only recently (but has around 1500 uses, mostly on Europe), and is called landuse=religious In my opinion, it seems this tag conflicts with amenity=place_of_worship in a large ammount of cases, if not all. I think it could be used for places that are not strictly for worship, but are used in religious practices (for example a religious school that is associated with a particular church, but not on the same grounds). Does this seems correct? Cheers, John ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] British English Spelling shop=jewelry
I don't think we should change the spelling of an well-established tag (more than 13 000 uses according to taginfo) See the comments about the abrupt change of power=sub_station to power=substation on github[1]. For example: [..] why bother changing the tag? Should we next have a vote on whether it should be spelt railway or spelled railroad? The problem here is not that the tag is mis-spelled, but instead that people are worrying about tag spelling when we should be encouraging people to edit. If enough people spell a tag using a standard incorrect spelling, or a (English standard correct) spelling, then write it up in the Wiki and people who render will know what to do. That is what seems crucial to me: ensuring that people know how to add things, and that people know what they mean once they're added. Correct spelling seems quite secondary to the matter, where correct *rendering* is the crux of the matter. [1]: https://github.com/gravitystorm/openstreetmap-carto/issues/230 2014-07-16 14:09 GMT-03:00 Andreas Goss andi...@t-online.de: http://wiki.openstreetmap.org/wiki/Proposed_features/BE- Spelling_shop%3Djewelry I kept it short ;) And I the think the Subject says it all. The use of jewellers could of course also be considered. __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] British English Spelling shop=jewelry
vending=news_papers seems harder to say because it seems some osm gardeners changed objects that previously had vending=newspapers (for example [1]), so the actual numbers are skewed. [1]: http://osm.mapki.com/history/node.php?id=2188351234 2014-07-16 16:41 GMT-03:00 Andreas Goss andi...@t-online.de: I don't think we should change the spelling of an well-established tag (more than 13 000 uses according to taginfo) So you think we should keep vending=news_papers? http://taginfo.openstreetmap.org/tags/vending=news_papers __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Subsequent wikipedia links
I made some changes to the page Key:wikipedia on the wiki. Please review: http://wiki.openstreetmap.org/w/index.php?title=Key%3Awikipediadiff=1060207oldid=1041603 2014-07-01 19:58 GMT-03:00 Jo winfi...@gmail.com: I've been experimenting with Wikidata a bit. I'm not a Wikipedian, rather a convinced Openstreetmapper. One of the problems I had with Wiktionary and Wikipedia is how data is duplicated over and over again. Wikidata finally started solving that. We should take advantage from that. Here are some examples of things I consider useful: Everything named after Guido Gezelle (mostly streets) http://overpass-turbo.eu/?Q=%28relation[%22name%3Aetymology%3Awikidata%22%3D%22Q336977%22]%3B%0A%3E%3E%3B%0A%3E%3B%0Away[%22name%3Aetymology%3Awikidata%22%3D%22Q336977%22]%3B%0A%3E%3B%0Anode[%22name%3Aetymology%3Awikidata%22%3D%22Q336977%22]%3B%29%3B%0Aout%20meta%3BC=51.98185;4.83689;7R Replace it with Q232785 and you get everything related to Father Damien. Unfortunately I didn't find where they buried his hands on Molokai. Polyglot 2014-07-02 0:22 GMT+02:00 Tobias Knerr o...@tobias-knerr.de: On 01.07.2014 22:25, yvecai wrote: This map could also be done with a third project linking OSM and Wikidata by automatically linking both datasets instead of manual tag entry of technical references. Call Overpass for OSM data (admin boundaries), then search wikimedia commons for flags with the corresponding name. But why would you prefer such a vague and error-prone style of linking when unambiguous linking via ID is possible? Even in very simple cases this is going to break down. Searching for flag Austria on Wikimedia Commons, for example, gives you the following top three hits: 1. http://commons.wikimedia.org/wiki/File:Animated-Flag-Austria.gif 2. http://commons.wikimedia.org/wiki/File:Flag_Austria_template.gif 3. http://commons.wikimedia.org/wiki/File:Smile-flag_Austria.gif The one we actually want is only ranked fourth: 4. http://commons.wikimedia.org/wiki/File:Flag_of_Austria.svg Wikidata, on the other hand, gets us straight to the one we want. How isn't this the better solution? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Subsequent wikipedia links
I removed the link to the key url=* because it's own wiki page advises it shouldn't be used, so I figured there was no need to link it here. As far as I understood, although it might make sense to tag an URL in some cases, the meaning of this key is too generic, making it hard to be used by tools. Therefore it's better to use another key that better indicates the meaning or relation of the URL, such as website=*, wikipedia=* and so on (not sure if there are others). 2014-07-09 11:43 GMT-03:00 Martin Koppenhoefer dieterdre...@gmail.com: 2014-07-09 16:37 GMT+02:00 John Packer john.pack...@gmail.com: I made some changes to the page Key:wikipedia on the wiki. Please review: http://wiki.openstreetmap.org/w/index.php?title=Key%3Awikipediadiff=1060207oldid=1041603 your edit looks fine to me, besides that you removed the url reference. This is still a valid tagging method, isn't it? (Shouldn't be used for wikipedia, but is fine for the rest, and should IMHO be kept there as a reference). Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] tree shrines
In the US, most of *these* sort of things are markers where people died in accidents. Wikipedia calls them roadside memorials ( https://en.wikipedia.org/wiki/Roadside_memorial), and I guess that might be the most common term in the US. To clarify, by these, you mean historic=wayside_cross, correct? Or does historic=tree_shrine has the same meaning? 2014-07-09 15:15 GMT-03:00 Brad Neuhauser brad.neuhau...@gmail.com: In the US, most of these sort of things are markers where people died in accidents. Wikipedia calls them roadside memorials ( https://en.wikipedia.org/wiki/Roadside_memorial), and I guess that might be the most common term in the US. Shrine, to my ears, has a different, more specifically religious connotation than these memorials--see the examples at https://en.wikipedia.org/wiki/Shrine I wouldn't use shrine to describe a marker where someone died unless it was a saint, or it was for people who literally worshiped ancestors. On Wed, Jul 9, 2014 at 7:02 AM, Friedrich Volkmann b...@volki.at wrote: Wayside shrines and crosses are quite common here in Austria, and probably in other parts of Europe too. They are mounted on posts (or pillars, walls...) made of various materials (wood, stone...), or on trees. When mounted on trees, I use a tag combination of historic=wayside_cross (or _shrine) with natural=tree + species=* etc. and (if applicable) name=*. I mapped a lot of these that way. Therefore I felt kind of annoyed when someone created a wiki page for the new and apparently synonymous tag historic=tree_shrine and immediately added it to the map features without any preceeding usage or discussion. I contacted him, but we didn't achieve a consensus. In order to untangle that tagging issue, I would like to ask native English speakers for their understanding of terms: - How do you call a cross at a tree? - How do you call a picture of a saint, or other shrine-like object, at a tree? - Is the term tree shrine common? - Is it considered a subset of the term wayside shrine, i.e. can you refer to a tree shrine as a wayside shrine? If we come to the conclusion that tree shrine is the correct term and that we therefore ought to tag them as historic=tree_shrine, some further questions arise: - Does it apply to crosses as well, or only to pictures and alike? - Does historic=tree_shrine imply natural=tree? - Is name=* the name of the tree or the name of the shrine/picture/cross? What if they differ? - Is start_date the birthdate of the tree or the date the shrine was made? -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ 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] Rendering for mappers
MapQuest Open is the only map style I never truly understood - it's a general purpose map, while others have their purpose stated clear in the name. What were the reason behind taking it on board, does anybody know? MapQuest matches the prerequisites to be a feature tile on OSM homepage [1]. About the rendering for the mappers: A similar discussion recently started on the *talk* mailing list [2]. [1]: http://wiki.openstreetmap.org/wiki/Featured_tiles [2]: https://lists.openstreetmap.org/pipermail/talk/2014-June/070074.html 2014-07-09 16:44 GMT-03:00 Daniel Koć dan...@xn--ko-wla.pl: W dniu 09.07.2014 19:08, SomeoneElse napisał(a): Historically, the standard style was a for mappers style - it was designed to show features that mappers had mapped. That has been changing (largely without community involvement or review). I tried That is exactly what I would expect! There are few nice themed styles on the main page, but no such working map. It doesn't need to be ugly, but its functionality for mappers must come first. It seems like the end goal is something a bit like what the Mapquestion Open style already provides (a summary of road information, not much else), which seems a curious design decision given that Mapquest Open tiles are already available as a style on the front page. MapQuest Open is the only map style I never truly understood - it's a general purpose map, while others have their purpose stated clear in the name. What were the reason behind taking it on board, does anybody know? OpenSeaMap or anything like this would better complete the set of maps we can use from the main page, this one is just duplicating the purpose of our default map. I have no preference which general map should be default - the beauty one or the working one - but two beauty maps and no working one makes no sense to me. When I act as an end-user of OSM, I want better search and additional services (routing is what I miss the most), not the nicer rendering. When I act as a mapper, I want to simply see all my tags. -- Mambałaga ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Enhancing natural=peak tag
Daniel, I don't know about standardization of rendering, but I would say the advice on the wiki is followed by OSM mappers much more often than some veterans think. 2014-07-08 20:05 GMT-03:00 Daniel Koć dan...@xn--ko-wla.pl: W dniu 08.07.2014 20:04, yvecai napisał(a): However, if rendering is an interesting topic, wiki is full of rendering examples and advices that aren't followed anywhere. Let the You don't even realize how sad is this observation for me... What is the role of writing documentation than - and approving it or declining? You can always use the tags as you like it, and they will be rendered this way or another (or not a all), so why waste the time proposing and documenting? renderer render and the cartographer style the map, and trust them to understand tags of interest to them. You have no choice but to trust external rendering services - they will do what they think is important anyway. And we show this trust by OSM license. But inside the project I think we need some more coherency. If there's an approved proposal with rendering hints, at least the default render should take it into account. Ideally I think all such features should be rendered - and if not, the documentation should be revised by rendering team explaining what is the problem. Eventually the consensus can be reached. Otherwise, if OSM is basically the GIS database, why the main project page has the map instead of big red Download the data! button? In my case it was as simple as taking the template and filling it up. Rendering section in this template (and the field in the proposition infobox) means it's not unusual that the tagging can have rendering implications. And I see the difference in scale of peaks type, which should be properly visualised to not make default map cluttered with unnecessary details (like https://github.com/gravitystorm/openstreetmap- carto/issues/689 ). But I just gave rough idea - the rendering team may feel some other settings would be better. -- Mambałaga ___ 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] Aerodrome types
One issue with the tagging schema that you specified is that it doesn't make it clear whether the aerodrome is a public airport. Actually, I found out there is a better definition for what I was calling simply airport or public airport. It's public use aerodrome. According to [1], Some States define a public use aerodrome as one that is available for use by the general public without a requirement for prior approval of the owner or operator I do agree using a separate tag to define whether an airport supports international flights seems appropriate. This way we could also take into consideration the alternatively international airports i.e. airports that only receive international flights when the original ones can't. I read in wikipedia[2] there are some airports that do have international flights, but are limited to some close countries, and are therefore called regional. Perhaps we could treat this case in this same key. [1]: http://www.iaopa.org/doc/icao-annex-survey.pdf [2]: https://en.wikipedia.org/wiki/Regional_airport#Regional_airport 2014-07-02 17:46 GMT-03:00 Janko Mihelić jan...@gmail.com: I don't like this way of mapping. There might be some overlaps, what if one aerodrome has a military and a public part? I would rather use separate tags like: aeroway=aerodrome access=private/public landuse=military international_flights=yes/no ... ___ 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] Aerodrome types
I agree with using the key aerodrome to specify further the type of the aerodrome (instead of aerodrome:type=* or type=*). Related to this: An airport is a special kind of aerodrome, and I think it is poorly documented on the wiki how to tag it. Looking at taginfo, it becomes clear that international aerodromes can be tagged with aerodrome=international. I assume most (if not all) international aerodromes are public airports. Private aerodromes (common inside some farms in Brazil) would be aerodrome=private, and military aerodromes would be aerodrome=military. So far so good. It isn't as clear how to tag a normal public *airport.* Is there some consensus on this? I suppose a domestic airport could be tagged with aerodrome=domestic aerodrome=public could also work, as long as it becomes clear that aerodrome=international is also a public airport. There are other classifications of aerodromes present on taginfo that are not documented. 2014-06-30 12:54 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Hello, I've recently reviewed some aerodromes in southern Brazil and, following some advice in the wiki [1], I've replaced the type tag with an aerodrome tag [2]. Do you agree that this is correct? Should we update tagging recommendations for aerodromes [3] and aeroways [4] in the wiki? [1] http://wiki.openstreetmap.org/wiki/Key:type [2] http://taginfo.openstreetmap.org/keys/aerodrome [3] http://wiki.openstreetmap.org/wiki/Tag:aeroway%3Daerodrome [4] http://wiki.openstreetmap.org/wiki/Aeroways -- Fernando Trebien +55 (51) 9962-5409 Nullius in verba. ___ 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] Aerodrome types
Interesting questions! The way I see it, we don't need to get into the details of who owns it (whether it is a company or the government), but classify according to it's use. When I say airport, I mean the kind of aerodrome the average person can use, usually with some stores and airflight companies. We could use aerodrome=domestic for normal airports instead of aerodrome=public, to avoid the need to consider who owns it. Most international airports in Brazil actually have internacional in it's official name. It means they have regular international flights. There are some normal airports that may receive international flights when *needed*, but they aren't known as international and I don't think they should be tagged as such (though they are classified as international alternative by the government). In my POV, an aerodrome with aerodrome=private would be an aerodrome used exclusively for transporting goods or people related to a company, or or privately owned by a big farm. I think ideally these shouldn't be tagged as aerodrome=international, even if it's the case. I believe aerodrome=military is self-explanatory, i.e. used for military operations and/or research. I'm not sure about other types of aerodrome=*. I don't know that much about this. I'm sure there can be other cases that don't easily fit with what I mentioned. 2014-07-02 14:05 GMT-03:00 Martin Koppenhoefer dieterdre...@gmail.com: 2014-07-02 18:32 GMT+02:00 John Packer john.pack...@gmail.com: An airport is a special kind of aerodrome, and I think it is poorly documented on the wiki how to tag it. From previous discussions I think I remember that it isn't clear what an airport is. Most if not all our aerodromes are probably airports, and also the helipads are probably airports according to the wikipedia definition of airport. Looking at taginfo, it becomes clear that international aerodromes can be tagged with aerodrome=international. I assume most (if not all) international aerodromes are public airports. What does an airport make international? If there once has flewn an aircraft into another country? Or must there be a scheduled flight into another country? Or a certain amount of such scheduled flights? Private aerodromes (common inside some farms in Brazil) would be aerodrome=private, and military aerodromes would be aerodrome=military. So far so good. is private about the ownership? Have a look at Fraport AG, the operator of Frankfurt Airport (biggest German airport) and traded at Frankfurt Stock Exchange. http://en.wikipedia.org/wiki/Fraport it is both, publicly and privately owned (majority is public ownership currently), would the Frankfurt Airport become private in OSM if the government decided to sell a bigger share of it? airport=international;private? Previous discussions ended up with the conclusion that it would be better to have the details mapped (e.g. number and size/shape of runways, encompassing polygon (!) for the airport itself) so that you could elaborate this information to estimate the importance. Unfortunately it seems quite expensive to do this on the fly, hence the missing progress in airport rendering at low zoom scales so far. That's why I agree with you that some basic tags could help the renderer (e.g. osm-carto) to achieve better rendering. Even a very simple metric (airports bigger than x and mapped as an area) might already improve the current rendering situation. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Where do source tags belong?
Putting notes on every object armcahir mappers: keep away is just as redundant and less informative than a source tag. I don't like all those source tags, but it addresses a real problem. I meant to say: add a note=* tag explaining the situation. Otherwise it indeed wouldn't help, but when you succintly explain the situation, you help not only future armchair mappers, but even local mappers that don't need to go there to verify the situation. I put such a tag on every feature that seems out of place to me, when I personally verify it is correct. (a housenumber in the wrong side of the road, a road crossing others in a strange way, etc) IMO, this is more useful than adding a source=* tag. By the way, the iD editor shows the note to mappers that select the object, even if they don't click to see all tags. (source=* is also shown) 2014-07-01 4:30 GMT-03:00 ael law_ence@ntlworld.com: On Mon, Jun 30, 2014 at 07:11:08PM -0300, John Packer wrote: If the tagging of the object is tricky or not obvious, or it is prone to be miscorrected by armchair mappers, it's useful to add a note in the appropriate language with the key note=*. Putting notes on every object armcahir mappers: keep away is just as redundant and less informative than a source tag. I don't like all those source tags, but it addresses a real problem. 2014-06-30 18:17 GMT-03:00 Tod Fitch t...@fitchdesign.com: At least in JOSM if you do a ctrl-h on a selected object it shows you the Well, I am a regular user of JOSM and I didn't know that. It would be nice if sometime I found time to explore all the corners of JOSM, but then I doubt that I would ever have time for mapping! More to the point, (some) armchair mappers don't know/bother/use other editors and are busy so don't have time to go looking. I fully agreed that that all those source tags are ugly and redundant: that it why I switched to changeset source tags. But then I suffered and had to switch back. In passing, many armchair mappers seem to use OSopenview etc and believe it is always correct. If I used openview regularly, I could add not-tags, but I don't and it would take too much time to check everything. ael ___ 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] Subsequent wikipedia links
To clarify: wikipedia:operator is exactly the same thing as operator:wikipedia. Historically, the key wikipedia has the same order as the key source. It might seem strange since this conflicts with the language version, but that's simply the result of an organic growth of the tag's definition. 2014-06-30 7:47 GMT-03:00 Jo winfi...@gmail.com: Indeed, sorry about that. 2014-06-30 12:46 GMT+02:00 Martin Koppenhoefer dieterdre...@gmail.com: 2014-06-30 12:27 GMT+02:00 Jo winfi...@gmail.com: The University of Derby would be: wikidata:operator=Q3183295 Devonshire Royal Hospital wikidata:operator=Q5267877 wouldn't operator:wikidata make more sense? ___ 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] Subsequent wikipedia links
I would advise to be cautious with adding wikidata tags with a bot, because a wikipedia article could have been moved and the wikidata tag would point to a wrong page. (i.e. the bot should also perform the standard checks even in this case) I believe leaving the wikipedia tag in place while adding the wikidata tag would be better in most cases. The main reason is that the wikipedia key is well established and supported in some sites, which either point a link to it or use some image from the page. 2014-06-30 8:19 GMT-03:00 Andy Mabbett a...@pigsonthewing.org.uk: On 30 June 2014 10:34, Andreas Goss andi...@t-online.de wrote: but I was aware it conflicts with the language version The best solution would be to just use Wikidata. If editors supported that, then they could also always show the titel of the Wikidata tag to avoid errors. http://wiki.openstreetmap.org/wiki/Wikidata I'm very strongly in faviour of tagging with Wikidata IDs; see my project proposal, at: https://wiki.openstreetmap.org/wiki/User:Pigsonthewing/Wikipedia but the level of understanding needed presents a high barrier to entry. I think we should continue to allow editors to tag with links to Wikipedia articles, but have the editing tool, or a bot, convert the tag to one with the equivalent Wikidata ID (or perhaps add a Wikidata tag, leaving the Wikipedia tag in situ). -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk ___ 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] Where do source tags belong?
If the tagging of the object is tricky or not obvious, or it is prone to be miscorrected by armchair mappers, it's useful to add a note in the appropriate language with the key note=*. For example, I have added it to part of a street that is used only for parking, and doesn't legally lead anywhere. (together with the appropriate tags). The armchair mapper should also be careful with these kind of things, and should contact the original mapper whenever he can, even if it's just asking if the correction is ok. (I'm not sure if OSM Messaging is built-in in JOSM, but it could be useful for quick messaging in this kind of case). 2014-06-30 18:17 GMT-03:00 Tod Fitch t...@fitchdesign.com: At least in JOSM if you do a ctrl-h on a selected object it shows you the source entry text that given on the change set (if it exists which it usually doesn't on older change sets). If the other editors don't show that, then they should be fixed. So the argument that it is not feasible for arm chair mappers to know the source of the data they are modifying if source:whatever=* tags don't exist is flawed. My issue with source:whatever=* tags is that you need one for every tag to avoid confusion about what the source for a specific tag is and it is a manual entry prone to error. That is automatic when looking at the history. Again in JOSM, it is very easy to compare versions of an object and find when the tag(s) were added or modified. Once on the change of interest you have the Source: blah,blah text right there. -Tod On Jun 30, 2014, at 12:53 PM, ael wrote: On Mon, Jun 30, 2014 at 06:40:47PM +0200, Jo wrote: Just like everybody else I started several years ago by adding source tags on the objects themselves. I changed to putting the source on to change sets, but hit a problem with armchair-mappers. I found armchair mappers overwriting carefully surveyed mapping with inferior and often wrong improvements. When I complained to them, they pointed out that it was not feasible to locate all the changesets and check the source tags. And I realized that was an impossible burden. So how is an armchair mapper to know that he/she is messing with something already gps/ground surveyed and keep away unless the source tag is right there where they can see it on the object? I nearly gave up on OSM at one point when all my hard careful work was completely destroyed by armchairs without local knowledge. I haven't seen anyone else make this point. As far as I can see, the only solution is to source-tag each object. Is there another solution? ael ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] No abbreviations in names edge case
there are 13 name:signposted in the db, not sure if there are more established alternatives... I don't think we should use this key, since it clashes with the usage of the key name for other languages (i.e. name:lg ). Something like name_signposted would be okay though. BTW there are some objects with the key name:abbreviation, which also clashes, is not standard and IMO can be safely changed to the key short_name . 2014-06-19 11:44 GMT-03:00 Martin Koppenhoefer dieterdre...@gmail.com: Am 19/giu/2014 um 08:54 schrieb Colin Smale colin.sm...@xs4all.nl: There should IMHO be an explicit tag to hold the version as displayed on the signs for any case where the abbreviator could be confused. +1, also useful for cases where the name on the sign is misspelled. For abbreviated versions you might (?) also use the tag short_name. there are 13 name:signposted in the db, not sure if there are more established alternatives... cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Key:contact - Misleading Infobox?
Indeed, data consumers should look at both variants, since the contact:* keys have a considerable number of uses. 2014-06-16 8:11 GMT-03:00 Martin Koppenhoefer dieterdre...@gmail.com: 2014-06-16 12:44 GMT+02:00 Mike N nice...@att.net: More importantly, to those who actually care about a data consumer using their POI: I'm not aware of any consumers that use the contact:phone version. I think any consumer should have a look at both variants (in my small projects I do this and I believe there are more people doing the same). Obviously, if you were forced to support just one, you'd choose the one with more usage, and this is without the prefix. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Religious-neutral tags needed for religious objects/non-church places
I don't think religious_symbol=* would be the best option for wayside cross. Here in Brazil, they often are found in curves that had automotive accidents in the past, and could indeed be said to be an historic feature, so I think this tag is good enough as it is. Like Volker said, the tag for wayside shrine really is religion neutral, but I can understand the confusion looking at it's wiki page. Em 13/06/2014 04:45, Volker Schmidt vosc...@gmail.com escreveu: Hey guys - I had a question about tagging wayside shrines. The wiki posits that they are Christian, but I want to use them for another religion. The wiki does not posit that they are Christian, on the contrary: There is a subtag religion and the text says: Frequently found along the way in Germany, Austria, Italy and probably elsewhere and refers to the Wikipedia article http://en.wikipedia.org/wiki/Wayside_shrine where the second picture is a shrine in Tokyo. But I don't like the historic= tag, because in other contexts it referes to he past use of a building or other object, whereas many wayside_shrines are recent and still in use. This led me to think about other religion-neutral tags main tags, and using a subtag for the object. here in Japan, there are probably tens of thousands of reeeaally small (Shinto) shrines and (occasionally Buddhist) temples. They are usually along roads, but sometimes hiking trails as well. The shinto ones are usually for natural beauty - this one is probably for this waterfall, though I could be mistaken. This one is 2mx2m. if you open it, there is just stuff inside, there isn't room for a person. This one is also fairly elaborate, with a gate, bridge and stairway, but others are just a small shed (sometimes less than 1m sq) and disused. If it wasn't religious, I'd tag most of them as a simple shed. They get placed all over, but here in rural Japan I find them on mountainsides, hilltops, and near bridges and lakes. In theory, besides the buddhist statuses and shinto gates, there are also really really tiny shines, about the size of a large trash can as well, but right now I'm just talking of something similar to what is in the picture. To me, this is also a wayside shrine. Am I right? I would use historic=wayside_shrine for the small shrines, whereas place of worship for the bigger ones. Man_made=cross or historic=wayside_cross similarly is geared for Christian religion, This is clearly not religion-neutral and I would like to see some neutral tags for these objects but there are millions upon millions of Shinto Gates and small figures of Buddha (ones you wouldn't think of as statues, like the big copper buddha at Kamakura) - but the existing tags are not religious-neutral and paired with the religion tag or a subtag to handle these; ie manmade=ReligiousSymbol, religiousSymbol= Wayside Cross, Shinto Gate, Buddha Statue, Spaghetti Meatball, etc I know that There must be many other symbols in other religions used regionally that I don't know of, so having an expanding sub-tag is better than filling up historic=, building=, and manmade= with more and more narrow tags as OSM gets more detail added from non-christian areas. I agree with this proposal. It would also eliminate the doubts which I always have when entering a brand-new historic=wayside_shrine or wayside_cross Volker Padova, Italy ___ 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] capital and state_capital: how are they being used in your country?
Honest question: are there capitals for something besides countries and states? If not, we could keep it simple: * capital=yes for country capitals * state_capital=yes for state capitals (already in use in some parts of America http://taginfo.openstreetmap.org/keys/state_capital#map). PS: Taginfo just released some new functionality, which allow us to compare the different uses of the different keys capital around the world: http://taginfo.openstreetmap.org/compare/state_capital/capital_city/capital_level/is_capital/capital(note that as demonstrated before, around 90% of the current values of the key capital=* seems to be incorrectly tagged). I'm not saying we should use the others, just though it was interesting. 2014-05-16 7:07 GMT-03:00 Martin Koppenhoefer dieterdre...@gmail.com: 2014-05-16 12:00 GMT+02:00 Andreas Goss andi...@t-online.de: For what apart from Rendering will this importance be usefull? And I still think it would be missleading and will lead to confusion. Someone who wants to look up all state capitals might just check all nodes for capital=4 (because it's the logical thing to do) not knowing that it can only be done correctly by also looking at relations. I don't see this as a problem. Looking for all state capitals is not within the scope of the capital tag, as you will miss those which are also capitals for bigger entities like countries. You might have to look up all capital=1/2/3/4/yes places and remove those which aren't state (level 4) capitals. Yes, rendering is probably the most important use case for this tag, why should that be a problem? cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] capital and state_capital: how are they being used in your country?
(because of current mapnik rules capital=yes should be preferred over capital=2, as the style sheet only takes account of capital=yes or not yes: *https://github.com/gravitystorm/openstreetmap-carto/blob/master/project.mml https://github.com/gravitystorm/openstreetmap-carto/blob/master/project.mml ).* I disagree with that. capital=yes is ambiguous and capital=2 should be preferred Mapnik rules can be changed as time allows. I wouldn't be surprised capital=yes isn't really used only on capital=2 cases. When there are more than one admin_centre, perhaps we could simply use the role label instead of the role admin_centre. It is currently used in states to indicate where to place the node of the state name, because the administrative centre of a state tends to be the same as it's capital city administrative centre. (example of the label role: https://www.openstreetmap.org/node/539668890 ) 2014-05-15 8:36 GMT-03:00 Martin Koppenhoefer dieterdre...@gmail.com: 2014-05-15 13:09 GMT+02:00 Pieren pier...@gmail.com: Why not. But the definition shall be clear : it's only the administrative(s) centre(s) place(s) to be linked. The risk if we don't specify a limit is that contributors will use it to link all places within the boundary (making a substitute of the infamous is_in tag). yes, of course we should only declare those places as admin_centres that are indeed administrative centres (having an administration office is maybe not enough to be a centre). I was thinking of places like these: http://it.wikipedia.org/wiki/Provincia_di_Barletta-Andria-Trani (Italian Province with 3 admin centres) http://it.wikipedia.org/wiki/Provincia_di_Carbonia-Iglesias (a Province with 2 centres). cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] capital and state_capital: how are they being used in your country?
Sorry, I meant the adminstrative centre of the state's capital city It is currently used in states to indicate where to place the node of the state name, because the administrative centre of a state tends to be the same as *the state's *capital city administrative centre. 2014-05-15 9:23 GMT-03:00 Matthijs Melissen i...@matthijsmelissen.nl: It is currently used in states to indicate where to place the node of the state name, because the administrative centre of a state tends to be the same as it's capital city administrative centre. (example of the label role: https://www.openstreetmap.org/node/539668890 ) Not necessarily though. For example, Amsterdam is the capital of the Netherlands and located in North Holland province, but not the capital of that province (which is Haarlem). Some more strange cases: - The administratively centre is not always equal to the ceremonial capital. For example, Amsterdam is the capital of the Netherlands, but The Hague is the administrative centre. - The administrative centre of a region might be licated outside the region in administers. For example, the city of Częstochowa is the administrative centre of Częstochowa county, but the city is not part of the county (the county forms a ring around the city). -- 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] capital and state_capital: how are they being used in your country?
Wait a minute. As far as I understood, the key capital=* isn't supposed to simply substitute admin_level. capital=2 means this city (which the node represents) is the capital city of this country (which has admin_level=2). capital=4 means this city (which the node represents) is the capital city of this state (which usually has admin_level=4) capital=2;4 would mean this city is the capital city of the country AND state. Is my current understanding of this key wrong? 2014-05-15 13:32 GMT-03:00 Andreas Goss andi...@t-online.de: Am 5/15/14 16:30 , schrieb fly: Regarding the original discussion I am in favour of using capital=[2-10]* if an additional tag is needed. The semicolon (;) is defined as value separator so we could have capital=4;6;8 or similar. This just sounds like a disaster waiting to happen. I also don't see why it would be needed. You are doubling the risk of errors when it comes to admin_levels. Now you don't just have to ensure all relations are correct, but also all nodes. You also have no reference to those numbers. When you add one admin_level to a relation that relation has a name (Bavaria is a state). When placing admin_centre you know the name of the relation and of the city so you can make a connection (Munich is the capital of Bavaria). And while that maybe is obvious at level 2 and 4, it becomes more compicated when you get into smaller administrative areas. This also makes it more complicated to find errors in the first place. I also bet that people are going to assume that some numbers are missing and are simply going to add them, especially as it varies from country to country, from state to state etc. Others might simply add a number with good intend, because they had the wrong admin_levels in mind. ___ 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] admin_level on nodes: wiki vs practice
Hi Martin, I was the one that marked the proposal for the key capital as cancelled (maybe abandoned was a better status). I did this because I saw it's use was a complete mess in tag info, and as far as I knew, admin_centre had the same purpose, so I just wanted to help to clean the wiki from it's countless inconsistencies and abandoned proposals. If the use of the key capital is well established, please at least create a page Key:capital explaining it's use. Em 13/05/2014 10:35, Martin Koppenhoefer dieterdre...@gmail.com escreveu: 2014-05-13 15:02 GMT+02:00 Ilya Zverev zve...@textual.ru: First, this discussion it seemed was about removing admin_level tags, and not straightening up the tagging schema. I posted my reply because I had seen the tag removed from Berlin, not replaced by another. Left there is capital=yes tag, which is sometimes used along with admin_level=* ( http://wiki.openstreetmap.org/wiki/Key:capital ). I am aware of that page (one hour ago reset it from cancelled to draft because capital as a key is not cancelled but well established). IMHO this proposal (and its discussion) doesn't advocate setting admin_level aside the capital tag. There was this idea back in 2008, but if you follow the discussion it looks as if capital is the key to go with (so no need for duplicating the same value in admin_level as well). Btw.: I completely agree with you that inheriting from administrative relations is worse than having an explicit tag on the place, as this inheritance idea doesn't work well with dynamic data (incremental updates and how they are usually applied, osm2pgsql). cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] admin_level on nodes: wiki vs practice
I really don't think this is considered a standard tag by most people. In taginfo we can find keys like capital_city, capital_level, is_capital, state_capital, capital. As far as I saw, each key is concentrated on some parts of the globe. It certainly is not a fact that it is standard. I had changed the proposal status to cancelled because I thought the node admin_centre in the administrative relations superseded the proposal for the key capital, but it seems I was wrong. Anyway, I added a template to the page Key:capitalhttp://wiki.openstreetmap.org/wiki/Key:capital . When people agree on a definition, we should add it to this page. 2014-05-13 12:45 GMT-03:00 Martin Koppenhoefer dieterdre...@gmail.com: 2014-05-13 17:24 GMT+02:00 John Packer john.pack...@gmail.com: I still think it's needed to create a proper page for this key. I find it hard to see a proposal page with such a long discussion as some kind of standard. I agree that the docu could be better here, and it would certainly be a first step to move the discussion to the proposals discussion page (I have done this now and also added some notes on actual usage), but that doesn't void the proposal or the fact that this is a standard tag. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] capital and state_capital: how are they being used in your country?
More information: All 48 nodes with capital=10 have admin_level=10 19 nodes out of 122 with capital=7 also have admin_level=7 21 nodes out of 331 with capital=6 also have admin_level=6 (this one came from that Spain import) 94 nodes out of 427 with capital=4 also have admin_level=4 182 nodes out of 346 with capital=yes also have admin_level=2 2014-05-13 13:41 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: None of them have admin_level=* tags. should have been None of them have admin_level=* tags on the nodes, only in relations. On Tue, May 13, 2014 at 12:40 PM, Fernando Trebien fernando.treb...@gmail.com wrote: Following from the previous discussion (https://lists.openstreetmap.org/pipermail/tagging/2014-May/017515.html ), it seems clear we would all like to know how these tags are being employed in each other's country. So if you know how it's being done in yours, or if you can try figuring it out, please take a minute to describe it here briefly. We will write a wiki article about it. I'll start with mine, Brazil: - Brasília [1] [2], which is the political capital but not the largest city, has capital=yes - São Paulo [3] [4], which is the capital of the São Paulo state, has state_capital=yes - Campinas [5] [6], which is a regular city (though a very large and important), has neither of those tags None of them have admin_level=* tags. Brasília's relation is actually missing a capital=yes tag, but I'll wait to hear you before adding it (or removing it from others' relations). [1] https://www.openstreetmap.org/node/34567423 [2] https://www.openstreetmap.org/relation/2758138 [3] https://www.openstreetmap.org/node/30674098 [4] https://www.openstreetmap.org/relation/298285 [5] https://www.openstreetmap.org/node/32070447 [6] https://www.openstreetmap.org/relation/298227 -- Fernando Trebien +55 (51) 9962-5409 Nullius in verba. -- Fernando Trebien +55 (51) 9962-5409 Nullius in verba. ___ 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] deforestation tag
I didn't understand. When is landuse=grass and landcover=grass different things? Em 04/05/2014 07:02, Pieren pier...@gmail.com escreveu: On Fri, May 2, 2014 at 7:21 PM, John Packer john.pack...@gmail.com wrote: +1, landuse=grass does not make sense, as grass is not a use, use landcover=grass for grass covered areas, and landuse=meadow, if it is a meadow I would love to replace all landuse=grass to landcover=grass on my city, but Mapnik doesn't render landcover=grass. (e.g. http://www.openstreetmap.org/way/167367132 ) -1 Since landuse and landcover are not always matching, you create two separate layers of land polygons partially overlapping each other. This would increase the complexity of mapping which is something the crowd will never accept. Pieren ___ 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] direction=forward/backward on nodes ?
To make it less ambiguous and easier I would deprecate forward/backward completely for nodes and advice to use cardinal coordinates for all nodes. I think that would be ok for traffic_sign:direction=*, but not for traffic_signals:direction=* or direction=* when used with highway=stop/give_way, because it wouldn't be as easy to know to which highway's direction the highway=traffic_signals/stop/giveway applies to. IMHO we should use relations for cases like this (see turn restrictions, via nodes, for reference) +1 2014-04-14 8:44 GMT-03:00 fly lowfligh...@googlemail.com: Am 14.04.2014 08:28, schrieb Peter Wendorff: Hi, Am 13.04.2014 21:35, schrieb Steve Doerr: I'm surprised that so many people are jumping to this conclusion. Let's remember that a way is just a series of nodes in a particular order. So a node is not necessarily an isolated object. Agree In many cases, it exists solely as part of a way. Thus the concept of direction is not meaningless for a node which is part of a way. Agree partly. It's not meaningless, but it get's ambiguous very often. Exactly, it is not meaningless but ambiguous and can easily lead to wrong results. Take traffic signals as one example where the direction might be used: Besides an intersection someone could add the traffic lights on the four individual ways (instead on the intersecting node itself). This matches the installation of the individual lights and the stop positions, but it produces wrong results without a direction tag. The drawback of that is, that someone crossing the intersection straight meets two traffic lights, which is wrong of course. The mapper therefore might decide to add direction-tags to them, as each traffic light node is relevant and applied only for one of the two directions. Looks perfect now - all four traffic lights are mapped separately where they are, routing for cars works great (provided that the direction tag is known and supported by routers). Enter of the next mapper: He want's to add the footways and cycleways that cross the streets using the pedestrian traffic lights integrated in the traffic lights mentioned above. As a result the nodes previously mapped with a direction are shared by two ways, and it's hard to determine what the direction tag refers to, as of course crossing for pedestrians is possible and meaningful for both directions. Thanks for another example where cardinal coordinates work but forward/backward fails. I haven't examined any uses of the tag on a node, but I can imagine, for instance, that a node in a way with a direction attribute might be used to represent a road-sign that applies only to traffic on the way passing that node in a particular direction. For other traffic signs it's the same, and that's why we usually map the road signs meaning on the road that is affected by it. (The sign itself may be mapped as such, as an obstacle and a physical object next to the street), while maximum speed, maximum dimensions (width, height, weight), oneway access, access restrictions and so on are mapped on the where they hold. Here the direction is useful (look at the oneway=yes tag), meaningful and not ambiguous; on nodes it is or get's very lightly without tagging mistakes. Ok, we can take a split between unconnected nodes on the left-/right-hand-side of the road and nodes being part of a way. The first are less ambigious but you still need to know the driving directions where as the latter ones just won't work properly with forward/backward. To make it less ambigious and easier I would deprecate forward/backward completely for nodes and advice to use cardinal coordinates for all nodes. fly ___ 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] noexit=yes on ways ? (a typical OSM story)
What, in tagging a way, indicates on which end of it is the dead end? I asked that already). The question does not make sense. Of course the end that is not connected to another highway is the dead-end. If the way should not be connected to anything on either side it will already be flagged as a connectivity error. I think you missed André's point. If a way has two dead-ends: one of which is an actual dead-end, and another which is a connectivity error... then the connectivity error is missed because noexit=yes was used. Fortunately this doesn't actually happen because *noexit=yes on ways are ignored* on validators like JOSM. I think we all agree that tagging a way with noexit=yes isn't exactly an error, but it has disadvantages (other were cited in this thread) and it shouldn't be recommended on the wiki. 2014-04-13 16:20 GMT-03:00 Frederik Ramm frede...@remote.org: Hi, On 10.04.2014 18:08, André Pirard wrote: In other words, 40% tags (on ways) can't be wrong. But the problem is that 99.+% of these correct tags are mistakes and shouldn't even exist because they do not represent ways ending near another way, which are the targets of noexit=yes, but normal dead ends needing no other tagging. I don't see a problem in tagging a normal dead-end with noexit=yes. It doesn't hurt, and adds information (namely that this isn't just a bit where I had no time to continue tracing, but a proper end). I don't do it myself but I'll certainly not make an effort to flag this as error and get my knickers in a twist about it. What, in tagging a way, indicates on which end of it is the dead end? (I asked that already). The question does not make sense. Of course the end that is not connected to another highway is the dead-end. If the way should not be connected to anything on either side it will already be flagged as a connectivity error. What does happen when the way is split or unsplit? Logically, if you merge a dead-end with a non-dead-end, the result will still be a dead-end. If you split a dead-end then one part won't be a dead-end and the other will - however, having a way tagged noexit=yes which has no dangling ends doesn't seem to be a drastic error to me. In fact, is it the way or is it the highway? Just a segment or more and up to where? I think you should take a deep breath and calm down. The bit that is typical OSM about this is that people can't cope with a bit of fuzziness and then start endless discussions, and in the end claim that OSM is doomed, lacks quality, will never work, is ruled by idiots, whatever. I know who is right: our government who say that OSM is not [necessarily, to remain civil] up to the quality they expect for data. I fear that this does not favor obtaining data from them. Well who knows if we even want your government's data. Maybe it lacks the qualities we are looking for. I was enthusiastic, but I now believe less and less in OSM. Maybe you misunderstood OSM and you are slowly learning what it is, and what it is not. Please let us ask Osmose to mark as an error any nooexit=yes that is either not on a node or not close to another way. We could report that action to that government and others as an example that we at least try to put our data right. I don't think that we have to prove to any government that we are trying to put right something that is hardly a problem. In fact, spending brainpower and time on such a trivial issue would be quite a misallocation of resources. Now what about some more fun? Flood tagging noexit=no in the middle of every street? That wouldn't make 40% but 100% and require a wiki update by those able to understand contributors, wouldn't it? ;-) Vandalise OSM to prove a point and we'll kick you out. Just so that governments around the world can see that we're taking that seriously. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ 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] direction=forward/backward on nodes ?
Do note that when used on benches, *forward* and *backward* are not valid values (which is what we are talking about). *amenity=bench* with a *direction=** key use angles and cardinal directions as values. 2014-04-12 14:46 GMT-03:00 fly lowfligh...@googlemail.com: Sorry, forgot the link. Yes, it does make sense and is useful for benches and traffic_signals. Am 12.04.2014 19:43, schrieb John F. Eldredge: Since a node is a point, and has no dimensions, a direction tag is meaningless. On April 12, 2014 12:20:26 PM CDT, fly lowfligh...@googlemail.com wrote: Hey As I had much fun with the last subject (noexit), I just can not hold myself back to jump into another bee nest. I read on the wiki page [1], that direction=forward/backward are valid values also for nodes. Could someone please explain me, how this can work. I only find some major reasons not to do that: * You always have to look at the parent object to determine the direction * There is no editor supporting this tag when reverting a way direction * I am not allowed to split a way at this point which is another unneeded burn and once again you need special editor support which is not present. [1] https://wiki.openstreetmap.org/wiki/Key:direction ___ 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] direction=forward/backward on nodes ?
I have never used this key before because of the drawback you mentioned: There is no editor supporting this tag when reverting a way direction, but as far as I know, *direction=forward/backward* is used with *highway=stop* and *highway=give_way* and maybe some other signs. There are keys similar to *direction=forward/backward*; they aretraffic_sign:forward/backward=http://wiki.openstreetmap.org/wiki/Traffic_sign#As_part_of_a_way yes http://wiki.openstreetmap.org/wiki/Traffic_sign#As_part_of_a_way and traffic_signals:direction=forward/backwardhttps://wiki.openstreetmap.org/wiki/Key:traffic_signals:direction 2014-04-12 15:27 GMT-03:00 fly lowfligh...@googlemail.com: Please, tell me for what kind of keys is the paragraph about forward/backward useful. There are no examples and it is only about nodes. Thanks fly Am 12.04.2014 20:00, schrieb John Packer: Do note that when used on benches, /forward/ and /backward/ are not valid values (which is what we are talking about). /amenity=bench/ with a /direction=*/ key use angles and cardinal directions as values. 2014-04-12 14:46 GMT-03:00 fly lowfligh...@googlemail.com mailto:lowfligh...@googlemail.com: Sorry, forgot the link. Yes, it does make sense and is useful for benches and traffic_signals. Am 12.04.2014 19:43, schrieb John F. Eldredge: Since a node is a point, and has no dimensions, a direction tag is meaningless. On April 12, 2014 12:20:26 PM CDT, fly lowfligh...@googlemail.com mailto:lowfligh...@googlemail.com wrote: Hey As I had much fun with the last subject (noexit), I just can not hold myself back to jump into another bee nest. I read on the wiki page [1], that direction=forward/backward are valid values also for nodes. Could someone please explain me, how this can work. I only find some major reasons not to do that: * You always have to look at the parent object to determine the direction * There is no editor supporting this tag when reverting a way direction * I am not allowed to split a way at this point which is another unneeded burn and once again you need special editor support which is not present. [1] https://wiki.openstreetmap.org/wiki/Key:direction ___ 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] noexit=yes on ways ?
Just a quick comment: If it's not useful to use it on ways, then I don't think we should recommend it on nodes *or ways* on the wiki page (as it is currently). In fact, we should recommend against putting on ways. 2014-04-09 16:16 GMT-03:00 André Pirard a.pirard.pa...@gmail.com: On 2014-04-09 10:47, Pieren wrote : 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) ??? Let's explain in details. We let alone the Xmas trees. Assuming real noexit, the typical caseshttp://overpass-turbo.eu/map.html?Q=%3C%21--%0AThis%20has%20been%20generated%20by%20the%20overpass-turbo%20wizard.%0AThe%20original%20search%20was%3A%0A%E2%80%9Cnoexit%3Dyes%E2%80%9D%0A--%3E%0A%3Cosm-script%20output%3D%22json%22%20timeout%3D%2225%22%3E%0A%20%20%20%20%3Cquery%20type%3D%22way%22%3E%0A%20%20%20%20%20%20%3Chas-kv%20k%3D%22noexit%22%20v%3D%22yes%22%2F%3E%0A%20%20%20%20%20%20%3Cbbox-query%20s%3D%2250.66839555058174%22%20w%3D%225.717890262603759%22%20n%3D%2250.67569820203223%22%20e%3D%225.731172561645508%22%2F%3E%0A%20%20%20%20%3C%2Fquery%3E%0A%20%20%3C%21--%20print%20results%20--%3E%0A%20%20%3Cprint%20mode%3D%22body%22%2F%3E%0A%20%20%3Crecurse%20type%3D%22down%22%2F%3E%0A%20%20%3Cprint%20mode%3D%22skeleton%22%20order%3D%22quadtile%22%2F%3E%0A%3C%2Fosm-script%3E *look like* two normal junctions at each way end but one of them *is in fact *a dead end. Why would we tag noexit on the way and request the beholder to zoom in each end to determine which is dead if we can tag the information clearly on the end node? What about T shaped ways where the top way contains 2 dead ends? gotcha, there were 2? Now, instead of a vertical bar, what about a small (or larger) mesh like *rue Grétry*: are we going to tag as dead ends all the segments of the mesh up to the normal junction even if they're not directly related with a dead end? And, BTW, are we speaking (in Subject:) of ways or of roads? Must we apply noexit=yes to both ways of the same road when we split one? How would the brave contributor splitting a way cope with that if he hasn't got the faintest notion of what noexit is (no blame on him!)? These are [probably a part of] the questions that raise and should be settled and that no one advocating noexit on ways mentioned. Frankly, noexit on nodes (as designed) is much more logical and simple (than on ways, of course). Cheers, André. ___ 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] noexit=yes on ways ?
I removed the use on ways from the wiki page. The wiki is not for documenting Tagging-trends, but for documenting best practices. I agree 100% with this. I also added the following phrase to the Usage section: In the past this tag was used on ways very often, but because tagging on ways has several disadvantages, you should rather tag *noexit*=yeshttps://wiki.openstreetmap.org/wiki/Tag:noexit%3Dyeson nodes. Florian, I think you mentioned some outdoor map renders the noexit tag. Do you know which one? We could add a Rendering section to the wiki page. (JOSM also renders it on the editor) Could someone clarify the Usage section of the wiki page please? Cheers, John 2014-04-10 10:10 GMT-03:00 fly lowfligh...@googlemail.com: On 10.04.2014 14:51, John Packer wrote: Just a quick comment: If it's not useful to use it on ways, then I don't think we should recommend it on nodes /or ways/ on the wiki page (as it is currently). In fact, we should recommend against putting on ways. Well, there is one person against wiki fiddling and in favour of using it on ways, who simply does change the just corrected version without further discussion. As we have many contributers to this discussion which are in favour of using it only on nodes and your are so far the only one completely against it. Not to talk about, that the original created page did only nodes. Would you please revert your changes from yesterday. A link to this thread might be useful. Thanks ___ 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] noexit=yes on ways ?
I agree with André Pirard that: 1. If we say it should be tagged on the way, it should be clearer how it should be tagged (what if the cul-de-sac is splitted, etc) 2. noexit was a bad choice of name for this key Personally I don't know if using noexit=yes on ways is used by any software nowadays. I wouldn't be surprised if the current legitimate uses of noexit=yes are only on nodes. But yeah, tagging on ways isn't exactly an error. 2014-04-10 13:17 GMT-03:00 Mike N nice...@att.net: On 4/10/2014 12:10 PM, Yves wrote: I guess the problem arises from tagging dead-ends in a geo database. QA tools should keep there false positives for themself, not in OSM, don't you think? Except that I don't use QA tools when editing data. But often as I create something that ends suspiciously near another object, I can flag it as correct to the QA tools at creation time. Also there may be multiple QA tools. ___ 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] noexit=yes on ways ?
I also can't see why, but people also use noexit=no http://taginfo.openstreetmap.org/keys/noexit#values noexit=no is the same as fixme=continue I believe fixme=continue should be favored since it actually appears in QA Tools and in JOSM 2014-04-04 11:56 GMT-03:00 André Pirard a.pirard.pa...@gmail.com: On 2014-04-04 16:14, Nelson A. de Oliveira wrote : On Fri, Apr 4, 2014 at 10:54 AM, fly lowfligh...@googlemail.com lowfligh...@googlemail.com wrote: On 03.04.2014 21:22, Nelson A. de Oliveira wrote: On Thu, Apr 3, 2014 at 4:17 PM, fly lowfligh...@googlemail.com lowfligh...@googlemail.com wrote: Is noexit=yes useful on ways ? The way has one side that has/is an exit :-) Tagging the whole way as noexit=yes seems strange. If it is accepted, I gonna hange the wiki accordingly and gonna ask a for validator checks in JOSM, as we have more than 100,000 ways with this tag. Basically I agree with the current text ofhttp://wiki.openstreetmap.org/wiki/Key:noexit (except that I don't agree to use it on ways). Yes, except that it's a little bit unclear and hence much misunderstood. I made a revisable update according to what has been said before. I also can't see why, but people also use noexit=nohttp://taginfo.openstreetmap.org/keys/noexit#values In fact, the most misleading point is noexit itself. According to the true meaning, it should be intentional_tag or something that could apply to other seemingly funny tags too. Cheers, André. ___ 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] noexit=yes on ways ?
in what situations is noexit=yes useful at all, except as a cue to subsequent mappers in the very rare situation that one way ends very close to another one and there's absolutely nothing (not a wall, footpath, anything) between them? It might be useful when there is limited visibility of the ways using the satellite imagery (for example, being blocked by clouds or trees), so it becomes a confirmation that the way does indeed end there. It can also may make it easier to visualize the streets if the city has a lot of streets without exit. (JOSM properly renders nodes with noexit=yes) 2014-04-03 16:22 GMT-03:00 SomeoneElse li...@mail.atownsend.org.uk: fly wrote: Is noexit=yes useful on ways ? Asking a slightly broader question, in what situations is noexit=yes useful at all, except as a cue to subsequent mappers in the very rare situation that one way ends very close to another one and there's absolutely nothing (not a wall, footpath, anything) between them? Cheers, Andy ___ 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] Ticket for JOSM to read contact metadata closed
You should ask the developer for clarifications. But personally I agree with him. The effort to develop this functionality wouldn't be worth it. I don't think any website I added until now had contact metadata. Most people probably wouldn't even know this feature existed if it did. As far as I know, you can always develop a JOSM plugin (or hire someone to do so) if you need it. 2014-04-02 14:25 GMT-03:00 Andy Mabbett a...@pigsonthewing.org.uk: Not only was I disappointed to see this ticket: http://josm.openstreetmap.de/ticket/9885 closed as wontfix, but I don't understand the reason given: This format seems not to be used much. Too much work for too little gain. not least since I specifically referred to an hCard microformat or some other contact metadata. Was I unclear in my proposal? -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Wikidata
If an object exists both in Wikipedia and Wikidata, would you expect both tags to be used? Wikipedia links can be obtained from the Wikidata API for a given Wikidata ID and vice versa, so one of the two would suffice. It might seem redundant but the key wikipedia shouldn't be removed when adding the key wikidata to an object, because there are a number of sites that use the wikipedia tag and don't understand the wikidata tag right now. 2014-04-01 18:17 GMT-03:00 Tobias Knerr o...@tobias-knerr.de: On 01.04.2014 19:04, Andy Mabbett wrote: I commend this proposal to the list: https://wiki.openstreetmap.org/wiki/Proposed_features/Wikidata I like Wikidata and therefore want to see this proposal approved. :) What I'm interested in, though: If an object exists both in Wikipedia and Wikidata, would you expect both tags to be used? Wikipedia links can be obtained from the Wikidata API for a given Wikidata ID and vice versa, so one of the two would suffice. ___ 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] Post-voting-clean-up: help needed.
Personally I don't think it's obvious how to add/edit itens in pages like *Map Features*. For example, to edit the Tourism section, you have to go to http://wiki.openstreetmap.org/wiki/Template:Map_Features:tourism and *repeat* the information about the tag, such as which objects it can be applied to, description, photo, etc. (but using a different syntax) I have no idea why we have to repeat such information there instead of simply adding a reference. I wouldn't be surprised if some of this data is outdated. 2014-03-29 10:20 GMT-03:00 nounours77 kuessemondtaegl...@gmail.com: hi there, sorry for bothering. I tried to do the post-voting-clean-up on tourism=apartment. I changed the status for the proposal page to accepted, a created a new tag page [1] I thought this will then magically appear in the tourism [2] and the map features [3] page, since both of them seem not to be maintained by hand. But it does not. I used the templates etc. and tried to do as the other pages - but they are listed and mine not. I search a lot, but could not find a clue??? Am I overseeing something obvious??? Thanks for help! nounours77 [1] https://wiki.openstreetmap.org/wiki/Tag:tourism%3Dapartment [2] https://wiki.openstreetmap.org/wiki/Key:tourism [3] https://wiki.openstreetmap.org/wiki/DE:Map_Features ___ 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] Driving side
I removed the value opposite from the page. http://wiki.openstreetmap.org/w/index.php?title=Key:driving_sideoldid=1008962 2014-03-28 19:27 GMT-03:00 Tobias Knerr o...@tobias-knerr.de: On 27.03.2014 16:11, Pieren wrote: But you force the QA tools to search and load country relations even if they just have to check locally a way. This is not a problem for tools like osmose or keepright but it is a problem for tools like JOSM validator. There are other reasons why JOSM and its plugins should ideally have access to the driving_side (implicit or explicit) of each way anyway. Other functionality affected by it includes the Lanes Details style and the Turn Lanes plugin. And this functionality is not made easier by the new value. Introducing a value just for the sake of one test case within a subset of the available validators isn't worth it imo, especially as it only detects unnecessary rather than wrong data. ___ 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] Driving side
While I suggested the value opposite with the same reasoning as Pieren i.e. to guarantee this tag is used on ways only when necessary; the truth is there wouldn't be any guarantee because the values left and right still exist (though theorically only for countries). The advantage of *not* having opposite as a value is not to need to verify the country's driving_side to be able to tell which driving_side that way has. Since we need to use validator rules anyway, we could use: 1. driving_side is only allowed ways that belong to countries that have driving_side specified; 2. driving_side (on ways) must have the opposite value of the driving_side specified in that country. 2014-03-25 5:51 GMT-03:00 Pieren pier...@gmail.com: On Mon, Mar 24, 2014 at 4:37 PM, Tobias Knerr o...@tobias-knerr.de wrote: Could you elaborate? The left/right is only on boundary relations. The opposite is only on ways. This will also avoid a proliferation of unnecessary driving_side=left/right on ways where it's only required for the non-default rule. Pieren ___ 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] Driving side
The current values would work well for both streets and countries, so keep them. Actually, that's why I want to change it. I think having only one value (driving_side=opposite (or inverted)) would be better to tag highways. It is a little shameful to admit it, but sometimes I confuse left and right; so by restricting this tag's values there wouldn't be any confusion, and restrict it's use only to highways that actually need them (besides making it simpler to use). This tag never went through a formal proposal process, and have very few uses, so I think there is no impediment for changing it's use. Of course, another option is to restrict *left/right* values to countries and the *inverted* value to highways, but if there is no interest to applying this tag to the countries, then it might as well be restricted to highways. 2014-03-22 8:09 GMT-03:00 Tobias Knerr o...@tobias-knerr.de: On 21.03.2014 21:07, John Packer wrote: There are, in my city, a couple of streets that have an /inverted/ driving side. So I am going to extend this tag's documentation to include ways that have it's driving side opposite to it's country's normal driving side. That's a good and useful extension, as has already been mentioned on the key's talk page. So I suggest you go ahead and extend it. Perhaps, with this new definition, this tag could be redefined to have only one value: driving_side=opposite (this way, it could avoid any confusion about it's use) What do you think? I don't think there is any good reason to force someone who wants to tag countries' driving sides to invent new tags. The current values would work well for both streets and countries, so keep them. ___ 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] Driving side
You are right, since these streets are rare, there is no need to add the value inverted. With a tag that has been used on 4 countries and 14 highways, it's a bit too early to analyse mappers' interest imo. Actually, it's not early, this tag was documented since early 2012. But let's hope this lack of interest can change now. Ok, I have officially extended this tag's use on highways. Please review: http://wiki.openstreetmap.org/wiki/Key:driving_side One question: I am using the following template on this wiki page to show one example: map lat=-26.30884 lon=-48.84413 z=17 w=350 h=100 format=jpeg layer=mapnik/ However I want to use Mapnik's zoom level 19. But the wiki won't let me have zoom levels bigger than 17. I believe this template was not updated to know Mapnik support bigger zoom levels. Does someone knows how to fix this? Thanks 2014-03-22 11:24 GMT-03:00 Tobias Knerr o...@tobias-knerr.de: On 22.03.2014 14:30, John Packer: I think having only one value (driving_side=opposite (or inverted)) would be better to tag highways. It is a little shameful to admit it, but sometimes I confuse left and right; so by restricting this tag's values there wouldn't be any confusion, and restrict it's use only to highways that actually need them (besides making it simpler to use). It's not only highways that need them. That would tell an application about the exceptions, but how is it supposed to know the default driving side for a country if it isn't tagged? Of course the application could consult an external database, but by that reasoning, countries (and cities) wouldn't need population tags, translated names, ISO-Codes, currency tags and so on either. Nevertheless, some people like to map all that and we have keys for these purposes. That using these values poses a problem for people who confuse left and right is unfortunate, but with those inverted highways being really rare, I think looking at a labelled left/right arrow before tagging it would be a feasible workaround? This tag never went through a formal proposal process, and have very few uses, so I think there is no impediment for changing it's use. Changing it wouldn't be a problem, which is why I support adding highways as a use case. I just don't think changing the values would be an improvement. Of course, another option is to restrict /left/right/ values to countries and the /inverted/ value to highways, but if there is no interest to applying this tag to the countries, then it might as well be restricted to highways. With a tag that has been used on 4 countries and 14 highways, it's a bit too early to analyse mappers' interest imo. Tobias ___ 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] Driving side
There is a tag documented on the wiki called driving_sidehttp://wiki.openstreetmap.org/wiki/Key:driving_side =right/left. According to it's description, this tag should only be used on countries, and it describes the side of the traffic in the whole country. So far so good, but according to taginfo it is used only once on a relation, however there are some uses on some ways, and even nodes(?). There are, in my city, a couple of streets that have an *inverted* driving side. So I am going to extend this tag's documentation to include ways that have it's driving side opposite to it's country's normal driving side. Is there any interest of using it on countries? If there is not, I will exclude the possibility of use on countries from this tag's documentation. Perhaps, with this new definition, this tag could be redefined to have only one value: driving_side=opposite (this way, it could avoid any confusion about it's use) What do you think? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Driving side
It's been defined for countries, and is used on it, as you said. I don't think I said that, all I said was according to taginfo it is used only *once* on a relation. If people aren't going to use it, I intend to restrict it's use to streets. It seems it wasn't formally proposed anyway. I don't see why there should be any distinction regarding the driver's side. One more thing: this only makes sense if there is no physical barrier between the opposite traffic directions. If there is, then it's just a separate way with no special change in driving side. The streets I mentioned do not have any physical barrier. Also, there are some signs indicating they use an inverted driving side (Mão inglesa) This is one of these streets: http://www.openstreetmap.org/way/266622965 2014-03-21 17:24 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: I wonder what you mean by Is there any interest of using it on countries?. It's been defined for countries, and is used on it, as you said. You could simply tag the country with driving_side=right/left and use the same (but with the opposite value) on those streets. That said, I think driving side also implies driver side inside the vehicle. Though I find it very unlikely to see this information in use one day, it's best to define this meaning early on. A change of driver side requires either a change of vehicle or some special vehicle that can drive on both sides. In the case of your city, driving side changes, but driver side doesn't. You could include that in the description of opposite. One more thing: this only makes sense if there is no physical barrier between the opposite traffic directions. If there is, then it's just a separate way with no special change in driving side. On Fri, Mar 21, 2014 at 5:19 PM, Fernando Trebien fernando.treb...@gmail.com wrote: On Fri, Mar 21, 2014 at 5:07 PM, John Packer john.pack...@gmail.com wrote: There is a tag documented on the wiki called driving_side=right/left. According to it's description, this tag should only be used on countries, and it describes the side of the traffic in the whole country. So far so good, but according to taginfo it is used only once on a relation, however there are some uses on some ways, and even nodes(?). There are, in my city, a couple of streets that have an inverted driving side. So I am going to extend this tag's documentation to include ways that have it's driving side opposite to it's country's normal driving side. Is there any interest of using it on countries? If there is not, I will exclude the possibility of use on countries from this tag's documentation. Perhaps, with this new definition, this tag could be redefined to have only one value: driving_side=opposite (this way, it could avoid any confusion about it's use) What do you think? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ 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] layer=-1, rivers, bridges and tunnels
I believe there was a proposal for tagging a bridge separately: man_made=bridge. I think it would be really nice to have the actual outline of the bridge rendered Em 15/03/2014 10:02, Peter Wendorff wendo...@uni-paderborn.de escreveu: Hi, I agree partially with you here. Yes, adding bridges in addition to the road is possible and may be a good idea. What we currently map as being a bridge in fact is the property of the road is on a bridge instead. Changing the current tagging scheme to duplicate the corresponding segment of the way and tag the bridge as a separate, but again linear object is worse in all but one point. The only point this is better in is that a street with a continuous name may not have to be splitted because of the bridge; but on the other hand we do so for anything else, too: speed restrictions, footway or not, highway type, surface and anything else; so it doesn't solve an issue dedicated to bridges. On the other hand it doesn't solve the issue with multiple parallel ways on the same bridge, e.g. considering a dual carriage way on one bridge construction we currently map the property road is on a bridge again on both parts of the dual carriage way independently, but it's impossible to decide from the data (usually) if it's one bridge or two bridges. Your proposal to duplicate the way does not solve this issue either, as you would still need two separate ways here. regards Peter Am 15.03.2014 13:25, schrieb André Pirard: Hi, I wonder why we make bridges split and split and split the roads. In reality, bridges are pieces of concrete or stonework at level -1 under an uninterrupted foil of tarmac at level 0. Or at level 0 if it's understood that the renderer knows what's a bridge. And the renderer knows, as it draws two thin stripes beside the road. So, a bridge can be a little way segment overlaying the road. This lets the routing software ignore the unnecessary complication of having to account for bridges as part of the route. This lets the bridge having its own attributes, unrelated to the road, for example a different name. This makes obsolete discussions wondering if the bridge must be split in two because the road changes in the middle. Etc. etc., all pieces clutch in very neatly. And BTW, this is similar to tunnel=culvert which is an optional feature of a bridge and that surprises no one at layer -1. And now, if we put bridges and culverts at -1, the rivers or streams are normally at -2. Tunnels (inside which the road runs) should be segments too, at level +1 or 0. I have tagged a number of streams and rivers at -2 -1 0 and I find it appreciable to have an instant view of where the complete main stream is, if not exaggeratedly long, as well as less prone to errors. Cheers, André. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] leisure=events
I think it should be either amenity=* or landuse=*. leisure=* sounds odd, since the place can be vacant most of the time(and not accessible during that time). 2014-03-12 18:15 GMT-03:00 Martin Koppenhoefer dieterdre...@gmail.com: 2014-03-12 22:12 GMT+01:00 Antônio Marcos toni.o...@gmail.com: But still is there any other key other than landuse or leisure that fits better with event_space? for me leisure is OK, amenity would be fine as well. Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - amenity=boat_sharing
Perhaps you should also post the proposal to the mailing list of these countries that actually have boat sharing, to try to gather more interest. 2014-03-03 10:52 GMT-03:00 SomeoneElse li...@mail.atownsend.org.uk: nounours77 wrote: Dear all, Just to remind you that the proposal https://wiki.openstreetmap.org/wiki/Proposed_features/boat_sharing is still open for comments. If you think that it's an important thing to map, and it fulfills the usual criteria (e.g. verifiability), I'd just go and map it - I wouldn't worry too much about a formal proposal and the lack of interest that there is with it. Cheers, Andy ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - All You Can Eat
Amigos, I no longer feel this proposal is appropriate, therefore I'm canceling it. Thanks for all your comments. I am creating another proposal to describe the serving system of a restaurant. It is based on all_you_can_eat:type from this proposal, which I found to be quite interesting when used properly. It is still in *Draft* status, and can be seen in the following link: http://wiki.openstreetmap.org/wiki/Proposed_features/Serving_System Cheers, John 2014-02-24 16:38 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: I remember having been to restaurants here in Brazil where the food that is served as all you can eat is not exactly the same as the one you may order from a regular menu. Not far from my home there is a restaurant that serves 3 cuisines at different times of the day (italian and japanese for dinner, and an all-you-can-eat regional buffet for lunch; I'm sure but they may operate a cafe for breakfast). Place all the values in the cuisine tag and you won't be able to tell at which time each cuisine is offered. How do you express that the all-you-can-eat service is offered only for the regional cuisine? Answer: you need 2 objects (nodes or areas) for that. But anyway, I'm with Martin, it's best to use :service_times to avoid confusion with the regular opening_hours tag. The place is usually open (offering its regular service) for a longer period than that in which it offers an all you can eat service. On Sat, Feb 22, 2014 at 4:37 PM, Paul Johnson ba...@ursamundi.org wrote: On Monday, February 17, 2014, Steve Doerr doerr.step...@gmail.com wrote: On 17/02/2014 18:04, Fernando Trebien wrote: I still think that opening_hours as a subtag would be an unnecessary specialization that would only be needed rarely. Can you provide an example in which you would not be able to represent that information in a different way? (such as using two or more geometric objects) It's quite common in the UK for a restaurant to operate as a normal, a la carte restaurant most of the week, and offer an all-you-can-eat buffet on, say, Sundays. I'm at a loss to understand why that would be represented as two separate geometric objects. Yeah, I've been trying to think of a use case scenario that makes sense for this, and I can't. It seems to be more in line with the expectation typical by cuisine. For instance, Genghis Grill seems to be about the only chain around that doesn't consider Mongolian. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - All You Can Eat
When you say no longer appropriate, do you mean to say the all_you_can_eat idea is not appropriate, or that working through the approval procedure got bogged down? ;-) I feel the idea is not appropriate, at least not to my initial needs. I started this proposal to be able to tag some buffets and rodízios (which usually are all-you-can-eat), and tried to be more generic. But seeing the comments and after further reflection, I think I got off track. That's why I am drafting another proposal to directly address my needs (how to tag some kinds of serving systems). In a first reading of the new proposal I see you did not include all_you_can_eat as a value or tag and I assume you now want to use buffet, smorgasbord, etc., to indirectly say that, right? There is some overlap, but I believe tagging something as a buffet doesn't necessarily mean it would be an all-you-can-eat option. A rodízio hardly will not be an all-you-can-eat option, but this is not 100% of certainty either. 2014-02-28 21:33 GMT-03:00 Dave Swarthout daveswarth...@gmail.com: @John, When you say no longer appropriate, do you mean to say the all_you_can_eat idea is not appropriate, or that working through the approval procedure got bogged down? ;-) In a first reading of the new proposal I see you did not include all_you_can_eat as a value or tag and I assume you now want to use buffet, smorgasbord, etc., to indirectly say that, right? On Sat, Mar 1, 2014 at 7:18 AM, Bryce Nesbitt bry...@obviously.comwrote: On Fri, Feb 28, 2014 at 4:15 PM, John Packer john.pack...@gmail.comwrote: Amigos, I no longer feel this proposal is appropriate, therefore I'm canceling it. Thanks for all your comments. Remember it's still OK to write a note (in the local language preferably) associated with any node. Not everything is destined to be a tag. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fwd: tag for planetarium
I would argue the main public of planetariuns are tourists. 2014-02-25 9:56 GMT-03:00 Martin Koppenhoefer dieterdre...@gmail.com: 2014-02-25 12:02 GMT+01:00 Pieren pier...@gmail.com: Unfortunatelly, today in OSM, a museum is more considered as a touristic attraction than a place for education and works of art preservation. +1 (also to the rest). I favor amenity=planetarium cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fwd: tag for planetarium
Maybe my last email was unclear. I vote on tourism=planetarium 2014-02-25 10:02 GMT-03:00 John Packer john.pack...@gmail.com: I would argue the main public of planetariuns are tourists. 2014-02-25 9:56 GMT-03:00 Martin Koppenhoefer dieterdre...@gmail.com: 2014-02-25 12:02 GMT+01:00 Pieren pier...@gmail.com: Unfortunatelly, today in OSM, a museum is more considered as a touristic attraction than a place for education and works of art preservation. +1 (also to the rest). I favor amenity=planetarium cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] closing-hours
if you're very versed in openening_hours tagging (which I am not) you can AFAIK even express stuff like except every last wednesday in the month from 9:00 to 17:00 (something occuring here e.g. for street cleaning). That's actually related to something I need to do here. How can I describe a different opening hours for the first saturday of every month? PS: Sorry for hijacking this conversation. 2014-02-25 11:33 GMT-03:00 Martin Koppenhoefer dieterdre...@gmail.com: 2014-02-25 15:24 GMT+01:00 Peter Wendorff wendo...@uni-paderborn.de: Hi André, as far as I know, the same would be possible with opening_hours=24/7, Fr 14:00-22:00 off +1 if you're very versed in openening_hours tagging (which I am not) you can AFAIK even express stuff like except every last wednesday in the month from 9:00 to 17:00 (something occuring here e.g. for street cleaning). cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] wiki definition for man_made=works
There is an interesting question on this tag's talk page: I think it collide with building=industrial, building=factory and landuse=industrial and i propose to delete this Tag. Or why should we use this Tag? cptechnik - Peter Coenen - Windeckhttps://wiki.openstreetmap.org/wiki/User:Cptechnik( talkhttps://wiki.openstreetmap.org/w/index.php?title=User_talk:Cptechnikaction=editredlink=1) 22:06, 31 July 2013 (UTC) 2014-02-25 13:36 GMT-03:00 Martin Koppenhoefer dieterdre...@gmail.com: Am 25/feb/2014 um 17:27 schrieb Martin Koppenhoefer dieterdre...@gmail.com: Am 25/feb/2014 um 17:10 schrieb Pieren pier...@gmail.com: Why not. But what about this sentence : landuse=industrial to show the area around the building. ? IMHO the building should be included. There's no problem in tagging all areas that are industrially used with landuse=industrial, so my suggestion is to add landuse=industrial to works if it's missing. Another possible question is whether to add landuse=commercial to offices inside the plant, which I'd reply with not in general, maybe yes if it is a big and or fenced area of only offices that happens to be enclosed by the plant. If a producing /manufacturing company has an administrative site outside of producing facilities this would not be industrial of course. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] wiki definition for man_made=works
Then I think I am confused too. As the description is right now, what is the difference between building=factory and man_made=works ? Do note that product=* and/or produce=* is not necessarily tied to man_made=works. I see man_made=works is much more used than building=factory, so I probably am missing something here. 2014-02-25 16:26 GMT-03:00 Martin Koppenhoefer dieterdre...@gmail.com: 2014-02-25 17:44 GMT+01:00 John Packer john.pack...@gmail.com: There is an interesting question on this tag's talk page: I think it collide with building=industrial, building=factory and landuse=industrial and i propose to delete this Tag. Or why should we use this Tag? I think he is confused ;-) you can find documentation about building and landuse in the wiki that give their definitions, usually it should be the tag or key page. I cannot see a collission but sometimes there is overlap, which is not necessarily something bad. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - All You Can Eat
So now, what's the difference in /serving style/ between rodizio and dim
sum?
I never went to a restaurant with *dim sum*, but reading about it on
wikipedia, I would say the differences are:
In a rodízio, the waiters go around offering food, and don't leave food on
a table unless requested by the clients upon offering. Also, in rodízio,
the food doesn't come in plates, so there is no system for counting the
expenses(I haven't heard of a rodízio that's not all-you-can-eat).
2014-02-17 15:52 GMT-03:00 Serge Wroclawski emac...@gmail.com:
On Sat, Feb 15, 2014 at 7:57 AM, John Packer john.pack...@gmail.comwrote:
Actually, all_you_can_eat:type=* describes the *way* the food is served.
If the value is buffet, then people go to the food to get it; if the
value is rodízio, then waiters go around the restaurant offering samples
of food to each table;
I think type is the wrong word, and I hate subtags, so why not simply
serving={buffet|whatever...}
So now, what's the difference in /serving style/ between rodizio and dim
sum?
if the value is conveyor_belt, then people sit around a rotating table
which carries the food(probably always used for sushi); and so on.
Fine so far, but I cannot see a need for a separate
all_you_can_eat:opening_hours subtag when the normal opening_hours tag would
serve the purpose.
It should only be used for special cases. For example, if a cafe has an
all-you-can-eat happy hour every friday afternoon, then you might include
all_you_can_eat:opening_hours=Fr
14:00-18:00.
This all seems like too much microtagging..
- Serge
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - All You Can Eat
Updated the proposal.
Summary of changes:
1. combined subtag :opening_hours with the main tag (inspired by the tags
lit and fee)
2. removed value only from main tag
3. added value special to main tag
4. renamed subtag :type to serving_system (should I move this to a new
proposal?)
2014-02-17 16:33 GMT-03:00 John Packer john.pack...@gmail.com:
So now, what's the difference in /serving style/ between rodizio and dim
sum?
I never went to a restaurant with *dim sum*, but reading about it on
wikipedia, I would say the differences are:
In a rodízio, the waiters go around offering food, and don't leave food on
a table unless requested by the clients upon offering. Also, in rodízio,
the food doesn't come in plates, so there is no system for counting the
expenses(I haven't heard of a rodízio that's not all-you-can-eat).
2014-02-17 15:52 GMT-03:00 Serge Wroclawski emac...@gmail.com:
On Sat, Feb 15, 2014 at 7:57 AM, John Packer john.pack...@gmail.comwrote:
Actually, all_you_can_eat:type=* describes the *way* the food is
served. If the value is buffet, then people go to the food to get it;
if the value is rodízio, then waiters go around the restaurant offering
samples of food to each table;
I think type is the wrong word, and I hate subtags, so why not simply
serving={buffet|whatever...}
So now, what's the difference in /serving style/ between rodizio and dim
sum?
if the value is conveyor_belt, then people sit around a rotating table
which carries the food(probably always used for sushi); and so on.
Fine so far, but I cannot see a need for a separate
all_you_can_eat:opening_hours subtag when the normal opening_hours tag
would
serve the purpose.
It should only be used for special cases. For example, if a cafe has an
all-you-can-eat happy hour every friday afternoon, then you might include
all_you_can_eat:opening_hours=Fr
14:00-18:00.
This all seems like too much microtagging..
- Serge
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - All You Can Eat
John, at this point, would you please you put all this into a summary, or
a full proposal, so we can see the entire package?
Do you mean this?:
http://wiki.openstreetmap.org/wiki/Proposed_features/All_you_can_eat
I think I should better document the serving_system values. I will do that
this week for sure.
2014-02-17 20:57 GMT-03:00 Dave Swarthout daveswarth...@gmail.com:
So now, what's the difference in /serving style/ between rodizio and dim
sum?
The former is a serving style while the latter is a cuisine. The latter
might also appear in restaurants that employ a serving style of rodizio.
Btw, this is the first time I've been exposed to that term either in print
or in reality but coincidentally, I ate lunch at such a place the the other
day here in Chiang Mai. We ate quite a bit of food there as they just
continued to bring it to the table
John, at this point, would you please you put all this into a summary, or
a full proposal, so we can see the entire package?
Cheers,
Dave
On Tue, Feb 18, 2014 at 3:57 AM, John Packer john.pack...@gmail.comwrote:
Updated the proposal.
Summary of changes:
1. combined subtag :opening_hours with the main tag (inspired by the
tags lit and fee)
2. removed value only from main tag
3. added value special to main tag
4. renamed subtag :type to serving_system (should I move this to a new
proposal?)
2014-02-17 16:33 GMT-03:00 John Packer john.pack...@gmail.com:
So now, what's the difference in /serving style/ between rodizio and dim
sum?
I never went to a restaurant with *dim sum*, but reading about it on
wikipedia, I would say the differences are:
In a rodízio, the waiters go around offering food, and don't leave food
on a table unless requested by the clients upon offering. Also, in rodízio,
the food doesn't come in plates, so there is no system for counting the
expenses(I haven't heard of a rodízio that's not all-you-can-eat).
2014-02-17 15:52 GMT-03:00 Serge Wroclawski emac...@gmail.com:
On Sat, Feb 15, 2014 at 7:57 AM, John Packer john.pack...@gmail.comwrote:
Actually, all_you_can_eat:type=* describes the *way* the food is
served. If the value is buffet, then people go to the food to get it;
if the value is rodízio, then waiters go around the restaurant
offering samples of food to each table;
I think type is the wrong word, and I hate subtags, so why not simply
serving={buffet|whatever...}
So now, what's the difference in /serving style/ between rodizio and
dim sum?
if the value is conveyor_belt, then people sit around a rotating
table which carries the food(probably always used for sushi); and so on.
Fine so far, but I cannot see a need for a separate
all_you_can_eat:opening_hours subtag when the normal opening_hours
tag would serve the purpose.
It should only be used for special cases. For example, if a cafe has
an all-you-can-eat happy hour every friday afternoon, then you might
include all_you_can_eat:opening_hours=Fr 14:00-18:00.
This all seems like too much microtagging..
- Serge
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - All You Can Eat
It seems I was too brief in my initial email, so let me clarify. What I am proposing *is not* cuisine=all_you_can_eat. I am proposing three new tags: all_you_can_eat, all_you_can_eat:opening_hours and all_you_can_eat:type. I am in complete agreement cuisine=all_you can_eat and cuisine=buffet are not a suitable alternative for my proposal. 2014-02-15 8:19 GMT-02:00 Dave Swarthout daveswarth...@gmail.com: The problem with cuisine=all_you_can_eat is that All you can eat is a pricing scheme, not a cuisine. This would prevent tagging with the actual cuisine, such as cuisine=Chinese or cuisine=Mediterranean. +1 cuisine=* should be reserved for the actual type of food, not the pricing/serving scheme. Agreed. +1 On Sat, Feb 15, 2014 at 1:06 PM, Shawn K. Quinn skqu...@rushpost.comwrote: On Fri, Feb 14, 2014, at 09:03 PM, John F. Eldredge wrote: The problem with cuisine=all_you_can_eat is that All you can eat is a pricing scheme, not a cuisine. This would prevent tagging with the actual cuisine, such as cuisine=Chinese or cuisine=Mediterranean. +1 cuisine=* should be reserved for the actual type of food, not the pricing/serving scheme. -- Shawn K. Quinn skqu...@rushpost.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - All You Can Eat
Reading up on Wikipedia (http://en.wikipedia.org/wiki/All-you-can-eat#All-you-can-eat_.28AYCE.29), this tag could also be shortened to ayce=yes/no. I agree all_you_can_eat=* is a little long, however I would like to keep it that way. Because if another mapper saw a place with ayce=*, he probably would not be able to tell it's meaning without consulting the wiki. At least I know I wouldn't. 2014-02-14 22:49 GMT-02:00 Fernando Trebien fernando.treb...@gmail.com: There are many all-you-can-eat restaurants in North America too, and just like here, the actual food type (cuisine) may vary considerably. Reading up on Wikipedia (http://en.wikipedia.org/wiki/All-you-can-eat#All-you-can-eat_.28AYCE.29), this tag could also be shortened to ayce=yes/no. On Fri, Feb 14, 2014 at 10:33 PM, John Packer john.pack...@gmail.com wrote: What does taginfo suggest people are currently tagging places with an all you can eat option as? The closest I was able to find were 2 uses of cuisine=all_you_can_eat, 1 use of note=all_you_can_eat, 5 uses of buffet=yes and 68 uses of cuisine=buffet. The tag cuisine=buffet might have a considerable number of uses, however cuisine=* describes the type of food, not the way the food is served. Also my proposal is not specific to buffets, and allows other styles of all-you-can-eat syles(like rodízios). I'm not sure about the other countries, but I can say this tag will be pretty useful in Brazil, where things like rodízios and buffets are considerably common. Of course, I tried to include every case I could imagine. 2014-02-14 22:07 GMT-02:00 SomeoneElse li...@mail.atownsend.org.uk: John Packer wrote: http://wiki.openstreetmap.org/wiki/Proposed_features/All_you_can_eat What does taginfo suggest people are currently tagging places with an all you can eat option as? I'm not convinced that this necessarily needs a proposal... Cheers, Andy ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
