Richtfunkstrecken

hab ihn nochmals angeschrieben mit Verweis auf das Forum.

Gruss
walter

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.

:roll_eyes: 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. :wink:

Sag mal, wie lange mappst Du jetzt schon Stromleitungen? Und wie oft hast Du da schon gemeinsame Knoten mit anderen Objekten, die nichts mit Strom zu tun haben, gesehen und hoffentlich gefixt? Und dann willst Du uns weismachen, das zusätzliche Elemente die sonstige Arbeit nicht behindern?

Baßtölpel

Auf welche Probleme sollte ich dabei stoßen? Große Datenmengen in Ballungsgebieten können nervend sein. Aber das ist nichts, was als ein Problem gesehen werden sollte. Manchmal sind Straßen oder Wasserwege mit Stromleitungen verknüpft. Das stellt für mich dann ein Problem dar, wenn ein optischer Knick in einer eigendlich geraden Leitung entsteht. Meine Gefühle sind da aber nicht so extrem.
Das Stromleitungsthema gibt es etwa 2 Jahr weniger, als mein OSM-Konto.

Hi, bahnpirat
Bitte meinen Comment nicht falschverstehen. Im Prinzip könnte man auch Rifu-Strecken eintragen. Aber dies kann auf keinen Fall ohne Zustimmung des Betreibers erfolgen.
Außerdem ist eine 2D-Ansicht einer Rifu-Verbindung absolut “Käse”. Der Austritt aus dem heute meißt verwendeten Parabolspiegel ist zwar gerichtet, daher auch eine deutlich erhöhte Reichweite erzielt wird. Aber das ganze passiert in luftiger Höhe.
Aber was macht es Sinn, so eine Linie zu ziehen. Man müsste sogar 3D-tags erfinden und anwenden. Die Rifu-Physik ist dann immer noch nicht integriert.
Deine “Bodenlinien” solltest du also wieder abbauen. Auch ist deine Source völlig veraltet. Und kein Mensch wird sich jemals kümmern, um Rifu-Strecken auf den aktuellen Stand zu bringen.
Ich bin ( leider ) seit 10 Jahren raus aus diesem Geschäft und habe meinen damaligen Job selbst demontiert. Da ist leider nicht mehr viel von übriggeblieben.
Also, bitte wieder abbauen… :frowning:

Ach kommt Jungs: Um die Diskussion etwas zu bereichern, ergreife ich hiermit auch das Wort für bahnpirat :smiley:

Natürlich sind die Informationen über die RiFu-Verbindungen spannend, vor allem da der Infrastrukturatlas der BNetzA closed-source ist!

Ich bin in meinem Revier schon über jede Menge spannende Kommunikationsinfrastruktur gestolpert, seien es Kommunikationstürme mit Schusswaffengebrauch, die ACE-Troposcatter oder Sat-Uplink-Stations in der Pampa mit unklarem Betreiber… Wo, wenn nicht in OSM, sind Infos über solche Objekte zu finden!

Ich interesse mich, ehrlich gesagt, zwar auch nicht für Hochspannungsmasten, DSL-Hauptverteiler oder Hundekottütenspender, aber bin froh zu wissen, wo ich ggf. suchen müsste.
Wens nicht interessiert, der ignoriert’s halt.

Natürlich Dich entlastet das Dich, lieber bahnpirat, aber insoweit nicht, als dass die Lizenz sauber sein muss und das Tagging als Line-Verbindung sicher sub-optimal ist…

Just my 2cents

-1

OSM soll eine Datensammlung von Fakten sein und diese sollen auch richtig sein. Sie dürfen aber nicht an dem Wohlwollen von irgendeinem Unternehmen, einer Behörde oder einer Privatperson hängen. Wenn etwas da ist, wird es auch gemappt; egal ob Frau Meier nun möchte, daß die Hausnummer des Wohnblocks in dem sie wohnt nicht notiert wird, oder ob ein Jäger seine Hochsitze nicht in einer Karte sehen möchte oder die Existenz einer Militäranlage geleugnet wird.

Karten sind hochpolitisch und OSM sollte den Anspruch haben, sich nicht von Dritten beeinflussen zu lassen, die eben nicht wollen, daß die Welt so dargestellt wird, wie sie tatsächlich ist.

Christian

Um der “Richtfunklinien - Da darf nix im Wege stehen - Richtfunkphysik” Diskussion jetzt noch mal ein bisschen “Futter” zu geben, schaut mal, was man alles machen kann, wenn man im Physikunterricht gut aufgepasst hat.
http://www.onlinekosten.de/news/artikel/51548/0/Ericsson-zeigt-Richtfunk-ohne-direkte-Sichtverbindung

