Re: [Tagging] Feature Proposal - RFC - cemetery=sector
2014-07-14 16:04 GMT+02:00 Martin Koppenhoefer dieterdre...@gmail.com: thank you for setting this up. There are some comments on the talk-page: http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Cemetery_sector Thanks! In my town, these got tagged as place=locality, and, while I couldn't agree the least with the tagging, I found no suitable tagging solution to set things right. Regards, Simone ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Suggestions for the correct tagging of Field borders
2014-07-14 23:10 GMT+02:00 Dudley Ibbett dudleyibb...@hotmail.com: I'm trying to work out exactly how a generic field would be mapped using this new tag. I'm using landuse=farmland on the individual field, and there are other mappers who do the same around here. You can add crop=* to specify the crop if you like. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] city/settlement importance -- WAS [OSM-talk] The biggest violation of OpenStreetMap, ever.
2014-07-14 21:38 GMT+02:00 Christian Quest cqu...@openstreetmap.fr: Not worse than the current osm.org rendering... but I agree that it is weird ;) agreed (besides the z5 for NE and class 0, which looks more or less reasonable to me) It is not catched by my query because there is no capital=* tag on it. Albany is the state capital (something I've just learned thanks to WP). So more tags may be useful to catch these major places. yes, other things could be: administrative importance besides capital (seat of important institutions and companies, seat of government, ...), airports and ports, road and railway connections, famous monuments, libraries, universities, zoos, museums, stock exchange, courts, ... There are two tags on the NYC place=* node: importance=international and rank=0. importance=* is a proposed tag since 2009, with 700+ occurences. rank=* is not documented in the wiki and currently have 600 occurences. There is a proposal for rank: http://wiki.openstreetmap.org/wiki/Proposed_features/new_place_values but it is outdated in this form (should not be strictly linked to population otherwise it would be pointless). I have proposed this some years ago, and used it for some time in my own rendering, but after a while gave up because people hacked it continuously (despite the lack of visibility of my map ;-) ). I think this is something that can be done by analyzing the data intelligently up to a certain level of certainty, but might still require some manual fix and adjustments in exceptional cases. Still this analysis will require some ressources and could unlikely be done on a dynamic dataset (i.e. preprocessing and hooking the updated results from time to time similar to coastline). For place=* nodes rank=0 has 135 occurences, with a lot of then in Lituania and several too in Brazil... to avoid too many false positive, it need to be limited to place=city yes, the idea of rank was to give a relative scale within the same place-value, so you can't compare rank=0 of a village to that of a city. Given the emptyness of the area around Clermont-Ferrand, and Brive, it is quite logical to get them on the map. They are the major cities in the area ;) San Francisco is hard to find, L.A. doesn't appear before zoom 10 (but is hard to spot due to its brevity), and spelled out at zoom 11. But also in Europe there are some serious problems, e.g. Zurich (typical hard case, OK) isn't there at zoom6, unlike Clermont-Ferrand, Brive-la-Gaillarde, or the famous Ebingen on the Swabian Alb ;-) Zurich... admin_centre:4=yes, a tag you'll find only in Switzerland... no capital/is_capital/importance/rank... well, Zurich has its importance not because of the administrative (government) status, but because of the many banks, the stock exchange, its science community (and the cultural life). We need a default uniform tagging scheme, then update OSM. capital=* + importance=* should be enough, with population to provide a sort order to help text placements for similar capital/importance values. importance is like rank, it can be disputed and it is not clear, on what aspects the importance is based on. I'd rather like to see an importance for several properties / fields. importance maybe have different subjects attached to it. For example, importance:religion=international/national/regional so Mecca or Lourdes may be promoted on some maps but at least data is there. +1, and maybe even more diverse (e.g a scale from 1 to 1000 or allowing fractions, so later adjustments (compared to something else) can be easily applied). The only problem may be a new kind of vandalism based on these tags... yes, it's not the only problem, but could be a major one (I have also seen this for tourism=attraction occassionally). Maybe we should switch to the tagging list ;) +1 cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Future proposal - RFC - amenity=dormitory
2014-07-14 20:39 GMT+02:00 Steve Doerr doerr.step...@gmail.com: And also, a dormitory is a communal facility containing two or more beds - otherwise it's just a bedroom. it can be also a part of a monastery... cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Relations are not categories excepted for type=network ?
I discover that OSM contains 1575 relations of type=network (taginfo). I guess its definition is coming from this wiki proposal: http://wiki.openstreetmap.org/wiki/Relations/Proposed/Network Quotes: A network groups together routes that share common characteristics, e.g. a common operator, a common classification scheme (e.g. E-road network: E 1, ..., E 999), ... Use cases Person A sees a bus route with number 217 and wonders how many other bus routes exist in that city. Renderer M wants to render all German motorways using white font on blue sign (official layout), and all E-roads with white font on green sign. This can be implemented by adding rules for 20614 (view, XML, Potlatch2, iD, JOSM, history, analyze, manage, gpx) and 20645 (view, XML, Potlatch2, iD, JOSM, history, analyze, manage, gpx). Renderer M wants to render all cycle routes that belong to the D-Netz. However, there are a lot of other national cycle routes as well. Plus some attached relations examples very explicite. As raised in the discussion page, is that not exactly breaking the relations are not categories ([1]) principle ? Can we delete such relations when we meet them ? Pieren [1] http://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Relations are not categories excepted for type=network ?
Am 15.07.2014 17:58, schrieb Pieren: I discover that OSM contains 1575 relations of type=network (taginfo). I guess its definition is coming from this wiki proposal: http://wiki.openstreetmap.org/wiki/Relations/Proposed/Network As a hint for further inverstigations: I guess this might be public transportation related Cheers, Michael. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Problem with access=designated
On 13.07.2014 20:44, Mateusz Konieczny wrote: According to http://wiki.openstreetmap.org/wiki/Tag:access%3Dofficial access=designated often includes ways that have no legal dedication like e.g. recommended routes of a local bicycle club Is it OK to use this tag in situations like this? No, that sentence completely contradicts how the designated value is used in my experience. In fact, based on the usage in my area the definition of official could be used 1:1 for designated. It should also be noticed that the value official is only a proposal, but was never approved. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Problem with access=designated
On 13/07/2014 19:44, Mateusz Konieczny wrote: According to http://wiki.openstreetmap.org/wiki/Tag:access%3Dofficial access=designated often includes ways that have no legal dedication like e.g. recommended routes of a local bicycle club Presumably here you don't actually mean access=designated but instead mean something like foot=designated or horse=designated (i.e. foot or horse traffic is suggested by signage to use a particular route). access=designated (43k in taginfo - [1]) is surely meaningless. Looking locally (e.g. [2]), I suspect what people really mean is private or perhaps permissive. And no, I'd never suggest that recommended routes of a local bicycle club would be even bicycle=designated for that reason alone. Cheers, Andy [1] http://taginfo.openstreetmap.org/tags/access=designated [2] http://www.openstreetmap.org/way/42400330 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] city/settlement importance -- WAS [OSM-talk] The biggest violation of OpenStreetMap, ever.
Making a rank or importance attribute is entirely subjective. It might as well be a tag like importance:according_to:Bob=5. If it was objective, then there could be a number like annual_number_of_tourists=35 or annual_number_of_pilgrims=140. For economic importance some other figure, a number nobody can refute. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] city/settlement importance -- WAS [OSM-talk] The biggest violation of OpenStreetMap, ever.
2014-07-15 19:47 GMT+02:00 Janko Mihelić jan...@gmail.com: Making a rank or importance attribute is entirely subjective. It might as well be a tag like importance:according_to:Bob=5. If it was objective, then there could be a number like annual_number_of_tourists=35 or annual_number_of_pilgrims=140. For economic importance some other figure, a number nobody can refute. while I agree somehow, the algorithm might be so complex that you'd have to put a very long list of tags to the object and there might be stuff that is hardly puttable into tags, but might still be verifiable. Also figures like annual_number_of_tourists or annual_number_of_pilgrims are not verifiable by the small on the ground mapper, and institutions in charge of determining these figures might be tempted to cheat in order to appear more important, so there will always remain some doubt ;-) cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Relations are not categories excepted for type=network ?
In Belgium and The Netherlands a network-relation is used to group together all nodes and routes of a walking network. This avoids that we have to repeat the name, operator, etc. on each route (signposted path between 2 nodes) and the nodes. m. On Tue, Jul 15, 2014 at 5:58 PM, Pieren pier...@gmail.com wrote: I discover that OSM contains 1575 relations of type=network (taginfo). I guess its definition is coming from this wiki proposal: http://wiki.openstreetmap.org/wiki/Relations/Proposed/Network Quotes: A network groups together routes that share common characteristics, e.g. a common operator, a common classification scheme (e.g. E-road network: E 1, ..., E 999), ... Use cases Person A sees a bus route with number 217 and wonders how many other bus routes exist in that city. Renderer M wants to render all German motorways using white font on blue sign (official layout), and all E-roads with white font on green sign. This can be implemented by adding rules for 20614 (view, XML, Potlatch2, iD, JOSM, history, analyze, manage, gpx) and 20645 (view, XML, Potlatch2, iD, JOSM, history, analyze, manage, gpx). Renderer M wants to render all cycle routes that belong to the D-Netz. However, there are a lot of other national cycle routes as well. Plus some attached relations examples very explicite. As raised in the discussion page, is that not exactly breaking the relations are not categories ([1]) principle ? Can we delete such relations when we meet them ? Pieren [1] http://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
