Ich habe die Streckenführung im bemängelten Bereich verbessert - jetzt geht sie zumindest über die noch heute sichtbaren Streckenabschnitte und auch am Bahnhof vorbei, was vorher im Kartenfehler bemängelt worden war - den habe ich damit auch geschlossen.
Die Qualität ist wirklich unterirdisch. Die Strecke teilt sich wahllos Punkte mit Grenzen, Straßen, “landuses”. Meines Erachtens macht es nur Sinn dass sich mehrere Ways Punkte teilen, wenn sie auch logisch etwas miteinander zu tun haben - aber vielleicht habe ich auch davon eine falsche Vorstellung, bin ja noch nicht lange dabei.
Trotzdem habe ich jetzt überall getrennt wo ich es für sinnvoll hielt. Wenn es schon kaum fest gelegte Regeln bei der OSM gibt (außer lösche niemals etwas ), versuche ich wenigstens die Daten so zu bearbeiten, wie ich denke dass ich deren Qualität steigere.
Da hätte ich keine Bedenken, da das meist durch die Punkt-Fang-Funktion der Editoren verursacht wird.
Wer sich auskennt, vermeidet das durch Strg-Klick (JOSM) oder mit Filtern.
Tip in JOSM: Einen razed-Linienzug, der nichts mehr mit den realen Objekten zu tun hat, kann man markieren und per G (Unglue) auf einmal komplett von allen Punkten lösen, ohne andere Verbindungen an den Punkten zu tangieren.
Wenn also das sehende Auge des Experten als Grundlage für Mapping ausreicht, dann könnten wir in absehbarer Zeit ein ernsthaftes Problem bekommen. Dann sollten wir uns mit der Idee auseinandersetzen, für bestimmte (in der Sache ja durchaus relevante) Einträge, eigene Datenlayer oder Datenbanken zu schaffen. Für empfindliche Einträge wie z.B. administrative oder postalische Grenzverläufe gäbe das ja eh schon Sinn.
Unser sehendes Auge ist doch unsere Grundlage unseres Mappings. Und jeder ist ein bisschen Experte in einem bestimmten Bereich seines Interesses, alle Ergänzen wir uns… Wenn ich ein lineares Landschaftselement mit trapezförmigen Querschnitt habe, welches gewässerbegleitend ist, habe ich mit Sicherheit einen Hochwasserschutzdamm… Kombination aus sehen vor Ort und und Interpretation aus Wissen heraus. Wenn ich einen Hang an einem Berg habe mit mehreren deutlichen, südexponierten Terassenstufen kann ich an allen zehn Fingern abzählen, was das mal war… Richtig, ein Weinberg… Auch wenn es in der Region z.B. seit 150 Jahren keinen Weinbau mehr gibt.
Es wird vielleicht so kommen, daß man sich mittelfristig für einen bestimmten Dateninhalt extra Datenbanken schaffen muß. Eigene Datenlayer haben wir aber im Prinzip in der Gestalt schon, als daß bestimmte Inhalte der OSM-Datenbank nicht mehr auf der Hauptseite, sondern nur noch auf “Spezial”-Seiten ausgewertet werden: OpenRailwayMap, historic.place, WaymarkedTrails, Freie Tonne, OpenSeamap, OSMHydrant…
Rendering/Auswertung ist das eine. Aber wenn in nicht allzuferner Zukunft Special-Interest-Mapper jedes römische Heerlager, jede irgendwann mal geplante U-Bahn-Linie, historische Eiszeitränder usw. eintragen, dann wird es für Neumapper schwierig, sich beim Editieren zu orientieren. Separate Datenbanken/Datenlayer, die man dann einfach “ausblenden” kann, wären dann schon eine Lösung.
Bahnstrecken ist da ein gutes Thema… Unsere NLE https://de.wikipedia.org/wiki/Niederlausitzer_Eisenbahn ist mittlerweile in Teilen stillgelegt und abgebaut… Wenn jetzt solche abgebauten Teile in eine neue Datenbank ausgelagert werden:
Können weiterhin existente Streckenteile und -elemente (OSM-Datenbank) und nicht mehr existente Teile und Elemente (“Datenbank hist. Elemente”) an ihren Punkten von existent zu nicht mehr existent weiterhin topologisch sauber gehalten werden?
Können Relationen der Gesamten Bahnstrecke erstellt werden, die existente und nicht mehr existente Elemente umfasst, also Elemente aus zwei Datenbanken? Wo ist diese Relation, in der Hauptdatenbank, in der neuen? Wer ändert Verlinkungen auf Webseiten Dritter (z.B. wikipedia, wikidata)? Funktioniert dann weiterhin ein saubereres Rendering (z.B. historic.place, OpenRailwayMap)?
Es gibt sicher noch weitere Fragen… Datenbankstruktureller Art, die da geklärt werden müssen.
Speziell diese Topologieregeln zu garantieren, macht die Sache schwierig, vor allem, wenn wir noch nicht mal OGC-konforme Datentypen haben.
Eine eigene Feature-Klasse innerhalb einer Datenbank wäre was anderes… z.B. Grenzen. Grenzen könnten eine eigene Feature-Klasse innerhalb der Datenbank sein, mit eigenen Topologieregeln einerseits, gegebenenfalls mit topologischen Regeln zu anderen Elementen andererseits. Ich kenne jetzt nicht technische Struktur der OSM-DB, ich befürchte aber, daß es derzeit nicht möglich sein dürfte…
Das ist doch nur eine Frage der Filter in JOSM. Wenn die Software dann noch verschiedene Vorlagen dafür mitliefert wäre eigentlich alles ganz einfach umsetzbar oder?
Ich fürchte nein.
Die Gefahr, dass Aktionen auf sichtbaren Objekten auch Auswirkungen auf versteckte haben, ist recht groß.
JOSM warnt inzwischen z.B., wenn andere nicht sichtbare Objekte gelöscht würden, der Niederschwellen-Editor iD vermutlich nicht.
Ich schätze mal, dass viele Relationen-Unfälle auf solchen Kollateralschäden beruhen.
Das Anzeigen von getrennten Layern ist das eine, die innere Konsistenz der DB ist ein ganz anderes Kaliber.
Ein paar aufgelassene Bahnlinien machen den Kohl mMn nicht fett, aber als Ablage für alles und jedes Spezialinteresse ist OSM und der Mapper/Nutzer irgendwann überfordert. Momentan sehe ich das noch nicht, aber ganz ignorieren sollte man diese Gefahr nicht.
natürlich wissen die das, und hast du dir das mal richtig angeschaut?
das sind ganz andere ansätze, und die werden irgendwann vor den selben problem stehen,
oder haben die schon unterschiedliche time-layer?
diese problematik haben wir bereits auch ohne razed und abandoned objekte,
durch zb. 3d, straßen als flächen, und immer mehr detailmapping werden wir uns so oder so etwas einfallen lassen müßen…
irgendwann brauchen wir sowas wie reservierte ebenen, ich bin kein experte, aber das muß sicherlich auf der datenbank-seite gelöst werden.
Nein. Du darfst nicht vergessen daß JOSM nur von einer Minderheit der Mapper genutzt (Statistik), meist eine technisch versierte Minderheit.
Angeblich steht das O in OSM für offen. Wenn die Daten so komplex sind, daß sie nur noch von einer technisch versierten Minderheit mit einem ganz bestimmten Editor oder sogar nur einem bestimmten Plugin noch veränderbar sind, dann ist das nicht mehr offen.
Es liegt in der Natur der Sache, daß mit steigender Erfassungsdichte in einem Gebiet, die Komplexität der Daten und deren Zusammenhänge steigt. In gleichem Maße sinkt die Möglichkeit für einen Neueinsteiger, sich in die, zu diesem Zeitpunkt gültigen Datenstrukturen reinzudenken. Mit steigender Erfassungsdichte steigen auch speziellere Interessen. Die Datenstrukturen lassen sich aber nicht dauerhaft vereinfachen und die Komplexität und die Datenzusammenhänge steigen weiter. Will man alles weiter einfach halten, wird man auch nicht mehr offen, da man bestimmte Nutzer- und Erfassergruppen mit durchaus offenen Daten und Nutzungsinteressen aussperrt.
Ich bin überzeugt, daß es da auch keinen Ausweg gibt…
Ach, doch. Eine Idee wären z.B. ergebnisorientierte Editoren, die dem Gelegenheitsnutzer nur bestimmte Eingaben ermöglichen -z.B. ein POI-Editor oder ein Adress-Editor, der es (lediglich) ermöglicht, vorhandene Gebäude (entweder schon in der DB vorhanden oder durch Sat-Bild annähernd verortet) mit Adress- oder POI-Daten zu vervollständigen. Grenzen, Straßen, Landuses … können nicht angefasst werden. Für entwickelte Gebiete wie D wäre das komplett ausreichend für die Mehrzahl der potentiellen Nutzer. Das würde sogar neue Nutzerschichten eröffnen (inkl Schnittstelle für Tourismusagenturen, Filialketten etc.). Im Expertenmodus (JOSM) kann dann alles wie gehabt laufen. Man muss nur denktechnisch davon Abstand nehmen, dass jeder Nutzer Bock darauf hat, “datenbankisch” zu lernen. Das will ich Echt nämlich kaum jemand.
Da bin ich anderer Meinung. Eine zusätzliche, neue Nischengruppe nicht auch noch zu bedienen, wenn Ihre Spezialinteressen nicht in das Gesamtgefüge von OSM passen (wie z.B. historische Informationen), ist für mich kein Problem sondern nur gesunder Selbsterhaltung. OSM muß nicht jegliche Art von Infos anreichern. Offen heißt daß jeder im bestehenden und erwünschten Umfang beitragen kann, nicht daß man zwingend auf jede beliebige Erweiterung eingehen muß, insbsondere wenn diese Nachteile für die Mehrheit der Benutzer mit sich bringt.
Aber die überwiegende Mehrheit an Beitragenden auszusperren um die Wünsche einer kleine Minderheit zu befriedigen, das ist ein Problem.
(Darum bin ich auch froh daß die Begeisterung für superkomplexe Multipolygone nachgelassen hat, mit denen man “seine” Gegend praktisch versiegeln kann.)
Soll also heissen, Flächen von ways und 3D Tagging von komplexen Gebäuden sollten also “ausgesperrt” werden (bzw die Proposale sollten abgelehnt werden), weil diese (3D-Gebäude) dann nicht mehr wartbar oder durchschaubar sind für Einsteiger oder Normale User?
Aus eigener Erfahrung weiss ich, das ein komplexes 3D Gebäude keine Chance hat, genau wie komplexe MP, diese durch andere User zu erweitern oder zu verbessern. Die stehen dann so, wie man sie hinterlassen hat, auch wenn man mal ein paar Monate nichts persönlich dran tut. Im schlimmsten Falle werden sie gar “zerstört” und findet dann z.B. in der F4 nur noch ein Häufchen “Elend” vor, das man bestenfalls noch revertieren kann. Im Prinzip ist ein 3D Gebäude ja die Hinterlassenschaft eines einzelnen Users, und wenn dieser “aussteigt”, was ist dann?
Im Prinzip “abreissen” und wieder neu aufbauen - wie im richtigen Leben, wäre dann manchmal angebracht.
Erg.: Soll also heissen, eine 3D Welt der Gebäude (Türme, Brücken, alle Bauwerke) und ein 2D Welt der Strassen haben keine Existenzberechtigung in dieser aktuellen OSM?
Genausowenig wie unterirdisches oder innergebäudliches (wo sich z.B. urban auch so vieles abspielt)?
Genausowenig wie Geschichte mit den möglichen Hinterlassenschaften, die man auf den ersten Blick vor Ort nicht mehr erkennt?
Genausowenig wie alle möglichen Funktionen, Features, Angebote, die ein Gebäude, eine Einrichtung, eine Firma, ein gastronomischer Betrieb so beinhaltet?
Im Prinzip sind u.a. dies alles Dinge, die den Reiz dieser Plattform ausmachen und dieses “Ding” zum ultimativen Hobby machen, was es letztlich auch bleiben soll, auch wenn wir dadurch “nie” perfekt und professionell werden können. Aber die Akzeptanz unserer Arbeit spiegelt sich in den hundertfachen Anwendungen wieder, was uns alle dazu animiert, es “noch besser” werden zu lassen.
), versuche ich wenigstens die Daten so zu bearbeiten, wie ich denke dass ich deren Qualität steigere.