camp_site tag verbessern

Hey.

Erst mal großes Lob für das Projekt welches du in die Hand nimmst!

Mir fällt gerade nichts mehr ein was man noch aufnehemen könnte, bzw. was man verändern könnte.

Gruß

Das Lob nehme ich gerne an, dank 🙂

Naja gerade die untere Tabelle der Attribute ist problematisch. Ohne Frage sind die sehr wichtig aber ich wüßte nicht wie ich die ohne Redundanz modellieren sollte.

Bei den anderen wäre es gut mal rüber zu schauen, vielleicht gibt es ähnliche Tags schon. z.B. gibt es ja horses=yes für Restaurants. Man könnte ja verallgemeinern und auch dogs=yes/no

moin,

sieh' doch 'mal bei den seamap-Leuten nach, was es da schon gibt. Viele Campingplatzannehmlichkeiten finden sich auch in Yachthäfen.
Man muß ja nicht das Rad neu erfinden 🙂

http://openseamap.org/
http://www.freietonne.de/

Gruß

Jörk

Hallo,
ich finde die Idee auch gut, Campingplätze näher zu beschreiben. Allerdings sollte man einem Key eindeutig ein Value zuordnen können. Da sehe ich bei Textilwäsche und beim Leasing ein Problem. Hier wäre ein seperates erfassen ala washing_mashine=yes und dryer=yes mMn besser.

Ansonsten schließe ich mich auch Jörk an. Bspw. würde ich einen Imbiss, Kiosk, Tante-Emma-Laden, Restarant, FKK-Strand, etc. extra einzeichnen, da wo es ist und nicht dem Campingplatz alle diese Tags zuordnen.

Hallo !,

ich würde für Dusche folgendes tag vorschlagen: show=no|yes|cold|hot
Es wird meist als Hot-Shower bezeichnet, nicht als Warm-Wasching.

animals=yes wäre einfacher als die Aufzählung aller erlaubten Tiere

Statt disposal wäre auch dumpstation gebräuchlich.

Derzeit sind ja viele campingplätze mit tourism=camp_site und wenige mit tourism=caravan_site gemappt.
Ich finde, es wäre am besten, die Anzahl der Stellplätze anzugeben, und zwar je Art.
tents=yes|no|number
caravans=yes|no|number
cabins=yes|no|number

internet_access=yes|no|wlan wäre auch nicht schlecht
Ev. auch noch eine Angabe, ob über Nacht ein Tor geschlossen wird.

Walter

Ah alles sehr interessant 😄

Ich finde die Unterscheidung caravan_site, camp_site eh sehr komisch, sind die meistens doch zusammen (aber vlt. nur in der BRD?)

Das mit den Tieren meinte ich auch so, nur die einzelnen Ausprägungen können ja auch interessant sein z.B. wandern mit Pferd.

Stellplätze würde ich noch unterscheiden nach saisonal und Dauercamper, so war das auch im Katalog aufgespalten und macht ja doch Sinn oder?

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':
- alle allgemeinen Eigenschaften können/sollen nicht an einen Punkt gebunden werden
sondern eher an den ganzen Campingplatz, sprich die Fläche.
Lediglich beim Check-In könnte es ein Punkt sein.
Dabei gibt es zwei Wege etwas zu taggen:
Entweder als 'scout=yes/boy/girl/no' oder als Unterpunkte wie z.B. 'camp_site:scout=*'.
Hängt von den eigenen Vorlieben / anderweitigen Verwendbarkeit ab, was man bevorzugt.
Ich mag die zweite Schreibweise nicht besonders, da es die Verwendbarkeit in anderen
Zusammenhängen verhindert.
- 'tent=yes/<number>' alternativ eine Zahl, wenn es eine obere Grenze gibt.
Damit erübrigt sich der Key 'maxtents'. 'caravan' entsprechend
- 'open_fire=yes/no' ist wichtig, sollte aber nur dann an einzelne Punkte gebunden werden,
wenn es nur an speziellen Plätzen erlaubt ist. Kann man ggfs. auch für Grillplätze verwenden.
- 'backcountry' finde ich überflüssig, das sieht man eigentlich aus der Umgebung.
Es sei denn man meint 'wilderness_camp(ing)' (mit geringem Komfort/Infrastruktur).
Dann sollte man das auch so nennen.
- 'impromptu' sagt(e) mir nichts und überschneidet sich mit 'backcountry'.
- 'camp_site=check_in' mag sinnvoll sein.

