Ich bin inzwischen der Ansicht, dass die von Dir erwähnte OSM-Idee zwar von den Schöpfern von OSM gut gemeint war, bei näherer Betrachtung heute aber verbesserungswürdig ist.
Wir echauffieren uns über Behörden, welche uns Ihre Daten nicht zur Verfügung stellen möchten, ignorieren hierbei aber dass sich diese doch lediglich über die durch uns weitergereichte Qualität sorgen.
Meine aktuelle Meinung ist, wenn uns schon vollständige Daten zur Verfügung gestellt werden, sollte wir diese als gesamtes so auch akzeptieren, und diese vor einer weiteren Veränderung in OpenStreetMap schützen. Aber diese Daten sehr wohl in Nominatim integrieren.
Solches kann zum Beispiel in einem Landkreis für Adressen zutreffen, möglicherweise aber für dortige Wanderwege, und Kinderspielplätze nicht.
Eine OpenStreetMap welche mir vorschwebt, könnte daher Modular funktionieren, z.b OSM mit Plugins und Apps. Manche Plugin Inhalte wären veränderbar, andere mit Namensnennung wieder nicht.
Das hat aber mit Open Source und freien Daten genau … nichts mehr zu tun.
Geschützte amtliche Daten in OSM, deren Fehler man nicht beseitigen kann, sollten direkt in der “Quelle” bleiben. Wenn jemand amtliche Daten nutzen will, dann kann er das auch ohne den Umweg über OSM tun.
Tatsächlich ist es heute schon beim Nominatim-Setup möglich, amtliche “TIGER”-Daten aus den USA (für Hausnummern) und amtliche britische PLZ-Daten zu integrieren, ohne dass diese dafür in OSM importiert werden müssten. Daten, die der Mapper eh nicht verändern kann, müssen auch nicht in OSM sein, insofern ist das für mich der ideale Kompromiss: Jeder, der einen Nominatim selbst betreibt, soll von mir aus entscheiden, ob er ausschliesslich den OSM-Daten trauen will oder ob er den amtlichen Daten den Vorzug gibt. An OSM muss man dafür nichts ändern.
Um eine substantielle Gemeinschaft zur Mitwirkung an OpenStreetMap zu bewegen, benötigt mein ein gemeinsamen Ort -Portal- wo man sich trifft, und man sollte Honigtöpfe zulassen.
Für mich bestünde der Reiz an einem modularen OpenStreetMap darin, dass sämtliche Daten gemeinsam indiziert sind. Zu jedem Modul sollte es auch ein Anti-Modul geben, welches frei bearbeitbar ist.
Beispiel:
Nehmen wir gesetzlich festgelegte Fahrradwege in Tirol. An den Routen wird es keine -on the grund- Alternativen geben, da diese gesetzlich so bestimmt sind. Es ist aber durchaus denkbar, dass eine Brücke oder ein Straßensegment durch ein Naturereignis zerstört ist, und Vorort wenige Meter entfernt ein OpenStreetMap Mapper(in) bereits eine Alternative gefunden hat. Diese würde dann per Anti-Fahrrad Routen App, als Overlay die Amtliche Route überlagern. In einem modularen OpenStreetMap würden Routen mit Namensnennung CCBY 3 oder 4.0 angezeigt, sowie als Overlay auch unsere osmgenerierten Ausweich strecken. OpenStreetMap könnte so Amtlichen Stellen auch als Feedback System dienen, bei ihrer nächsten Veröffentlichung, wären dann von uns gesammelte Korrekturen amtlich geprüft enthalten, und unsere Anti Fahrrad Routen App durch mit Hilfe von Amtlicher Seite bereinigt.
Dieses Szenario könnte man auf viele Fachbereiche übertragen.
Hotel Plugin: Die Vereinigung der Hoteliers eines Landkreises (Tourismusverband), stellt uns ihr Mitglieder (Hotel)Verzeichnis zur Verfügung.
Anti Hotel Plugin, hier würde ein durch Umbau geschlossenes Hotel anzeigen.
Adress Plugin: Amtliche Adressen in einem bestimmten Landkreis
Anti Adress Plugin: Adressen on the Ground
In Landkreisen, wo uns keine Amtlichen Adressen zur Verfügung gestellt werden, gäbe es dann folglich auch nur unsere Anti Adress App (mit unseren aktuellen OSM Adressen).
Das ist eine sehr schöne Formulierung (ein Zitat? klingt nach altem China ;)), aber auf OSM angewandt, würde diese Sentenz eher das „klassische“ Wir-erheben-alles-selbst-vor-Ort stützen. Die Quelle des Wassers = der Geodaten ist die Realität vor Ort, nicht irgendwelche amtlichen Daten, denn diese sind ja bereits aus der Realität abgeleitet; dabei können auch Fehler passieren, die wir doch hoffentlich nicht schon deshalb übernehmen und bewahren wollen, nur weil es sich um amtliche Fehler handelt. Oder, und das ist ein noch größeres Problem amtlicher Daten, die amtlichen Daten sind nicht aus der Realität abgeleitet, sondern aus eingereichten Planungsunterlagen, die aber vielleicht niemals so umgesetzt wurden. Und was ist dann „richtiger“: Das, was die amtlichen Daten behaupten, oder das, was wir vor Ort vorfinden? Doch hoffentlich letzteres. Wenn in den amtlichen Daten (um ein reales Beispiel aus Nordwürttemberg aufzugreifen) ein kleiner Hühnerstall eingetragen ist, in der Realität dort aber ein deutlich größeres Ferienhaus steht, dann wollen wir in OSM, soweit möglich, doch wohl das Ferienhaus eintragen und nicht den Hühnerstall – ob das Ferienhaus nun legal gebaut wurde oder nicht, ist für OSM egal, OSM soll einfach soweit als möglich die Realität abbilden.
Das nur zur Interpretation dieser schönen Sentenz. In der Praxis ziehe ich für das Mapping sehr gerne amtliche Daten heran (in meinem Fall hier v.a.: Maps4BW), aber wir wollen doch immer prüfen, was wir da übernehmen. Für Hausumringe z.B. bildet Maps4BW eine sehr gute, versatzfreie Vorlage für’s Nachzeichnen, aber man muss diese Vorlage immer mit Luftbildern oder noch besser Ortskenntnis vergleichen, denn (s. Beispiel oben) manchmal wurde vor Ort anders gebaut, als es eingetragen wurde, oder (weiteres reales Beispiel) der Hausumring in Maps4BW umfasst auch einen Keller, über dem sich aber nur noch eine ebenerdige Terrasse befindet – dann würde ich diese Terrasse nicht mit in den Hausumring in OSM übernehmen. Auch die Hausnummern in Maps4BW stimmen zwar in den allermeisten Fällen, manchmal gibt es aber auch regelrechte Tippfehler; warum sollten wir diese nicht korrigieren?! Und dass die Angaben zu Waldwegen in Maps4BW nur mit allergrößter Vorsicht zu behandeln sind, sollte bekannt sein. Sprich: Am Beispiel von Maps4BW zeigt sich mMn, dass amtliche Daten sehr nützlich sind, aber normalerweise nicht einfach importiert oder kopiert werden sollten (dass dies leicht zu Desastern führt, zeigen schon die komischen importierten Straßendaten in den USA, deren Aufräumen immer noch andauert), sondern nur eine Quelle neben anderen darstellen. Sie sollten nur mit Urteilskraft, eingeschaltetem Verstand und unter Vergleich mit Luftbildern usw. Element für Element geprüft und dann einzeln übernommen werden, am besten natürlich auch nur dort, wo man Ortskenntnis hat und daher die Plausibilität noch besser beurteilen kann.
Während Deine oben zitierte Sentenz wunderschön formuliert war, muss ich muss gestehen, dass ich weder diese ersten 2 Sätze noch den Rest verstanden habe, sorry. Warum sollen Adressen, die ich selbst vor Ort erhebe, jetzt plötzlich „Anti-Adressen“ sein? Und was wäre da der Honigtopf? Wenn ich unzuverlässige, scheinbar allwissende, de facto aber oft grob interpolierte oder schlicht falsche Geodaten, Adressen usw. haben will, nehme ich einfach Gg Maps; das brauche ich in OSM nicht auch noch.
Das klingt, sorry, für mich sehr nach einem Monster-OSM, das technisch unsäglich kompliziert, überladen und absturzanfällig ist. Über unterschiedliche Ebenen, die ein- und ausgeblendet werden können, kann man immer diskutieren (z.B. Höhenlinien oder bestimmte POIs in der Karte ein- oder ausblenden), aber „Apps“ in OSM? Keine Ahnung, was das sein soll, aber es klingt furchtbar.
Bei einem modularem OSM, könnte man den Layer, Amtliche Adressen, an der Grenze zu einem anderen Land automatisiert überleiten.
Wer mit Bayerns amtlichen Adressen bei Freilassing die Grenze überquert, würde in Salzburg automatisiert auf Österreichs Amtliche Adressen treffen. Müsste also hierbei nicht das Plugin wechseln. Ich stelle mir das so wie bei Bienenwaben vor. Der Imker hängt die Wachsplatte ein, und diese wird von den Bienen Wabenförmig besetzt. Heraus kommt eine Layer mit flacher Hierarchie.
Wir würden also mit nur zwei Wachsplatten das auslangen finden. Die Amtliche “Adress-Wachsplatte”, und eine zweite für unsere OSM Adressen. Wobei in Österreich und Bayern, unsere OSM Wachsplatte nur noch Abweichungen von Amtlichen Adressen darstellen würde, in Ländern ohne Amtliche “Wachsplatte” hingegen, wäre die OSM “Wachsplatte” weiterhin die alleinige für Adressen.
(Eine solche OSM wäre dann auch für die grenzüberschreitende Zusammenarbeit von Blaulichtorganisationen geeignet, und bei Naturkatastrophen -Elementarereignissen- über den schnell reagierenden OSM Layer sehr belastbar)
Ein solches miteinander verweben, wäre bei Behördendaten einfach. Andere Datenbereitsteller müssten sich wohl vor Aufnahme in ein Modulares OSM, -damit Deine Befürchtung “Monster” nicht tatsächlich eintritt- einem Zertifizierungsprozess stellen.
