Tagging von Campingplätzen als Punkt _und_ Fläche

Hallo zusammen,

am Wochenende habe ich ein Changeset kommentiert bei dem ein Mapper das tagging eines Campingplatzes verbessert hat.

https://www.openstreetmap.org/changeset/118387308#map=15/50.4305/9.1803&layers=ND

Nach der Verbesserung des taggings haben wir dort jetzt drei Campingplätze statt einem und zwei davon wurden als Pfadfinderplätze getaggt. Der Name klebt nur an den Nodes, die Fläche hat keinen Namen.

Außerdem gibt es zwei Rezeptionen.

Leider fühlt sich der Mapper von mir belehrt statt meinen Kommentar als dazu verstehen was er eigentlich sein sollte nämlich konstruktive Kritik.

In direkter Mailkommunikation wurde behauptet es sei völlig unklar wie man Campingplätze korrekt erfasst.

Deshalb hier jetzt mal meine Frage an die Runde ob das was ich da ändern würde dem common sense entspricht:

Ich würde folgendes ändern:

  1. Einzelnode mit tourism=camp_site innerhalb des Polygons entfernen und dessen Tags auf das Polygonobjekt übertragen
  2. Tag tourism=camp_site von Rezeption entfernen und diese stattdessen mit amenity=reception desk taggen
  3. Tag scout=yes entfernen da der Platz zumindest laut Webseite kein Pfadfinderplatz ist.
    Falls es einen tourism=camp_pitch speziell für Pfadfinder geben sollte, dann kann man dieses entsprechend taggen.

Wenn ich das richtig sehe werde ich im wesentlich dafür kritisiert, dass ich den redundanten Node innerhalb des Polygons als Fehler sehe. Wie seht ihr das?

Sven

Hallo,

Dein Kommentar ist im Stil in Ordnung. Wer in OSM aktiv ist, muss mit konstruktiver Kritik klarkommen. Anders wäre es nicht mit den Grundsätzen unseres Gemeinschaftsprojekts zu vereinbaren.

Zustimmung.

die Doppelerfassung eines Campingplatzes mit tourism=camp_site sowohl für die Fläche als auch für die Rezeption ist falsch. Es gilt die One-Feature-One-OSM-Object-Regel (ein Objekt in der Natur, ein Objekt in OSM). Die Erfassung als Polygon enthält mehr Informationen über die Ausdehnung und ist hier vorzuziehen.

Viele Grüße

Michael

Ich tagge das Campingbüro üblicherweise als office=camping
Ansonsten stimme ich dir zu.

Edit:
Die Vorgabe Campingbüro → office=camping macht osmand so, finde ich prima, auch wenn es im Wiki nicht so vorgeschlagen wird.

OK, das kannte ich noch gar nicht.

Taginfo sagt:
amenity=reception_desk: 1580
office=camping: 460
camp_site=reception: 1101

Da jeweils unterschiedliche keys verwendet werden sind natürlich doppelt und dreifachtagging möglich.

Mal schaun vielleicht bau ich auch noch office=camping in OpenCampingMap ein.

Am sinnvollsten erscheint mir allerdings immer noch amenity=reception_desk insbesondere weil so eine Rezeption gerade bei größeren Anlagen oft auch nicht nur für den Campingplatz zuständig ist.

Sven

Unter konstruktiver Kritik verstehe ich etwas anderes. Ich habe kein Problem, wenn jemand eine anderere Meinung hat.
Doch Sätze wie “schön erst mal dass Du dich um besseres Tagging für Campingplätze kümmern möchtest aber…” und “Soll ich das Tagging reparieren oder möchtest Du dich dran versuchen?” … haben mit konstruktiver Kritik nicht viel zu tun. Es hat für mich eher etwas Oberlehrerhaftes an sich, so von oben herab.

Außerdem dachte ich, dass das Wiki beschreibt, wie gemappt wird. Und wenn das Wiki dazu nichts hergibt, mappt man so, wie man es für richtig und sinnvoll hält. Und bisher habe ich zum Mappen von Campingplätzen im Wiki nichts Fundamentales gefunden. Bei einigen anderen Veränderungen durch mich sehe ich durchaus ein, dass es anders auch sinnvoll ist, vielleicht auch sinnvoller. Und in solchen Fällen ändere ich gerne meine Meinung.