Weiter mit euren Vorschlägen auf 'Talk:Tag:tourism=camp_site':
- scout=yes/no/boy/girl ist in Ordnung. Kann ggfs. auch beim Domizil verwendet werden.
- caravan/cabin/tents=yes/no/<number> ist in Ordnung, ggfs. auch motor_home.
- für Öffnungszeiten gibt es bereits den Key 'opening_hours'.
<http://wiki.openstreetmap.org/wiki/Key:opening_hours>
Damit kann man sowohl Uhrzeiten als auch Tage/Monate beschreiben.
- Dusche halte ich für wichtig also 'shower=yes/warm/cold/no'
- 'baby_bath' halte ich für übertrieben. Wer mit einem Baby auf einen Campingplatz fährt,
hat sicher auch Vorkehrungen für die Versorgung des Babys getroffen.
- 'disposal=yes' ist unnötig. Es gibt 'amenity=waste_disposal'
- 'power_supply' nun ja, ein Wert von 'yes/no' sollte reichen.
- 'cleaning' ist überflüssig, es gibt 'shop=laundry'. Ggfs. kann man mit 'fee=yes/no'
angeben ob es extra kostet oder inklusive ist.
- 'leasing/payment, wenn es unbedingt sein muss. Ich halte das für zu detailiert.
- 'dog=yes/no/...' und 'horse=yes/no/stable/range/...' halte ich für spezielle Eigenschaften,
die man taggen können sollte.
- 'places' Bei Parkplätzen gibt es den Key 'capacity/capacity:*'.
Den kann man hier (angepasst) weiterverwenden.
- Mittagsruhe kann wichtig sein. Sofern es nicht durch 'opening_hours' abgedeckt ist,
würde ich 'key=quiet_time' vorschlagen. Werte entsprechend 'opening_hours'.
Damit kann man auch die genauso wichtige Nachtruhe abdecken.
- 'award' nun ja. Kann man dann ggfs. auch für Restaurants und Hotels verwenden.
- 'association' Das sollte man besser über eine / gfs. mehrere Relation/en abhandeln.
Es fehlen zwei wichtige Tags: 'name=*' und 'operator=*' in bekannter Funktion.

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:
- FKK-Platz (naturism=yes/no)
- Bademöglichkeit
- Hallenbad
- Entsorgung für Chemietoiletten (chemical_toilet=yes/no)
- Frischwasser
- Stromversorgung (hier bitte Normen angeben damit die Werte eindeutig sind)
- Behindertengerecht
- Internetzugang

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/Rela … posed/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 :-)

Augustus Kling wrote:

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.

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.

Augustus Kling wrote:

Außerdem möchte ich noch folgende Eigenschaften in den Raum werfen:
- FKK-Platz (naturism=yes/no)
- Bademöglichkeit
- Hallenbad
- Entsorgung für Chemietoiletten (chemical_toilet=yes/no)
- Frischwasser
- Stromversorgung (hier bitte Normen angeben damit die Werte eindeutig sind)
- Behindertengerecht
- Internetzugang

Entsorgung ist mit amenity=waste_disposal + waste=... bereits möglich.

EvanE wrote:

phone=* wurde bereits abgelehnt.

...wird aber dennoch häufig genutzt, siehe http://osmdoc.com/de/tag/phone/

!i! wrote:

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 :-)

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

