Höhlen, Stollen, Keller und andere Löcher

Ein Problem hierzu ist mir nicht bekannt, und kann auch keines in diesem Thread finden. Eine Relation wurde anders genutzt als vorgesehen - über so etwas stolpere auch ich hin & wieder, und stellt hier im Forum auch schon mal eine Frage dazu. Das macht es aber nicht zum Problem. Es gibt aber Menschen, die das zum Problem erheben wollen. In diesem Fall wollte jemand nur temporär eine Relation, um einfacher auf seine Weise arbeiten zu können. Andere Wege wurden gezeigt, und ehe er reagieren konnte, meint jemand Drittes das Ganze eskalieren zu müssen.

Die Beratungsresistenz kann ich hier nicht finden. In #13 wird das erste Mal die Relation erwähnt, in #15 eine Alternative aufgezeigt, und in #16 löschst Du - ganz ohne Kommunikation, wo Du diese doch in #14 einforderst.

Doch, ich. Ich fand das bisher extrem doof. Bin zu Höhlen durch den Wald, nur um dann festzustellen: Ist gar keine. Habe dann das Tagging untersucht, und mir für meine Kartenerstellung Notizen gemacht. Ein offener Punkt.

Da ich hier mitlese: Meine ist nun bereits angepasst. Ich würde mir aber nie anmaßen zu behaupten, alle von der OSM Datenbank abgeleiteten Karten zu kennen. Ging wohl nicht darum miteinander etwas zu lösen…

BTW, Netwolfs langer Text hat mit Kopfnicken.

Mich interessiert das auch, und es ist relevant für die Prüfung von OSM gegen eigene Daten (Kataster wurden ja schon genannt). Auch für geologische Auswertungen, die historische Objekte-Karte, …

Und doch, wir sind hier bei “jeder mappt das, was er wichtig findet” und “jeder darf seinen Stil in gewissen Grenzen ausleben”. Das Problem sind die “gewissen Grenzen”, die an dieser Stelle zwischen “Nutzer XY will das so erfassen” und “Wir brauchen eine gemeinsam auswertbare Datenbasis” laufen.

Eine Sammelrelation finde ich unnötig, aber sie tut niemandem weh, außer das sie irgendwann veraltet. Aber das muss man sich halt überlegen, ob/wie man die Pflegen will.

Das geht mir eindeutig zu weit.
Ein Projekt wie OSM kann nicht funktionieren, wenn ein Teilnehmer seine Ansicht zur allein Gültigen erhebt und alles, was dem widerspricht, diskussionslos löscht.

Zur Sache: Jede Relation ist genau genommen eine Sammelrelation: Sie enthält (sammelt) alles, was zu einem bestimmten Sachverhalt gehört. Da gibt es Relationen, die abgeschlossen sind in dem Sinne, dass man feststellen kann, ob sie vollständig sind oder nicht (Grenzrelationen, Routen), bei anderen geht das nicht (z.B. site-Relationen), wo immer wieder neue Objekte dazu kommen können.
Strittig sind Relationen unklaren/neuen Typs, die sowohl geschlossen (z.B. Kiez-Grenzen in Berlin) als auch offen (z.B. Straßen mit einem bestimmten Namen) sein können. Die belasten die Datenbank aber nicht über Gebühr, sie sollten nur nicht ausufern, damit nicht überall an nodes und ways Dutzende von ungenutzten Relationen dranhängen.

@geri-oc, gormo, Joachim, seichter: Danke!

(Hätte ich selbst geantwortet, hätte die Gefahr bestanden, daß ich im Ton entgleise…)

Gruß,
Zecke

Nahmd,

an dieser Stelle macht sich auch die Unzulänglichkeit des OSM-Datenmodells bemerkbar: neben den elementaren geometrischen Objekten Punkt und Linie (wir haben noch nicht mal einen Typ “Fläche”) gibt es nur den Datentyp Relation. Da ist nichts anderes. Wer Zusammenhänge zwischen OSM-Objekten darstellen will, dem bleibt nur die Relation. Jegliche Argumentation vom Type “Relationen sind nicht dies und das” läuft da ins Leere, wenn sie nicht die Frage beantworten kann: “Wie soll ich dies und das darstellen?”