Nun habe ich ja die Sichtweise des Forums zu Campingplätze gelesen.

Vielleicht hilft mir das ja in der Zukunft so zu mappen, dass die Nutzer der OSM Daten damit zufrieden sind. Schön wäre es aber, wenn dieses alles im Wiki nachzulesen wäre.

Das tut es doch. Was genau fehlt Dir denn im Wiki? Ich ergänze das dann gerne aber mir fehlt leider die Fantasie mir zu erschließen was genau Du dort vermisst.

Gruss

Sven

@Wetterauer: ja, die Wortwahl in der CS-Disk könnte vorsichtiger und freundlicher gewählt sein, in der (Haupt)Sache liegt giggls aber schon richtig,
auch wenn in OSM die Abbildung eines bestimmten Ojektes als Fläche ODER (vereinfachend) Punkt(Node) zulässig ist,
dann ist die doppelte Erfassung als Fläche UND Punkt i.d.R. problematisch und keine Verbesserung.
Statt (zusätzliche) Neuerfassung eines Objektes immer erstmal schauen, was an Bestand schon da ist und den verbessern/aktualisieren.

halte ich für eine ganz ganz schlechte Idee, das hat mit dem hier doch gar nichts zu tun:
https://wiki.openstreetmap.org/wiki/Key:camp_site
und führt durch den geforderten Haupttag tourism=camp_site quasi automatisch zu Dopplungs-Problemen.
Die Franzosen sehen das wohl genauso und warnen ausdrücklich davor:
https://wiki.openstreetmap.org/wiki/FR:Key:camp_site#Anciennes_valeurs_conflictuelles
Könnte man für DE imho auch so umsetzen…

Genau deshalb habe ich den Changeset bemängelt, denn der tut leider genau nur das und ergänzt überhaupt keinen Mehrwert.

Ich habe in meiner Bug View auf http://opencampingmap.org generell die Empfehlung drin Plätze als Flächige Objekte zu erfassen. Eine Ausnahme gibt es jedoch und das ist, wenn der Node Teil einer Site-Relation ist.
Beispiel: https://www.openstreetmap.org/node/3824691120
In solchen Fällen ist die Platzgrenze häufig nicht klar erkennbar. Die Site-Relation dient dann dazu immobile Objekte, die offensichtlich Teil der Ausstattung des Platzes sind (tilette, Feuerstelle, …) dem Platz zuzuordnen.

Das ist leider so nur in einem alten Proposal im Wiki und in meinem privaten Blog dokumentiert. Da sollte ich mich mal drum kümmern.

Das mit dem Punkt vs. Fläche ist im übrigen kein Alleinstellungsmerkmal von tourism=camp_site. Das ist ja in vielen anderen Fällen ebenfalls problematisch. Wenn man beispielsweise ein Restaurant als Node erfasst, was absolut OK ist, dann sollte man halt an das Gebäude kein selbst weiteres amenity=restaurant drankleben.

Was mir in diesen Diskussionen oft auffällt ist dass Mapper oft nicht so Recht den Blick darauf haben dass es halt schon darauf ankommt dass OSM-Daten verwendbar sind und dass (im schlimmsten Fall widersprüchliches) redundantes tagging meist mehr schadet als hilft.

Gruss

Sven

Kann Menschen die an Thema x interessiert sind, insbesondere Auswertern nur raten hier zu argumentieren und an einer Verbesserung der OSM-Dokumentation mitzuwirken.
Wobei ich dabei primär die konkrete Tag/Value/Key-Dokumentation meine und nicht abgelegene private Blogs.
Eine exemplarische Kritik an einzelnen CS brauche ich dazu nicht - “Der Fisch stinkt vom Kopf her” - würde einem Mapper keinen Vorwurf machen, solange die Dokumentation unvollständig ist.

Ein konkretes Beispiel habe ich #7 genannt, um sowas wie camp_site=reception perspektivisch in DE auszuknipsen braucht es kein proposal, sondern erstmal eine Übersetzung + Warnung wie in FR.

Gruß
Jo

Was ich ja mache.

Ganz so “abgelegen” ist das auch wieder nicht. Auf http://blogs.openstreetmap.org ist das Blog immerhin verlinkt.

Site-Relations sind ein ziemliches Nischenthema. Meistens braucht es die nicht.

