Boundaritis - wo soll das hinführen?

“Erst wenn X gemappt wurde, darf Y gemappt werden” halte ich für Unsinn. Wenn es sich um Daten handelt, mit denen OSM grundsätzlich etwas anfangen kann, sollte man nicht anfangen die Mapper da bevormunden zu wollen. Aber grundsätzlich muss man eine Grenze ziehen, welche Daten eben sinnvoll sind und welche nicht. Natürlich @lutz überlässt man das erstmal dem Augenmaß des Mappers und vertraut ihm. Aber bei so vielen Menschen, die an diesem Projekt mitarbeiten, hat eben nicht jeder Augenmaß und irgendwann kann man nicht mehr jeden einfach gewähren lassen. Wir revertieren aus gutem Grund, wenn jemand erfundene Städte einträgt. Und wir revertieren (bzw. würden das tun) aus gutem Grund, wenn jemand die Grenzen des Skythenreichs einträgt. Vielleicht sollten wir aus gutem Grund revertieren, wenn jemand die Grenzen der DDR einträgt. Vielleicht nicht. Aber irgendwo müssen wir diese Grenze ziehen. Nicht exakt, aber genauer als sie bis jetzt gezogen ist. Denn existieren tut sie ja schon, egal wie oft mancher behauptet es müsse sie nicht geben.

Und zum Thema Eisenbahn/Wasserstraßen/Strominfrastruktur: Dass hier so viel toleriert wird und so viel tolerierbar ist, liegt vor allem daran, dass es andere meist wenig stört. Eisenbahninfrastruktur ist räumlich von anderen Dingen getrennt, Wasserstraßen ebenso. Solange ich daran nichts ändern will, ist alles in Ordnung so weit. Oberirdische Stromleitungen sind zumindest sichtbar und relativ wenige, so dass man damit leben kann. Wenn mitten durch den Ort, den ich bearbeiten will aber plötzlich 20 historische Grenzen und dazu noch ein paar dutzend aktuelle, kleinteilige Grenzen (wie Schul- oder Kirchbezirke) verlaufen, dann stören die mich aber eben doch ganz massiv. Und es hilft eben nicht, die durch den Editor irgendwie leicht ausblenden zu können, denn die Daten stehen ja in Beziehung zueinander. Wenn ich jetzt ein Gebäude verschiebe, weil der, der es eingezeichnet hat, das Luftbild falsch ausgerichtet hatte, dann kann es sein, dass ich die Grenze mitverschieben müsste (weil der, der sie eingetragen hatte, keinen exakten Verlauf hatte, aber wusste, dass das Gebäude auf dieser Seite der Grenze sein muss) oder es kann sein, dass die Grenze da bleiben muss (weil sie eben doch exakt da eingezeichnet wurde). Und diese Entscheidung kann ich nicht treffen, wenn die Grenze mir gar nicht angezeigt wird, aber ich kann sie auch nicht treffen, wenn sie mir angezeigt wird, ich aber keine Informationen über den tatsächlichen Grenzverlauf habe.

Ich auch. Deshalb habe ich das auch nicht geschrieben. Ich halte es aber auch nicht für sinnvoll, die Länge von Halbschranken zentimetergenau zu erfassen, bevor der Wald, in dem der BÜ liegt, überhaupt in der Datenbank ist.

–k

Zu dieser Revolution der europäisch-amerikanischen Geschichtsschreibung hätte ich gerne paar mehr Details!
scnr :stuck_out_tongue: :smiley:

Geht es hier noch um Admingrenzen? Ich glaub das Thema ist längst abgeschweift…

Um Admingrenzen ging es gar nicht, eher um Wahlkreis-, Schulbezirk-, Bistums- und sonst noch welche -grenzen.
Das führte schnell zur Grundsatzdiskussion, was überhaupt in OSM gehört.

“Vorschriften” halte ich für illusorisch, weil sie nicht durchsetzbar sind, solange es nicht etwa so viel Kontrolleure wie Mapper gibt :O.

“Overlay-Daten” wie Pilzstandorte ohne Wechselwirkung zu anderen OSM-Daten kleistern zwar irgendwann das Editor-Bild zu, lassen sich aber relativ einfach ausfiltern. Andererseits lassen sie sich aber auch komplikationslos in getrennte Datenbanken auslagern.