aighes wrote:

EvanE wrote:

phone=* wurde bereits abgelehnt.

...wird aber dennoch häufig genutzt, siehe http://osmdoc.com/de/tag/phone/

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?

!i! wrote:

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

!i! wrote:

Ich finde die Unterscheidung caravan_site, camp_site eh sehr komisch, sind die meistens doch zusammen (aber vlt. nur in der BRD?)

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.

aighes wrote:

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.

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.
- 'camp_site' heißt du kannst dort dein Zelt aufstellen.
Ob man auch Wohnanhänger/Wohnmobile benutzen darf, ist nicht festgelegt.
- 'caravan_site' heißt nichts weiter, als dass du mit deinem Wohnwagen über Nacht bleiben darfst.
Das ist nämlich in vielen Ländern erst mal verboten.
Daher auch teilweise in Kombination mit 'amenity=parking'
Also eine völlig andere Richtung.

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,....

Es gibt auch LKW-Stellplätze, wo Camper manchmal geduldet werden.
Ich möchte dafür folgendes TAG vorschlagen: amenity=truck_stop

Falls es für Autobahn-Rastplätze noch kein eigenes TAG gibt, wäre ich für amenity=rest_area.
Auch hier ist die Übernachtung im Camper oftmals möglich.

Falls bei tourism=picnic_site campen ausdrücklich erlaubt ist, wäre das auch noch hier einzubeziehen.

In Frankreich habe ich häufig am Rand von Ortschaften (abseits von Camping-Plätzen) eigene Dumping-Stations gefunden.
amenity=waste_disposal trifft die Sache nicht ganz so gut. Wie wäre es daher mit amenity=dump_station dafür?

Walter

Ich habe versucht die Vorschläge dieses Threads zusammenzufassen. Ihr findet den Vorschlag (alles andere als ferig) unter http://wiki.openstreetmap.org/wiki/Prop … _camp_site

Die Seite ist übrigens zum Ändern und Umstrukturieren da.

Vielen Dank Augustus! :-)

Bitte diskutieren wir nun im Wiki weiter.

ok der RFC ist gestartet!
http://wiki.openstreetmap.org/wiki/Prop … _camp_site

!i! wrote:

ok der RFC ist gestartet!
http://wiki.openstreetmap.org/wiki/Prop … _camp_site

So weit, so gut. (Ist schön geworden.)
Vielen Dank an Augustus Kling.

Ein paar Kleinigkeiten sind mir aufgefallen:
- "Whenever NUMBER is mentioned as a tag value it means that a numeric value shall be used instead."
Ich glaube die übliche Form ist <number> oder einfach number.
- In einer Relation haben die Mitglieder meistens 'Rollen' oder sollten sie haben.
Ich würde folgende Rollen vorschlagen:
o outer für den gesamten Bereich
o inner für Teilbereiche
o exterior für Teile, die ausserhalb des eigentlichen Geländes liegen.
Beispiele: Bootsanleger, Surfschule, Reithof, Parkplätze, ...
Die ersten zwei entsprechend der Verwendung bei einer Multipolygon-Relation.
- "highway=service Streets intended for vehicles and not to be used by pedestrians normally."
Die Einschränkung für Fußgänger entspricht nicht dem allgemeinen Gebrauch von
highway=service. Dort sind Fußgänger/camp_site-Nutzer keineswegs ausgeschlossen.
Mit highway=service können auch die Wege gekennzeichnet sein, die für An-/Abfahrt
von Fahrzeugen benutzt werden dürfen. Ansonsten werden diese nur von Fußgänger und
ggfs. Radfahrern genutzt. Es gibt da sicher viele unterschiedliche Varianten.
- "Applies-to: relation,area"
tourism=camp_site ist für Knoten und Flächen definiert.
Warum fehlt hier der Knoten?
- Die Seite ist ziemlich lang, dabei jedoch übersichtlich gegliedert.
Sie wird nicht übersichtlicher, wenn noch überall Diskussionsbeiträge zwischen geschoben
werden. Warum nicht von Anfang an die zugehörige Diskussionsseite verwenden?