Hier der Link zum “abgelegenen” Blog:
https://blog.geggus.net/2021/09/announcing-support-for-site-relations-in-opencampingmap/

Sven

Das ist doch ein “immer mal wieder” Nervthema. Navigieren tut man grundsätzlich zu Punkten und nicht zu Flächen. Campingplatzflächen sind daher sowas wie landuse und meines Wissens können die an Flächen geklebten Infos schlecht ausgewertet werden.

Letztlich haben wir das selbe Problem überall. Bei Höfen wird manchmal die Hofanlage und Ackerfläche so benannt, was sie alsAdresse unauffindbar macht …

Ich finde es daher völlig okay, einen Punkt und eine Fläche zu setzen. Aber dann sollten wir halt konsekvent keine Tags mehr erlauben, die an Punkte und an Flächen gesetzt werden können.

In dem Beispiel also ne klare Unterscheidung zwischen “Campingplatzzugangspunkt” (amenety Klasse) und “Campingplatzfläche” (landuse Klasse)

Dann habe es auch dieses Chaos nicht…

Warum sollten tags die an Flächen angehängt sind schlecht auswertbar sein?

Schlecht auswertbar ist alles was eine Tagging-Redundanz erlaubt also beispielsweise das Erfassen von Flächen und Punkten mit dem selben Tag weil man das geometrisch verschneiden und dann auch noch eine Entscheidung treffen muss welche Variante Präferenz hat. Das mache ich bei der OCM derzeit nicht weil ich das als Fehler einstufe der behoben werden sollte.

Ich sehe prinzipiell keinen Vorteil in der Erfassung von Nodes statt Fläche. Wo sollte der denn sein?

Wenn Objekte in der Realität flächig sind sollte man sie auch als solche erfassen.

Letztlich ist das mit den Nodes doch nur historisch zu erklären. Am Anfang als man nur mit GPS Mappen konnte hat man halt einen Node gesetzt statt Flächen zu erfassen, was besser als nichts war. Heute ist es meistens ziemlich unsinnig flächige Objekte als Node zu erfassen.

Sven

Na ja. “Meistens” ist vielleicht etwas hoch gegriffen. Bei Campingplatzen und Schulen mag das ja so sein, aber wirklich sinnig wäre es bei shop nicht wirklich. Und auch Automaten und Kassen haben eine räumliche Ausdehnung und ich käme nicht auf die Idee (bzw. sehne keinen wirklichen Mehrwert), das als Fläche zu erfassen. Und im größten Teil der Welt außerhalb unserer europäischen Mapperblase ist jeder (gepflegte) node noch immer wertvoller, als eine vor zehn Jahren genau erfasste Fläche…
(Bei “mir” wurde ein Einkaufszentrum detailiert zu flächigen Läden umgemapped, die vorher als Punkte erfasst waren und ich gepflegt hatte - jetzt ist mir das zu unübersichtlich und seit fünf Jahren pflegt das keiner mehr wirklich.)

Aber das ist doch dann eher ein Problem des editors, der kein vernünftiges indoor-Mapping unterstützt? In JOSM geht das relativ easy.

Wo ist denn der Vorteil des erfassens als Fläche? Campingplätze haben oft eine grosse räumliche Ausdehnung und grenzen gerne an 3-4 Straßen.

Was hilft es mir denn, jetzt raten zu müssen, wann ich vor dem Zaun stehe und wann ich die für’n Campingplatz typische Infrastruktur zugänglich hab? Das ist im Regelfall der Eingang. Und nur dort sind Infos wie Öffnungszeiten und Ausstattung überhaupt sinnvoll.

Der Rest ist landuse.

Meiner Meinung nach eine komische Unsitte, Infrastrukturibformatiinen zugunsten von Flachenmaping zu verstecken. Genauso geht das bei manchen Freibädern. Die sollten eigentlich - wie ein Campingplatz - aus Elementen wie Pool, Liegewiese, Baumgruppe, Servicegebäude, Zaun etc bestehen.

Und nicht dazu führen, dass man einen Zaun abfahren muss, um den Eingang zu suchen.

Und genau dafür gibt es entrace=main. Dann hat man idR auch kein

Warum verstecken? Wenn ich einen Campingplatz habe, ist das eine Fläche und kein Punkt. Aber dieser braucht halt auch die Info, wo ich rein komme (s.o.)