Der Wiki-Eintrag “Relationen sind keine Kategorien” geht an der Realität vorbei und wäre besser gelöscht. Das ist meine Sicht, deshalb werde ich sicher nicht löschen.

Man könnte sich (mal ganz ins Unreine gedacht) etwas vorstellen wie eine umgekehrte Relation: statt dass die Relation auf die Member verweist und mit jedem Neumitglied eine neue Version bekommt, verweisen die Member auf die Relation bzw. einenneuen Typ, nennen wir ihn mal “Entity”, der keine geographische Bedeutung mehr hat oder haben muss. Damit kann man z.B. einen Verein erfassen. Oder ein Projekt. Oder eine Sammlung. Oder was auch immer.

Dazu lässt man als Values für Keys nicht wie bisher nur Stringwerte zu, sondern auch Verweise auf Entities. Die werden in der DB als Referenz abgebildet, sind also eindeutig, sicher gegen Tippfehler (anders als “operator=” und dann ein “Saualändischer GebirgsVerein” in zehn verschiedenen Schreibweisen) und haben auch referentielle Integrität, d.h. solange es eine Referenz gibt, kann man das Entity nicht löschen.

Damit würde man im hier besprochenen Beispiel ein Entity anlegen mit Namen “Projekt Erdhöhlen da und da”, und den Höhlen ein “is_in” (oder ähnlich) geben mit Verweis auf das Projekt-Entity.

Der Vorteil dabei ist, dass das Entity unabhängig von der Anzahl der Verweiser ist und klein bleibt, und auch nicht hunderte bis tausende Versionen hat, weil es sich bei Aufnahme eines Verweisers schlichtweg nicht ändert.

Außerdem muss es nicht in der Relationsbox dargestellt werden; mit sieht statt dessen in der Tag/Value-Box einen Pfeil und die dann den Namen des entsprechenden Objektes.
Ich denke, dass auch die Größe der JOSM-Relationsbox viel dazu beiträgt, die Nutzung von Relationen kritisch zu sehen. Eine kleine Ecke einer Stadt geladen, und die Box quillt über.

Man kann langsam und schrittweise für Key/Value-Paare, über deren Nutzung ein breiter Konsens besteht (z.B.: “highway=residential”), entsprechende Entities schaffen (Straßentyp=Wohnstraße-Entity) und dann die Key/Value auf Key/Pointer umstellen: “highway → Straßentyp=Wohnstraße-Entity”) und genießt danach die Vorteile strukturierter Daten, u.a. Eindeutigkeit und Sicherheit gegen Tippfehler.

Weiteres Beispiel: man könnte auch statt einer Postleitzahl eine Referenz auf ein Postleitzahlbezirk-Entity hinterlegen. Womit eine saubere Beziehung definiert ist. Und man ohne Suche alle Objekte mit dieser PLZ per Index aus der DB ziehen kann. Ginge auch mit einer Relation, aber wer mag eine Relation mit 45764582734653 Mitgliedern haben?

Doch zurück zu den Sammelrelationen: als Alternative zu einer Relation “Berchtesgadener Alpen”, die die dortigen Wege und Hütten und und und enthält, würde ich ein Entity “Berchtesgadener Alpen” vorziehen und dann von den Objekten ein Key “gehört zu” mit Link auf das Entity. Bietet die gleichen Vorteile (sauschnelles Laden aus der Datenbank über Index statt über spatiale Suche) ohne den Nachteil der großen Relationen mit ihren hunderten Versionen.

Und über Höhlen mit einem “Bestandteil des aktuellen XYZ-Projektes”-Attribut wird sich kaum jemand beklagen, insbesonders wenn das verlinkte Projekt-Entity die Beschreibung des Projektes und die Mitarbeiter enthält, so dass man leicht Kontakt herstellen kann.