Noch eine Kleinigkeit:
Ist der Proposal auch überall bekannt gegeben worden? (Forum:de, Forum:*, talk:de, talk*)

Edbert (EvanE)

EvanE wrote:

[…]
- "Whenever NUMBER is mentioned as a tag value it means that a numeric value shall be used instead."
Ich glaube die übliche Form ist <number> oder einfach number.

Die Verwendung von „NUMBER“ hat keinen speziellen Grund und darf gerne verändert werden.

EvanE wrote:

- In einer Relation haben die Mitglieder meistens 'Rollen' oder sollten sie haben.
Ich würde folgende Rollen vorschlagen:
o outer für den gesamten Bereich
o inner für Teilbereiche
o exterior für Teile, die ausserhalb des eigentlichen Geländes liegen.[…]

Die Elemente einer Relation müssen keine Rollen haben. Ich bin außerdem der Meinung, dass Rollen nicht vergeben werden sollten nur damit keine leere Rolle steht. Die von dir vorgeschlagenen Rollen habe ich aber so ähnlich eingebaut weil sie mir schlüssig scheinen.
Aus „exterior“ habe ich aber „external“ gemacht weil ersteres meines Wissens nach „an der Außenseite“ und nicht abgetrennt/alleinstehend bedeutet.

EvanE wrote:

- "highway=service Streets intended for vehicles and not to be used by pedestrians normally."[…]

Der Satz ist angepasst.

EvanE wrote:

- "Applies-to: relation,area"[…]
Warum fehlt hier der Knoten?[…]

Den hatte ich übersehen.

EvanE wrote:

- Die Seite ist ziemlich lang, […].
Sie wird nicht übersichtlicher, wenn noch überall Diskussionsbeiträge zwischen geschoben
werden. Warum nicht von Anfang an die zugehörige Diskussionsseite verwenden?
[…]

Weil der Bezug von Diskussion zu Bereich auf der Seite verloren gehen kann wenn die Seite zu Beginn umstrukturiert wird. Zudem drohen die Diskussionen auf einer separaten Seite übersehen zu werden wenn sich ein Leser nicht mit Wikis auskennt.
Diskussionen sollten aber nur noch unter „To be clarified“ stehen. Falls gewünscht, können wir die Diskussionen auch auf der Diskussionseite führen.

EvanE wrote:

Noch eine Kleinigkeit:
Ist der Proposal auch überall bekannt gegeben worden? (Forum:de, Forum:*, talk:de, talk*)

Edbert (EvanE)

Posting auf Talk habe ich nicht gefunden. Rest ist ja für den Prozess nur ein nice2have,,,

Ich hab probiert das auf talk zu mailen aber da ich bei beiden kein Mitglied bin wird das wohl von den Mods gefiltert. Wäre nett, wenn jemand der beide aboniert hat eine Message mit dem Betreff "[tagging] Feature Proposal - RFC - Extend camp_site" senden könnte.
Weitere inhaltliche Diskussionen ab jetzt bitte nur noch im Wiki! 🙂

Augustus Kling wrote:

EvanE schrieb: ... Ich glaube die übliche Form ist <number> oder einfach number.
Die Verwendung von „NUMBER“ hat keinen speziellen Grund und darf gerne verändert werden.

Es scheint kein einheitliches Vorgehen zu geben. Am besten gefiel mir kursiv: number

Augustus Kling wrote:

EvanE schrieb: In einer Relation haben die Mitglieder meistens 'Rollen' ...
... Die von dir vorgeschlagenen Rollen habe ich aber so ähnlich eingebaut weil sie mir schlüssig scheinen.
Aus „exterior“ habe ich aber „external“ gemacht ...

