Also… arbeiten wir mal die aufgelaufenden Themen auf. Ich musste mir selbst auch erst eine Meinung machen.
Ich habe mir die “Import/Guidelines” und zusätzlich “Mechanical_Edit_Policy” (jeweils englische Version) durchgelesen. Beides Mal bin ich der Auffassung, dass diese nicht anzuwenden sind, da es sich nicht um einen Import in der angesprochenen Weise handelt. Wäre es so, gäbe es eine “Ordnung”. Soetwas wie einen feldweisen Import mit wenigen Changesets oder einmalige Bearbeitungen von ways. Soweit ich das beurteilen kann liegt hier ein organisches Wachstum vor. Die Zahl mit fast 600 ways kann ich inzwischen bestätigen. Exakt sind es 574 ways, was mir ehrlich nicht bekannt war.
Diese Schlussfolgerung/Meinung würde ich allgemein nicht teilen, weil es ebend auch kaputte/fehldene Beschilderung geben kann. Auch Behörden haben manchmal keine so genauen Daten, weil sie diese nur übernehmen und die Erzeuger keine genaueren Daten erstellen konnten (siehe Projekt zum niedersächsisches Fahrradrouten Netz der Tourismusmarketing Nds). Wir können ja immer nur vereinfachte Abbildungen der Realität erstellen und da stößt man auch mal an die technischen Grenzen. Aber die Kernaussage ist angekommen und ich kann damit leben. Auch führt es von eigendlichen Thema zu weit weg, als das wir es hier ausdikutieren sollten. Man wird schließlich immer eine Ausnahme (in beide Richtungen) finden.
Das ist in der Tat neu für mich. Denn wenn Start- und Ziel-Fernmeldeturm einer Verbindung von Betrieber ‘A’ sind, dann gehe ich davon aus, dass auch die Verbindung von ‘A’ betrieben wird. Dass die Verbindung zu Unterknoten von anderen Betreibern sein können war mir klar. Es gab vor längerer Zeit einen Import der MDF’s (DE:DSL-Hauptverteiler), die wie ich annehme von der Deutsche Telekom, oder Tochterfirma betrieben wird. Nach der Aussage von Rogehm wäre es also nicht selbverständlich hier den “operator” aus dern Endknoten herauszudeuten?
dicker, fetter Schlussstrich von meiner Seite
Ich stelle fest, dass Richtfunkverbindungen, so wenig sie auch den normalen Kartenbetrachter oder Mapper in seinem Altag beeinflussen/behindern, nicht in der OSM DB gewünscht sind. Es gibt scheinbar mehr Gründe die dagegen als dafür sprechen, sie in der Datenbank zu belassen. Der Mehrwert ist nicht immer auf den ersten Blick zu sehen. Dann soll also der Gruppenrat mal eine Entscheidung treffen, was mit diesen unnötig langen Wegen passieren soll. Die Entscheidung sollte aber bitte nur die Richtfunkverbindungen betreffen. Nicht was da sonst noch so dran hängt, wie Türme in Punkt- oder Polygon-Form.
Okay, ich kann es nicht lassen. Einen letzten Scherz auf Kosten des Datenmodells/Tagging muss ich noch fallen lassen. Da es sich um Schutzräume handelt, die den den Zugriff/die Nutzung behindern, wenn nicht sogar versperren, bietet es sich da nicht als alternatives Tagging an “barrier=microwave_link” zu verwenden? Das wäre auch auf der Karte besser zu sehen. Aber wir mappen ja nicht für den Renderer.