Hab ein paar Verbesserungsvorschläge:
Nicht animals=dogs,horse… verwenden sondern am besten gleich horse=yes, dog=yes - wie bei den Access-Tags verwenden.
Und stets aufpassen das das im Singular bleibt, also nicht horse, dogs!
Dann noch zu Payment: Das wird bereits bei amenity=vending_machine verwendet.
Dort ist das Schema payment:coins=yes|no payment:notes=yes|no, usw.
Am besten das übernehmen, damit alles schön einheitlich bleibt.
Auch leasing, cleasing und power_supply betrifft das.
Ah ok ich werde mal probieren alle Tags die hier ewähnt wurden und schon irgendwo genutzt werden mal rauszusuchen.
Also ich bin immer wieder erstaunt mit welcher Detailfülle manche Leute taggen wollen. Dabei sollte man erst einmal eine gute Basis erstellen. Ein Campingplatz wird in der Regel so groß sein, dass er als Fläche getaggt werden soll. Dann auf dieser Fläche die Wege für Autos und Fußgänger einzeichnen. Ebenso die festen Gebäude wie Empfang/Platzwart, Toiletten, Shop, Restaurant usw. Diese dann mit den zugehörigen Tags versehen. Nicht vergessen den Zaun und die Tore einzutragen. Als weitere Detailierung kann man die Bereiche für Zelt, Caravan, Motorhome eintragen, so sie getrennt sind. Und nicht die Parkplätze vor dem Campingplatz vergessen.
Dadurch entfällt natürlich vieles, was du gerne als Eigenschaft des Platzes hättest, da es schon als eigenes Objekt existiert. Der Anwender einer Kartendarstelllung sieht jedoch recht gut, wie groß der Platz ist sowie was und wo es alles gibt.
Es gibt Bemühungen/Vorschläge verteilte Objekte, die zu einem Oberbegriff gehören (z.B. Uni-Campus, große Firmen, …) durch eine Relation zu einer Einheit zusammen zu fassen. Das sehe ich eigentlich auch für einen Campingplatz.
Nun zu deinen/euren Vorschlägen auf ‘Tag:tourism=camp_site’:
Weiter mit euren Vorschlägen auf ‘Talk:Tag:tourism=camp_site’:
Meiner Meinung nach sollte man soviel wie möglich an bestimmte Punkte/Gebäude binden.
Dann hat man auch gleich den Überlick, wo wichtige Einrichtungen sind. Auf einem großen
Gelände gibt es z.B. sehr wahrscheinlich mehr als eine Toilette.
Zur Liste der bestehenden Tags:
Überschrift: Statt Attribut Feature, dann Key, dann Value und zum Schluss Description.
In der Beschreibung können/sollen mögliche ergänzende Tags aufgeführt werden.
Eigentlich braucht man noch die Festlegung ob auf Knoten, Wegen oder Flächen anwendbar
sowie Rendering und ein Beispielfoto.
Feature Key Value Description / additional Tags
Toilets ‘amenity’ ‘toilets’ ‘fee=yes/no’
Restaurant ‘amenity’ ‘restaurant’ ‘cusine=italian/french/…/steak/fish/…’
FastFood ‘amenity’ ‘fast_food’ ‘cusine=burger/pizza/kebab/sushi/…’
Piers ‘man_made’ ‘pier’ ‘floating=yes’
'mooring' 'yes/private/no' 'maxstay=<number>', 'operator=*', 'access=*'
‘natural=beach’ ist eigentlich nur für Strände an der Seeküste gedacht.
‘leisure=beach_resort’ steht noch nicht in den Map_Features.
Es enthält diese Einschränkung allerdings nicht.
Sailing, waterski, (table) tennis, riding, diving usw. geht meist über ‘sport=…’
manchmal jedoch auch über ‘leisure=…’.
Für einen Swimingpool gibt es keine klaren Vorgaben, nicht einmal für Pools in Freibädern.
Zum Namen:
Man kann auch ‘campsite’, ‘campground’ oder ‘camping_ground’ statt ‘camping_site’ nehmen.
Leider ist der Sprachgebrauch in den USA, Großbritanien und Australien sehr unterschiedlich.
Hoffe es hilft.
Edbert
Wow da hat sich aber einer Mühe gemacht OO
Nodes für einzelne Bereiche auf dem Campingplatz, nicht wenige wollen es also ganz genau taggen. Gut ich denke das kann man machen, da ich Informatiker bin würde ich allerdings taggen an einen Node bevorzugen, da es Suchanfragen erhebich vereinfacht. Allerdings lassen sich so die ganzen Probleme der doppelten Tags/Nodes sehr elegant umschiffen also machen wir das so und packen alles in eine Relation. Gabs da nicht eine IS_IN Relation oder sowas?
Bei maximaler Ausbaustufe ist es in der Tat eine Fläche, nur zumindest bei uns ist es dann doch des öfteren erst mal nur ein Node. Ich hoffe ja die Betreiber dafür gewinnen zu können, nur dafür muss halt erstmal das Schema aufgebohrt werden 
Nun habe ich nurnoch die folgenden Modellierungsprobleme:
Anzahl der Plätze:
Es soll ja rein:
-ob Zelte, Caravans, Bungalows erlaubt/verfügbar sind
-wieviele Plätze davon vorhanden sind
-wieviele der Plätze Dauercampern vorbehalten sind
-das bestehende max_tents oder capacity(Parkplätze) soll irgendwie mit einfließen
Stromanschluss:
Irgendwie hatte wohl noch keiner das Problem, konnte jedenfalls noch nirgendwo etwas finden. Habe deshalb eine Diskussion eröffnet. Caravans, Boote,… haben ja unterschiedliche Stecksysteme also entweder Schutzkontakt oder Starkstrom(CEE) soweit ich weiß.
http://wiki.openstreetmap.org/wiki/DE_talk:Key:power
Schließ+Ruhe Zeiten:
Wenn wir beides per Formatierung wie bei opening hours abdecken, sollte das doch ok sein oder?
Gut ansonsten werde ich mal noch interessante Sachen zusammentragen. Gibt es einen bestimmten community prozess der das Erweitern bestehender Tags betrifft? Muss da abgestimmt werden wie bei Proposed features?
Das vorgehen könnte doch so aussehen. Wenn nur ein Node vorhanden ist und Daten für die flächige Darstellung nicht vorliegen bekommt der Node die Tags. Ansonsten wird das was möglich ist extra eingezeichnet und mittels Relation verknüpft. Diese Aufteilung halte ich für sinnvoll, da derzeit viele (wenn nicht sogar die meisten) Plätze eben nur aus einem Node bestehen. Und man evtl. auch nicht genau weiß, wo die jeweilige Einrichtung sich befindet. Besser alles klebt am Node oder an der Fläche als das es fehlt. Ziel sollte aber Fläche+Einrichtungen extra sein.
max_tents kann man integrieren, wenn man bei tents nur yes|no taggen kann. Mir gefällt aber die Variante ohne max_tents besser. Weil wenn max_tents vorhanden ist, ist es logisch, dass tents=yes getaggt ist.
Über tents|caravans=number würde ich nur die frei verfügbaren Plätze zählen und Dauercampingplätze über durable_camping=yes|no|number erfassen.
Ein Zeltplatz hat ja verschiedene Bereiche für Caravans und Zelte. Diese würde ich mit area=tents|caravan|durable_camping einzeichnen und der Fläche ein surface=gras|gravel|ground|… mitgeben.
Ich schließe mich dem Vorschlag an die Plätze mit mehreren Objekten zu beschreiben und diese dann zu gruppieren. Zum Gruppieren schlage ich [1] vor. Dabei würde ich Infos, die für den gesamten Platz gelten, in die Relation übernehmen (beispielsweise ein Schlüssel website).
Mein Vorschlag für die Relation in Anlehnung an [1] sind die Schlüssel und Werte:
type=site
site=camp_site (weil am häufigsten verwendet, siehe [2])
name=Name vom Platz
website=Adresse, falls vorhanden
phone=+Nationalkennung-Lokalteil (nach [3], siehe [4])
Die einzelnen Einrichtungen am Platz wären als Mitglieder der Relation einzutragen.
Außerdem möchte ich noch folgende Eigenschaften in den Raum werfen:
Falls jemand Campingführer besitzt, welche Kriterien sind dort für die Plätze gelistet?
Gibt es fürs Camping spezielle Stecker/Steckdosen? Inwiefern sind diese genormt?
[1] http://wiki.openstreetmap.org/wiki/Relations/Proposed/Site
[2] http://osmdoc.com/en/tag/tourism/#values
[3] http://tools.ietf.org/html/rfc3966
[4] http://wiki.openstreetmap.org/wiki/Key:phone
Ein Taggen direkt an der Relation halte ich erstmal für wenig sinnvoll:
1.Zu komplex wenn Campingplatz-Betreiber mitarbeiten sollen
2.ein enorm hoher Änderungsaufwand an bestehenden camp_site Nodes und der auswertenden Programme
3.das erfassen der Campingplatz-Struktur z.Z. noch ein Sonderfall ist
Ich denke z.Z. spiegelt ein erweitertes taggen des Platznodes/areas sehr gut die Bedürfnisse wieder. Einer späteren automatischen Migration der Daten steht ja nichts im Wege.
Soweit hätten wir alles an Eigenschaften, fehlen nur noch die o.g. Probleme 
phone=* wurde bereits abgelehnt.
Da müsste du oder sonst jemand einen erneuten Versuch machen.
MMn sollte das aber alles an den Platz gebunden sein, da man zur Zeit kaum darauf hoffen darf, dass Renderer die Informationen in der Relation sinnvoll auswerten. Ob doppeltes Eintragen schadet, kann ich nicht einschätzen.
Entsorgung ist mit amenity=waste_disposal + waste=… bereits möglich.
Der nächste Schritt wäre das alles als Feature Proposal aufzusetzen, siehe http://wiki.openstreetmap.org/wiki/Proposed_features und dann den ganzen Ablauf über Draft, Proposal, Voting durchzuführen. Bevor du das machst aber in den Listen der aktiven, aufgegebenen, abgelehnten und angenommen Proposed Features nachsehen, ob es Überschneidungen gibt. Je nach dem kannst du auch einen aufgegebenen Vorschlag neu beleben.
Die spezifischen Tags für Relationen sollten in dem Vorschlag enthalten sein. Es kann sich im Verlauf der Diskussion herausstellen, dass ein separater Vorschlag sinnvoller ist, da das Zusammenfassen von Objekten per type=site von allgemeinerer Natur ist.
Wichtig ist erst einmal, all die neuen Tags auch formal absegnen zu lassen.
Wenigstens die Fläche sollte als Indikator für die Größe eingezeichnet sein. Ein Mapper, der nebenbei feststellt, da ist ja was, mag ein Node als Hinweis genügen, dass dort noch mehr anzusehen und einzutragen ist.
Für deine Campingplatz-Betreiber kannst du dann ein HowTo schreiben, wie man einen Campingplatz in OSM mit möglichst vielen Details sinnvoll mapped.
Wie auch immer, ein tolles Projekt, dass du angestossen hast.
Edbert
Nun, das sollte nur als Hinweis dienen, dass an dem Punkt eventuell mit Widerstand zu rechnen ist.
Das ist ein allgemeines Problem des gesamten Vorschlags, dass es viele Punkte gibt,
die auch anderweitig verwendet werden können. Bei diesen Punkten kann Widerstand
aus unerwarteten Richtungen kommen.
Zu osmdoc.com/de/tag habe ich noch eine Frage.
Ist das die Verwendung in Deutschland oder in der ganzen Datenbank?
Das sollte weltweit sein…jedenfalls sind Einträge aus den USA enthalten…
Oje also ein Feature Request…kann sich mal jemand per Email melden der sowas schon durchgezogen hat? Ich bin da ein wenig überfordert mit dem Ablauf, da ich auch noch ein paar andere Sachen am köcheln habe.
Also muss ich da für jeden Schlüssel, den ich da neu einführe ein eigenes Freature Request machen? Auch wenn ich bestehende nur verändere?
Nein sicher nicht. Was zusammen gehört, sollte auch zusammen bleiben.
Aber es kann sich im Laufe des Prozesses herausstellen, dass einzelne Teile so weitreichend / allgemein sind, dass es besser ist sie getrennt zu behandeln. Zum Beispiel gab es bereits zwei Vorschläge zu Relationen für Gelände (site/campus), die du aufgreifen könntest. Solche Dinge stellen sich erst im Laufe der Diskussion heraus.
Insgesamt ist dein Ansatz schon recht gut:
Was willst du neu,
Was muss erweitert werden.
Was existiert bereits und kann entsprechend genutzt werden.
Edbert
Unterschied camp_site, camp_ground und caravan_site.
Eine “camp_site” (und auch ein “camp_ground”) ist im englischen (amerikanischen) Sprachgebrauch ausschliesslich (!) für Zelte ausgewiesen! Meist sind damit primitive Plätze in der Wildnis gemeint, an denen man als Mehrtages-, Wildnis-Wanderer oder -Reiter sein Zelt aufschlagen darf (z.B. in Natur-, Nationalparks etc. wo man anderswo nicht zelten darf).
Die meisten deutschen (und europäischen) Campingplätze sind i.d.R. als “caravan_site” zu taggen, da dort nicht nur gezeltet wird (Zelte sind dort meist sogar in der Minderheit).
Meine Faustregel: dürfen auf den Campingplatz auch Wohnwägen oder Caravans dann ist das ein “caravan_site”, nur Zelte dann “camp_ground”, und ist letzterer nur nach (mehr oder weniger) langem Fußmarsch durch die Wildnis zu erreichen, ist klein (und hat wenig oder gar keine “Infrastruktur”) “camp_site”.
Micha H.
Hallo Micha,
wenn das mit dem Sprachgebrauch so ist, sollte man sich evtl. auf ein anderes Tag einigen. Bspw. einfach nur camping.
Was nun auf dem Platz erlaubt ist, sollen ja zusätzliche Tags regeln.
Ein Tag für alle “Campingplätze” ist deutlich einfacher zu taggen. Andernfalls geht nämlich wieder die Fragerei hier los. “Ist es nun camp_side oder camp_ground?”. Und die Unterschiede klar zu definieren ist sicher unmöglich.
Ist ein Brunnen, wo man sich Wasser zum Waschen erpumpen kann schon “Infrastruktur”, oder bedarf es dafür fließendes Wasser?
Das Tag sollte nur die Bedingung haben, dass es ein ausgewiesener Ort ist, wo zumindest eine Möglichkeit des Übernachtens (in Zelt, Caravan oder Hütte) besteht.
Bzgl. des Proposals: Ich würde es alles in einem machen.
Dann bräuchte ich wirklich mal jemanden, der weiß wie man das Proposal richtig formuliert und der näher mit mir zusammen arbeiten möchte.
Langsam, langsam, ein bestehendes und genutztes Tag zu ersetzen ist besonders schwer. Ich sehe im Augenblick auch keinen Anlass dafür.
Die augenblickliche Situation scheint unbefriedigend aber die Werte ‘camp_site’ und ‘caravan_site’ für ‘tourism’ existieren und werden auch unterschiedlich benutzt.
Edbert
Ok scheint sich ja keiner zu melden, wo würde man denn solche Erweiterungen von camp_site formal hinpacken?
Klar Sachen die unabhängig sind laufen seperat z.B. die Nacht/Mittags Ruhe, Stromanschlüsse,…