Da kann man ja in Münster gleich noch ein paar Zacken oder einige Schlangenlinien dazuzeichnen. :slight_smile:

Das sehe ich ähnlich. Wo ein Funkturm ist, wie hoch der ist, und von mir aus auch wieviele Antennnen von was für einem Typ da in welche Richtung zeigend dranmontiert sind, das kann man alles mappen (und das kann man vor Ort auch überprüfen).

Bloss ob von da eine Richtfunkstrecke irgendwohin existiert, das halte ich für nur zweifelhaft überprüfbar.

Bye
Frederik

Das sind Mikro-Details, die für 99% der OSM-Fälle geeignet sind. Für eine Makro-Infrastruktur wie die Richtfunkstrecken sind’s halt leider nur die falschen, bzw. ‘unbrauchbare’ Informationen.

Wenn man sich diese Karte (hoffentlich nicht Deine Datenquelle, bahnpirat ;)) anschaut:

  1. Sind hier die Antennentypen, Turmhöhe etc. eingezeichnet? → nein
  2. Werden die Fresnel-Zonen berücksichtigt? → nein
  3. Wird berücksichtigt, dass die Richtfunkverbindungen nicht am Turm enden? → nein

Bietet die Karte dem Leser einen Mehrwert? → ja ganz klar, die Karte liefert auf einen Blick die relevanten Informationen der Richtfunkverbindungen, nämlich einen Überblick über das Netzwerk.

Die Diskussion ist aber wohl müssig, solange Lizenz und Tagging nicht geklärt sind, bzw. bahnpirats an sich schöne Idee hier tot gemacht wird.
Ich finds schade…

Ja, free_as_a_bird, ich find’s auch schade, das der Zeitpunkt eines solchen Versuches, ein neues Detail in die OSM aufzunehmen, vielleicht etwas zu früh gewählt wurde.
Eigentlich kann eine solche “Luftverbindung” definitiv nicht 2-dimensional dargestellt werden. Noch fehlen jegliche tags für Antenne, Antennenform, überhaupt Luftverbindungen.
Wie wär’s denn mit einem erfassen des deutschen Luftraum’s. Siehe auch “Lhttp://de.wikipedia.org/wiki/Luftfahrtkarten”
Ich glaube, da muß die 3D Entwicklung noch einiges dran tun.
Außerdem müsste für Rifu eine ganze Menge neuer tags erfunden werden, um definitiv konkrete Aussagen zu treffen.
Hier geht es um Frequenz, Sendeleistung, Übertragungsbandbreite, Gewinn durch die Antenne, Antennengröße, Verlust durch das Funkfeld, weitere Verluste im Koaxkabel oder Hohlleiter etc. Dann geht das ganze sogar in’s Indoor Mapping, da sich bei ( nicht allen ) Rifu-Verbindungen der Sender/Empfänger im Gebäude befindet.
Auch eine konkrete Angabe der Rifu.Verbindung ( mal als Bsp. DRS 155/7500 Köln 8 - Bonn 2 701/652 o.ä. - halt Telekom bzw andere Netzanbieter interne Angaben ) wären nötig. Sonst sehe ich absolut keinen Vorteil, den man hier erzielen kann, natürlich nur für demjenigen, den es angeht.

Also ich finde das Richtfunk mappen schon spannend und interessant.

Wie schon oben erwähnt wurde, sollten hierfür Kriterien und Tags geschaffen werden.

Hallo,
nachdem doch jetzt der Richtfunk das allgemeine Interesse in der deutschen OSM-Gemeinde gefunden hat, wird es Zeit für einige tagging-Vorschläge:
Hier mal ein Teil der tag’s, was man so alles braucht:

directional_radio=yes (Richtfunkeinrichtung)
directional_radio:microwave=yes (elektromagnetische Rifu-Einrichtung) directional_radio:optical=yes (optische Richtfunkverbindung)
waveguide=yes (Hohlleiter) ; coaxial_cable=yes (Koaxkabel) - Verbindung von Sd/Em zur Antenne, ergänzt mit waveguide:length= 30 (Hohlleiterlänge in m)
radio_antenna=mirror (Parabolspiegel) =yagi (YAGI-Richtfunk) =portabel (transportierbare Rifu-Antenne - für Kurzeinsätze)
mirror:diameter=2 (Durchmesser des Rifu-Spiegels 2 meter)
microwave:transmitter=yes (Nur Sender - bei Einweg-Rifu);; microwave:transceiver=yes (bidirektionaler Rifu, Sd+Empf.)
microwave:transmit_power=50 (Rifu-Abstrahlleistung in dBm)
microwave:frequency=7.512 (Frequenz des Rifu-Signal’s in GHz)
microwave:channel=7,5_10 (der 10 Kanal im 7,5 Ghz Raster)
microwave:transmission_rate=155 (Rifu Signal Übertragungsrate hier:155 MBit/s)
hop (Funkfeld) ; hop:damping=20 (Funkfelddämpfung in dbm) ; hop:plane=horizontal (Funkfeldebene altern. vertical)