Das ist (für mich) genau so gut, wenn nicht sogar besser.

Augustus Kling wrote:

EvanE schrieb: Die Seite ist ziemlich lang, .... Warum nicht von Anfang an die zugehörige Diskussionsseite verwenden?
Weil der Bezug von Diskussion zu Bereich auf der Seite verloren gehen kann wenn die Seite zu Beginn umstrukturiert wird. Zudem drohen die Diskussionen auf einer separaten Seite übersehen zu werden wenn sich ein Leser nicht mit Wikis auskennt.
Diskussionen sollten aber nur noch unter „To be clarified“ stehen. Falls gewünscht, können wir die Diskussionen auch auf der Diskussionseite führen.

Kurzer Hinweis am Anfang sollte genügen. Wenn die Menge irgendwann zum Problem wird,
kann man das immer noch auf die Diskussionseite verschieben (oder nach dem Voting).

@!i! Ein Teil von meinen Anregungen waren eher Meta-Diskussionen,
Von daher wollte ich das nicht auf die Wiki-Seite packen.
Ab jetzt Diskussion nur noch dort.

PS: Das Beispiel 2 gefällt mir sehr gut.

Edbert (EvanE)

Ich war mal frech und habsauf die Diskussionsseite verschoben. Stimmt schon, dass das schnell unübersichtlich wird.

!i! wrote:

Ich war mal frech und habsauf die Diskussionsseite verschoben. Stimmt schon, dass das schnell unübersichtlich wird.

Wichtig dabei ist, dass es auf der Diskussionsseite eine vernünftige, sprich übersichtliche Gliederung gibt.
Im augenblicklichen Zustand der Diskussionsseite sehe ich das als gegeben an.

Was ich mir noch wünsche, ist ein Hinweis auf die Diskussionsseite weiter vorne im Artikel.
Am besten direkt nach der grünen Box. Nur eine Zeile Text, ohne eigene Überschrift.

Wenn das OK ist, mache ich es gerne selber.

Edbert (EvanE)

Den Hinweis kannst du natürlich einfügen, dafür ist es ja ein Wiki. Falls dabei etwas schief gehen sollte, können wir schließlich die alte Version wieder herstellen.

Hallo, der Proposal steht ja schon eine Weile, weiß jemand ob das bereits über talk, talk-en und talk-de lief? Weil bissel wenig Kommentare für meinen Geschmack?

Wollen wir sonst die Vote Phase eröffnen?

Das Proposal ist richtig gut geworden, sieht sehr übersichtlich aus.
2 Fragen hätte ich jetzt noch.

Ich kann nirgends eine Diskussion über Trinkwasser finden.
Es gibt den Vorschlag: fresh_water=yes/no
Dabei wundere ich mich, dass ein neuer TAG dafür erfunden wurde.

drinking_water=yes würde bedeuten, der Platz verfügt über Trinkwasser (in einigen Outdoor camp_sites sicherlich nicht selbstverständlich)
watering_place=yes würde bedeuten, es gibt einen Schlauch, um Trinkwasser-Container im Camper zu füllen.
amenity=drinking_water/watering_place, falls ein separater Node dafür vergeben wird.

Mir fehlt jedoch die eindeutige Kennzeichnung, ob ein dauerhafter Wasseranschluss direkt am Stellplatz möglich ist.

Stromanschluss:
Das TAG für power_supply=* führt so garantiert zu Wildwuchs. Also entweder es sollte yes/no vorgegeben werden,
oder es gab auch mal einen Vorschlag (finde ich jetzt leider nicht mehr), den Anschluss gleich mit iec60309 zu taggen.
http://de.wikipedia.org/wiki/IEC_60309

Falls ein Campingplatz einen anderen Anschluss besitzt, könnte dieser dann mit TYP x gekennzeichnet werden.
http://de.wikipedia.org/wiki/L%C3%A4nde … frequenzen
Diese Bezeichnung ist zwar keine Norm, aber einfacher zu vergeben und ebenfalls eindeutig.
Wenn wir es ganz genau machen wollen, wäre auch noch diese Variante zu überlegen:

