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

“die meisten hier” haben mir gerade zugeflüstert, dass sie deinen Aussagen widersprechen wollen. :roll_eyes:

@cycling_zno: lass dich nicht von einem Troll/jemandem der laut eigenen Aussagen keine Ahnung von der Materie hat, demotivieren, so jemanden ignoriert man am Besten.
@geomehr - wo du schon von Regeln sprichst: http://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer

@cycling_zno

es wäre schade, wenn du jetzt aufgeben würdest, genau deine arbeit macht die osm-datenbank für die zukunft wertvoll!
weg vom 08/15 mappen zum detail.
über das wie, wird es immer diskussionen geben, aber es ist allemal besser zu beginnen, als ewig alles totzureden und auf der stelle zu treten.

wir werden man_made=cellar_entrance auswerten, eventuell hilft als checkliste für dich ein temporärer network-tag an die überprüften objekte?

grüße von lutz

Hallo,

Die österreichischen Kollegen wissen auch noch nicht so recht, wie sie die Eingänge der Erdställe taggen sollen. natural=cave_entrance ist da wohl falsch am Platz.
http://overpass-turbo.eu/s/6ww

Wäre man_made=cellar_entrance auch hier anzuwenden?

Ich könnte auch anbieten, im Wiki was zu beschreiben.

Anh. Für “Erdstall” gibt es keinen engl. Begriff. Wie wäre es für eine von Menschenhand geschaffene Erdhöhle mit man_made=cavity ? Nur als Vorschlag.

man_made=cellar_entrance finde auch ich besser als nur man_made=adit
Im Nachbarort habe ich einige Vorratskeller, die in einen Sandsteinhang eingegraben wurden. Die Eingänge habe ich jetzt mal auf man_made=cellar_entrance geändert.

Nahmd,

Ich habe für die Gebirgsregionen, in denen ich arbeite, die ganzen markierten Wege, Hütten usw. in einer Relation gesammelt. Diese Sammelrelationen .oO( er hat Jehova gesagt!) werden vor Ort weitergepflegt. Geht. Allerdings gibt es da unten deutlich weniger Löschtrolle und Bedenkenträger als hier oben.

Sag, welche Tags die Relation hatte, oder ein Objekt, das drin war, dann kann man sie suchen und entlöschen.

Bitte sei an dieser Stelle nicht zuuuuuu böse. OSM ist immer noch eine äußerst techniklastige Geekveranstaltung. Leider. Du bist mit Deiner Kritik nicht alleine.

Die Hauptkarte ist symptomatisch: sie richtet sich vorwiegend an Mapper; der gemeine Benutzer™ bleibt außen vor. So was banales wie ein Kontextmenü mit “Wo bin ich? Marker abwerfen. …” fehlt. Von Route berechnen lassen oder GPX der heutigen Tour anzeigen lassen ganz zu schweigen. Obwohl das OSM-Gesamtprojekt das alles kann. Nicht mal einen Link zu einer Routing-Seite findet man.

Einschub: Wo ist die Funktion zum Marker abwerfen hin? Die war doch mal unter Teilen zu finden? Gibts die gar nicht mehr?

Zurück zum Text: als Antwort auf einen einfachen Wunsch die Antwort zu bekommen: “arbeite Dich in PostGis ein” oder “lerne ArcGIS” oder eben auch “lerne die OP-Abfragesprache”, damit muss man hier rechnen. Sei da bitte nicht (zu) verärgert. Das ist nicht böse gemeint. Wenn man in eine Materie voll eingearbeitet ist, übersieht man leicht, vor was vor einer Wand der Anfänger steht. Obwohl man selbst davor gestanden hat.

Ich hab irgendwas um 90 Regionen in den Ostalpen angelegt. Das war einfach, weil die Grenzen mal vom Alpenverein definiert wurden, nur halt sehr viel Arbeit.

Man kann aber auch mit einer unscharfen Beschreibung arbeiten. Als Beispiel im Kleinen das Siebengebirge und etwas größer der Westerwald. Ich führe die Grenze anhand der Beschreibung orographisch an Wasserläufen entlang, wenn nicht vorhanden, an topographischen Merkmalen, und wenn gar nichts hilft, greife ich beherzt zum Lineal. Weil die Grenzen nicht scharf definiert sind, muss ich damit rechnen, dass jemand eine andere Meinung hat und eine Grenze korrigiert. Und das ist auch gut so™. Die “Belohnung” findet man bei Wikipedia, wenn man auf den OSM-Lupe oben rechts klickt.

Wenn Dich die Region “Fränkische Alb” interessiert und Du lokale Kenntnisse hast, fang einfach an, die einzutragen. Die Grenzführung muss nicht perfekt sein. Du musst nur anderen zugestehen, die Grenze zu verfeinern oder zu korrigieren.

Die Nutzung von definierten Regionen kannst Du auf der Karte von Maxbe sehen. Wenn genug Regionen in DE erfasst sind, wird es auch für topographische Karten interessant, in kleinen Maßstäben die Regionen anzuzeigen.

Erfasse die Region nur, wenn Dich Region an sich interessiert. Nicht aber als reines Hilfsmittel für andere Arbeiten. Das frustriert nur.

Die Objekte, an denen Du arbeitest und bei denen Du noch unsicher bist, in einer dafür anzulegenden Region zu suchen, ist grober Unfug. Die Objekte gehören markiert. Durch einen Hinweis im “note” oder durch ein eigenes Tag oder auch durch eine temporäre Arbeitsrelation, das ist zweitrangig. Nach einem Tag suchen ist ok, die Regionssuche ist dazu keine Alternative.

