Boundaritis - wo soll das hinführen?

Eine konzeptionelle Problematik kann man (nachhaltig) nicht operativ, sondern nur konzeptionell lösen. Und hier etwas auf die Bahn zu bringen, ist nach meinem Verständnis eine Aufgabenstellung für den OSM-Vorstand.

Ich bin erst kurz dabei, nehme aber eine deutliche Schieflage wahr: Während die einen Themen bis ins letzte Detail gemappt sind (z.B. die erwähnten Bahnstrecken, wo am Weichenvorfeld jedes Signal mit Typ und ref eingetragen ist), fehlen in derselben Gegend nur ein paar hundert Meter weiter noch sämtliche Bäche, die vom Hügel zu Tale rauschen und die nicht gerade winzig sind. Oder es fehlen noch fast alle Tracks, die die Felder durchziehen und über die sich OSM-nutzende Wanderer / Spaziergänger eher freuen würden als über das Datum der letzten Auswechslung des Leuchtmittels eines Bahn-Lichtsignals.

Ich wäre dafür, einen gewissen Mindeststandard pro km² festzulegen, eine Liste von allgemein kartenwürdigen Features (Waldflächen, Wege, Wasserläufe, Bebauung), die zu sagenwirmal mindestens 80 Prozent gemappt sein sollten, bevor man sich der Farbe der Rückenlehnen von Sitzbänken zuwendet.

–ks

Man kann den Leuten nicht vorschreiben was sie zu mappen haben. Für mich sind “traditionelle” Themen wichtig, also Hausnummern (Gebäude nur so grob, dass man weiß dass da ein Haus steht, aber ohne jetzt jede Gartenhütte und jedes Planschbecken zu mappen), Straßen mit Geschwindigkeits- und sonstigen Beschränkungen, daneben aber auch z. B. Telefonzellen, Briefkästen mit Leerungszeit und ref, oder auch Rettungspunkte. Andere Leute setzen andere Prioritäten und bevorzugen es z. B., Hydranten einzuzeichnen. Das kann man ihnen m. E. nicht verbieten.

Was Frederik nicht erwähnt hat, dabei weiss er es viel besser als ich, ist das der Erfolg von OSM (historisch) sehr wahrscheinlich genau darauf beruht, dass einerseits OSM selbst keine auf eine bestimmte Zielgruppe spezialisiertes Projekt ist, anderseits man sich themenspezifisch trotzdem austoben kann wenn man so will.

Ich gehe auch davon aus, dass bei den ach so bösen Eisenbahn- und Strommapper, die Heimatgegend sehr wohl super gut gemappt ist. Ich sehe jetzt überhaupt kein Grund zu verlangen, dass zuerst X gemappt werden muss bevor unabhängiges Feature Y erfasst werden darf.

Nein, man kann die Mapper zu nichts zwingen.

“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