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

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?

Rolf, vielen Dank für dein Engagement.

Nach überfliegen der Wiki-Seite würde ich das cellar:type aufteilen. Ich würde die Nutzung vom Typ trennen, also cellar:type=rock, aber cellar:use=beer_storage. Beides beschreibt eher den Keller, aber nicht den Eingang, deshalb würde ich noch ein cellar_entrance:type etablieren. Damit könnte man z.B. diese Typen unterscheiden: gemauerte Einfassung mit Tor, Tor direkt im Fels, komplett zugemauert und Eingangshäuschen (so mal auf die Schnelle :D).

Desweiteren sollte noch geklärt werden (ausgeschlossen werden), ob das Tagging auch für Hauskeller gilt.

Gruß
Daniel

Rolf - logisch, keine Kritik an deinem super Engagement! Wer auch immer das weiterpflegt, ich wollte nur einen Denkanstoß geben, worüber man noch nachdenken könnte.

Gruß,
Zecke

.oO(Sammelralation “Altglascontainer im Rheinland”)

Was die Stollenmünder, Erdställe, Kleingruben und andere Erdlöcher anbelangt: Es ist so vielfältig, dass ein komplettes Taggingschema sinnvoll wäre.
Zumal viele diese Dinger teil-natürlichen Ursprungs, künstlich geweitet (sei es aus Bedarf oder weil man das Material abbauen wollte, oder wei’s der Wasserführung diente) und später dann zu U-Verlagerung, Lagerstollen, Luftschutzstollen, Flüchtlingsunterkunft(!) und schliesslich zum halb verwaisten Ort wurden.

Was die Bierkeller betrifft:
Ich habe mir in Mainz schon mal ein paar Stunden als Freiwilliger Schwielen an die Hände gebuckelt, beim Wiederausgraben historischer (Bier-)Lagerkeller aus dem Mittelalter, die in späteren Zeiten irgendwie versandt waren. Das hat in vielen mittelalterlischen Städten da ein wahrliches Labyrinth, ganz ohne Kloake.
Durchaus etwas, was wirklich lohnenswert für Indoormapping und 3D-Visualsierung wäre.

Streng fachlich gibt es keine künstlichen Höhlen, denn

Vielleicht sollten wir uns im OSM-Wiki daran anpassen? Ich würde das machen, wenn kein Gegenwind kommt.

Wikipedia ist zwar keine Quelle, aber ich hab die Primärquellen tlw. vorliegen, und das stimmt so was da steht.