Entities und Links sind die strukturierte Version der Alternativvorschläge zur Höhlen-Projekt-Sammelrelation.

Nicht ausgegoren und ins Unreine, just my 2.38¢ und zum Weiterspinnen.

Gruß Wolf

Nahmd,

und jetzt mal wieder on Topic. Wie passt das ins Höhlenschema:

:sunglasses:

Gruß Wolf

“Klodeckel” oder “Sargdeckel” würde ein Forstarbeiter sagen - wenn ein Teil des Baumes wegbricht ist man begraben.

@Netzwolf, das war einmal die Höhlenrelation: http://www.openstreetmap.org/relation/1612032
Ich habe es schon selber versucht über die History zumindest die Inhalte zu retten, aber leider einen Timeout bekommen. Mit wieder herstellen und den reverts habe ich mich bisher nicht befaßt, da es in den vergangenen 6 Jahren keinen Grund für mich dazu gab.

@Rogehm, danke für dein Angebot ein WIKI anzulegen. Sollten wir so machen, dann ist es schon mal definiert.

Mein Vorschlag ist:
Für alle Keller und nicht natürlich geschaffene Unterweltzugänge:

man_made=cellar_entrance

Man könnte dann die Erdställe, wie anderes kellerhaftes auch in einem optionalen

Cellar:type=* 

Näher definieren. Erdstall, Felsenkeller, Eiskeller, Bierkeller, Ehrhard_Keller, Bunker, Championzucht , Silbersandmine, … was auch immer.
Ausserdem

Access=no	

Wenn das Teil veschlossen oder betreten verboten ist.

State=inuse
wenn er noch genutzt wird
State=disused
wenn er dem Verfall preisgegen ist

Und dann noch das übliche name, WIKIPEDIA, Denkmal, Image etc. tagging.
Klopf es mal rein in eine neue Wiki Seite und wenn jemanden noch was einfällt kann es ja noch ergänzt werden. Ich schau mal ob ich ein paar Bilder hab.

Ein Beispiel der gesamten Palette hab ich mal in https://www.openstreetmap.org/node/1397135420 gemapped
Danke!

@geomehr, ob eine wissensbasierende Datenbank besser wird durch löschen bezweifel ich aber mach was du für richtig hältst.

ist das mit state=… an bisherige Tagging-Schemata (bspw. Eisenbahnen) angepasst oder ein Schuss ins Blaue?

Ich bin eindeutig für man_made=cavity als generisches Übertag, wenn man keine Ahnung hat, wasfür ein menschgemachtes Hohlraumding das ist.

Für Bunker haben wir schon nen anderes Schema, military=bunker, http://wiki.openstreetmap.org/wiki/DE:Tag:military%3Dbunker .

@cycling_zno: Alles klar ! Danke, das ich nicht in den Besen beissen muss. :wink:

Bilder gibt es genug. Brauchst nicht zu schauen. Ich fang dann schon mal an. Bei Fragen wende ich mich direkt an dich.

Gruß Rolf

@gormo: Ich denke, da mich die Sache mit den Erdställen selbst so beschäftigt hat, hat der man_made=cavity auch noch Platz. Ist ja auch anders definiert.
Da muss ich auch noch mit den Österreichern reden.

Nahmd,

Das ist die Höhlenrelation. :slight_smile:

Tipp: Keys bitte durchgehend in Kleinbuchstaben.

Gruß Wolf

Das state-Tag gefällt mir nicht. Warum nicht das bewährte disused=yes, falls der Keller nicht mehr genutzt aber noch existent ist?
Tags, die für sehr viele Arten von Objekten gültig sind, muss man meines Erachtens nicht zwingend dokumentieren, es sei denn als “sinnvolle Kombination”.

Gruß,
Zecke

@Netzwolf & Zecke Nur die Ruhe…

Ich kenn mich schon ein bisserl’ aus und werde hier nur bewährte und eindeutige Zusatztags einbringen. Lasst mir ein bisschen Zeit. Danke.

Gruß Rolf

Hallo