In der Tat ist das Sammeln im Arbeitsgebiet in einer Relation die bequemste Lösung, weil man man JOSM-Bordausstattung mal eben alle gerade bearbeitete Objekte laden kann. Die Suche in der Region nach einem Tag ist ein klein wenig aufwendiger.

Es möge einer der Overpass-Experten erklären, wie Du die Objekte aus einer definierten BBOX (Deinem Gebiet) mit einem bestimmten Tag/Value in den JOSM lädst. Bleibt man Dir eine verständliche Erklärung schuldig, hast Du jedes Recht, die Relation zu benutzen. Sag ich einfach mal so.

Lass Dir da nicht reinreden: die Renderer werden nur angepasst, wenn es die entsprechenden Key/Values bereits gibt. Damit es gibt, musst Du sie eingeben/anpassen. Und zwischen Deiner Eingabe/Änderung und der Übernahme in die Renderregeln sind die Objekte nicht sichtbar. Das ist keine schlampige Arbeit Deinerseits, sonder unvermeidbar.

Die Alternativen sind gar nicht ändern oder die Feinklassifikation mit Subtags zu machen: also (nur ein Beispiel!) man_made=adit; adit:type=cellar. Aber auch damit würdest Du es nicht allen recht machen; Du kannst im Forum nach den Diskussionen zu den memorials suchen.

Der Geschichtskarten-Datenfilter kennt die cellar bereits, und sobald im Datenbestand, werden die ab (zur Zeit, das kann sich noch ändern) Zoom=13 dargestellt.

Du kannst mit dem Erfassen loslegen, fürs Darstellen ist gesorgt.

Ganz schlechter Plan!

Ich freue mich, wenn ich hier Diskussionen zu Themen mitlesen kann, auch und gerade wenn ich von denen nicht viel verstehe. Gerade die — nennen wir sie mal so — exotischen Projekte sind besonders interessant und machen (noch) den Reiz von OSM aus.

Ich bekenne ich schuldig. Und zwar für die Strecke des jährlichen Drachenlaufes im Siebengebirge, und für diverse Jäger- und Hirtensteige, die aufzuspüren mein Sommersteckenpferd ist. Du siehst es aber vollkommen richtig: es gefällt Dir nicht, Du löschst es aber auch nicht aus der DB.

Ein ungelöstes Problem ist die äußerst schleppende Anpassung der Renderregeln der Hauptkarte. Seit mittlerweile Jahren definierte und breit akzeptierte und im Wiki beschriebene Keys werden ignoriert. Die nicht gerenderten Schotterflächen ärgern mich, sie sind aber nicht wirklich wichtig. Dass aber die Schwierigkeit von Pfaden “sac_scale” nicht berücksichtig wird, ist fast schon kriminell.

Ich habe mich schon einmal für mehrere Monate aus dem Forum zurückgezogen. Mich komplett zu verabschieden würde in der Tat ein Menge Arbeit und Zeit sparen sowie Ärger vermeiden. Nur ist das keine wirkliche Option mehr, wenn man erst einmal OSM-süchtig ist.

Gruß Wolf

PS: Und jetzt mach weiter, sonst habe ich den ganzen Sermon umsonst geschrieben. :confused:

Kann es sein, das es sich um positiven Stress handelt? Ich habe gelesen, das dies absolut der menschlichen Psyche als Ausgleich entgegenkommt. Sprich: Tolles Hobby !

Und wenn jetzt cycling_zno nicht wieder Höhlen und Felskeller taggt, dann fress ich 'nen Besen. Ich stehe zu meinem Wort und schreib dir eine Wiki-Site.

Gruß Rolf

genau das ist das problem! jeder von euch kennt die probleme mit den sammel relations und hat ein schlechtes gewissen. aber scheert sich 0 drum. schön weiter mit dem stiefel wie bisher und ja nix ändern. und dann auf beleidigt machen, wenn einer die faxen dick hat von der “beratungsresistenz” einiger sogenannter super-mapper und den scheiss löscht. egal, ich kann damit leben der böse bube zu sein und hab dem treiben eh viel zu lang nur zu gesehen. rücksicht werde ich zukünftig keine mehr nehmen und lang rum-diskutieren wieso, weshalb und warum. ihr kennt das thema ewig und nix ist passiert. wir sind hier nicht in der waldorf schule und arbeiten nach dem motto irgendwas kann schliesslich jeder und lass doch mal dem xy auch sein schönes spielzeug. danke für den tipp mit den anderen relationen, die werde ich mir jetzt auch mal zur brust nehmen. ihr wollt es ja nicht anders.

Aus eigener Erfahrung: sehr schön formuliert!

Wie sagt Netzwolf:

Ich mappe da wo ich bin … und auch detailliert, wie es die Wirklichkeit ist, ohne zu abstrahieren. Nicht einmal da erreiche ich es, alle Informationen zu erfassen. Ein paar Tage später fällt mir schon wieder verändertes auf …

Was stört dich an den “anderen Daten”, wenn du sie nicht nutzen willst?
Warum löschen?
Nehme dir deine Gegend “zur brust” - dort ist sicher auch noch (viel) “unerfasstes”.

Finde ich auch in Ordnung, erfasst mehr als cellar_entrance, und bei Erdställen ist die Funktion ja auch unklar, daher wäre ein Erdstall auch kein cellar_entrance.

Ich finde beide Begriffe auch gemeinsam sinnvoll.

man_made=cavity frü wenn man nix genaues weiss
man_made=adit/cellar_entrance/… wenn man genaues weiss.

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