Für viel problematischer halte ich die Spezialdaten wie z.B. Kirchbezirke, die in Beziehung zu “echten” OSM-Daten wie Häusern und Straßen stehen. Die müsste ich z.B. bei Offset-Korrekturen mit anfassen bzw. die werden nolens volens mit angefasst, wenn sie Knoten und Linien gemeinsam haben.
Und dummerweise kann ich gerade die deswegen auch nicht problemlos in eine getrennte DB auslagern.
Diese Daten beeinflussen das Mappen nicht unerheblich und von daher kommt auch das Anliegen, diese Datenart nicht ins Uferlose wachsen zu lassen.
Mehr als ein Anstoß kann die Diskussion hier sowieso nicht sein.

Es ging hier eigentlich NIE um Admingrenzen. Diese sind nämlich “zulässig” und bedarfen keiner Änderungen.
Es geht Frederik (und auch mir) wohl um all den anderen Beifang, der da sonst noch mit type=boundary, boundary=killefitt rumschwirrt.

Gruss
walter

Ja das Problem mit der Vielzahl der Relationen kenne ich :confused: Vielleicht muss man sich auch eine weitere bzw. andere Lösung überlegen für Relationen. Vielleicht eine Lösung die es nicht mehr erforderlich macht Wege, Punkte oder Relationen in eine Relationen einzufügen.

In einem Vortrag, vielleicht von einer FOSS-GIS, wurde auch schon mal erwähnt dass es in der Schweiz Straßenkreuzungen gibt an denen an die 200 Relationen zusammentreffen. Eine solche Kreuzung zu ändern wäre mit gigantischer Arbeit verbunden :confused:

Hi Walter, zuletzt waren wir hier bei alte Bahnlinien :wink:

jo, ist was dran.
wenn ich deine Frage in “Wann reden wird endlich wieder über Grenzen?” umformuliere, bin ich ganz deiner Meinung.

Gruss
walter

Eigentlich sind nicht die Relationen das Problem, sondern die darin enthaltenen Mitglieder (nodes/ways), speziell wenn viele Relationen die selben Objekte enthalten. Das ist gerade bei Grenzen sehr häufig der Fall.
Beim Anklicken des Objekts tauchen dann viele Relationen auf, in den es Mitglied ist. (Das war vielleicht gemeint.)

Genau, bloß wer oder was ist OSM?
Gehören wir da nicht dazu?
Interessant finde ich, das man sich Zufrieden gibt, nur Geduldet zu sein…

Vieleicht ist es ja nur eine Behauptung, aber ich frage mich, warum wird wegen ca. 1% des Datenbankvolumens so ein Getöse veranstaltet?
Die Fehlerquote allein an falschen Schreibweisen in der Datenbank ist bestimmt größer.
Automatische Fehlerbereinigung unerwünscht, automatische Importe unerwünscht, automatische Edits unerwünscht, automatische Kontrolle erwünscht?
Das könnte eventuell einer der Gründe der Grenzziehung sein?

Grüße von Lutz

Natürlich gehören wir alle da dazu. Aber das gibt nicht einem einzelnen (oder einer kleinen Gruppe) das Recht, alles was sie aus welchem Grund auch immer in der Datenbank haben wollen, da auch reinzukippen. Sondern die Mehrheit muss definieren, was gewollt ist und was nicht.

Im Übrigen bin ich für automatische Fehlerbehebung - bei Imports gibt es aber gute Gründe, vorsichtig zu sein, wie die Vergangenheit gezeigt hat. Trotzdem sind die grundsätzlich sinnvoll, sie müssen aber richtig umgesetzt werden. Dafür haben wir ja auch einigermaßen klare Regeln gefunden, was gut ist und weiterhilft und was Mist ist und besser gleich revertiert wird (was ja nicht heißt, dass die Daten, besser aufbereitet, am Ende trotzdem verwendet werden können).

Da wir schon vom Thema abschweifen… Gehören 3D-Gebäude und Indoormapping in OSM?

Das Thema 3D-Gebäude wäre ganz einfach. Das klassische Gebäude in OSM und der Rest extern. Dann könnte man geg. aucht mit gescheiten Tools das modellieren…

Sind mehrere Ebenen übereinander dann helfen in OSM auch nur noch Filter. On-the-ground mapping geht da nicht. Nur noch on the floor, underground, overground, on-the-roof-top… Mappt doch auch so heute keiner mehr on-the-ground :smiley:

Virtuelle Grenzrelationen…
Zur Reduktion der ganzen Grenzen sehe ich tatsächlich nur die Möglichkeit Relationen in Relationen zu packen und das dann zu verschachteln.