@cycling_zno: So, Erstfassung fertig! Bevor die anderen sich draufstürzen und alles plattmachen (“American Football - Prinzip”), möchte ich erst mal deine Meinung hören.
Was fehlt, was ist nicht richtig usw… Danke!

http://wiki.openstreetmap.org/wiki/DE:Tag:man_made%3Dcellar_entrance

Danke. Gruß Rolf

Vielen Dank für’s anlegen und für mich sieht es perfekt aus. Ich hab ein paar kleine Ergänzungen rein und wahrscheinlich fallen mir mit der Zeit noch mehr ein wenn ich die Keller in Franken umstelle.

@Netzwolf, danke für’s wiederherstellen der (er hat Jehova gesagt). Ich hab schon wieder ein paar weitere Teile hinzugefügt.

@geomehr, so geht Zusammenarbeit nur so als Tipp

Gruss aus Franken

@ cycling_zno
Hi,
Erst mal danke, das du zufrieden bist. Deine Ergänzungen sind vielleicht nicht ganz optimal.
Eine Kasematte hat mit einen Höhle eigentlich nichts zu tun. Katacomben sind hier ebenfalls nicht beschrieben, unterirdische Begräbnissstätten haben hier nichts zu suchen.
historic=yes für Historische Erdhöhlen und heritage=yes für Baudenkmale. Das cave:ref wird niemals ausgewertet, besser ref=cave:…

So, sorry, jetzt hab ich mal den Ball in der Hand und alle stürzen sich drauf… dann schnell ducken und weg…

Gruß Rolf

Mit “Das Objekt ist als Baudenkmal ausgewiesen.” ist wohl “heritage=yes” gemeint und nicht “historic=yes”.

Ansonsten s. http://wiki.openstreetmap.org/wiki/Proposal_process .

und die ersten schon sichtbar:

http://geschichtskarten.openstreetmap.de/historische_objekte/?zoom=17&lat=49.54521&lon=11.95522&layers=B00000000FFFFFFFTFFFTFFFT&detail=2

grüße von lutz

Ich habe mir deinen Entwurf mal angesehen. Spontan ist mir eingefallen:

Es gibt hier in der Nähe einen ehemaligen “Bierkeller” mit historisierendem Portal, der aber wohl kein Lagerkeller sondern eine Art Casino war.
http://de.wikipedia.org/wiki/Von_der_Heydt_%28Saarbr%C3%BCcken%29

Wäre das cellar:type=gastronomy?

apropos - ich vermisse cellar:type=storage
chill könnte misleading sein, wie wäre stattdessen storage? Braucht man extra die Kühlung, Keller sind ja von Natur aus kalt? Ggf. cold_storage?

Du hast jetzt adit auf einen Bergbaustollen beschränkt. Da Stollen aber primär erst einmal die Bauform bezeichnet (horizontaler Gang in den Berg hinein) wäre für mich ein Luftschutzstollen primär immer noch ein adit und kein cellar (wobei es die auch gibt mit Luftschutzfunktion). Ich glaube, da ist noch Diskussionsbedarf - frei nach Grönemeyer: Wann ist ein Keller ein Keller?

Gruß,
Zecke

@Zecke

'Abend. Ich sag mal, ich habe die Wicki-Site für cycling_zno erstellt, in der Annahme, er sei noch nicht bewandert im Wiki.
Dadurch, das seine Ergänzungen, die ich schon bemängelte, darauf deuten lassen, das er Wiki kennt und kann, möchte ich die Verantwortung dieser Seite auch ihm übertragen. Soll nicht heissen, ich halt mich jetzt raus. Gerne mache ich Änderungen. Aber bitte sprecht mit “cycling_zno”, das ist jetzt seine Seite.
Ich gebe jetzt den Ball ab. Und wenn er den Ball wieder zurückspielt, stürzt euch ruhig auf mich. Aber heute Abend ist Out-Time für mich. Kümmere mich morgen drum.

Gruß Rolf

Anh. Auch ist die engl. Version zu erstellen. @ cycling_zno. Frage: Kannst du das?