Re: [Tagging] leisure=swimming_pool for the pool or the complex?
Hi, I don't agree with the use of the "landuse"-key. Landuse should be used for larger areas where you need a (generic) term for a conglomerate of objects (like "landuse=residential" for an area with houses, garages, gardens, streets - each of which can also be mapped seperately), but not for single objects like a pool. Am 23.07.2013 05:23, schrieb John F. Eldredge: I am saying that the land_use tag makes sense for in-ground pools, since they greatly reduce the odds of the land subsequently being used for some other purpose. In that case it would also be valid to use "landuse=building" or something like that because the same argument holds here. I don't think that the landuse-key should be used in such way. In short, I'm a bit concerned about the increasing use of the landuse-key for everything that covers a relatively small space, since the key is intended for large areas. Seoman Yes, I know such reuse does happen on rare occasions; the city of Nashville, TN, closed all of its public pools in the 1960's rather than obey a court order to integrate them, and turned at least one of the pools into a sunken garden. Bryce Nesbitt wrote: On Mon, Jul 22, 2013 at 7:04 PM, John F. Eldredge mailto:j...@jfeldredge.com>> wrote: You state "The pool after all is a man-made object that just sits on the ground". Some pools sit on the surface of the ground, and so could potentially be moved from one location to another. Others are built into an excavation, and can't be moved without demolishing them. They are a permanent change to the landscape, unless you fill them in. Surely you don't mean to suggest we need to map a distinction between movable and unmovable pools? Last week I watched a building getting moved. As a kid my parents went to the low rent ski area. The lift poles were different colors, sometimes two or three to a pole. The lift had been assembled from the parts of other lifts decommissioned at other areas. Everything in the "man_made" category can be moved, including at unsustainable cost, the in-ground pools. Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging -- John F. Eldredge -- j...@jfeldredge.com "Reserve your right to think, for even to think wrongly is better than not to think at all." -- Hypatia of Alexandria ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] What is and what isn't a valid type=multipolygon relation for osm ?
Am 13.10.2012 20:02, schrieb Martin Koppenhoefer: * "Exactly two unclosed ways belonging to a role, and no more should share an endpoint (eg. the most extreme nodes of a way represented by the black dot in the images). If an endpoint is shared by less than two unclosed ways, the polygon can't be closed and is ill formed. invalid example 1 If an endpoint is shared by more than two unclosed ways, it's ill formed and a closed polygon can't be reconstructed unambiguously. invalid example 2" Since the "Valid Multipolygon conditions" section is at the top of the page, new mappers are reading this first. And if you don't give examples about what that means (or at least provide appropriate links), many will stop reading here, bercause they simply can't follow. I'm in OSM for over a year now and I still shy away from anything containing multipolygons because I'm not sure I understand them correctly. So, in my opinion there can't be too many examples (both for correct and incorrect use of multipolygons). Seoman ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Extended Conditions - response to votes
Sorry, I didn't realise I was on the 'Tagging' instead of the 'Talk-de' list. And the first link was wrong, too ... (note to self: drink coffee first, write to list afterwards ...) So, again in English: />>Honestly, for me this cause has become too complex, so I won't vote (for now). In my understanding there is one k.o. criterium, mentioned by Walter in the German forum ([1], post #81). He objected that there are problems with SQL queries and the HSTORE scheme, Georg agreed ([2], Post #89). I don't understand much of this but I agree that the queries have to work in every case. So my question is: Can anybody solve the problem mentioned by Walter in favour of the proposal? I'm talking about a real query test, not statements like 'that should work in theory'.< And now, to make up for my blunder, here is a (rough) translation of Walters and Georgs posts in the German forum: 'In Postgresql (the database OSM uses internally) tags are stored in the form key=value. In the Simple-/Snapshot scheme the so called HSTORE is used for this; that is a data structure for depositing any number of information of an object (i.e. the tags of a node/way). All postgresql specific HSTORE queries, changes, indexing - everything - only can work with complete keys, the values can be arbitrary [3]. Queries like "/List all nodes with the key 'maxspeed' or 'maxspeed:wet'/" are no problem at all, but a query like "/List all nodes with 'maxspeed%'/" doesn't work! (% is the wildcard for SQL). Queries for values (what stands behind the "=") can be done easily and with good performance, too. In other words: *The database the entire OSM data is kept on doesn't support variable keys when tagging.* You can save them but you cannot query them.' [...]' And here Georgs (shortened) reply: '[...] The problem of variable database keys (which coincide with the OSM keys) mentioned by Walter persists. Therefore: Variable conditions in the key prevent meaningful database queries [...]. Variable conditions in the value on the other hand remain a matter of applications' Sorry for the mess, Seoman [1] http://forum.openstreetmap.org/viewtopic.php?pid=252489#p252489 [2] http://forum.openstreetmap.org/viewtopic.php?pid=252834#p252834 [3] http://www.postgresql.org/docs/9.1/static/hstore.html ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Extended Conditions - response to votes
Ich muss ehrlich sagen, dass die Sache für mich zu komplex geworden ist, daher werde ich (derzeit) auch nicht abstimmen. Nach meinem Verständnis ist aber das Folgende ein K.o.-Kriterium: Im Forum hat wambacher (Walter) auf Schwierigkeiten mit SQL-Queries und dem HSTORE-Schema hingewiesen ([1], Post #81). GeorgFausB (Georg) hat etwas weiter ([2], Post #89) geantwortet und zugestimmt. Ich habe davon leider nur wenig Ahnung, stimme aber zu, dass die Queries in jedem Fall funktionieren müssen. Meine Frage daher: Kann jemand das von Walter angesprochene Problem zugunsten des Proposals lösen oder nicht? Damit meine ich einen tatsächlichen Query-Test, nicht Aussagen wie "das sollte theoretisch gehen". [1] http://forum.openstreetmap.org/viewtopic.php?pid=252644#p252644 [2] http://forum.openstreetmap.org/viewtopic.php?pid=252834#p252834 Seoman ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Centre for Media Services
Hi,
I'd like to tag a service centre at a university. They call themself the
"Centre for Information and Media Services" ("Zentrum für Informations-
und Mediendienste" in German) and provide all kind of services, like
maintenance of computer infrastructure, data processing, software
administration, account managing and so on.
For now, I've tagged it as "amentity=service_centre" +
"services=multimedia" (with "s" so not to mix it up with "service=*").
Does anyone have suggestions for more precise tags?
Seoman
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
[Tagging] University with buildings in 2 cities
Hello, I'd like to do some mapping on the university of Duisburg-Essen. As the name suggests, this university has buildings in two cities and on several locations in each city. Also, I'd like to use the "type=site" relation for this ( http://wiki.openstreetmap.org/wiki/Relations/Proposed/Site ). The "amenity=university" and the "name:de=Universität Duisburg-Essen" (and corresponding "name:en=*" of course) I'd like to assign only once for the parent relation of the university. But I'm afraid that's overdoing it: I know we don't map for the renderer, but in this case the name of the university will probably be rendered somewhere in the middle of the two cities - in another city (Mülheim). The same problem on a smaller scale is within each city. For now I think I'm going to put the tags on the relations of each location, resulting in three to four name and amenity tags in each city. But I'm still open for suggestions. Did anyone encounter the same problem? Gerhard ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Use cases: where would a count of all lanes be useful?
Am 19.09.2011 13:29, schrieb Nathan Edgars II: Can someone give an example of a case where the number of lanes, including turning lanes, on a road would be more useful than just the through lanes, and where another tag (such as width) would not be even more useful? I'm unable to think of such a case. Traffic simulation (e.g. by cellular automata) is a use case for this. At crossroads it can make a huge difference for traffic engineering to know if a (turn) lane can contain 3 or 30 vehicles. To determine the "capacity" of a turn lane one would need information about its length - and one would get this easily if start and end point of the lane are known. Otherwise one would have to tag something like "turn_lane_left_1=xx" and "turn_lane_left_2=yy" (indicating length or capacity or whatever) in case of two turn lanes with different lengths. Seoman <>___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Forestry
Hi all, I came across forest roads, signposted as follows: "Forest road closed for motor vehicles, riders and harnessed teams. Free for forestry". (Actually the sign is in German: "Forstweg gesperrt für Motorfahrzeuge, Reiter und Gespanne. Frei für Forstbetrieb".) For now they are tagged as: * access=forestry * bicycle=yes * foot=yes * highway=track * horse=no * motor_vehicle=no * surface=gravel * tracktype=grade2 and I would complement this with "carriage=no". Now looking at the sign would you recommend a) "access=forestry"+"motor_vehicle=no" or b) "motor_vehicle=forestry" so the access-tag becomes obsolete? Thanks, Gerhard (Seoman) <>___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