power_supply=yes/no
power_supply:socket=iec60309/typ_f
power_supply:voltage=230/120
power_supply:frequency=50/60

Da Spannung und Frequenz aber anhand des Landes bereits bekannt sein müsste, wäre ich fast für die einfachere Variante:

power_supply=yes/no/iec60309/typ_f

Walter

gibt's eigentlich einen Tag für "Wifi"? Viele Campingplätze bieten Free-Internet an. Meist muss man beim Empfang einfach einen Zugangscode holen.
Ich finde, diesen Tag sollte man für Campingplätze haben... Naja, nicht nur für Campingplätze, aber da wäre gerade die Möglichkeit damit anzufangen.

internet_access=wlan/terminal
internet_access:fee=yes/no

Die obere Zeile steht bereits im Proposal, ob gebührenpflichtig oder nicht könnte man auch noch dazu erfassen.
wifi statt wlan habe ich in OSM bisher noch nicht gesehen.
Da sich solche Normen aber sehr rasch ändern können, ist die Erfassung eher problematisch.
Auch bei wlan werden derzeit weder Baudrate noch Kanal erfasst, da auch das kurzfristig geändert werden kann.

Walter

oh hoppla.... das hatte ich übersehen, dass das schon getaggt werden kann. danke für die info.

Das mit power_supply stimme ich dir zu, das sieht übersichtlich aus! Das mit Frequenzen wäre wohl etwas zu viel des guten da das Stecksystem i.A. doch auch die Spannungen bestimmt, oder?

Nur haben da schon international Leute drübergesehen? Doof dass man zum senden an die Liste immer Mitglied sein muss 🙁

Das Stecksystem allein reicht nicht aus weil sich die Belegung der Kontakte unterscheiden kann.
IEC60309 definiert verschiedene Stecker und ist daher nicht präzise genug. Beim Typensystem bin ich mir nicht sicher ob es umfassend genug ist – weiß aber auch nicht was auf Campingplätzen zu erwarten ist. Außerdem kann sich der Abstand zwischen den Kontakten bei gleichem Typ unterscheiden Beispielsweise CEE7/16 „Eurostecker“ und BS4573 (britische Rasierersteckdosen, hoffe die Norm stimmt) oder verschiedene Abstände in Italien (hier weiß ich nicht inwiefern das historisch bedingt ist und verschwindet).

Ist ein Camper unter euch? Bitte nachsehen wie/ob die Stecker in Campingkatalogen erwähnt werden.

watering_place erscheint mir als unpassend und ich würde erwarten, dass darunter eine offene Wasserfläche (Bad, Tränkebecken oder ähnliches) verstanden wird. Gibt es eigentlich überhaupt einen Grund das Nachfüllen von Tanks von Wohnmobilen getrennt von Trinkwasser zu behandeln? Also würde amenity=drinking_water ausreichen?

Ich finde auch, dass es mit dem Wasser ein wenig zu filligran ist, oder?

Stecker werden angegeben z.B. www.campingplatz-deutschland.de
-CEE 3polig 10A
-220V zweipolig 10A

Meint CEE 3polig den blauen Stecker [SB, SS] oder Kupplung [KB, KS]? Ist auf den Campingplätzen Stecker oder Kupplung verfügbar?

Falls dies das einzige gängige System ist wäre power_supply=CEE17_blue ausreichend.

@!i!: Sind die Stecker nicht mindestens für 16A ausgelegt? Ich nehme an mit dem 2poligen Stecker meinst du einen Schuko (CEE7/4), oder?

[SB] Bild von Stecker (Mobilefreizeit24)
[SS] Schema von Stecker (International Configurations)
[KB] Bild von Kupplung (Mobilefreizeit24)
[KS] Schema von Kupplung (International Configurations)