Wambacher schrieb:

Die Lösung dafür sind virtuelle Grenzrelation.
Diese werden bei Bedarf neu aus den den Basisrelationen berechnet. Um das Editieren zu vereinfachen und damit diese nicht beschädigt werden können sind diese read-only und werden in den Editoren ausgeblendet bzw. erst gar nicht geladen.

Für mich ist nicht Menge an Daten/Relationen in OSM relevant sondern das einfache editieren. Auch für Leute die nicht so viel Erfahrungen haben. Viele lassen nämlich die Finger von Objekten wenn sie sehen, dass da irgendwas mit Relationen ist. Oder sie machen einfach… und jemand wird das dann schon reparieren.

Grüße,
G.

Unter virtuell würde ich verstehen… dass ich keinen direkten Bezug zu OSM Objekten mache.

Sonder nur sage hier (lan, log) geht es los… über, über, über, Start=Ziel wie bei eine Routenberechnung für Autofahren… Start, Via, Ziel

Nun, wenn ich mir die Grenze nach Polen abschaue, z.B. http://www.openstreetmap.org/#map=16/52.0480/14.7435&layers=N

habe ich an einem Liniensegment 13 Relationen im administrativen Zusammenhang, eine Wahlkreisrelation, ein PLZ-Relation und eine TMC-Relation. Hinzu kommen als separate Linien; 2 Schutzgebietsgrenzen (je eine polnische und eine deutsche) und eine Grenze des Naturraumes (von polnischer Seite…)

Was Schutzgebiete anbelangt, so ist es hier offensichtlich, daß bei beiden die Landesgrenze auch die jeweilige Schutzgebietsgrenze definiert.
was naturräumliche Grenzen anbelangt, können diese (eigentlich) nicht an der Landesgrenze aufhören…

Sowas wie Grenzen der Kirchsprengel… sind hier nicht.

Wie ich oben schon schrieb, bin ich der Meinung, daß Wahlkreise sich aus administrativen Grenzen ableiten und für verzichtbar in OSM halte. Meiner Meinung nach kann das vollständig extern abgeleitet werden (Zuordnung Regionalschlüssel zu Wahlkreis).

Wenn aber Schutzgebiete (in welcher Form auch immer) in Teilen durch Grenzen definiert werden, sollten auch Grenzen Bestandteil dieser Admingrenzen sein… Hier hat man zwei Möglichleiten: eintweder der entsprechende Abschnitt wird Teil der Schutzgebietsgrenze oder die Schutzgebietsgrenze wird im entsprechenden Abschnitt mit der Admingrenze “verklebt”.

Sicher ist beides nicht ideal… aber im Ergebnis erhält und behält man Grenzen der jeweiligen Gebiete entsprechend ihrer Grenzdefinition.

Ich sehe hier kaum Möglichkeiten, die Anzahl der grenzbezogenen Relationen deutlich zu verringern.

Sven

…der bei JOSM in der Standardnutzung Grenzen immer ausblendet.

Komisch: bei mir ist es genau umgekehrt :wink:

Aber im Ernst. es sind immer noch viele.

Der Multilinestring DE-Polen steht bei mir auf der Abschussliste und über die Landrelationen sollte man mal ernsthaft nachdenken. Die gibt es fast nur bei uns (Nord- und Ostsee) und fast sonst nirgenswo.

Bleibt noch eine etablierte PLZ-grenze und ein mMn unnötiger Wahlkreis des Jahres 2013.
TMC wird wohl auch verwendet.

Die hier verwendeten Ways nun auch noch für andere Relationen zu benutzen, ist eigentlich logisch - aber ich halte absolut nichts davon. Drüberlegen ja, aber nicht teilen.

Gruss
walter

Den Sinn dieser Multilinestrings habe ich bisher nicht verstanden.

Mit ist es egal… ob Adminsegmente in Schutzgebietsrelationen verwendet werden, oder ob Schutzgebietsgrenze lediglich mit Admingrenze verklebt werden. Ok, letzteres würde “one feature, one element” und dem KISS-Grundsatz entsprechen… also 1:0 dafür.

Sven

Der ist Member von D-A-CH 2463632 - und die lebt nicht mehr lange.

Gruss
walter

@seichter
Da gibt’s von dir in Aglasterhausen eine obsolete_boundary=administrative. Kann die weg?