Da kommen aber noch einige tags dazu, nur mal zur Info.

Also ganz ehrlich: So geil die Technik auch ist (ich bin selber vom Fach), aber ich halte dies für vollkommen unnötig in der OpenStreetMap-Datenbank. Dass man am man_made=tower, tower:type=communication einen Tag für Richtfunk anbringt (ein bisschen scheint sich das Schema communication:*=yes durchzusetzen, also communication:mobile_phone=yes oder communication:microwave=yes), erscheint noch sinnvoll, da man das irgendwie am Turm sehen kann. Aber ob der Hohlleiter mit einem Dielektrikum gefüllt ist oder welche Direktivität eine Antenne hat, ist für die OpenStreetMap-Datenbank vollkommen übertrieben.
Ich lasse mich gerne eines Besseren belehren, aber momentan bin ich schon froh, wenn jemand überhaupt den Unterschied zwischen man_made=mast&communication:mobile_phone=yes (Handymast) und man_made=communications_tower (Fernmeldeturm) versteht und dann so kartiert. Die OpenTopoMap ist bisher die einzige Karte, die zwei unterschiedliche Symbole dafür verwendet.

Nachtrag:

Bitte nicht Bandbreite und Datenrate - geschweige denn Symbolrate - durcheinander bringen!

Sorry, korrigiert

Jedoch steht die transmission_rate im direkten Zusammenhang mit der bandwith:

Zusammenhang zwischen Datenübertragungsrate, Bandbreite und Schrittgeschwindigkeit
Zwischen Bandbreite und maximaler Datenübertragungsrate (Kanalkapazität) besteht ein fester Zusammenhang, der durch das Shannon-Hartley-Gesetz definiert und manchmal auch als Nachrichtenquader der Nachrichtentechnik bezeichnet wird… (Wiki)

Ja sicher, allerdings ist die Shannon-Grenze das theoretische Limit, dem man sich von unten nähert. Heutige Modulations- und Codierungsverfahren kommen schon recht nah ran und jedes zehntel dB mehr ist inzwischen eine Publikation wert. :wink: Die Grenze ist abhängig vom SNR, besser gesagt dem Logarithmus, und dieses muss natürlich bei der Pegelplanung festgelegt werden, schwankt aber je nach Ausbreitungsbedingungen.
Fazit: Kanalbandbreite und Signal-zu-Rauschabstand sind für die Übertragungsrate gegeneinander abzuwägen.

“Ich weiss nicht, ob Sie es schon wußten,”

aber ich habe den Eindruck, daß bahnpirat sich ausgeklinkt hat. Alle Fragen bis auf die wichtigste (Quellen und Berechtigung) vor 2 Tagen beantwortet und damit ist die Śache wohl erledigt.

Ist nur mein Bauchgefühl, aber das ist oft sehr gut.

Gruss
walter

ps: nein, ich schreib ihn nicht ein 3. mal an.

Ok, eigentlich ein hochinteressantes Thema, aber OSM möchte ja nicht, wie ich mitbekommen habe, Luft- oder Freiraum-tagging ( jedenfalls im Moment ).
Aber was passiert jetzt in Münster ( Fernmeldeturm )? So lassen, wird eh nicht ausgewertet?
Im übrigen könnte man doch, zumindest Parabol-Antennen, irgendwie im OSM unterbringen. Das 3D-Tagging ist hier natürlich gefragt. Antennengröße, Höhe und Richtungsangaben wären schon sinnvoll. Natürlich auch ein eigenes Symbol.

Hab mir nochmal die Datenlage mit Overpass Turbo angeschaut:
möglicherweise haben wir hier zunächst ein Daten-Qualitätsproblem mit man_made=communications :confused:

Obige Overpass-Abfrage zeigt die Fernsehtürme deutschlandweit (man_made=communication_tower, laut Wiki Fernmeldetürme mit mehr als 100m Höhe). Die Abfrage liefert deutlich mehr Ergebnisse als naiv angenommen, vermutlich mit einer ganzen Menge an False-Positives

Ein häufiges Problem ist offensichtlich, dass Mobilfunkmasten als man_made=communication_tower gemappt werden (statt als man_made=mast ; tower:type=communication)

Eventuell sollte man mal nen Projekt OpenNetworkMap o.ä. gründen. Vielleicht auf Basis von Wikidata, nur mit ner richtigen OSM-Verknüpfung :wink: