Boundaritis - wo soll das hinführen?

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?

Wie der Name schon andeutet: ja.
Das sind die Grenzen bevor die von LGL BW verfügbar wurden.
Ich habe die nicht gelöscht, sondern nur “unschädlich” gemacht, da ich abwarten wollte, ob nicht gelegentlich die alten besser waren. Die Schamfrist betrachte ich als abgelaufen.
Woanders habe ich die schon beseitigt, da oben in BW aber offensichtlich noch nicht.
Mit Vorsicht löschen, da die Grenzen immer wieder auch mit “echten” Knoten wie Wegen, landuse etc. verklebt sind/waren.

Ja, es ist abgeschweift, und das aus gutem Grund.
Im deutschen Forum tauchen so nach und nach Diskusionsfäden auf, die nach der “Salamitaktik” dem Mapper suggerieren sollen, dass irgendetwas in der Datenbank “krank” (*itis) ist und deshalb ausgemerzt werden muss.
Heute ist es die “Multipolygonitis” und “Boundaritis”, und morgen wird es die nächste “*itis” sein.
Deshalb ist es wichtig, dies auch allgemein zu diskutieren.

Ich weiß nicht, wo Du die 99% hernimmst, vieleicht geht der “normale Mapper” heutzutage zu Haufe auf die State of the map oder anderen großen OSM-Konferenzen.
Historic.Place kann sich weder über zu wenig Trafic, noch unzureichender Zustimmung (Mailverkehr mit Mappern) beklagen.
Wie das bei den anderen “putzigen” Projekten aussieht, weiß ich nicht.
Übrigens darf bei der Ausrichtung von OSM nicht nur der Mapper im Vordergrund stehen, sondern auch der Anwender (und hier nicht vorwiegend der von kommerziellen Unternehmen im OSM-Umfeld).
Wenn Bedarf besteht, sollte es erlaubt sein, darüber nachzudenken, den Bedarf in OSM einzupflegen.

Ich behaupte jetzt mal: ohne Kreativität wäre OSM gar nicht entstanden. Aber das war wohl noch vor der 1000-Regeln-Zeit, als es nur exakt zwei Regeln gab: Nicht von anderen Karten kopieren, und Spaß haben!
Als ich vor Jahren in Berlin die ersten “Pseudo-3D-Häuser” in der Karte gesehen habe, dachte ich “geil”, die waren natürlich ebenso wie die ersten Fußballfelder, die so aussahen wie ein Fußballfeld mit zweckentfremdeten key/values gemalt.
Da haben kreative Mapper gezeigt: so wollen wir es in der Karte sehen; und heute existieren 3D Karten - ein Glück dass das nicht gleich zu Anfang erstickt worden ist.

Ich werde jetzt mal böse und frage: “Weil die sich gut kommerziell verwursten lassen?”.
Nicht dass der Eindruck entsteht, ich hätte etwas gegen die kommerzielle Nutzung von OSM, ganz im Gegenteil, diese ist wichtig und bringt OSM ein Stück weit nach vorne. Aber wenn grundsätzlichen Entscheidungen, wohin OSM geht, vorwiegend von kommerziellen Anbietern und Mappern aus deren Umfeld getroffen werden, habe ich große Bedenken…

Welcher Nutzen zählt? Der für Dienstleister im OSM-Umfeld?
Außerdem haben Luftbildmapper schon lange den “vor Ort Mapper” übertrumpft, dieser ist vom Aussterben bedroht oder hat sich aus OSM zurückgezogen.
Die wenigsten lassen sich von jemand anderem irgendwohin schicken, nur um etwas zu überprüfen.
Desweiteren kann eine Überprüfung von z.B. Rathaus-, Museums-, oder Bibliotheksdaten im Internet auch von Mappern vorgenommen werden, die nicht “vor Ort” sind.
Ich denke schon, das damit etwas schneller und einfacher überprüft werden kann.