Die folgenden beiden Stecker habe ich bisher auf Camp_Sites angetroffen:

CEE 17 = IEC 60309 P+N+PE 6h = blauer Stecker (bzw. natürlich die Buchse, sonst wäre ich längst tot)
CEE 7/4 = Typ E = Schuko

beide in Europa mit 230V (fälschlich oft auch noch mit 220V bezeichnet)

mein Vorschlag für die Tags daher: cee_17 und cee_7_4
Alternativ zu cee_7_4 könnte ich mir auch schuko oder typ_e als TAG gut vorstellen, da einprägsamer.

Weitere Stecksysteme, die ev. noch auf der Welt vorkommen könnten:

CEE 7/5 (= Typ E) in Frankreich: http://de.wikipedia.org/wiki/Stecker-Typ_E
BS 1363 (= Typ G) in Großbritannien: http://de.wikipedia.org/wiki/Stecker-BS_1363
NEMA 5-15 (Typ B) in USA: http://de.wikipedia.org/wiki/Stecker-Typ_B
AS 3112 (= Typ I) in Australien: http://de.wikipedia.org/wiki/Stecker-Typ_I
BS 546 (= Typ M) in Südafrika: http://de.wikipedia.org/wiki/Stecker-Typ_M
SI-32 (= Typ H) in Israel: http://de.wikipedia.org/wiki/Stecker-Typ_H
SEV 1011 (Typ J) in der Schweiz: http://de.wikipedia.org/wiki/Stecker-Typ_J

Walter

Es macht natürlich Sinn nur die Buchse am Platz zu haben, aber man hat halt in anderen Bereichen schon zu viel gesehen. Selber habe ich beim Camping noch nicht nach Strom gesucht.

Die englische Wikipedia hat eine Tabelle, die die Stecksysteme zusammenfasst. Ich schlage vor davon die 2. Spalte fürs Tagging zu nehmen weil die Typen A-D und I unterteilt sind.

Ist es ok, wenn wir wie beim name-TAG den Wert mit Großbuchstaben und Leerzeichen definieren,
oder ist es besser, den TAG-value nur mit Kleinbuchstaben und underline zuzulassen.

Also "CEE 7/4" oder besser "cee_7_4".

Einfacher lesbar ist sicherlich die erste Variante. Es wird dann aber auch häufiger zu Eingabe-Varianten kommen (z.B. "CEE7/4" ohne Blank).
Für eine automatisierte Auswertung wäre eine Variante ohne Leerzeichen sicher vorzuziehen. Fragt sich blos, ob das hier notwendig ist.

Walter

Die Tags sollten schon automatisch ausgewertet werden können. Ich halte die Schreibweise mit _ und in Kleinbuchstaben für eindeutiger und fehlerrobuster.

Ich habe mal eine Seite über power_supply begonnen, falls das Proposal angenommen wird.
http://wiki.openstreetmap.org/wiki/Key:power_supply

Walter

Hello,

First of all, I read German quite well, but I am not so good in writing it. Therefore my posts/replies are in English, but any answer in German is no problem.

I have noticed that there has been little movement in the camp_site topic. My wife and myself have been traveling from the Netherlands to South Africa (see www.DeEinderVoorbij.nl) during the last year. The road and camping information of OSM has been one of our most important navigation sources. Therefore I am interested to move the camp_site topic forward and to make a few adaptations/extensions to make it suitable for areas with no campings like we have in Europe.

In Africa one is often forced to camp in the yard or parking of a hotel with use of hotel ablutions or to look for a bush camp ("impromptu"camping). It then is important to know which hotels offer the service and which bush camp sites are suitable.

On the discussion page http://wiki.openstreetmap.org/wiki/Talk … _camp_site I have added a few proposals.

Please let me know if I can help moving this ahead.

Regards,

Jan van Bekkum