Re: [Tagging] Nuclear Key
Am 03.04.2011 04:26, schrieb David Murn: On Sat, 2011-04-02 at 12:11 +0200, Ulf Lamping wrote: *... and I'll especially call it wiki fiddling if the currently widely used tags are removed from the wiki without even keeping a note of the old tags.* Doesnt the fact that the proposal exists, outlining the change from the old to new tags, cover the 'note of the old tags' that you ask for? No. If a tag is in wide use, it's not ok to remove that information from the corresponding wiki page. Period. It's not enough that you may find it at some proposal pages. Should all tagging proposals be put through a proposal, a discussion, RFC and voting stages, and then be passed onto another group of 'people who know exactly what theyre doing' (but apparently dont use the tag, or participate in the tagging discussions), so that they can either vote or veto it? No, it's not about power in the project. If someone changes a wiki page of a widely used tag, it's a *must* to keep information of the current way. Otherwise people finding the tag in the osm data, they are forced to search, which is not ok. The wiki page should inform the user about the current status of the tag, mentioning both there's a way the tag was used for quite a while and there's a proposed new way of doing things. If the author is not able to write this down in an informative way, he/she shouldn't change the wiki. P.S.: I have helped to transform the formerly used tagging schema, e.g. man_made=power_wind to the current one because the initial way really lacked a lot of things. The recent change causes a lot of trouble and doesn't add a lot of benefit the way it is done. I dont remember seeing your name in any of the discussions, and a quick search through the wiki doesnt find your name linked with power or generators. Out of interest, how come its okay for you to transform a tagging schema, but its not okay for a community-agreed change to the scheme to take place? It's community agreed if the majority of mappers use this tag, not when some people voted upon it. Did your 'transform'ing of the schema get presented on tagging@ on the power page, or have any voting? If not, how can you call this case wiki-fiddling and yours not? At that time, the tagging@ list didn't even existed. Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Nuclear Key
Am 02.04.2011 11:03, schrieb David Murn: On Fri, 2011-04-01 at 14:42 +0200, M∡rtin Koppenhoefer wrote: This (new ?) schema seems not often used (some plant has the 2). Excellent example of wiki fiddling ... at least this was discussed and voted about: Im sure I remember seeing this discussed either on here or possibly on the talk list, and I personally received an email from the proposer since Ive added some power stations and presumably the proposer emailed a bunch of people he thought would be interested. If someone comes up with a proposal, discusses it on mailing lists, emails current users of the tag, casts and finishes a vote, how on earth can you call it wiki-fiddling? Just because someone changed the wiki to something some people disagree with, doesnt mean its a case of 'wiki-fiddling'. Yes, but if someone tries to change an existing and working schema with something slightly different - that could be integrated with minor changes into the existing schema - I'll call that wiki fiddling, regardless if a vote was done or not. This way we'll have to change each and every tag every year because someone finds the new and improved way to do things as the current tag fashion expects him to. *... and I'll especially call it wiki fiddling if the currently widely used tags are removed from the wiki without even keeping a note of the old tags.* Please keep your hands off existing documentation of widely used tags, unless you know exactly what you are doing ... Regards, ULFL P.S.: I have helped to transform the formerly used tagging schema, e.g. man_made=power_wind to the current one because the initial way really lacked a lot of things. The recent change causes a lot of trouble and doesn't add a lot of benefit the way it is done. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mountain passes
Am 14.02.2011 13:40, schrieb M∡rtin Koppenhoefer: 2011/2/14 Nathan Edgars IInerou...@gmail.com: http://mapper.acme.com/?ll=36.76925,-82.20018z=16t=T If this isn't mountain_pass=yes, what should it be mapped as? IMHO natural=pass would be the most logical way to do it. Natural describes in it's vast majority geographical features as which I would see a pass as well. While I agree that this would be logical, the crowd has chosen otherwise ... Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mountain passes
Am 14.02.2011 14:22, schrieb M∡rtin Koppenhoefer: 2011/2/14 Steve Bennettstevag...@gmail.com: On Mon, Feb 14, 2011 at 11:32 AM, Ulf Lamping ulf.lamp...@googlemail.com wrote: That was the start of the discussion in 2007, but was changed due to the changes (around the same time) of highway=tunnel / highway=bridge to tunnel=yes / bridge=yes - so using the same logic for passes seemed like a good idea then ... Ah, yes, good point. Although it's slightly complicated by a pass theoretically being a point rather than a stretch of road. And that presumably makes it hard to render - you'd need to work out which way the point is oriented. IMHO you don't. Simply render Simplonpass, 2005 m at the given point in a pleasant font. Done. Rendering a single point and a label is often found on topological maps. For street maps, you'll usually have a bridge like symbol which needs an orientation of the corresponding way to be drawn properly (as Osmarender is already doing). Obviously, it would be much better than nothing if mapnik at least would just render a point with a label ... :-) Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mountain passes
Am 14.02.2011 22:22, schrieb Nathan Edgars II: On 2/14/2011 4:05 PM, yvecai wrote: Actually, Mapnik would render a 'pointSymbolizer', how would it look like? Just a label could be enough. Why not simply use the same style as place=locality? Because I would like to see the elevation in the label - at least in higher zoomlevels. Basically the same behaviour as natural=peak would be my favourite. They fit the definition (in fact there seems to be no reason not to apply that tag to passes other than redundancy). Well, tagging every unpopulated named place with place=locality is really misleading. A football stadium is usually unpopulated and has a name :-) If we have a specific tag for a specific feature we shouldn't add more generic stuff to it IMHO. Makes it more difficult to render without a real benefit. Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mountain passes
Am 13.02.2011 20:57, schrieb j...@jfeldredge.com: I guess this partly comes down to the questions of how you define a way, and how you define a pass. If a particular pass becomes little-used, because a tunnel or a lower pass provides an easier way to get past the mountains, does that make it stop being a pass? What if the pass is a boundary between two nations, and the border crossing is closed because one or both nations don't maintain a customs station there? Does that make the pass stop being a pass, in the geographic, rather than political, sense? ---Original Email--- Subject :Re: [Tagging] Mountain passes From :mailto:dieterdre...@gmail.com Date :Sun Feb 13 13:36:08 America/Chicago 2011 2011/2/13 Nathan Edgars IInerou...@gmail.com: According to http://wiki.openstreetmap.org/wiki/Key:mountain_pass passes only make sense on ways. But it's possible to have a pass with no way crossing it (not even an informal footpath) or with multiple ways crossing (a dual carriageway, or parallel highway and railway). How should these cases be handled? no, it is IMHO not possible that a pass has no way that crosses it, otherwise it wouldn't be a pass. In the narrower sense you are correct, but: http://en.wikipedia.org/wiki/Col_de_Bretolet A pass (french: Col) that has no way to either side, but a way over a ridge from the Col de Cou ;-) If there is more then 1 one way I guess you would have to tag all of them. Especially in the U.S., I've seen some dual carriageways with two pass nodes, e.g.: http://osm.org/go/T2U0CV8Ye-?layers=O Maybe natural=pass (or mountain_pass) on a node might be more logical for the feature if you bear in mind that the wiki suggests to tag ele with it. The underlying problem what makes a pass a pass is *very* difficult to answer, e.g. there's a lengthy Wikipedia discussion about it. If a pass is closed due to political differences but there's a way over it, this is an easy one (mountain_pass=yes and access=no). The difficult question: What is generally a way in this regard? If you can travel the pass by car, 4*4, horse, MTB, hiking, via ferrata or extreme sports? If you read the wiki page, it started in 2007 with highway=pass, so you can see that I (and others) basically had roads in mind when I've wrote it (and no one at that time seemed to even mention passes with no way). In practice today, a lot of nodes with mountain_pass=yes are tagged, where you don't see any way nearby (maybe from imports?), and a lot of nodes on hiking trails, roads, etc. So today in OSM a mountain_pass=yes denotes the geographical feature in the wider sense (german: Scharte, Sattel, Joch, ...), not the narrow definition of being a passage on a way. Regards, ULFL P.S: What bugs me more is the (not so un)common practice to put the node near the way (where the sign is?) and not exactly on the road. This makes it difficult for renderers to detect the kind of way a pass provides ... ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mountain passes
Am 14.02.2011 00:07, schrieb Steve Bennett: On Mon, Feb 14, 2011 at 8:28 AM, Ulf Lampingulf.lamp...@googlemail.com wrote: P.S: What bugs me more is the (not so un)common practice to put the node near the way (where the sign is?) and not exactly on the road. This makes it difficult for renderers to detect the kind of way a pass provides ... That makes sense if you think of a pass being a locality (we had a picnic up at the pass) rather than a particular road feature (we drove over the pass). I would probably do the same thing, naïvely. Probably a more intuitive tag would have been highway=mountain_pass (like highway=turning_circle...) That was the start of the discussion in 2007, but was changed due to the changes (around the same time) of highway=tunnel / highway=bridge to tunnel=yes / bridge=yes - so using the same logic for passes seemed like a good idea then ... Anyway, every solution has it's pros and cons here. Also, it doesn't look like Mapnik actually does render it? http://osm.org/go/znyo7Chj2-- AFAIK, only osmarender at (too?) high zoom levels (from z15) and JOSM renders it. I would be glad, if Mapnik would render this as well. The same zoomlevels and logic as for peaks (icon, name, ele at different zoomlevels) would make sense for me ... Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - natural=bare_rock
Am 29.01.2011 13:33, schrieb M∡rtin Koppenhoefer: 2011/1/29 John Smithdeltafoxtrot...@gmail.com: On 28 January 2011 21:35, M∡rtin Koppenhoeferdieterdre...@gmail.com wrote: Yes, IMHO (I'm not an English native) this is not scree. I would tag them landcover=bare_rock (or depending on the size landcover=pebbles) http://en.wikipedia.org/wiki/File:Wave_Retreating_from_Pebbles.jpg Why bother with landcover=* when we have natural=* and surface=* already? why explain the same issues a hundred times? You can find the answer in the ML archive and in the wiki. If you advertise your own proposal(s) a hundred times here, then please also mention the (widely used) alternatives. Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC: historic:civilization and historic:period Re:new key civilization
Am 12.01.2011 17:59, schrieb j...@jfeldredge.com: Your examples are rather ridiculous. A Viking captain, or King Arthur's sword, would not be logical items to have on a map. Hmmm, I guess Pieren is very much aware of this :-) A building or archaeological site likely would be on a map, and tagging them with the civilization and era would make it easy to generate special-interest maps. Yes, in principle. In practice, lot's of sites have *several* different roots throughout the ages. A castle may be build in early medieval ages, continuously extended throughout those ages, largely changed in the baroque era and mostly rebuild after damages of the second world war. Oh, and all of that on top of a hill that was already populated in the celtic age. How do you tag that? Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC: historic:civilization and historic:period Re:new key civilization
Am 13.01.2011 03:08, schrieb M∡rtin Koppenhoefer: 2011/1/12 Ulf Lampingulf.lamp...@googlemail.com: In practice, lot's of sites have *several* different roots throughout the ages. A castle may be build in early medieval ages, continuously extended throughout those ages, largely changed in the baroque era and mostly rebuild after damages of the second world war. Oh, and all of that on top of a hill that was already populated in the celtic age. How do you tag that? the hill or the castle? Could you explain both? Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Karting...
Am 10.01.2011 12:28, schrieb John Smith: http://wiki.openstreetmap.org/w/index.php?title=Template:Map_Features:sportdiff=prevoldid=583789 I'd be more inclined to use the English and shorten it to just sport=cart Some time ago, I had a look at how sport=motor is actually used. By looking at the names in the OSM planet, I found some quite often existing stuff (motocross, karting, ...) as a name like: Kartarena Bottrop was tagged with the generic sport=motor and the name suggests to be a karting arena. So I looked at how often sport=xy alternatives for e.g. karting appeared in tagwatch (taginfo, osmdoc, ...?). sport=karting was most often used and easy to remember (no underscore), so I've added it to the JOSM presets and mappaint display. You'll find this and some other formerly sport=motor things in the JOSM presets under: sport/motorsport/... Regards, ULFL P.S: I don't tend to change this in JOSM ;-) ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Towing service?
Am 07.01.2011 03:26, schrieb Alan Mintz: I can't find a tag for the base of operations of a towing service - i.e. you call them to tow your broken car or truck to a repair shop. The basic definition would be a service that tows cars and other light vehicles. Truck and other heavy vehicle towing would be a separate option. I propose: shop=towing [+ hgv=yes] For me, a shop would be to get in, buy something (or at least get some service done) and go out. That's not the case here. A towing service will get to your place to do something, much like the office of a plumber (which in most cases also wouldn't qualify for a shop). You might even won't be allowed to enter the area. Different thing would be car repair or car rental, which is also doing towing service, in these cases I simply would add towing_service=yes. Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Thoughts on how to replace or modify an exist/established tag (Was: Feature Proposal - RFC - sluice_gate)
Am 06.01.2011 23:06, schrieb Simone Saviolo: ... but in fact the map is not reliably usable. Fine, if you think OSM is working unreliably - just go on and start your own reliable project :-) If you set up something like an OSM core profile and the majority of people find it useful, this might - in the future - become an addition or exchange of the current wiki page anarchy - when people agree that it's more useful than the current wiki thing. Side note: The Map Features is basically already such a thing. I've seen several of such discussions over the OSM years passed now - and I just habe some serious doubts that this will happen. BTW: I did intense analyzing of the existing features and I can tell you that even this took a *lot* of time. Don't underestimate the effort for such a culture independent profile (if this is possible at all). What most people completely seem to miss here: The current wiki anarchy just shows, that finding a clear and valuable (definition of a) tag is *much* more dfficult than most people can even imagine ... Regards, ULFL P.S: Reading this thread, I've already seen a lot of bullshit bingo candidates, being process maturity one of the most valuable ;-) ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Thoughts on how to replace or modify an exist/established tag (Was: Feature Proposal - RFC - sluice_gate)
Am 07.01.2011 00:10, schrieb Steve Bennett: If by do their best you mean, the people involved work hard and in good faith, yes. If you mean the result is optimal, then clearly not. There are lots of bugs in mapnik. Where are the trac tickets to improve the situation? And just look at the table I produced to see the wide discrepancy in tag support across different editors and renderers: http://wiki.openstreetmap.org/wiki/User:Stevage/tagsupport I'm not argueing that there certainly are bugs, but renderers have - by definition of their intention - discrepancies in what they want to display. I really like your table (BTW: A more frequent update would help), but taking it as an argument for missing standards is just strange. The other way round might make more sense. If all renderers, the wiki, OSMDoc and alike lists that feature, it seems to be in common use. Obviously, this doesn't reflect in any way the semantics of that tag. This is just like when you write software to implement an open-source standard. No one is forcing you to implement the entire standard. But most developers see the benefit in operating in this standard way, to improve interoperability. We are not writing software here, your comparison is therefore wrong for several reasons. Even if it would be right, why are there so many competing standards out there? Please also remember: Standards need quite a while to evolve, e.g. first GPX was born in 2002! Compared to that time and complexity, our tags are already quite mature - without any standard body! Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - sluice_gate
Am 03.01.2011 21:20, schrieb Paul Norman: They both have elements of flow control, but function in quite different ways and look very different. A weir is used to raise the water level or control flow, with water flowing over the top. A sluice gate is essentially a valve for small waterways. You might add such a description to the wiki page, as others might be confused as much as I was. BTW: My feeling is, that sluice gates formerly were tagged with waterway=weir most of the time anyway. The suggested term floodgate would be more intuitive for me as a none native speaker - if the term fits for native speakers as well. Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Call for German, French, Russian Japanese updates for changed tag
Am 22.11.2010 10:26, schrieb Tom Chance: Hello, Some time ago a proposal to change the way we specify types of power generators was passed. Unfortunately, the German, Russian, French and Japanese translations haven't been updated. Hi Tom! Please revert the changes in the english page! A passed proposal doesn't mean in any way that it's a good idea to change existing information that's been there for quite a while. Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Call for German, French, Russian Japanese updates for changed tag
Am 22.11.2010 10:49, schrieb Tom Chance: Ulf, the proposal introduced a new set of tags to specify the type of power=generator, deprecating two existing tags. The new set of tags is more powerful and loses none of the detail made possible by the old tags. I'm not gonna argue with you, wether the new proposal is better than the existing stuff, as that's not the question to ask. When that happens, the only logical course of action is to update the wiki documentation showing the new tags and removing the deprecated tags. It makes no sense to continue telling people about deprecated tags. First of all, please repeat a hundred times on the blackboard: There's no such thing as a deprecated tag in OSM. Especially not, if the new proposal is only a few weeks old ;-) Your logical course of action has a quite unlogical component: As long as editors, the database and renderers using the existing tags - as they do - it's quite unlogical to remove the description about those tags in a hassle. This will e.g. confuse anyone looking for the intention of those tags as found in the database. Another thing already mentioned quite often: 20 out of 20 mappers isn't a reasonable amount of people to force ideas over all others. It's an indication that it is probably a good idea - but not more. If the mappers think your proposal is a good idea they will use it. But that's up to the mappers. So I'll herefore ask you to change the page back to it's original state. Adding a noticeable remark / link to the approved proposal page is perfectly reasonable, simply replacing the existing content is definitely not. Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Call for German, French, Russian Japanese updates for changed tag
Am 22.11.2010 22:28, schrieb Petr Morávek [Xificurk]: Ulf Lamping napsal(a): First of all, please repeat a hundred times on the blackboard: There's no such thing as a deprecated tag in OSM. Especially not, if the new proposal is only a few weeks old ;-) Sure there are deprecated tags in OSM - it doesn't mean that they are not used in the database or that editor is forbidden to use them... it simply means they are deprecate in favor of a better tagging scheme. If someone thinks that the new tagging scheme is not better, then he/she should open discussion about its problems, preferably in mailing list or on wiki itself. You didn't get the smiley ;-) Sure, there are tags that you could call deprecated, highway=minor would be an example - no one would actually encourage to use this tag any more. But - simply because some people written a proposal and voted upon it, doesn't automatically deprecate the former widely used tag. You could call it deprecated if the vast majority of mappers would see it that way and no one would actually encourage to use the old tag any more. Which is really not the case here. Regards, ULFL P.S: If the old tag would be there only for a weeks (or maybe even a small amount of months) and not very widely used I wouldn't insist for a clean way of change. But the old definition is there for years and a few (ten?) thousand times used. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag a (main) entrance to a large feature?
Am 18.11.2010 10:41, schrieb Nathan Edgars II: Features such as parks may cover a large area, and if the park is drawn as a polygon, routing software will likely choose the centroid. The nearest point on public roads to the centroid may however not be the actual entrance to the park. For example, go to http://www.yournavigation.org/ and get directions from Orlando, FL to Wekiwa Springs State Park (the actual entrance is in the southeast corner; use Wisteria St, Orange County, FL). How can we make sure that the software will know where the entrance is? By drawing footways / highways where they actually are. It's really that simple ;-) Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] geology taggin?
Am 17.11.2010 21:29, schrieb Elizabeth Dodd: On Wed, 17 Nov 2010 21:11:18 +0100 Ulf Lampingulf.lamp...@googlemail.com wrote: It is accepting that semantically different things can reside under the same key and that this doesn't cause any problems - except for people like you that seem to think that a systematic approach is a value in itself. There are good reason for keeping semantically different things in different groups. 1. the new mapper. I remember trying to work out, with multiple wiki pages open, how something was described, and then tagging it. It took forever, and then the editors improved their presets and I remembered more of them. Funnily, I (to some extend) was the one that improved the JOSM presets. I challenge you to explain to a new mapper why cafe is under amenity and bakery is under shop, when they live in an area where bakeries include cafes as their normal state. You are asking why semantically different things (a place to eatdrink vs. a place to go in, buy something and go out) are placed in different keys? How does this correlate with your first sentence? Fine example, as amenity was s crowded that we had to split the shops away from it, creating another key that seems to cause confusion here. This example is exactly the result of such an approach to semantically sort things and it's possible negative side effects. 2. finding if someone has already described this item or not When items in the real world haven't got an OSM tag, how do I find the comprehensive list of features and search it? So there are shops that sell building bricks. Outdoor display area, with brick walls to show the bricks for sale, and a little office for the salesperson. Shop? Amenity? Light industrial? Office? If we don't tag with rational schemes we will have multiple duplicate tags simply because people can't find the place where the tag was placed in the schema. You are probably mixing up rational and semantical grouping. I've simply argued that a rational scheme (aka a scheme people can understand/remember) isn't necessarily a scheme that groups along a semantical boundary. Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] geology taggin?
Am 17.11.2010 21:43, schrieb M∡rtin Koppenhoefer: It is accepting that semantically different things can reside under the same key and that this doesn't cause any problems - except for people like you that seem to think that a systematic approach is a value in itself. it depends what you implicate with creating problems. If you invent a new value, it is not clear where to put it, because there is no logic. Of course there is a logic, it's just a logic that you don't like and therefore deny to recognize ;-) What about valleys. Say you wanted to put a valley in the db. Is this natural? Maybe yes, as long as it is not artificial. So what's the problem? If you make presets for an Editor, you will have to filter the values by what they express, some are geographic features, others are physical landcover features, others are even different things. Some may think about a specific feature being more of a geographic feature, some a physical landcover and some may not even get the distinction between the two. This complicates the life of all ;-) You are implying there's an obviously correct way to make these distinctions, which is not the case. If you take a look at: http://de.wikipedia.org/wiki/Datei:Blaubeerwald.jpg the physical landcover would be bushes for me and certainly not trees. You may disagree. This complicates the life of all: mappers, especially new ones as well as application developers. While I was working to improve the JOSM presets, the more detailed the (sub-)menus became, the harder it was to place specific items into the right menu - let alone to find the right group boundaries (aka menus) at all to remain understandable. The more groups (aka keys) you have, the harder it gets to understand and remember each boundary (aka the rules behind it). The more detailed each specific group is defined, the harder it get's to place a new item into the existing groups, e.g. it may fit into two definitions or none at all. Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] geology taggin?
Am 16.11.2010 13:51, schrieb M∡rtin Koppenhoefer: 2010/11/16 Ulf Lampingulf.lamp...@googlemail.com: So what is the *exact* problem with surface? it extents the usage of surface as attribute for routable entities to all kind of entities, therefore reducing simplicity for the data consumers with no benefit at all. No, surface was meant (and is in fact used widely) to describe the surface material of something, being it a highway, beach or whatever. There is e.g. *no* problem to describe the surface of e.g. natural=beach with that tag. A router wouldn't try to search for surface, but for highway or alike. It might want to analyze surface in addition to another tag. I doesn't make sense to me, if people use surface as a standalone tag, because it should always be an addition to other tags. But that's not a problem with that tag, but how people using it in clear breach of the definitions. Another advantage of specialized tag landcover is that in contrast with surface it by itself implies area=yes. So what is the *exact* advantage of landcover? well, one you cited yourself. Did I? Another one was written above: trees, which are not representable with surface. I've never argued to use surface for trees, but the well established natural=wood / landuse=forest. Sorry, this kind of vague we might want to have xy because someone might want to ... is pretty much pointless. this is not vague at all, and people are frequently popping up with the landcover proposal, as there seems to be a desire for it. Reading your new proposal page, I only see a vague definition that is in direct conflict with landuse and natural and therefore will confuse mappers how to tag things. It remains unclear under which circumstances someone should use landcover, landuse and/or natural. Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] geology taggin?
Am 15.11.2010 11:39, schrieb Morten Kjeldgaard: On 2010-11-14 20:30, Ulf Lamping wrote: landuse=nature_reserve is your own personal concept. Please have a look at (and make yourself comfortable with) the existing map features before you discuss here. Arrogance doesn't bring any respect to your point of view. Yes it's leisure=nature_reserve and not landuse, I am so sorry Ulf, I should have used a better example for those who strive to misunderstand. First of all: May I kindly remind you of your own words in this thread: But those of us concerned future development of the database ... which was a direct response to a mail from me in this thread. This implies that I am not interested in the future development of the database. Telling this to someone who has spend a significant amount of effort into developing the database (since 2007) isn't very nice. I've seen too many times people argueing about how tags should be, that obviously had an idea how they think it should be, but didn't really know how it currently is. Your example of nature_reserve falls into that category, as the concept of putting this into leisure, landuse, natural or whatever else is simply broken. The whole nature_reserve as an area is broken. This conceptual problem should be known to people argueing about landcover ... Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] geology taggin?
Am 16.11.2010 00:57, schrieb M∡rtin Koppenhoefer: 2010/11/15 Ulf Lampingulf.lamp...@googlemail.com: as the concept of putting this into leisure, landuse, natural... is simply broken. +1 Oh, BTW, as a side-effect, putting this into landcover is *also* broken. The whole nature_reserve as an area is broken. it is clearly an area. What else should it be? All boundaries delimit areas. Yes, germany is basically also an area. Some people think it's a good idea to not tag this as an area but using a boundary way / relation. Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] geology taggin?
Am 16.11.2010 02:57, schrieb Nathan Edgars II: On Mon, Nov 15, 2010 at 8:20 PM, Ulf Lampingulf.lamp...@googlemail.com wrote: Am 16.11.2010 00:57, schrieb M∡rtin Koppenhoefer: 2010/11/15 Ulf Lampingulf.lamp...@googlemail.com: The whole nature_reserve as an area is broken. it is clearly an area. What else should it be? All boundaries delimit areas. Yes, germany is basically also an area. Some people think it's a good idea to not tag this as an area but using a boundary way / relation. http://wiki.openstreetmap.org/wiki/Multipolygon The multipolygon relation is OpenStreetMap's area data type. Which is - well - just wrong. The closedway is the traditional way of OSMs data type for an area and the multipolygon is the modern way if the traditional model doesn't fit well. Most people in OSM will model e.g. most buildings with a closedway and not with a multipolygon (unless necessary). Both would be possible and both are an area. Are you done being pedantic? Sorry, you've missed the point. Maybe this should better read: The whole nature_reserve as a closedway is broken. Obivously nature_reserve is an area (however you model it). But it's usually an area more the size of germany compared to e.g. the size of a single building (yes, you could endlessly discuss about this statement). So while you're modelling the boundary of the nature_reserve (e.g. using a multipolygon) and you're not using a closedway (which you'll probably never do for a nature_reserve), it *never* get's in the way of landuse, natural, surface or landcover. Remember: This part of the thread was about a need for landcover because of nature_reserve - which I denied. Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] geology taggin?
Am 16.11.2010 03:49, schrieb Petr Morávek [Xificurk]: The problem with surface is that it is currently proposed (and used) to describe two different things: 1) A property of certain object, which can be area, way, node... 2) What is on the surface of certain _area_ of land (landcover). Although there is currently no big overlap between usage (1) and (2) on areas, I think it would be better to differentiate these two use cases, so one can easily e.g. filter out and render only landcover map. So what is the *exact* problem with surface? Another advantage of specialized tag landcover is that in contrast with surface it by itself implies area=yes. So what is the *exact* advantage of landcover? Sorry, this kind of vague we might want to have xy because someone might want to ... is pretty much pointless. Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] geology taggin?
Am 14.11.2010 14:24, schrieb Morten Kjeldgaard: On 13/11/2010, at 12.40, Ulf Lamping wrote: How is landcover orthogonal to landuse / natural? Because you can imagine a landcover area overlapping -- or being a part of -- a landuse area. For example, landuse=nature_reserve might include landcover=heath, landcover=trees, landcover=lava_field. And these may also include areas outside of the nature reserve and be part of an adjacent landuse=farmyard. landuse=nature_reserve is your own personal concept. Please have a look at (and make yourself comfortable with) the existing map features before you discuss here. If you would now this specific discussion a bit longer, you might have known that it was suggested (some time ago) to use some kind of boundary for a nature reserve - which would be an improvement IMHO. OSM tags were not delivered to us on stone tablets. They are constantly evolving because new and surprising uses and ways of doing things emerge. Yes, we can use surface=* for everything, roads, buildings, forests, lakes, banks, restaurants, and so on, and that perhaps makes sense if you think of the map as a photoshop document where each pixel only has one colour. I can argue exactly the same way: Yes, we can use landcover=* for everything ... But those of us concerned future development of the database, wish for a more expressive and rich set of tagging options, enabling us to describe more complex circumstances of the world. You may have to learn that a change isn't always an improvement ;-) BTW: There was exactly *no* good example, which real world problem could be solved with landcover that can't be done with: surface, natural and/or landuse. Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] geology taggin?
Am 13.11.2010 12:04, schrieb Morten Kjeldgaard: On 13/11/2010, at 09.27, John Smith wrote: On 13 November 2010 15:38, Morten Kjeldgaard m...@bioxray.dk wrote: Yes, the landcover tag would be very useful in many instances, and quite orthogonal to landuse. Are you going to write a proposal for it, Martin? surface=* is currently used to denote the landcover information. Yes, for example surface=trees. Not very satisfactory is it? The landcover tag is necessary to bring OSM the next step along in development, and enables a detailed description for example useful in science and planning, vis-à-vis the multiple layers idea of Frederik Ramm. How is landcover=trees any more helpful then widely used landuse / natural?!? How is landcover orthogonal to landuse / natural? BTW: There is *no* benefit of a new landcover tag compared to existing tags. Please also have a look at the subject of this thread. This is about geology - trees are not part of that AFAIK. Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] geology taggin?
Am 13.11.2010 12:58, schrieb M∡rtin Koppenhoefer: 2010/11/13 Ulf Lampingulf.lamp...@googlemail.com: Am 13.11.2010 12:04, schrieb Morten Kjeldgaard: How is landcover=trees any more helpful then widely used landuse / natural?!? in the case of landuse: landuse=residential, landcover trees ? Or natural=beach, landcover trees? Landuse is the _usage_ of an area. How is landcover orthogonal to landuse / natural? landuse is the usage of the land, natural is used to denote features like summits, cave entrances, beaches, bays, ... No. Have a look at the natural section of: http://wiki.openstreetmap.org/wiki/Map_Features heath, scree, scrub, fell, sand is what you think what landcover should be. We already have that. Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] I started a draft on a new main key culture
Am 07.11.2010 14:04, schrieb Sam Vekemans: Hi, Adding 'culture=community_center' and culture=community_centre' would helpfull. although there needs to be a clear difference from 'tourism' key. perhaps 'tourism' is reserved for things that are designed primarly for the benifit of visitors to the area, were 'culture' is more for locals 'cultural activities/things/places. I came to the conclusion, that deciding if e.g. a museum better fits in tourism or leisure is pointless - as it is both and the decision will largely depend on your personal bias and the museum in question. I'll have a better answer in a few weeks. You may have a look at recent versions of JOSM. I have spend quite some time thinking about how to put these into the preset menu so that it makes sense. The solution that made most sense to me (and doesn't take care too much about the existing tags) is: - tourism - culture - leisure Limit tourism to signposts, information bureaus and alike. Deciding between culture and leisure is a lot easier then ... Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] url vs. website
Am 04.11.2010 06:17, schrieb Paul Johnson: On 11/03/2010 01:39 PM, M∡rtin Koppenhoefer wrote: The mapfeatures declare that url should not be used and website should be used instead. Is this a common agreement? I find url used 3,5 times more often (260 000) then website (66 800) in the database. I don't think it's a common agreement by any means, URL is more universal and includes websites; Well, url is a bit too generic IMHO and comes from the days when it was completely unclear how urls and alike will be tagged by our mappers. In common use today is: website= image= wikipedia= email= (... and url=) Don't know if that qualifies as url being deprecated though ;-) For some time there was quite a confusion between url and website, and people used url where website really would fit better as it is more specific both for mappers and data users alike. That doesn't mean you shouldn't use url at all, but if you tag the website for a specific object, you should use website rather than url. Think of use url if you know what you are doing, website probably better suits what you want to tag :-) websites excludes many types of URLs. I've not seen a lot else used than the above mentioned so far ... Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] shop=kiosk
Am 18.10.2010 15:04, schrieb j...@jfeldredge.com: However, a shop, located in a kiosk, that is selling cigarettes, newspapers, sweets, snacks and beverages is not selling kiosks, so labeling it with shop=kiosk breaks the label according to the merchandise sold principle. A shop that sold kiosks would be selling the buildings to would-be business people. So a supermarket is selling super markets?!? Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] shop=kiosk
Am 19.10.2010 00:10, schrieb M∡rtin Koppenhoefer: could be either food or newspapers/tobacco/sweets/etc. and/or lotto and/or public transport tickets and/or telephone cards and/or flowers etc., so it doesn't fit into shop=xy because it doesn't allow to deduct what is sold/which service is offered (which is the purpose of the shop-key). Use building=kiosk for standalone Kiosks and building_part=kiosk or s.th. similar for shops that are part of a building and sell out of the window (and are considered to be kiosk according to the mapper). Hmmm, Use building=kiosk for a kiosk like building. Use shop=kiosk for a shop that sells kiosk like stuff. If something else is sold, use shop=florist, shop=xy ... Problem solved, next please ;-) Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] shop=kiosk
Am 19.10.2010 01:23, schrieb M∡rtin Koppenhoefer: my point was that there is no kiosk like stuff I'm not living in a black and white world - do you? There's a list of stuff potentially sold in a kiosk (at least here in germany). I don't know if I can buy public transport tickets at a specific kiosk - until I ask about it at that kiosk. Same goes with a supermarket. Do you know if a supermarket will sell you a broom? Some will and some won't. We've never had a discussion about what the minimum assortment of goods a supermarket has to sell before we call it a supermarket. We simply tag it and go on. If other countries don't have such kind of shops, then don't tag it that way - where is the problem? If other countries have to name it newsstand (although it sells nearly the same kiosk like stuff), then tag it as shop=newsstand - where is the problem? Trying to discuss that there's no such thing as kiosk like stuff that a kiosk sells is simply bullshit. If you don't have such kiosks or no such kiosk like stuff in your country, fine, then don't use the shop=kiosk tag. Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] emergency=fire_hydrant
Am 18.10.2010 12:20, schrieb Rodolphe Quiedeville: Le 18/10/2010 09:31, Rodolphe Quiedeville a écrit : Hi, I started rename amenity=fire_hydrant to emergency=fire_hydrant as it is describe in the wiki. I checked there's no rendering in mapnik styles and t...@h. [...] I forgot to say that I've opened a ticket to fix the JOSM presets : http://josm.openstreetmap.de/ticket/5537 If someone could say to me how to fix the Merkaartor presets too, I'll do my best to do it too. There has been a very lengthy discussion about the emergency category - and there wasn't a clear outcome. There wasn't a consensus if the change is useful at all and it's still unclear what should be in the emergency category and what not. Then the Wiki was changed without community consensus. Then you seem to have made a mass edit without following the code of conduct about mass edits. Now you have the nerve to tell the JOSM developers: The key for fire hydrant is false, it's emergency=fire_hydrant instead of amenity=fire_hydrant, here a patch to fix the default presets The JOSM presets are correct and don't need to be fixed. Please revert the wiki and your mass edit changes back to it's original state! The developers have better things to do than these wiki fiddling nonsense ... Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] emergency=fire_hydrant
Am 19.10.2010 02:53, schrieb Richard Welty: On 10/18/10 8:40 PM, Ulf Lamping wrote: There has been a very lengthy discussion about the emergency category - and there wasn't a clear outcome. There wasn't a consensus if the change is useful at all and it's still unclear what should be in the emergency category and what not. it looked pretty non-controversial There wasn't even a consensus in the pro-change fraction what qualifies as an emergency and what not. until a small number of people started arguing loudly against it. I've counted 8 individuals that argued against the change at about 20 (not counted them) total participants. Doesn't look like a small number to me. Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] shop=kiosk
Am 17.10.2010 11:52, schrieb M∡rtin Koppenhoefer: shops should be tagged with shop=shop category, which refers to the kind of stuff sold, also in cases like supermarket or convenience, which are less obvious then e.g. shop=electronics. shop=kiosk breaks this rule, as it doesn't refer to the sold products but to the building typology. Therefore I'd like to propose to use building=kiosk and mark shop=kiosk as deprecated. The 10184 uses of shop=kiosk should be retagged by local mappers to indicate the product(s) sold (newspaper, fast_food, lottery-stuff, tobacco, etc.) For me, a kiosk is a special kind of a (very small) shop, as a supermarket is a special kind of shop. We don't tag the kind of stuff you'll buy in a supermarket. Same thing here. However, it is a misconception in the wiki, that shop=kiosk must be a special kind of building. A kiosk can just be a window or part of a fuel station, or ... If you find a kiosk, mark it as shop=kiosk. So if you find a kiosk *building*, you could mark it as building=kiosk. Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - rental
Am 16.09.2010 15:19, schrieb Jonas Stein: Are there tags missing? Any other issues? http://wiki.openstreetmap.org/wiki/Proposed_features/rental Yes, it's simply a bad idea. E.g. a car rental station is very different from a ski rental station. It looks quite different, it's used for a very different purpose, amenity=car_rental is already well established, ... This proposal has been already discussed on the german ml and the problems with this proposal won't go away if you announce it here. Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - rental
Am 16.09.2010 21:21, schrieb André Riedel: 2010/9/16 Ulf Lampingulf.lamp...@googlemail.com: Am 16.09.2010 15:19, schrieb Jonas Stein: Are there tags missing? Any other issues? http://wiki.openstreetmap.org/wiki/Proposed_features/rental Yes, it's simply a bad idea. E.g. a car rental station is very different from a ski rental station. It looks quite different, it's used for a very different purpose, amenity=car_rental is already well established, ... A shop=car is also very different from a shop=ski or shop=supermarket but it does exists in the same category shop. Well, Sixt will very rarely sell you a car, but a ski rental station very often will also sell you ski if you like. I'm not saying that the rental tag is generally a bad idea (I've recently added this to JOSM presets to indicate rental services for shop=motorcycle). What I'm saying is that there are places that will exclusively rent you something, and other places that will rent you something but also sell it to you, repair your own stuff and alike. So there are situations like amenity=car_rental where a standalone tag makes perfect sense, while in other situations the rental is only a minor part of the business. Putting this somehow all under a rental tag still seems a bad idea to me. Not everything that can be grouped together also should be. Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - rental
Am 16.09.2010 23:11, schrieb André Riedel: 2010/9/16 Ulf Lampingulf.lamp...@googlemail.com: Well, Sixt will very rarely sell you a car, but a ski rental station very often will also sell you ski if you like. I'm not saying that the rental tag is generally a bad idea (I've recently added this to JOSM presets to indicate rental services for shop=motorcycle). What I'm saying is that there are places that will exclusively rent you something, and other places that will rent you something but also sell it to you, repair your own stuff and alike. You can use rental and shop at the same time. So there are situations like amenity=car_rental where a standalone tag makes perfect sense, while in other situations the rental is only a minor part of the business. Putting this somehow all under a rental tag still seems a bad idea to me. Probably we should use rental=yes or shop=yes if it is only a minor part. Selling cars and sometimes letting of cars: shop=car rental=yes selling only few ski equipments and rental is the main business: rental=ski shop=yes Very certainly we should keep amenity=car_rental and not switch to rental=car just for the sake of tag cleanliness in completely unrelated scenarios - and BTW loosing lot's of clarity of the tag usage already in wide use. Replacing current tag usage with something a lot more ambitiuous without a real gain is, well, ... Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - rental
Am 17.09.2010 02:55, schrieb M∡rtin Koppenhoefer: 2010/9/16 André Riedelriedel.an...@gmail.com: Selling cars and sometimes letting of cars: shop=car rental=yes selling cars and renting motorbikes. shop=car rental=yes? Better use the syntax of the proposal: selling cars and letting of cars: shop=car rental=car selling only few ski equipments and rental is the main business: rental=ski shop=yes renting ski and located in a shop rental=ski shop=yes? I won't use shop or rental with yes/no because it is against the convention. I don't know which convention you are talking about, as there is none today in that regard. Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] is tourism a good category for everything cultural?
Am 24.08.2010 09:36, schrieb Ross Scanlon: Well, I will take a change to 'troll' again about it. This discussion comes up again and again because we don't have: a) clear tagging guidelines (*not* rules) b) mechanism to replace tags Agree totally. This (b) would be easily recitified by normalising the database in regards to tags. So how do you easily: normalise the mappers minds, renderers, editing software in regards to tags?!? Over several years past now, I have seen this discussions come and go. When someone was actually doing something, it usually ended up in a mess of wiki, mappers, editors and renderers disagreeing how to tag something. A confusion causing a *lot* more harm than any good. It's simply a misconception, that just cleaning up the tag names will lead to an easier mapping experience. Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] is tourism a good category for everything cultural?
Am 24.08.2010 10:29, schrieb Ross Scanlon: ... The renderers would simply have to look in the tagging table to see what needs to be displayed. Sounds to me that you have absolutely no clue how OSM is actually working. Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] craft= Proposal
Am 24.08.2010 10:08, schrieb Peter Körner: Hi some months ago I started a craft= proposal in my wiki user space: http://wiki.openstreetmap.org/wiki/User:MaZderMind/Key:craft http://wiki.openstreetmap.org/wiki/User:MaZderMind/DE:Key:craft It has grown over time and I got some questions to move it over to map features. I'd love to do so and I will also create a JOSM preset for that new key. I'd just wanted to ask here if this would be ok for you, too. Sounds like a good idea to me. The german and english pages differ a lot in the amount of examples. Maybe sync the pages? Might be a good idea to add few explaining words to the english examples, so none native speakers will get it faster. Please explain (on that page) differences between existing tags and craft ones e.g. shop=bakery vs. craft=bakery. Otherwise people will guess, which often differ in result :-) Please use BE: jeweler - jeweller Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] is tourism a good category for everything cultural?
Am 24.08.2010 10:46, schrieb Ross Scanlon: ... The renderers would simply have to look in the tagging table to see what needs to be displayed. Sounds to me that you have absolutely no clue how OSM is actually working. Regards, ULFL Typical. NFI about database use so you resort to slinging mud. I have a significant idea about how osm works as I have to integrate it into programs I write or contribute to. If the database was normalised then I'd have a reduction of about 1000 lines of code in one program alone. Hint: OSM is not about database coders saving their time. Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] is tourism a good category for everything cultural?
Am 23.08.2010 23:37, schrieb John Smith: Martin, So its ok to shift stuff from tourism but not shift stuff from amenity to emergency? No it's not ok to wiki-fiddling emergency, or tourism, or cultural or whatever - especially not, if a lot of people actually disagree with that change. I've seen that you're trying to win a battle against the state of the art*, seems you think it's a good idea to confuse a lot of people by editing the wiki. OSM is *not* about seeking the nicest possible tag name, it's about people tagging things. Regards, ULFL * http://wiki.openstreetmap.org/w/index.php?title=Tag:emergency%3Dfire_hydrantaction=history ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Dancing school
Am 17.08.2010 00:31, schrieb John Smith: On 17 August 2010 08:24, Ulf Lampingulf.lamp...@googlemail.com wrote: What is the benefit to put this all under amenity=school - and then have a tag no renderer actually can use, because it is far too generic? The benefit is an existing tag that isn't very specific, so we could imply the existing tag to be amenity=school, school=general if there is no school=* tag. That's not a benefit, that's only one of the possible definitions. Implying a specific meaning in the absence of a tag is usually asking for trouble. People tend to forget tags while not knowing your implication. Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Zone 30 (maxspeed)
Am 06.07.2010 20:38, schrieb Colin Smale: On 06/07/2010 18:44, Richard Mann wrote: I'm not really clear what is the value of tagging a zone, except in a note. Why not just use the standard maxspeed tag? +1 Here in NL it warns you that the given road sign (could be maxspeed, could be some other restriction) is valid until further notice i.e. until you leave the Zone. Without the Zone indication the restrictions lose their official validity at the next junction, which leads to speed limits etc. having to be repeated very frequently. So it is really only a shorthand notation to save money on signs and to reduce the clutter of street furniture. The default speed limit in built-up areas is 50kph so that actually rarely needs to be signed at all. But to make an area limited to 20kph means it has to be signed explicitly. It sure would make life easier if you could just draw a (temporary) polygon and get Potlatch to set maxspeed=20 on all enclosed roads though... Well, no. Two different things here: a) What's the actual maxspeed value b) What's the cause of the actual maxspeed value Wether b) needs to be tagged or not is a matter of personal opinion - further discussions on this are therefore pretty much pointless ... It was a long and hard discussion on talk-de that b shouldn't be replacing a altogether - I'm personally very glad that this concensus was made. If someone want's to specially tag b), I don't see a reason not let him do it that way. I'm not doing it but it won't harm anyone and will save us from ongoing discussions if we want to tag the actual value OR the inherent cause of it (sign, zone, ...). Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Parking for businesses..
Am 18.05.2010 09:13, schrieb Roy Wallace: On Tue, May 18, 2010 at 3:10 PM, Roy Wallacewaldo000...@gmail.com wrote: I propose to add the following to the Parking wiki page, in the table of the Tags section, as follows: (http://wiki.openstreetmap.org/wiki/Parking) Column Key: access Column Value: public/customer/private Column Element: [node or area] Column Comment: Specify the intended users of the parking lot. access=public if intended for the general public, access=customer if intended only for those who are visiting nearby shops/amenities, or access=private if access is more restrictive than access=customer (e.g. for staff only, or requiring specific permission). Sorry, let me try that definition one more time: Specify the intended users of the parking lot. access=public if parking is available for general public use; access=customer if parking is only for those who are visiting nearby shops/amenities; access=private if access is otherwise restricted (e.g. for staff only, or requiring specific permission, etc.). Only use access=customer or access=private if this restriction is signed or otherwise enforced. The final sentence is to make the tag verifiable. Thoughts? Use access=permissive instead of access=customer and you get what's in use for years. Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fast food vs. restaurant vs. cafe
Am 05.05.2010 06:17, schrieb John F. Eldredge: Yes, that is the origin of the term. However, usage of words shifts over time, often into multiple meanings, depending upon context. From what I have heard, a coffeehouse in Amsterdam, Holland, now means a place that sells marijuana, not one that sells coffee. It's called a coffee shop[1] and those are available throughout the netherlands. You can buy soft drugs and soft drinks (maybe a coffee) for local consumption, but you'll often won't get any cakes or alike or any alcohol there. But seeking for corner cases throughout the world is probably not the best way to find a good way to tag things. I guess even most dutch mappers won't tag a coffee shop as amenity=cafe, because the main purpose to get there is not to get a coffee. Regards, ULFL [1] http://en.wikipedia.org/wiki/Cannabis_coffee_shop ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fast food vs. restaurant vs. cafe
Am 05.05.2010 07:47, schrieb Roy Wallace: On Tue, May 4, 2010 at 6:22 PM, John Smithdeltafoxtrot...@gmail.com wrote: On 4 May 2010 18:14, Roy Wallacewaldo000...@gmail.com wrote: 1) allow for the specification of more than one type simultaneously, e.g. amenity=A;B, amenity=B;C, etc., or 2) change/specify in more detail the definitions of A, B and C so that they *are* mutually exclusive, or 3) be forced to tag things incorrectly Which option shall it be? I vote 2, which includes the option of just using amenity=D (where D=A OR B OR C) Do you have any concrete examples? So, I've been asked for a concrete example, presumably referring to how to define fast_food/restaurant/cafe *mutually exclusively*. I looked at the current wiki definitions for all three tags, and these are the best, new *mutually exclusive* definitions I could come up with, in the form of a flowchart: http://img94.imageshack.us/img94/1179/amenity.gif If you have suggestions to improve the flowchart, that's great - the main point is that, I believe, it is possible to precisely define the definitions of cafe/amenity/restaurant. And, I would suggest a unified flowchart in this case makes life easier than comparing three separate, vague wiki pages, or by doing mental experiments. You are asking for black and white definitions/decisions where there's lot's of room for grey. What about a place that serves limited breakfast in the morning, would classify as a cafe throughout the day, serves full meals only at noon and becomes a bar selling cocktails at night? What you can do is try to find good descriptions so that most people understand what is meant and decide locally how to tag it best. Regardless how fine grained you are doing this, there will always be corner cases where two people will disagree with each other. What you just can't do is find a precise definition that is valid throughout the world and will be doubtless in all possible situations. BTW: The flowchart is using highly subjective language heavily-advertised pseudo-food which is *very* certainly not a good way to find a concensus. Why does it try to offence junk food fans? Oh, and the definition of pseudo food will very certainly differ between people from the western world and people in africa starving right now. Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fast food vs. restaurant vs. cafe
Am 05.05.2010 22:36, schrieb Roy Wallace: There's only room for grey (w.r.t. the OSM definitions) if we want there to be. Following the OSM discussions for years now I would say: That's an illusion. I think I do understand your point, though, that you think it better to keep using these tags in a fuzzy, subjective, variable way throughout the world. Trying to redefine a vague definition existing for years with something more exact a lot later on is just asking for trouble. Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Is highway=service, service=drive_thru a good idea?
Am 12.04.2010 19:54, schrieb Anthony: Well, I now see that there are a few. I still don't understand why, though, and I don't think we should keep doing something which makes no sense just because we've done it in the past. It's not (only) because we've done it in the past, it's just a lot easier to type because you don't have to remember if it was a space, a hyphen or an underscore - you can simply type an underscore and you're done. Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] tag proposal image=http:/... .jpg
Am 05.02.2010 12:26, schrieb Tobias Knerr: Sam Vekemans wrote: I edited the page 'image' feel free to fix / edit/ delete http://wiki.openstreetmap.org/wiki/Image The problem with this proposal is that there isn't a definition which of the several images that likely exist for most objects should be referenced. And I expect that it would hard to create one, as there aren't any remotely objective criteria defining /the/ image for an object - it can always only be /an/ image of the object. This misses the point. In Wikipedia there's also no definition which of the several images that likely exist for most objects should be referenced, but Wikipedia has a lot of geo related articles with an image. My opinion is that personal preferences like that shouldn't be part of the OSM database. No my favourite Sunday walk route relations, no subjective food=extremely_tasty for restaurants, and no my favourite image of the object either. There's a big difference between the subjective my favourite walk and the objective this is a picture of the object. Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag a flagpole / ~flagstaff?
Am 05.02.2010 23:56, schrieb John Smith: On 5 February 2010 23:53, Jonas Steinn...@jonasstein.de wrote: How to tag a flagpole / ~flagstaff? I could not find it in the wiki. I had a quick look on the wiki, couldn't see anything. try something like amenity=flag_pole and add something to the wiki Sounds more like man_made to me, like a tower or beacon. I'd suggest: man_made=flag_pole Regards, ULFL P.S: Quick look at OSMdoc (http://osmdoc.com/en/tags/) found no real usage in either way ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposed: flagpole
Am 06.02.2010 03:23, schrieb Jonas Stein: Rationale Flagpoles are important landmarks. Usually they are visible over a long distance. http://wiki.openstreetmap.org/wiki/Proposed_features/flagpole This is my first proposal i hope everything is correct with it. Please contact me if something is wrong, kind regards, Hmmm, you might want to add the actual tagging? Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Offices/non-shop businesses
Am 27.01.2010 01:46, schrieb Martin Koppenhoefer: 2010/1/27 Roy Wallacewaldo000...@gmail.com: On Wed, Jan 27, 2010 at 8:51 AM, Woll Newallw...@2-islands.com wrote: The appropriate land-use tag is commercial (defined as Predominantly offices, business parks, etc.), so maybe such things should be tagged commercial=software_development, commercial=call_centre etc plus company name in the name tag? Not bad, but commercial is an adjective, not a noun. you could use commerce instead? still: Perhaps office=commercial + commercial=* would be better? +1, I like this because it also allows for office=non-commercial Keep it simple: office=call_centre Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] What's a power=station?
Am 19.01.2010 05:54, schrieb Stephen Hope: I wouldn't be so worried about it except for the fact that we use English tags exactly so that you can make a good guess as to what the data means without having to go to a lookup table. When almost all of the tags are readable, then an incorrect tag like this will just cause problems. In fact , it already has - I did a quick survey of it's use in some areas where I know what's actually there. Some sub-stations are marked with power=station (correct according to the wiki) some with power=substation. I think sub-station and station are both tainted now, unfortunately. I'm not saying this is a good thing, but: a) It doesn't really matter for most mappers. b) It doesn't really matter for almost anyone else ;-) c) The definitions of these tags were done in ~december 2007 probably by germans and the native english speakers didn't even care to correct these definitions till now. Since december 2007 it doesn't seemed to matter for most people how the actual wording is. d) I don't think it's a good idea to change a tag description two years after it was documented, because the wording is slightly wrong for some parts of the english speaking world. Because doing so is an annoyance for anyone involved and the wording will *always* be slightly wrong for someone. Not to mention that a lot of people won't notice/ignore any changes here, as these definitions are old enough in OSM terms. My approach: Stick to the wiki definitions even if you don't like it and go on mapping :-) e) Unless someone develops a nice open power distribution map, this discussion is pretty much pointless and will continue or flare up again endlessly, regardless of what we'll end up with it now. So if you are really interested in fixing this power wording problem, go and develop such a map. This will motivate the mappers much more to do it right than to conform to whatever rules set/changed in the wiki. Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Comparison of tag support: Mapnik, Osmarender, Potlatch, JOSM, Kosmos, Map Features (wiki)
Am 14.12.2009 10:05, schrieb Steve Bennett: On Mon, Dec 14, 2009 at 12:23 PM, Ulf Lamping ulf.lamp...@googlemail.com wrote: Yeah, and I think there is an unfortunate problem where the wiki/mappers don't want to tell the renderers what to do, and the renderers don't want to tell the mappers how to map. And I guess this is a good thing. I think it would be even better for the mappers to give guidance to the renderers, like This tag should be rendered distinctly from that tag or the combination of x,y,z should be rendered identically to tag w. The mappers very often can't find a consensus how to tag stuff. In the end this would probably mean that lot's of mappers annoy a very limited amount of rule writers ;-) I guess this is also a lack of man power. Don't underestimate the amount of time that is needed here. Having the actual usage numbers from e.g. OSMDoc[1] would really help here. Yeah, I was just having a look at tagwatch, which has usage numbers for the few hundred tags that are explicitly referred to in the wiki. Can't see how to get global numbers though - only by continent. I may try and integrate these numbers, but I'm a bit wary of what they mean. (eg, one bulk import of 10,000 nodes with a certain tag should not necessarily count for more than 8,000 nodes created manually by 20 different mappers. True. But I'm not sure if this is an often found problem in this case. BTW: tagwatch has a problem especially with the most used keys, see: http://tagwatch.stoecker.eu/Europe/En/keystats_amenity.html It will stop adding new values to the key list, if there are 300 items already accounted (IIRC due to memory reasons). So these numbers has to be taken with caution. It might be better to think in terms of core tags and specialist tags or something. If something is core, we expect all decent renderers to render it. How do you enforce this with people doing the renderer maintenance in their spare time? ;-) I didn't say enforce! All I'm saying, is you give a list of priorities, like all renderers should support these tags. Just like when you saw what the other renderers are doing, I think programmers would be inspired to implement that kind of list. And obviously certain kinds of tags can be implemented very easily, just with a colour or whatever, while others are harder. With all the stuff we already have, nothing is very easy to implement as adding new stuff will make it harder to read the existing stuff on the map :-) Maybe a top hundred of mostly used, but not rendered tags would be nice. I've started something similiar some time ago, but you'll have to somehow filter out tags that won't be interesting, e.g. created_by will be very often used but usually not rendered on a street map (although osmarender once rendered it). I guess, this filter will look quite different for the different renderers. I think its a much better way to display each renderer maintainer: Look, these are the tags that x, y and z are rendering and you don't. Maybe you've just missed it? And also the other way round: No one else is rendering x=y, maybe this is a bug? Yep. And the one I'm concerned about, renderer X supports tag A, renderer Y supports tag B, yet A is pretty similar to B. The mass of landuse=* and natural=* are pretty haphazard - I don't think any sharp distinctions are being recorded. Maybe as a first step we'll iron out the unintended differences between the renderers. That would already be a huge success! If this is done (and this will take some time and effort) then look at the missing definitions. As mentioned already, the next best step IMHO would be to have the actual usage numbers from OSMDoc. However, it's up to you what you do with your free time :-) Doesn't mean I don't want suggestions! [1] http://osmdoc.com/de/tag/sport/ Is there a way to get a big dump from this? I can only see a way to access one key at a time. Fascinating stuff, though. I note the usage of leisure=nature_reserve, natural_reserve and nature_preserve. Also, 457 leisure=swimming_pool, but 7188 sport=swimming. Hint: Don't try to get it all right in one rush, it will only make you mad ;-) If you look at OSMdoc or tagwatch, you'll find a *lot* of stuff that won't make sense (at least when you first look at it) and you'll find lot's and lot's of typos. Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Comparison of tag support: Mapnik, Osmarender, Potlatch, JOSM, Kosmos, Map Features (wiki)
Am 13.12.2009 11:35, schrieb Steve Bennett: Sorry for the spam. Sort of. :) http://wiki.openstreetmap.org/wiki/User:Stevage/tagsupport This is getting interesting. Side by side are now Mapnik, Osmarender, Potlatch, JOSM, Kosmos, and the Map Features wiki page. It's rather amusing, if a little depressing, seeing how little correlation there is. In particular, documenting a tag in the wiki seems to have little relationship with how well supported it is. The number of redlinks (undocumented tags) is also somewhat alarming - we should get into the practice of documenting every tag, regardless of whether it has any official status. Your comments welcome! Stephan Wolff gave some comments on talk-de that I'll try to translate: a) which versions of the programs / rules are displayed? How old is the table? b) what does highway=* or man_made=* mean? c) why is that power=line and power=tower and lot's of others displayed in the map have no entry in the Mapnik column? d) will a tag be displayed as node, way, area or only one of them? e) for mapnik and osmarender the minimum zoomlevel would be helpful My comments on this: a) a creation date would be really nice b) was obvious for me - but I'm a developer myself :-) c) maybe a bug? d) would be helpful but probably clutter the table a lot e) would be helpful but not critical (any probably clutter the table a lot) The questions were already answered on talk-de, but this might give you an idea of what the table is missing for the interest of normal mappers :-) Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Comparison of tag support: Mapnik, Osmarender, Potlatch, JOSM, Kosmos, Map Features (wiki)
Am 14.12.2009 11:02, schrieb Pieren: What is core and what is not ? What is in the wiki Map Features ? But anyone can add his tag, approved by 10 or 12 voters in the Map Features... You cannot fix priorities for other people creating the data or other applications using the data. What is the core for OpenCycleMap is not the same as the core for OpenWaterwayMap, OpenCrimeMap, OpenHikingMap, OpenShopMap, OpenTourismMap, OpenSchoolMap, etc... You are really expecting too much from the rendering side of the project. At least for the OSM based maps I've seen so far, the core of features that a map wants to display is often very similiar: streets, rivers, forest, ... plus some special interest stuff specific to this map. This isn't true for all maps and obviously maps will use different styles (colors, thickness, ...) to display these core features in different ways. However, having a list of features that a lot of other maps are displaying will very certainly help map makers in choosing the things they want to display. I don't see this as a has to be implemented but as a toolbox for mapmakers. Just don't underestimate the amount of time to get such a knowledge. What we need is a clear definition of the tags and this is done by searching a consensus on the wiki and on this list and we see if we succeed or fail with the statistics. We have e.g. lot's of highway=path in the database and no one (except the mapper) really knows what this *exactly* means in a specific case, as there is more than one definition out there. But statistics just can't tell you anything about this semantic. If we don't have a common definition of the tags, we end up with different rendering rules and even worst, with different tagging presets in the editors. The rendering rules doesn't matter a lot in this regard. It only displays a cycleway with a certain color, thickness and such - so it can be recognized as a cycleway. What the mapper wants to describe with highway=cycleway and what a map user understands out of this is basically out of the scope of the map display. So, what we have to do first, if we have to fix priorities, is to improve the definitions of the tags, avoid duplicates or changes in the meaning of the tags one year or two after their creation (e.g. the other thread about cycleway on this ML). I just don't know how to stop mappers from using a tag in a way they want to use it :-) Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Comparison of tag support: Mapnik, Osmarender, Potlatch, JOSM, Kosmos, Map Features (wiki)
Am 14.12.2009 11:59, schrieb Steve Bennett: On Mon, Dec 14, 2009 at 9:02 PM, Pierenpier...@gmail.com wrote: Btw, I do think that OpenHikingMap should interpret highway=cycleway exactly the same way as OpenCycleMap, OpenSwimMap, OpenMarijuanaMap...etc. They will each render it differently, but it should *not* be the case that cycleway means a paved surface in OpenSwimMap but it means a mountain biking trail in OpenHikingMap. Does that make sense? It's pretty important. Till today I only have seen maps that rendering a cycleway only with a specific visual representation. It was up to the user to get the semantic behind the magenta thin line The real problems now showing up with the routing software, there it is essential to distinguish between surfaces, if it's legal to use the way (or not) and all such details. You are really expecting too much from the rendering side of the project. What we need is a clear definition of the tags and this is done by searching a consensus on the wiki and on this list and we see if we succeed or fail with the statistics. Absolutely. I'm only constantly referring to the renderers because they're the physical manifestation of that definition. There may be other uses of OSM data, but the renderers matter the most. Well, not in the regard that you seem to have in mind :-) So, what we have to do first, if we have to fix priorities, is to improve the definitions of the tags, avoid duplicates or changes in the meaning of the tags one year or two after their creation (e.g. the other thread about cycleway on this ML). Yes. Part of the process fixing a tag may involve mass updates to existing data, or, more painfully, deprecation and a slow, manual check and update. Mass updates will often be seen as a bad move :-) Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Comparison of tag support: Mapnik, Osmarender, Potlatch, JOSM, Kosmos, Map Features (wiki)
Am 14.12.2009 01:29, schrieb Steve Bennett: On Mon, Dec 14, 2009 at 11:13 AM, Ulf Lamping ulf.lamp...@googlemail.com wrote: Partly because of differences in the intention of the renderers. It makes a difference if you want to have a nice map or if you want to aid in editing. Yeah, of course. The hypothetical SkiOSM renderer would support different tags from CampusOSM renderer. But there are lots of differences that can't really be accounted for that way. Why does JOSM support proposed= when the wiki explicitly prohibits it, for example? :) Where does proposed= is prohibited in the wiki?!? And lots of other little examples. Yes, a lot are probably simply bugs. Why on earth does Osmarender support sport=curling (when nothing else does), but not basketball, baseball... Why do all the editors/wiki propose a huge range of sports, but the renderers essentially ignore it all? Well, as I've said. Different people write different rules and have different interests :-) (I had thought sport=chess would be a joke, but I've already used it three times just in my suburb!) But also because different people are writing the rules. I think most of the people working on mapnik, osmarender, Kosmos or JOSM won't often work also with other renderers at the same time. Yeah, and I think there is an unfortunate problem where the wiki/mappers don't want to tell the renderers what to do, and the renderers don't want to tell the mappers how to map. And I guess this is a good thing. There's a lot of second guessing. Having an overview now, what the other renderers are doing is a good way to encourage anyone to become better here. I guess this is also a lack of man power. Don't underestimate the amount of time that is needed here. Having the actual usage numbers from e.g. OSMDoc[1] would really help here. There is also other stuff, e.g. the widely used piste map things that are documented at: http://wiki.openstreetmap.org/wiki/Proposed_features/Piste_Maps. Jeez, there's something seriously wrong in this whole proposed/approved process. People put a lot of work into describing a feature, but because it's not clear what action it's trying to make happen, the thing just dies. (Yes, I vote to make it possible to...uh...continue to do what I already do.) The voting process was actively torpedoed by some people some time ago :-( It might be better to think in terms of core tags and specialist tags or something. If something is core, we expect all decent renderers to render it. How do you enforce this with people doing the renderer maintenance in their spare time? ;-) I think its a much better way to display each renderer maintainer: Look, these are the tags that x, y and z are rendering and you don't. Maybe you've just missed it? And also the other way round: No one else is rendering x=y, maybe this is a bug? In all my suddenly non-existent free time, I intend to make a pass over a lot of these redlinks, adding descriptive entries, at least. (This tag appears to be used in germany, it's supported by ... etc.) As mentioned already, the next best step IMHO would be to have the actual usage numbers from OSMDoc. However, it's up to you what you do with your free time :-) Regards, ULFL [1] http://osmdoc.com/de/tag/sport/ ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] kosher amenities
Liz schrieb: On Fri, 16 Oct 2009, Lennard wrote: BTW2: It's halal. What you lack in replying restraint, you make up for with extra letters? My keyboard doesn't write Arabic, but I'm quite sure it ain't halal or hallall or halall - that any transliteration is probably missing something I've seen both halal and hallal written in Nuremberg turkish cuisine restaurants. Anyway: http://en.wikipedia.org/wiki/Halal So we might want to use the term halal (for presets, rendering rules, ...), but hopefully won't get upset if some mappers use one of the transliterations :-) Regards, ULFL ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
