Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists
Which too schemes? I think you'd need to be more specific. As for deprecating semicolon-delimited lists. I don't think it's practical to abolish them completely, so they'll have to stay. I do agree that it makes sense to try and avoid them as much as possible, but it's simply not always possible. As for the remark that route_ref shouldn't exist, and that information should be in route relations. Well there are bus lines which may never have route relations. (on demand buses which don't have a fixed route, school buses, market day buses, Sunday and Friday evening special service fares to get students home, etc.). But it's still information which is not hard to map when surveying, and which is good to have when no route relation has been set up yet, or to validate the correctness of the route relation. About the remark that it's hard to figure out whether an item is missing from the list. I'm sorry, but it's not because 7;8;10;11 are there that 9 necessarily is missing from the list. I deleted everything which was hidden under the three dots. Jo ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Electronic or 'e' cigarettes?
On 22 January 2015 at 14:02, Dave F. dave...@madasafish.com wrote: A shop that solely sells electronic cigarettes has been added locally. I guess this type of product will be on the increase so I think it's best to clarify unified tag, if there's ever been such a thing in OSM :-) Yes, I also think this is one of the more common shops that has no clear defined tag. Checking Tag-info it's 8/6 in favour of electronic_cigarettes over e-cigarettes. Currently, the most common tag is shop=e-cigarette: e-cigarette x170 e_cigarette x10 electronic_cigarettes x8 electronic_cigarette x4 e-cigarettes x6 To me, electronic_cigarettes is clearer should be used, but I thought it best to discuss first. I don't smoke, are all these power based? I understand your argument in favour of shop=electronic_cigarettes. If you think it's worth it, feel free to start a proposal to change the name. -- Matthijs ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists
Hi Jo/Polyglot and list, On 22 January 2015 at 12:01, Jo winfi...@gmail.com wrote: Which too schemes? I think you'd need to be more specific. 1. key=values;separated;by;semicolon 2. several key:subkey=* route_ref:De_Lijn=1;2;3;4;5;6;7;8;9;284;285;310;315;316;317;333;334;335;337;351;352;358;370;371;372;373;374;380;395;520;524;525;537;586;597 I don't know if this is a real or fictitious example, but try not to hit the limit of 255 characters for values. ;) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists
On Thu, Jan 22, 2015 at 12:59 PM, althio althio althio.fo...@gmail.com wrote: I even find the second example more difficult to visualize. It's just worse than the first in every respect. From a mapper's point of view My little +1 for key:subkey=* New people don't know how to add new keys. So they will have problems to add cuisine:antwerp = yes (in case such a thing would exist :-) ). it's much easier to come up with cuisine=Antwerp, especially when there is an input field cuisine. regards m. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Deprecation of associatedStreet-relations
2015-01-22 6:53 GMT+00:00 Marc Gemis marc.ge...@gmail.com: It seems like the German community started some voting process on the deprecation of the associatedStreet-relation (it was on the mailing list and on the forum). Discussion is going on on the wiki https://wiki.openstreetmap.org/wiki/DE:Relation:associatedStreet Hi all - does anyone know what the geographic distribution of associatedStreet is like? taginfo doesn't render a map (it seems it doesn't do that for relations). I hear rumours it's mainly Germany but it'd be handy to know. Best Dan ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Deprecation of associatedStreet-relations
Hi all - does anyone know what the geographic distribution of associatedStreet is like? taginfo doesn't render a map (it seems it doesn't do that for relations). This shows a map, I don't know if this is what you are looking for: http://taginfo.openstreetmap.org/tags/type=associatedStreet#map http://taginfo.openstreetmap.org/tags/type=associatedStreet#combinations also shows that 61 307 / 218 176 = 28.10% are also tagged with ref:FR:FANTOIR=* so from France. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Electronic or 'e' cigarettes?
Hi A shop that solely sells electronic cigarettes has been added locally. I guess this type of product will be on the increase so I think it's best to clarify unified tag, if there's ever been such a thing in OSM :-) Checking Tag-info it's 8/6 in favour of electronic_cigarettes over e-cigarettes. To me, electronic_cigarettes is clearer should be used, but I thought it best to discuss first. I don't smoke, are all these power based? Dave F. --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
On 21.01.2015 08:28, Markus Lindholm wrote: Before we get carried away by a zillion relations I think we have to answer the questions as to what purpose do we want to explicitly associate an address with a POI or a building. Is it so that the data consumer can find her way to a POI? That's obviously superfluous as the POI already has a geographical location given. But not the address, according to your suggestion to keep addresses in separate nodes. Concerning buildings, an address node is imprecise. It may be on one side of the building, while you'd better come from the other side of the building. Search Nominatim for my postal address Davidgasse 76-80 and click the House in the search results. You couldn't achieve that with a single address node. In fact, the address node would be at the southern end of the building complex, while I live at the northern end, so you wouldn't find your way to my appartement. The only purpose I can think of is to facilitate for the data consumer to send a physical letter to the POI and that is a bit of a fringe use case. With buildings is even murkier as to what the purpose would be. Is there any country where the address would be part of the ID for the building in the cadastre? Seems unlikely as a building can have many addresses. I think that we don't need to care about the cadastre. It's something independent from OSM. I think we should generally not ponder about application purposes too much. The purpose of tagging is to represent data in a clean and unambigous way. Leave it over to applications to do something with it or not. If someone wants to make a carnival report on whether buildings with even or odd housenumbers are larger, why not? So I'm not advocating that a zillion relation be created, just that if you REALLY need an EXPLICIT association between an address and a POI/building then you should use a relation. And that addresses would be stored in the database in a coherent manner. That mixes the needs of mappers and data consumers. As a mapper, I don't need such an association at all. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists
It's an actual example: https://www.openstreetmap.org/node/80725474 https://delijn.be/nl/haltes/halte/303059 (real time information) 121 characters... there's still some breathing room. I guess the risk of the street getting congested is higher than hitting the 255 characters limit. Jo ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
Hi Friedrich. I can't say for whole World, as for Russia we have plots of lands having addresses without buildings. They are not always dedicated to be build up with something. There is three ways, (maybe more, but i don't know for sure): 1. Large landuses as landuse=industrial may have their own address, like. Springfield, Green Road, 123. and every building inside this territory have their own address like: Springfield, Green Road, 123, building 2. (Keep in mind that we traditionally have different addresses parts order). 2,3. Rather small land lots with demolished or not yet constructed buildings. We can say that they are dedicated to be built up with something in future, but they may appears empty for ages. It's rather common situation for rural areas, when owner have purchased land lot, but haven't built capital house yet. But these lots should have addresses for mail correspondence and fees. Wed, 21 Jan 2015 21:02:14 -0600 от John F. Eldredge j...@jfeldredge.com: On 01/19/2015 03:39 AM, Friedrich Volkmann wrote: On 18.01.2015 22:23, Markus Lindholm wrote: I think that comes down to how addresses are viewed, either as a proper feature in their one right or as an attribute to some other feature. Yes, that's the crux. I think addresses are proper features, so a distinct address should be found only once in the database. And I see it the other way. Addresses are just attributes. It may pendend on the country, I don't know. In Austria and most certainly in entire central Europe, an address is always bound to a building, apartment or strictly delimited plot of land. An address cannot exist on its own. Every address includes a housenumber, indicating that there's a house. There are no addresses in the midst of a lake or somewhere in the cliffs. If you have a strictly delimited plot of land, with no house currently built upon it, but which is intended for later construction, does it have a house number? Or is the address only assigned once a building is built? -- John F. Eldredge -- j...@jfeldredge.com Darkness cannot drive out darkness; only light can do that. Hate cannot drive out hate; only love can do that. Dr. Martin Luther King, Jr. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Deprecation of associatedStreet-relations
Hi, Am 22. Januar 2015 11:45:47 MEZ, schrieb althio althio althio.fo...@gmail.com: Please vote here: https://wiki.openstreetmap.org/wiki/Talk:Relation:associatedStreet Is this a formal voting? It is not as formal as a proposal voting. I would like to know how the community (those who vote) think about associatedStreet relations. I think that in Germany the majority does not like them (anymore). Is there a date for start and end vote? No, there is no end date at the moment. Start date was yesterday. I will announce a end date. This end date will be date of announcement of end of voting + 14 days. It looks strange, hidden on a Talk:page without the usual template or RFC or call for votes on the international mailing lists. German forum and talk-de have been notified by myself. You may notify your local community if it will not read the next issue(s) of weeklyOSM. Best regards Michael -- Diese Nachricht wurde auf einem Smartphone verfasst, ist daher nicht GPG-signiert und enthält Tippfejler. This message was been written on a smartphone. That's why it is not GPG-signed and may contain tyops. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
On 22.01.2015 04:02, John F. Eldredge wrote: If you have a strictly delimited plot of land, with no house currently built upon it, but which is intended for later construction, does it have a house number? Or is the address only assigned once a building is built? When it is already intended for later construction, it usually already has an address (including house number or conscription number) assigned. But again, I can only speak of Austria. So we have three levels of estimated vs. fully surveyed address mapping: 1) address nodes: we know that the address is valid somewhere around that point 2) address as building attribute: we know at least one building where the the address is valid 3) address as plot attribute: we know the entire area where the address is valid Of course, the building may occupy the whole plot, especially in cities. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists
Rattling on about those bus stops, I have an other example: https://www.openstreetmap.org/node/485938967 bus http://wiki.openstreetmap.org/wiki/Key:bus?uselang=en-US yes highway http://wiki.openstreetmap.org/wiki/Key:highway?uselang=en-US bus_stop http://wiki.openstreetmap.org/wiki/Tag:highway=bus%20stop?uselang=en-US name http://wiki.openstreetmap.org/wiki/Key:name?uselang=en-US Porte de Hal - Hallepoort name:fr http://wiki.openstreetmap.org/wiki/Key:name:fr?uselang=en-US Porte de Hal name:nl http://wiki.openstreetmap.org/wiki/Key:name:nl?uselang=en-US Hallepoort network http://wiki.openstreetmap.org/wiki/Key:network?uselang=en-US DLVB;IBXL;TECB;TECC;IBXL operator http://wiki.openstreetmap.org/wiki/Key:operator?uselang=en-US De Lijn;STIB/MIVB;TEC;STIB/MIVB public_transport http://wiki.openstreetmap.org/wiki/Key:public%20transport?uselang=en-US platform http://wiki.openstreetmap.org/wiki/Tag:public%20transport=platform?uselang=en-US ref:De_Lijn 301026 ref:TECB Bsgipha1 ref:TECC Cbxhal1 route_ref http://wiki.openstreetmap.org/wiki/Key:route%20ref?uselang=en-US 27 route_ref:De_Lijn 136;137 route_ref:TECB W;123 route_ref:TECC 365a zone:De_Lijn 20 zone:TEC 6220 A bus stop served by 3 operators, of which one, there are 2 entitities each assigning their own identifier. For operator and network there are ; in those lists and I don't see what's the problem with those. For ref I don't want to find multivalue. For the rare occasions where this occurs (2 stops with different refs from the same operator), the nodes are duplicated, then grouped together in a stop_area. And before anybody says: we don't want those foreign keys in OSM, well the scripts I'm developing to assist contributors for adding route relations, heavily depend on them. Polyglot ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Deprecation of associatedStreet-relations
It is not as formal as a proposal voting. I would like to know how the community (those who vote) think about associatedStreet relations. I think that in Germany the majority does not like them (anymore). I will announce a end date. This end date will be date of announcement of end of voting + 14 days. German forum and talk-de have been notified by myself. You may notify your local community if it will not read the next issue(s) of weeklyOSM. Alright Michael, thanks for the details. Now that the international tagging list is notified thanks to this thread, I guess it does not really matter. But the starting process looked biased towards the German community. Mit freundlichen Grüssen althio ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Deprecation of associatedStreet-relations
Please vote here: https://wiki.openstreetmap.org/wiki/Talk:Relation:associatedStreet Is this a formal voting? Is there a date for start and end vote? It looks strange, hidden on a Talk:page without the usual template or RFC or call for votes on the international mailing lists. althio ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists
First point: It is good that several people invent, propose and use various schemes. Second point: At some point, unification of schemes with similar intent would be great. As usage grows, having the same kind of data treated differently is a pain for everyone, mappers, developers, maintainers and data consumers alike. I don't think one of the schemes is clearly superior to the other, only I wish that it could be open to discussion, open to improvements and settled. Once it is agreed upon (or enforced by any committee, anyone?), people can start to work on unified tagging, clear documentation, adapted presets and simpler algorithms with less cases or exceptions to handle. Or it is decided that we continue with the two schemes, that both are valid, accepted, documented for tagging and consumption. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Electronic or 'e' cigarettes?
On 22/01/2015, Andreas Goss andi...@t-online.de wrote: Using - instead of _ goes against a very established tagging practice. Only for whitespace as far as I know. So I don't see a issue here. That surprises me, but looking at a dump of Ireland (taginfo search is too coarse, so I used some local data I had) there does seem to be some cases, namely semi-detached and multi-storey. I wanted to search the british isles extract, but that's taking ages to process. I stand corrected. I would even say using _ is wrong. e_cigarette = e cigarette e-cigarette = e-cigarette It's not at all clear that e-cigarette is more common outside osm than e cigarette or ecigarette, as a google search will show you. On 22/01/2015, fly lowfligh...@googlemail.com wrote: Is it really to much typing to use electronic_cigarettes ? I don't think so, I'd be happy to use the more verbose, less marketing, less varied electronic_cigarette (singular, just because there's no more reason to make it plural than any other shop=* value... but it's a nitpick and I'm not going to argue about it if people feel otherwise). Anyway, I do not know a single shop in my area which only sells them so shop=* will never fit. I know a few that litterally sell just that. It's probably just a trend (anyone knows of a shop that only sells cigarettes ?) but a lot of them exist today. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Electronic or 'e' cigarettes?
On 22 January 2015 at 18:00, fly lowfligh...@googlemail.com wrote: Well the first page should be under proposal and it should not be listed under shop or if only under some proposal paragraph Only six shop types have been approved by the wiki/voting process: bakery, baby_care, second_hand, seafood, bookmaker, and lottery (and seafood is questionable due to not having the required number of votes). Do you suggest to list all other shop types, including well-known ones such as shop=supermarket, as 'under proposal'? The wiki page is very recent with only two contributors. I wouldn't be surprised if e-cigarette in the db was also contributed by no more than 1-2 mappers. I suggest contacting them to make sure that they are ok with e_cigarette, and then make the change to wiki and db. There are at least 30 mappers who have used shop=e-cigarette. Almost all of them started using this tag *after* user StephaneP imported about 80 e-cigarette shops in France. I also think that e-cigarette would be better than e_cigarette, as the - does not represent a space, and e-cigarette is a regular English word, used for instance in newspapers. -- Matthijs ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
Am 22.01.2015 um 04:02 schrieb John F. Eldredge: If you have a strictly delimited plot of land, with no house currently built upon it, but which is intended for later construction, does it have a house number? Or is the address only assigned once a building is built? In Germany the address always belongs to the plot and not to the building and they are assigned in advance. cu fly ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists
I even find the second example more difficult to visualize. It's just worse than the first in every respect. From a mapper's point of view My little +1 for key:subkey=* In free text like this thread, several key:subkey=* may look more heavy and complicated than key=values;separated;by;semicolon. _However_ I think this is reversed in the context of editors (iD, JOSM...) and elements lookup [1] where key and values are presented in tables. + key:subkey=* tabulated is easier to read + key:subkey=* tags are separated, it is slightly easier to select them and update, to delete one only, to add by copy/paste. + key=values;separated;by;semicolon means less typing/keystrokes but this is much mitigated by use of presets, auto-completion or copy/paste. [1] http://www.openstreetmap.org/way/106464005 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Electronic or 'e' cigarettes?
Existing pages: value e-cigarette is referenced in the wiki. http://wiki.openstreetmap.org/wiki/Tag:shop%3De-cigarette http://wiki.openstreetmap.org/wiki/Key:shop#Others The wiki page is very recent with only two contributors. I wouldn't be surprised if e-cigarette in the db was also contributed by no more than 1-2 mappers. I suggest contacting them to make sure that they are ok with e_cigarette, and then make the change to wiki and db. Indeed. I wanted to point to existing pages to explain the apparent choice of e-cigarette in taginfo. Also discussion on the Talk:page should be good starting point for a new proposal. Using - instead of _ goes against a very established tagging practice. I was wondering. Could you confirm that - is avoided in tags? It is not referenced at http://wiki.openstreetmap.org/wiki/Any_tags_you_like#Characters To me, electronic_cigarettes is clearer should be used You will have to decide if a common abbreviation is acceptable. [electronic_ OR e- OR e_] And as you noticed, singular vs plural. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists
Am 22.01.2015 um 18:08 schrieb Marc Gemis: On Thu, Jan 22, 2015 at 4:49 PM, althio althio.fo...@gmail.com mailto:althio.fo...@gmail.com wrote: Well at least iD knows quite well about the semi-colon: Just merge two ways together and you might get access=no;yes highway=primary;path without any warning. New people can have problems or make mistakes and then experienced users can help and point to recommended tagging or explain good practices . Not everybody reaches out to community for help. Probably many just stop mapping, requiring them to create a new key, instead of typing something in a free text field is not going to help IMHO. That is why I would be interested to mention the semi-colon on tag-pages where it is in common use. This helps in general for question about list or array, order or not. Or do you refer to iD (as the main editor for new people) where it is not possible to override presets to edit keys on the first part of the tag panel? What I tried to explain is that when you go for a tagging scheme where only cuisine:xxx=yes is allowed, the editor (iD) should offer a simple UI that allows people to create new values. In this case that means keys, since the values are actually in the keys. At this moment, it is also not possible to create JOSM presets that generates keys based on user input AFIAK. +1 Using a xxx:yyy schema also requires checkboxes besides every existing value in JOSM presets. So I don't see how it is any easier for new mappers or preset creators. Presets are a problem [1],[2] and it is not easy to present tag list with more than 50 tags per object. Cheers fly [1] https://josm.openstreetmap.de/ticket/6268 [2] https://josm.openstreetmap.de/ticket/8993 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Deprecation of associatedStreet-relations
Good to have this discussion. From a computer expert point-of-view relations are fantastic for data integrity and to keep database size low. From an OSM point-of-view, which includes being friendly towards novice users, relations should be avoided whenever possible. And associatedStreet relations are avoidable. Cheers, Johan 2015-01-22 21:46 GMT+01:00 Michael Reichert naka...@gmx.net: Hi, Am 2015-01-22 um 16:14 schrieb Vincent Pottier: Le 22/01/2015 14:00, althio a écrit : Hi all - does anyone know what the geographic distribution of associatedStreet is like? taginfo doesn't render a map (it seems it doesn't do that for relations). UK http://taginfo.openstreetmap.org.uk/tags/type=associatedStreet ~9000 PL http://taginfo.openstreetmap.pl/tags/type=associatedStreet ~1700 CZ /tags/type=associatedStreet ~ 100 HU http://taginfo.openstreetmap.hu/tags/type=associatedStreet ~ 130 SE http://se.taginfo.openstreetmap.se/tags/type=associatedStreet 900 RU http://taginfo.openstreetmap.ru/tags/type=associatedStreet 1850 FR is down No stats for DE This shows a map, I don't know if this is what you are looking for: http://taginfo.openstreetmap.org/tags/type=associatedStreet#map http://taginfo.openstreetmap.org/tags/type=associatedStreet#combinations also shows that 61 307 / 218 176 = 28.10% are also tagged with ref:FR:FANTOIR=* so from France. 28 % at least ! Overpass-API results for Germany (count function which is marked as experimental): 48.732 relations (I did not count their members) housenumbers in Germany total (including those which belong to associatedStreet relations): 7.762.395 [1] For comparison, number of addr:housenumber (number of associatedStreet relations in brackets, copied from above) in United Kingdom: 840 437 (9000) Poland: 5 173 771 (1700) Czech Republic: 2 824 442 (100) Hungary: 64 276 (130) Sweden: 341 533 (900) Russia: 2 444 832 (1850) [1] data from 2015-01-11, user Gehrke, https://wiki.openstreetmap.org/wiki/User:Gehrke#Entwicklung_des_Adressbestandes Best regards Michael -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. ___ 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] Electronic or 'e' cigarettes?
Am 22.01.2015 um 19:43 schrieb Matthijs Melissen: On 22 January 2015 at 18:00, fly lowfligh...@googlemail.com wrote: Well the first page should be under proposal and it should not be listed under shop or if only under some proposal paragraph Only six shop types have been approved by the wiki/voting process: bakery, baby_care, second_hand, seafood, bookmaker, and lottery (and seafood is questionable due to not having the required number of votes). Do you suggest to list all other shop types, including well-known ones such as shop=supermarket, as 'under proposal'? No, but it is common sence to introduce tags in proposal name space and once they are in common use accept them because of it use. The wiki page is very recent with only two contributors. I wouldn't be surprised if e-cigarette in the db was also contributed by no more than 1-2 mappers. I suggest contacting them to make sure that they are ok with e_cigarette, and then make the change to wiki and db. There are at least 30 mappers who have used shop=e-cigarette. Almost all of them started using this tag *after* user StephaneP imported about 80 e-cigarette shops in France. I also think that e-cigarette would be better than e_cigarette, as the - does not represent a space, and e-cigarette is a regular English word, used for instance in newspapers. No doubt about the spelling but still prefer a tag without abbreviation and advertising background. So call it by proper name. In my case electronic_cigarette=yes. Cheers ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists
Am 22.01.2015 um 21:32 schrieb Tod Fitch: I've been following this and the addrN thread with a mixture of amusement and irritation. Lots of the arguments come down to how easy it is to parse using some tool or another. Or whether the problem the original poster was trying to address actually exists. With respect objects that have multiple values for a key, the arguments seem to come down to either: 1. key=value1;value2;. . . ,valueN 2. key:value1=yes + key:value2=yes + . . . + key:valueN=yes As a programmer I can parse either set using any number of different methods. I am not against using a :' in the key string to create name spaces and for grouping related keys. I think that is a very useful construct. But from a purely logical point of view, I'd say the second way misses the concept of key=value and is using key:value with a noise suffix of =yes. Typically missing keys should be treated as having a value of either no or unknown. Unless you can show me where key:value1=is something other than yes then I may suspect you of putting values into the key field of the data. Might I suggest that a convention for keys that may contain multiple values that the : delimiter be used in the key but rather than putting arbitrary (data) values after the colon, use an numeric index: key:1=value1 key:2=value2 key:3=value3 No not at all, this makes it worse. Numbers are way to general and you gain little. : is usualy used for subkeys so key1, key2 would even be better. fly ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Electronic or 'e' cigarettes?
Existing pages: value e-cigarette is referenced in the wiki. http://wiki.openstreetmap.org/wiki/Tag:shop%3De-cigarette http://wiki.openstreetmap.org/wiki/Key:shop#Others On 22 January 2015 at 15:43, Dave F. dave...@madasafish.com wrote: Ah, As normal cigarettes are sold in multiples I didn't think of searching for the singular, but I guess people only buy one of these electronic types. Dave F. On 22/01/2015 14:16, Matthijs Melissen wrote: On 22 January 2015 at 14:02, Dave F. dave...@madasafish.com wrote: A shop that solely sells electronic cigarettes has been added locally. I guess this type of product will be on the increase so I think it's best to clarify unified tag, if there's ever been such a thing in OSM :-) Yes, I also think this is one of the more common shops that has no clear defined tag. Checking Tag-info it's 8/6 in favour of electronic_cigarettes over e-cigarettes. Currently, the most common tag is shop=e-cigarette: e-cigarette x170 e_cigarette x10 electronic_cigarettes x8 electronic_cigarette x4 e-cigarettes x6 To me, electronic_cigarettes is clearer should be used, but I thought it best to discuss first. I don't smoke, are all these power based? I understand your argument in favour of shop=electronic_cigarettes. If you think it's worth it, feel free to start a proposal to change the name. -- Matthijs ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging --- This email has been checked for viruses by Avast antivirus software. http://www.avast.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] Tagging road illumination quality
Volker Schmidt wrote: I am very cautious about any of this kind of measurement for the following reasons: 1) the results will be very difficult to standardise 2) the effort is far beyond that what a mapper can reasonably do. Oh well, I guess I'll have to write a comment here, because I recently finished my master's thesis on a related subject in street lighting research. While I wrote this message in parts on several days, there might be some repetition in it, but I hope the ideas are comprehensible. As a background, the eye requires a constrast between the target and the background before the target can be seen; the contrast can be in the colour, or in the luminance, or both. The eye also adapts to the prevailing luminance level; there's no exact model to predict the adaptation luminance given any scene, but the models of human vision take the adaptation level as a starting point - most scientific experiments have used a constant luminance background and a sufficiently long adaptation period (5+ or 20+ minutes) to fixate the adaptation luminance. The road planners have several lighting classes, which apply to different types of roads and pedestrian environments. The classes are not globally identical, but the basic ideas behind those classifications should be roughly similar. Generally the lighting classes set minimum requirements for the average illuminance or luminance on the ground, and a requirement for the evenness of the measured value, and possibly limits for measured glare. Sometimes there is a requirement that in the area next to the road the luminance should be a percentage of the value measured on the road. Some countries require that pedestrian environments fulfill some luminance condition on vertical surfaces, too, and some lighting classes might require or favour sufficient colour reproduction. These are the measurable quantities, and they are quite well predicted already in the planning phaze. When the lights get older and dirtier, less light reaches the road surface, so the new installations typically exceed the requirements. Lighting installations might be up to 40 years old, but some have been replaced earlier. The expected lifetime is often 15 to 20 years in the planner's operating cost calculations. In practice (assuming conditions found on normal roads, i.e. normal cost-optimized installations) the amount of light and the lack of glare are the most effective predictors for the average assessed quality of lighting. On ways used for vehicular traffic, glare seldom is an issue (but for example some early LED lights had a glare problem). There have been numerous studies, and they have compared the users' assessments to other attributes. When the test subjects are pedestrians, things like perceived openness of the area, emphasising the natural elements in the area with the lighting, perceived (lack of) options for escape and the ability to recognize other people's faces/intentions correlate with better lighting - and lighting can improve users' perceptions of those nonlighting attributes. Nobody has proposed a concrete model which could predict the perceived quality with all the recognized parameters. Such a model would require, for example, knowledge of the local living conditions and people's expectations of personal safety: there's a huge difference in what primes people into fear, between crime ridden environments and countries where street crime is very low. Measuring the road luminances is standard practice. They used to have to position the measurement device at regular intervals for measurements, but nowadays they use calibrated digital cameras with special software and do the measurements for a stretch of road surface from one picture. The officially acceptable devices cost more than your average DSLR camera, but from what I've read, the results could be sufficiently accurate for this kind of tagging. The problem is then that the road has to be empty, the tail and headlights of other vehicles would distort the values, and that to get comparable results the street has to be dry and the height needs to be constant; the road surface isn't a totally diffuse reflector (and wet surface even less so) so the values depend somewhat on the angle between the viewing direction and the road surface. The measurement grid has to be manually positioned over the picture, to get a standard sample between and of the whole area between two light poles. If, on the other hand, one were to measure upward, i.e. the mobile device measured the amount of light reaching it's light sensor and not the luminance of the surfaces visible in the camera, there are other hindrances. The sensor basically integrates over the half sphere space angle (or a smaller aperture), and the user holding the mobile phone blocks a significant portion of that; the old method for road lighting measurements had the persons doing the job walk away from the sensor
Re: [Tagging] Deprecation of associatedStreet-relations
Le 22/01/2015 14:00, althio a écrit : Hi all - does anyone know what the geographic distribution of associatedStreet is like? taginfo doesn't render a map (it seems it doesn't do that for relations). UK http://taginfo.openstreetmap.org.uk/tags/type=associatedStreet ~9000 PL http://taginfo.openstreetmap.pl/tags/type=associatedStreet ~1700 CZ /tags/type=associatedStreet ~ 100 HU http://taginfo.openstreetmap.hu/tags/type=associatedStreet ~ 130 SE http://se.taginfo.openstreetmap.se/tags/type=associatedStreet 900 RU http://taginfo.openstreetmap.ru/tags/type=associatedStreet 1850 FR is down No stats for DE This shows a map, I don't know if this is what you are looking for: http://taginfo.openstreetmap.org/tags/type=associatedStreet#map http://taginfo.openstreetmap.org/tags/type=associatedStreet#combinations also shows that 61 307 / 218 176 = 28.10% are also tagged with ref:FR:FANTOIR=* so from France. 28 % at least ! -- FrViPofm ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - Voting - Water tap
On Thu, Jan 15, 2015 at 7:13 AM, Kotya Karapetyan kotya.li...@gmail.com wrote: Dear all, As of today, a total of 16 votes have been submitted, 11 of them are approvals. Since 2 weeks have passed and the required number of votes (15) has been reached, I have closed the voting and will proceed with clean up. I appreciate all the discussion and help from your side (it was my first proposal, so I didn't know exactly how it should be carried out). I think you should take the negative feedback to heart, regardless of the vote outcome. You're messing with existing successful tagging efforts, making it harder for those who came before you, and effectively asking others to clean up after you. * The exactly how to do it is to address the issues and start over.* ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists
opening_hours:Mo-We 08:00-17:00 = yes opening_hours:Th-Fr 08:00-21:00 = yes would in my opinion lead to an inordinate number of subkeys. If you were reading other people messages you would probably notice that opening_hours=* tag was mentioned as minor exception to general rule *not to use semicolon in value.* ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Electronic or 'e' cigarettes?
On 22/01/2015, fly lowfligh...@googlemail.com wrote: The wiki page is very recent with only two contributors. I wouldn't be surprised if e-cigarette in the db was also contributed by no more than 1-2 mappers. I suggest contacting them to make sure that they are ok with e_cigarette, and then make the change to wiki and db. There are at least 30 mappers who have used shop=e-cigarette. Almost all of them started using this tag *after* user StephaneP imported about 80 e-cigarette shops in France. My hunch about few mapper was due to the spelling looking wrong to me, and the many variations. Thanks for checking. I also think that e-cigarette would be better than e_cigarette, as the - does not represent a space, and e-cigarette is a regular English word, used for instance in newspapers. No doubt about the spelling but still prefer a tag without abbreviation and advertising background. So call it by proper name. In my case electronic_cigarette=yes. I always spelled it ecigarette in my mind, but what do I know ? Googling and duckducking show all 3 variations to be fairly common. But they're all kind of slang/marketing terms (like e-cig), so I think that electronic_cigarette is a better fit for osm. FWIW, that's what wikipedia uses too. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - Voting - Water tap
On Fri, Jan 16, 2015 at 4:03 PM, Kotya Karapetyan kotya.li...@gmail.com wrote: 2. Having said this, I would like to draw your attention to the fact that people who currently actively oppose the proposal have not participated in a 4-month discussion, where most of the current concerns were raised and analysed. Your job as a proposer is not just to stuff something on the wiki and hope nobody notices... you need to *FIND* the community around the tags you are proposing. You did not do this. I happened to find you AND comment in a timely manner, so your statement above is not correct. The goal is not to 'analyze and ignore' but rather to reach 'consensus'. You are laser focused on mapping a specific feature, but missing the bigger picture. http://wetap.org/ is an example organization you should have been able to identify and contact. That's based on OSM data, and you are pulling the rug out from under them. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists
Using a xxx:yyy schema also requires checkboxes besides every existing value in JOSM presets. So I don't see how it is any easier for new mappers or preset creators. Problem in multiple values in value part in *key=value.* How iD should parse cuisine=mexican;japanese? This work repeated every time by wiki editors, by iD developers, by JOSM preset developers. There no point for this. Just ban semicolon and write actual page about *whatever*:mexican=yes *whatever*:japanese=yes *We don't have native arrays right now*. We have to decide which part of key=value will be ugly for some time so we can re-tag them back using real arrays. xxx:yyy=yes / semantic subtags are ugly, this is terrible for absolutely new to OSM people the same way key=value tags are terrible, but - we can provide newbies them with link to wiki. - we don't need to teach every person how to parse japanese from cuisine=mexican;japanese using f#$% regexes - we can provide clear definition at wiki page for iD or JOSM developers with description of tag instead of guessing by taginfo stats EVERY time they want to adjust something in presets - custom strings in editors or JOSM presets are easier to add - we get benefits from taginfo stats by using xxx:yyy=yes - advanced set querying for users, - reduced cpu load for database because there no need to compute *smart regexes* ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - Voting - Water tap
On Fri, Jan 16, 2015 at 4:03 PM, Kotya Karapetyan kotya.li...@gmail.com wrote: 7. Personally, I believe drinking_water=* is a much better solution than amenity=drinking_water: 7.1) The source of drinking water (which, I fully agree, is important for a lot of users) may not be a dedicated amenity, and still be very useful: e.g. a public toilet in a well-developed country can provide access to drinking water, but it's not an amenity=drinking_water, it is amenity=toilet. Marking one thing with two amenity nodes is possible but (1) it's a workaround rather than a nice solution; (2) I think many people, especially tourists from less developed countries, may not even understand such tagging and will be looking for a dedicated amenity. A key problem with your proposal is divergent tagging with no migration plan. - Double amenity was *not* in common use prior to your proposal: amenity=toilets;drinking_water Instead the tagging has been: amenity=toilets drinking_water=no Similarly for shops: amenity=shop toilets=yes toilets:wheelchair=yes toilets:disposal=flush Or other places: tourism=camp_site drinking_water=no toilets=yes At the first level of tagging these can be seen as attributes of the amenity, much like opening hours, website, etc.. If detailed tagging is done (e.g. individual camp pads), then the individual water taps can be mapped at that time. Until then the existing tagging works just fine. For backcountry camp sites tagging water is critical. The first question after where is it, is will there be water, followed by is that water potable. Bottom line: please listen to other mappers. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists
Propaganda. Propaganda. Propaganda. But it's harder to get all tags in category. How would you get all the payment methods, not the exact 'ellectrico'? Why normal person need to know about all payments methods if he/she only have mastercard/ellectrico/coins? You probably never use data at all. DATA against your words: http://taginfo.openstreetmap.org/search?q=payment. People prefer *complex* tagging schemes because they can actually *use* this data and not to write long post about regexes at tagging list. But for mappers, who are normal people, not the crazy data miners route_ref=1;2;3;4;5;123;124;125;126;234;235;236;456;457;458a How you search for ref=127? You are the crazy who want to use regexes. STOP. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Electronic or 'e' cigarettes?
On 1/22/15 23:13 , fly wrote: No, but it is common sence to introduce tags in proposal name space and once they are in common use accept them because of it use. Well, you can go ahead and create dozens of proposals that will go nowhere. I have completely given up on that process. It will be discussed here for 1-2 days and then will be forgotten. (I even asked for feedback for more feedback a few days ago... nothing). I'm not going to waste my time with that anymore when it's always the same few people who make any tag page edits in the Wiki anyway. If someone does not like in use and prefers proposed, fine go ahead and write it. Don't like the tag at all: Create a proposal for an alternative. But my time is limited and I rather have stuff documented so other mappers can find it and we don't have 10x different tags with slighly different meanings. __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists
On Fri, Jan 23, 2015 at 12:22 AM, Никита acr...@gmail.com wrote: we don't need to teach every person how to parse japanese from cuisine=mexican;japanese using f#$% regexes In my code editor I can search for complete word by ticking a checkbox, how simple is that ? It will not match japaneseinword or wordaroundjapaneseword when the checkbox is ticked and I search for japanese, but it will find japanese in chinese;japanese; korean Just provide the users a tool with a checkbox complete word or make it the default if you wish. People writing software for dummies will use this kind of techniques all the time. Hide the internals from the end-users. regards m ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists
On 15-01-22 01:44 PM, tagging-requ...@openstreetmap.org wrote: Message: 3 Date: Thu, 22 Jan 2015 18:08:49 +0100 From: Marc Gemis marc.ge...@gmail.com To: Tag discussion, strategy and related tools tagging@openstreetmap.org Subject: Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists Message-ID: CAJKJX-S3rCtHqSH+22+zrn0H5k6_ATTTOcmZmdcESYeK6k=1...@mail.gmail.com Content-Type: text/plain; charset=utf-8 In this thread we are also most interested in multiple values. I know :-) I have to add fuel to a heated discussion, but in the whole exchange on whether or not semicolon lists should be allowed/used, the most obvious example (to me) that requires semicolon lists was not mentionned, namely: opening hours. http://wiki.openstreetmap.org/wiki/Key:opening_hours I've tried before to collect data on parking restrictions in the city of montreal (Canada). Parking restricted/allowed times are an example of geographical data that requires a time description. I don't think the problem can be solved by relations. Simply because parking is allowed on two different streets between 2 and 3 pm, does not mean they're related. As noted on the wiki: http://wiki.openstreetmap.org/wiki/Relation#Types_of_relation They are not designed to hold loosely associated but widely spread items. It would be inappropriate, for instance, to use a relation to group 'All footpaths in East Anglia'. Similarly, holding all street segments for which parking is allowed between 2 and 3pm on the island of montreal in a relation strikes me as a bad idea. Substituting opening_hours = Mo-We 08:00-17:00; Th-Fr 08:00-21:00 to opening_hours:Mo-We 08:00-17:00 = yes opening_hours:Th-Fr 08:00-21:00 = yes would in my opinion lead to an inordinate number of subkeys. For example, in montreal alone, there are about 65000 different types of city parking signs. Let's say the number of individual distinct parking restrictions is only 10% of that, there would still be 6500 different subkeys (looking only at my city only). To make a long story short, this example, to me, shows that semicolon lists should stay in the tagging scheme. I would suggest discussing: A) For which keys and/or type of data are semicolon lists pertinent? B) How can semicolon lists be handled better in the different editors? as separate topics. Right now the two topics seem intertwined, which strikes me as less productive. With nothing but regards to all, Charles ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists
A) For which keys and/or type of data are semicolon lists pertinent? For keys that can logically have multiple values and that are not the main/defining key of the object. B) How can semicolon lists be handled better in the different editors? If you are using a tag from a preset, iD theorically can create the tag from any kind of interface. Not sure about JOSM, but I don't think this would be a show-stopper as long as semicolons is a better alternative. By the way, as far as I can tell people here wouldn't say that always avoiding semicolons whenever possible is good practice, correct? [1][2] [1]: http://wiki.openstreetmap.org/w/index.php?title=Good_practicediff=nextoldid=1128365 [2]: http://wiki.openstreetmap.org/wiki/Special:WhatLinksHere/Avoid_semi-colon_value_separator -- View this message in context: http://gis.19327.n5.nabble.com/Wiki-Edit-War-on-using-avoiding-semicolon-lists-tp5830523p5831050.html Sent from the Tagging mailing list archive at Nabble.com.___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Electronic or 'e' cigarettes?
Using - instead of _ goes against a very established tagging practice. Only for whitespace as far as I know. So I don't see a issue here. I would even say using _ is wrong. e_cigarette = e cigarette e-cigarette = e-cigarette The wiki page is very recent with only two contributors. I wouldn't be surprised if e-cigarette in the db was also contributed by no more than 1-2 mappers. I suggest contacting them to make sure that they are ok with e_cigarette, and then make the change to wiki and db. I just created the page, because the tag was used (TagInfo), but not documented. See: http://wiki.openstreetmap.org/wiki/Category:Undocumented_Tags __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists
On Thu, Jan 22, 2015 at 4:49 PM, althio althio.fo...@gmail.com wrote: New people can have problems or make mistakes and then experienced users can help and point to recommended tagging or explain good practices . Not everybody reaches out to community for help. Probably many just stop mapping, requiring them to create a new key, instead of typing something in a free text field is not going to help IMHO. In this thread we are also most interested in multiple values. I know :-) Or do you refer to iD (as the main editor for new people) where it is not possible to override presets to edit keys on the first part of the tag panel? What I tried to explain is that when you go for a tagging scheme where only cuisine:xxx=yes is allowed, the editor (iD) should offer a simple UI that allows people to create new values. In this case that means keys, since the values are actually in the keys. At this moment, it is also not possible to create JOSM presets that generates keys based on user input AFIAK. Using a xxx:yyy schema also requires checkboxes besides every existing value in JOSM presets. So I don't see how it is any easier for new mappers or preset creators. regards m ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Electronic or 'e' cigarettes?
On 22/01/2015 15:22, moltonel 3x Combo wrote: On 22/01/2015, althio althio.fo...@gmail.com wrote: Existing pages: value e-cigarette is referenced in the wiki. http://wiki.openstreetmap.org/wiki/Tag:shop%3De-cigarette http://wiki.openstreetmap.org/wiki/Key:shop#Others Using - instead of _ goes against a very established tagging practice. -1 The underscore character is widely substituted for the space character in tag keys and values, but I think the hyphen is considered OK. For the avoidance of doubt, in English you would write 'electronic cigarette' (with a space) or 'e-cigarette' (with a hyphen), but not 'e cigarette' (with a space). -- Steve --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists
a minor issue with semicolon separated lists: we don't have yet defined how to escape actual semicolons in values. cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists
Am 22.01.2015 um 14:07 schrieb Jo winfi...@gmail.com: network DLVB;IBXL;TECB;TECC;IBXL operator De Lijn;STIB/MIVB;TEC;STIB/MIVB I'd completely refrain in this case from tagging these to one object and use relations instead. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists
I cannot understand your example without illustration. Hide the internals from the end-users. We can easily hide *something*:japanese=yes *something*:korean=yes under single field *something*=*traditional semicolon presentation*, but not vice versa. I suggested plugin for JOSM that will present multiple subkeys as text field or as multiple checkboxes, it will be not so hard to implement for JOSM. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