Noch ein paar Gedanken, hier ist ständig von “Müll”, “Firelefanz”, in die Datenbank “kippen” die Rede.
Asoziale kippen ihren Müll z.B. in den Wald, weil sie ihn nicht brauchen und loswerden wollen.
“Kippt” jemand etwas in die Datenbank, dann braucht er es und will, dass es verwendet wird.
Wie groß der Nutzen des “Firelefanz” für OSM ist, kann sowieso erst später, eventuell erst nach Jahren eingeschätzt werden, z.B ob sich ein großer Anwenderkreis um den “Firelefanz” gebildet hat.
Und jeder Anwender ist von Nutzen für OSM, denn es wird ja gemappt, damit es benutzt wird.
Ich verstehe das Prinzip von OSM so: ich mappe meine Gegend (oder Sachen, die ich gut kenne), obwohl ich die Karten meiner Gegend selber nicht brauche (kenne mich ja hier aus).
Im Gegenzug mappt jemand woanders seine Gegend, und so habe ich eine Karte, falls ich mal dort bin.
Das bedeutet, dass ich wenn ich mappe, ich immer im Hinterkopf fragen muss: “Ist das eindeutig für den Anwender aus der Fremde?”

Ebenso, und das muß der “normale Mapper” nicht so im Hinterkopf haben, ist es Unrealistisch, von kleinen nichtkommerziellen Projekten zu fordern, sich eine eigene Server-Infastruktur aufzubauen.
Es ist nicht nur mit sehr hohen Kosten verbunden, sondern bedarf auch weitreichender IT-Kentnisse.
Dem Pilzkunde-Verein bliebe in der Regel nichts anderes übrig, als sich an einen kommerziellen Dienstleister zu wenden. Ähhh Moment mal :0 …

OSM hat als freie Geodatenbank so viel ungenutztes Potential: im Bildungsbereich könnten z.B. Schulatlanten oder politische Karten generiert werden.
Warum soll eine Karte mit Naturschutzräumen nicht aus OSM Daten zu erstellen sein?
Ich muß jetzt langsam aufhören, Kreativität macht durstig…

Ein kleines Beispiel als Konzept, das z.B. Regionsdaten für OSM von Nutzen sein können ist hier zu finden:

http://gk.historic.place/historische_objekte/index.html?zoom=9&lat=47.61248&lon=11.77287&pid=KmHaHdHbSaHe
http://gk.historic.place/historische_objekte/index.html?zoom=6&lat=46.43296&lon=7.1284&pid=KmHaHcSaHe

Übrigens ein Netzwolf Qualitätsprodukt :slight_smile:

Danke, für den Vorschlag nach Lösungen zu suchen :slight_smile:

Ganz grundsätzlich steht für das OSM-Datenmodel ein Layer-Modell an, bei dem jeder Mapper nur die Layer herunterlädt und bearbeitet, die ihn interessieren, mit anderen Layern möglicherweise als Hintergrund. Dann könnten AdminGrenzen und PLZ-Gebiete und Naturräume in einen solchen Layer verschoben werden, würden den normalen Bearbeiter nicht mehr irritieren, und das Risiko von Beschädigungen durch unvorsichtige Bearbeitungen (siehe Wambachers Auswertungen) wäre drastisch reduziert.

Darüber sollte man diskutieren, und nicht über kleinkarierte Relevanzklauberei.
Denn ersteres macht letzteres überflüssig.

Grüße von Lutz

Mein abschließendes (schon bekanntes) Fazit zu diesem Thread: Virtuelle und reale Objekte müssen ausnahmslos und vollständig voneinander entkoppelt (disjunkt) sein. Diskussion zur Objektrelevanz sind obsolet weil sie zu nichts führen.

Obwohl die Idee prinzipiell nicht schlecht ist, ergeben sich doch eine Fülle von Folgefragen. Was bedeutet das konkret? Auf welcher Ebene soll diese Entkopplung denn sichergestellt werden? Editor? API? Reicht dafür API 0.6 überhaupt aus, wenn nein, wie bleibt das ganze abwärtskompatibel, etc.?