Richtfunkstrecken

Zitat aus dem Wiki: "Mit dem Schlüssel man_made=* werden die unterschiedlichsten Arten von Menschenhand geschaffener Bauwerke beschrieben."

Unabhängig davon, ob man diese Information hier in OSM haben will oder braucht, stellt sich mir auch die Frage, wie man das vor Ort feststellen kann. Ein Bauwerk ist es jedenfalls nicht - und eine "Verlinkung" wohl auch nicht. Eigentlich ist da eher gar nichts, weil da nichts (störendes) sein darf ;-)

Ich denke, eine Richtfunkstrecke wäre gut mit zwei Nodes modelliert, die über eine Relation miteinander verbunden sind.

aighes wrote:

Ich denke, eine Richtfunkstrecke wäre gut mit zwei Nodes modelliert, die über eine Relation miteinander verbunden sind.

Weil ein Lauscher C, der in der Achse A–B steht, auch die gesendeten Inhalte einer der beiden Kommunikationspartner mithören kann? 🙂

Könnte man nicht einen allgemeineren Tag einführen, der Wlan-Kabel auch mit abdeckt? Den genauen Typ könnte man über zusätzliche Tags spezifizieren. 😄

pyram wrote:

Unabhängig davon, ob man diese Information hier in OSM haben will oder braucht, stellt sich mir auch die Frage, wie man das vor Ort feststellen kann.

Ja, da braucht man (im Gegensatz zu den Stromleitungen die jeder nachvollziehen kann) schon Insiderwissen.

chris66 wrote:

Ja, da braucht man (im Gegensatz zu den Stromleitungen die jeder nachvollziehen kann) schon Insiderwissen.

Zu dem "Insiderwissen" gehört bestimmt eine Erklärung dafür, wieso die Richtfunkstrahlen exakt am Zielmast aufhören und nicht einfach die dahinter liegende Gegend verstrahlen. http://www.openstreetmap.org/edit?edito … 078/8.1367

Sollte da irgendeine unsichtbare Abschirmung vorhanden sein, muss die dringenst auch erfasst werden.
Wie bei der Bahn: hier geht es los und da kommt man an.

Gruß
walter

ps: wieso ich gerade auf die Bahn komme, muß ich mal bei den Piraten nachfragen.

Hmm, ich bin mir nicht sicher, ob das Infos sind die "unbedingt" zu OSM reingehören. Bei WLAN Richtfunk gibt es ja die Freifunk etc. Karten, die das eigenhändig pflegen und auch aktuell halten. Für andere Mapper sind solche Sachen ja nur schwer zu "sehen" und zu verfifizieren, von daher erscheint es mir sinnvoller, sich dort maximal auf die Sender zu beschränken. Leider gibt es aber für TK-Einrichtungen noch kein einheitliches Tagging-Schema, wie es etwa bei power=* der Fall ist: http://wiki.openstreetmap.org/wiki/User … munication

Für mich gehören solche Informationen gar nicht in die OSM-DB, da sie in keiner Weise sichtbar, greifbar oder vor Ort nachvollziehbar sind.

Von daher eine klare Absage an Richtfunk- und andere Funkverbindungen, Reichweiten und Empfangsgebiete von Sendern, Funkbefeuerung, Warteschleifen und Anflugkorridore von Flughäfen, etc. Das ist etwas für Spezialdatenbanken.

bye, Nop

Richtfunkstrecken als Linien einzuzeichnen halte ich (als fast fertiger Hochfrequenzingenieur) für etwas gewagt. Besser ist es, die Antennen als Punkte einzutragen und mit communication:microwave=yes und evtl. einem Azimut- und Elevationswinkel zu versehen - wenn man die Verbindung auswerten möchte, hat man damit schon einen guten Anhaltspunkt.

Da hat man gut was zu tun:

wambacher wrote:

ps: wieso ich gerade auf die Bahn komme, muß ich mal bei den Piraten nachfragen.

Pirata do Bahn ist ein gutes Stichwort, kam da schon Rückmeldung? Die Linien werden immer mehr...

couchmapper wrote:

wambacher wrote:

ps: wieso ich gerade auf die Bahn komme, muß ich mal bei den Piraten nachfragen.

Pirata do Bahn ist ein gutes Stichwort, kam da schon Rückmeldung? Die Linien werden immer mehr...

nö, hatte das nur als kleines Wortspiel angesehen. Aber ich werde den Herrn Piraten jetzt mal auf diesen Thread hinweisen.

Nachtrag: Hab ihn in meiner bekanntermaßen liebenswürdigen Art angeschrieben. 😉 Mal sehen, ob er sich hier meldet.

Hier hab ich auch etwas beizutragen. Komme ursprünglich vom Fach. 🙂
Findet denn beim nun geplanten aber nicht gewünschten Mappen von Richtfunkverbindungen auch die Hardware Berücksichtigung?
Wie: Modulator, Demodulator, Empfänger, Sender mit Klystron oder Wanderfeldröhre. Dort geht's nämlich los mit dem Strahl und schwups durch den Hohlleiter (man_made=waveguide) zur Parabolant.
Die Antennenform läßt auch noch Varianten zu. Wie sind die physischen Ausstrahlmöglicheiten wie Beugung, Streuung, Spiegelung, Ablenkung, Widerstand, Umwegstrahl (atmosph.) und die Fresnelzone zu berücksichtigen?
Zum Glück gibt es keinen Langstreckenrichtfunk mehr, dann würde Deutschl. in sehr viele 60-80 km langen lines nur so "zerschossen", die man dann noch mit Relationen verbinden müßte.
Vor nicht allzulanger Zeit gab es noch eine Rifu-Verbindung "Hamburg-Stuttgart" z.B.....

wambacher wrote:

Zu dem "Insiderwissen" gehört bestimmt eine Erklärung dafür, wieso die Richtfunkstrahlen exakt am Zielmast aufhören und nicht einfach die dahinter liegende Gegend verstrahlen.
Sollte da irgendeine unsichtbare Abschirmung vorhanden sein, muss die dringenst auch erfasst werden.

Da die gesamte Erde schon in weit stärkerem Maß von der Sonne "verstrahlt" wird, kommt es auf so minimale Effekte nicht an.
Der Grund für die Erfassung von Richtfunkstrecken in einigen Karten ist natürlich, dass Bauwerke diese Strecken nicht unterbrechen dürfen.
Diese Wirkung endet am Zielmast.
Trotzdem möchte ich die Richtfunkstrecken nicht als Linie in der Datenbank haben. Den Vorschlag von aighes, zwei Nodes über eine Relation zu verbinden, finde ich gut.

Nop wrote:

Das ist etwas für Spezialdatenbanken.

+1

Vieles wurde schon gesagt. Deshalb zitiere ich hier sehr viel von anderen.

Ich denke, eine Richtfunkstrecke wäre gut mit zwei Nodes modelliert, die über eine Relation miteinander verbunden sind. --Nakaner

🤔 Dieser Meinung bin ich nicht, denn...

Der Grund für die Erfassung von Richtfunkstrecken in einigen Karten ist natürlich, dass Bauwerke diese Strecken nicht unterbrechen dürfen. --seawolff

So sehe ich das auch. Falls ihr es anders seht aber euch nicht speziell störrt, solltet ihr es genauso machen, wie ihr es auch mit Eisenbahnsignalen, Hundekottütenspendern, Eierverkaufsautomaten macht: einfach nicht beachten. Es gab noch keine Vorgabe über die Erfassung solcher Sachen. Deshalb habe ich mir da was aus den Fingern gesaugt. Da Funktürme als man_made=tower oder man_made=communication_tower eingetragen werden, lag man_made=("Funkwellenverbindung") nahe. Manche meinen zwar...

Ein Bauwerk ist es jedenfalls nicht - und eine "Verlinkung" wohl auch nicht. Eigentlich ist da eher gar nichts... --pyram

...da liegt der Meinungsgeber aber falsch. Es handelt sich um einen Schutzraum, der nur von anderen gleichartigen Schutzräumen durchschnitten/durchkreuzt werden darf. Unsichtbar, aber menschen-gemacht. Also ist "man_made" gar nicht so falsch. Es handelt sich um eine Verknüpfung/Verlinkung durch das Medium "Äther". Auch wenn man Kohlenmonoxid nicht sehen kann, ist es doch vorhanden und tötlich.

ps: wieso ich gerade auf die Bahn komme, muß ich mal bei den Piraten nachfragen.

😄 I see what you did there.

bahnpirat wrote:

Der Grund für die Erfassung von Richtfunkstrecken in einigen Karten ist natürlich, dass Bauwerke diese Strecken nicht unterbrechen dürfen. --seawolff

So sehe ich das auch.

Ich war zum gegenteiligen Ergebnis gekommmen: "Trotzdem möchte ich die Richtfunkstrecken nicht als Linie in der Datenbank haben."

Deshalb habe ich mir da was aus den Fingern gesaugt. Da Funktürme als man_made=tower oder man_made=communication_tower eingetragen werden, lag man_made=("Funkwellenverbindung") nahe. ... Unsichtbar, aber menschen-gemacht. Also ist "man_made" gar nicht so falsch.

Zur OSM-Definition von man_made (Zivilisationsbauten/Kunstbauten) passen Richtfunkstrecken nicht.

Bei fast 600 unsichtbaren Funkstrecken handelt es sich um einen Datenimport.
Für Datenimporte gibt es klare Regeln.
Aus dem WikiImport/Guidelines:

... before any actual work is performed on the import that contact is made with the community to see if there is interest in importing the data.
Discuss your plan. Email the OSM community to notify them of your plans, including a link to your wiki page.
It is required that the local community accept the import. Without local buy-in, the import can't proceed.
It is required to obtain proper permissions and licenses to use the data in OSM from the data owner.
It is required to register your permissions and project by adding a line to the table at Import/Catalogue.
It is required to write a plan for your import in the OSM wiki.
It is required to post your import for review on the imports@openstreetmap.org mailing list.

Bitte hole die fehlenden Punkte nach.
Passe das Datenmodell ans Diskussionsergebnis an.
Setze den Import erst nach Zustimmung der OSM-Community fort.

ich habe jetzt keine Probleme mehr damit; ist halt für einen Außenstehenden etwas ungewohnt.

Ist denn abzusehen, daß das auch mal verwendet werden wird? Man könnte das ja als Overlay darstellen (wie breit ist so ein Schutzraum eigentlich?)

Gruss
walter

Die Breite eines solchen Schutzraumes hängt von der länge der Strecke ab. Mir sind Breiten zwischen 200 und 400 Metern bekannt (links/rechts jeweils 100-200 Meter). Eine Faustformel kenne ich nicht. Aus der Erfahrung würde ich aber sagen: "0,1 Breite /100 Länge". Das wäre dann 200 Meter Breite (100 links, 100 rechts) für eine 200 km Strecke. Diese "Idee" hat aber keine fachliche Grundlage.

Chris66 hat sie schon einmal für eine Karte verwendet. Sie können helfen die typische Fragen (besser) zu beantworten: Wo kommt mein Strom her? Wie kommt mein Telefongespräch von Zuhause in das Büro in München? Wo geht braunes Wasser hin und warum kommt es kristall-klar wieder aus dem Wasserhahn raus und riecht nich mehr so streng? Warum wird die neue Stromleitung neben der alten gebaut? Was ist das für ein gelbes, rauschendes Rohr und warum soll ich da nicht rauchen? Warum gibt es einen zwei Meter breiten Streifen auf der Wiese, wo der Schnee schmilzt? Wieso kommt aus dem Atomkraftwerk so viel Wasser raus?

Bei fast 600 unsichtbaren Funkstrecken handelt es sich um einen Datenimport. Für Datenimporte gibt es klare Regeln. (usw.) --seawolff

Gut, dass wir in Deutschland sind und für alles ein Regelbuch haben. 😉 Sonst müssten wir Entscheidung/Lösungen selber finden.
Deine Zahl von "fast 600 Strecken" hat mich aufmerksam werden lassen. Da scheint es mehr zu geben, als auf dem ersten Bild von Chris66 zu sehen war. Ich lese aus Deinen Zeilen, dass du die Annahme vertrittst, dass es da ein oder mehrere Dateien gibt, die komplett oder ausschnittsweise importiert werden. Du unterstellst/nimmst an, dass es eine Plan gibt, der den "Import-Ablauf" vorgibt/regelt. Dass es eine koordinierende Stelle gibt, welche verantwortlich zeichnet. Da wäre ich aber nicht so sicher.

Zur OSM-Definition von man_made (Zivilisationsbauten/Kunstbauten) passen Richtfunkstrecken nicht. --seawolff

Ich glaube seawolff klammert sich zu sehr an "BAU" im physikalischen Sinne fest. Sie (Richtfunkstrecken) sind künstliche Energiewellen und auf diese Bauten angewiesen. Nicht alle "Zivilisationsbauten" werden mit man_made getagged (siehe building). Ebenso müssen nicht alle man_made auch Bauwerke ("es ist etwas künstliches, greifbares erschaffen worden") sein. Beispiele: cutline, surveillance (alles keine Bauwerk) Aber ich bin offen für Vorschläge. Es besteht die Möglichkeit, dass es eine Art gibt, diese Strecken einzutragen, die ich bisher noch nicht kannte. Her damit!

Was ist mit Busrouten? Sie sind eine logische und geordnete Verknüpfung von Orten. Obwohl den Verkehrsbetrieben die Straße nicht gehört und es irgendwie egal ist, was der Bus zwischen zwei Haltestellen macht, so tragen wir trotzdem den Routenverlauf ein. Warum? Weil wir es können! Weil wir eine der genauesten Kartenwerke herstellen, die man sich denken kann.

bahnpirat wrote:

Chris66 hat sie schon einmal für eine Karte verwendet.

🙂 Ja, oben meine Overpass Abfrage.

bahnpirat wrote:

Bei fast 600 unsichtbaren Funkstrecken handelt es sich um einen Datenimport. Für Datenimporte gibt es klare Regeln. (usw.) --seawolff

Gut, dass wir in Deutschland sind und für alles ein Regelbuch haben. 😉 Sonst müssten wir Entscheidung/Lösungen selber finden.

Das Regelbuch wirkt nicht gerade deutsch :-)
Es beschreibt auch nicht, wann ein Import zulässig ist, sondern wie man zu einer sinnvollen Entscheidung kommt,
ob die Community die Daten haben will, welche Datenstruktur und welche Tags angemessen sind.

Ich lese aus Deinen Zeilen, dass du die Annahme vertrittst, dass es da ein oder mehrere Dateien gibt, die komplett oder ausschnittsweise importiert werden.

Die Vermutung liegt sehr nahe (wobei die Form der Datei auch eine Liste oder Karte sein kann).
Oder behauptest du, die Ausrichtung aller Antennen vom Boden aus gemessen zu haben?

Was ist mit Busrouten? [] Warum? Weil wir es können! Weil wir eine der genauesten Kartenwerke herstellen, die man sich denken kann.

OSM ist eine mäßig genaue, umfassende Geodatenbank.
Jede Katasterkarte ist genauer.
OSM ist auch nicht allumfassend.
Busrouten werden (unregelmäßig) eingetragen.
Luftraumstrukturen werde nicht in OSM erfasst, obwohl wir es könnten und sie teilweise für Bauvorhaben relevant sind.
Die OSM-Community hat sich trotzdem dagegen entschieden.

bahnpirat wrote:

Dass es eine koordinierende Stelle gibt, welche verantwortlich zeichnet. Da wäre ich aber nicht so sicher.

Laß es uns konkret machen. Bahnpirat, woher genau kommen die Daten über Richtfunkstrecken, die Du in großem Umfang einträgst?

bye, Nop

Ich bin dagegen, die Funk-Verbindungen zwischen den sendenden Bauwerken einzutragen. Das kann man besser über Relationen abbilden. Daraus können dann spezielle Programme Verbindungslinien bei Bedarf generieren.
Denn wer kümmert sich nach Jahren um evtl. still gelegte Verbindungen, die aber als Linien weiterhin in der DB enthalten sind? Das kan man ja nirgends sehen.
Und wenn ich wirklich mal wissen will, was da so alles strahlt, suche ich bestimmt nicht in OSM :-( Da ist mir die Unsicherheit zu groß, dass die vorhandenen Daten nur aufgrund der Laune einiger sehr weniger erfasst sind und sehr wahrscheinlich nicht vollständig sind.

Also Funkstellen, sind ja irgendwas was man sehen kann (auf Gebäuden, Türmen etc.), ja - die Verbindungslinien definitiv nein.

Noframe wrote:

Ich bin dagegen, die Funk-Verbindungen zwischen den sendenden Bauwerken einzutragen. Das kann man besser über Relationen abbilden. Daraus können dann spezielle Programme Verbindungslinien bei Bedarf generieren.
Denn wer kümmert sich nach Jahren um evtl. still gelegte Verbindungen, die aber als Linien weiterhin in der DB enthalten sind?
...
Also Funkstellen, sind ja irgendwas was man sehen kann (auf Gebäuden, Türmen etc.), ja - die Verbindungslinien definitiv nein.

Du sprichst mir aus der Seele 🙂
+100

Moin,

bahnpirat möchte uns offenbar weder die Datenquelle nennen, noch über passende Datenformate reden.
Was sollen wir jetzt tun?
Die LWG um eine Prüfung bitten?
Lizenzfragen ignorieren und die Strecken gemäß der Mehrheitsmeinung hier in Relationen umwandeln?
Wenn ja, mit welchen Tags? "type=link", "communication=microwave_link"?

Wenn, dann wäre es eher eine Sache für die DWG. Wir würden bei unklarer Lizenzlage die Daten reverten oder redacten, wenn wir auch keine klaren Infos bekommen. Wenn ihr der Meinung seid, dass die Community in dem Fall nicht weiter kommt, sagt mir Bescheid (hier im Faden oder anderweitig) oder halt direkt der DWG.

Für das Tagging hatte ich recht weit oben ja schon vorgeschlagen, die Sender/Empfänger als Node zu erfassen mit den ganzen Eigenschaften und die Verbindung über eine Relation zu machen. Welche Eigenschaften wie in Taggs gegossen werden, darum sollte sich jemand kümmern, der von der Thematik Ahnung hat (typischerweise der Eintrager 😉 ).

seawolff wrote:

bahnpirat möchte uns offenbar weder die Datenquelle nennen, noch über passende Datenformate reden.
Was sollen wir jetzt tun?
Die LWG um eine Prüfung bitten?
Lizenzfragen ignorieren und die Strecken gemäß der Mehrheitsmeinung hier in Relationen umwandeln?
Wenn ja, mit welchen Tags? "type=link", "communication=microwave_link"?

Von ganz wenigen Ausnahmen - vorallem Verwaltungsgrenzen - abgesehen, gilt für OpenStreetMap der Grundsatz der Überprüfbarkeit. Ich muss mich als Mapper vor Ort davon überzeugen können, dass das, was da eingetragen ist, auch stimmt. Inwieweit dieses "überzeugen" mittelbar sein darf, ist manchmal umstritten - z.B. bei einer nicht direkt ausgeschilderten, aber in öffentlichen Unterlagen vorhandenen Fahrradroute gibt es Leute, die sagen: Man kann vor Ort nicht direkt sehen, dass die Fahrradroute hier lang geht, aber man kann beim Tourismus-Amt anrufen, und die bestätigen einem das dann.

Je schwieriger die Überprüfbarkeit ist, desto weniger können wir die Daten in OSM gebrauchen.

Schon deshalb muss bei so etwas wie einer Richtfunkstrecke, wenn man sie überhaupt mappt, mit angegeben sein, woher die Daten kommen (und wie man das also überprüfen kann).

Bye
Frederik

'abend, heute mal ernst

Also, die ehemaligen Richtfunkstrecken der Telekom betreibt schon seit mehreren Jahren die Fa. Ericsson (Sw)
Das sind also die großen Richtfunkverbindungen von Telekom-Türmen aus ( z.B. Colonius Köln )
Auch gibt es noch sehr viele 2 MBit Verbindungen zu den zahlreichen kleinen Türmen für Telekom/Mobilfunk.
Ich kann euch versichern, das diese Verbindungen 100% nicht für OpenSource zur Verfügung gestellt wird.
Mein Beitrag, der Ausbreitungsbedingungen von Rifu-Verbindungen war ernst gemeint.
An der Empfangsantenne kommt nur ein Bruchteil der Sendeleistung an. Alles andere verschwindet im "Raum".
Ich denke, die OSM kann dieses Vorhaben in keiner!!!! Weise erfassen.
Wie gesagt, ich bin ehemaliger Rifu-Techniker. Daher schließt bitte diese Diskussion ganz schnell. Danke.

Rogehm wrote:

Daher schließt bitte diese Diskussion ganz schnell. Danke.

Warum schließen? Solche Probleme werden hier ausdiskutiert und gegebenenfalls beseitigt. Da hat OSM nichts zu verbergen.

Deine Info zur eventuell kritischen Lizenzsituation sollte jetzt sogar ein energischeres Vorgehen erfordern. Wenn das stimmt, haben mMn noch nicht einmal in Relationen umgewandelten RFS eine Daseinsberechtigung. Wird Zeit, daß unser Kollege sich endlich wieder meldet.

Gruss
walter

ps: Meine "Zustimmung" am Anfang des Threads bezog sich auf die Annahme, dass die Lizenz ok sei.

Oha, Bahnpirat. Hier befindet der Kollege sich in einem großen Irrtum, wenn er denkt, alle Richtfunkverbindungen vom FMT Münster aus eintragen zu dürfen.
Erstmal ist der "operator" keinesfalls die Deutsche Telekom, nur der Turm selbst wird noch von einer Tochter der Telekom betrieben. Der Betreiber des Rifu ist Fa. Erriccson.
Außerdem sieht man viel zu viele Richtfunkverbindungen. Das könnte der Stand von 2000-2004 sein. Damals gab es sehr viele Rifu-Strecken. die meißten sind abgebaut.
Hier muß tatsächlich Einhalt geboten werden. Die Deutsche Telekom hat bestimmt kein Interesse, hier einen Rechtsstreit anzufangen. Da ich im "selben Verein tanze", gehe ich davon aus, das diese "Warnung" ankommt und richtig verstanden wird. Nochmal: Die Deutsche Telekom betreibt nur noch ganz lokal und vereinzelt Richtfunk (T-Mobile). Das große Geschäft wurde schon 2004 outgesourct. Nachtrag: Ab 2004 Der "Verkauf" des Rifu Netzes von Telekom an Fa. Ericsson erfolgte erst 2007 nach langen Verhandlungen.

Rogehm wrote:

Oha, Bahnpirat. Hier befindet der Kollege sich in einem großen Irrtum, wenn er denkt, alle Richtfunkverbindungen vom FMT Münster aus eintragen zu dürfen

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.

Je schwieriger die Überprüfbarkeit ist, desto weniger können wir die Daten in OSM gebrauchen. --woodpeck

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.

Erstmal ist der "operator" keinesfalls die Deutsche Telekom, nur der Turm selbst wird noch von einer Tochter der Telekom betrieben. Der Betreiber des Rifu ist Fa. Erriccson. --Rogehm, bezogen auf den Fernmeldeturm Münster

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. 😉

bahnpirat wrote:

so wenig sie auch den normalen Kartenbetrachter oder Mapper in seinem Alltag beeinflussen/behindern

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

...Und dann willst Du uns weismachen, das zusätzliche Elemente die sonstige Arbeit nicht behindern?

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.... 🙁

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

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

Rogehm wrote:

Im Prinzip könnte man auch Rifu-Strecken eintragen. Aber dies kann auf keinen Fall ohne Zustimmung des Betreibers erfolgen.

-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 … verbindung

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

brogo wrote:

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.

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

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).

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:

Rogehm wrote:

microwave:bandwith=155 (Rifu Signal Bandbreite hier:155 MBit/s)

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)

Rogehm wrote:

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. ;-) 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 🤔

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 ;-)

free_as_a_bird wrote:

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

Das liegt aber auch daran, dass die Tags sehr konfus sind und keiner wirklich durchblickt und anscheinend der Wikipedia-OSM-Layer nur man_made=communication_tower rendert, das andere aber nicht. (Die Hauptkarte rendert keins von beiden...)

saerdnaer wrote:

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

Keine so schlechte Idee ein neues Projekt zu straten. Nur Network lässt sich in dem Fall auf vieles anwenden. Vllt "OpenCommunicationMap". Da wären wir in der richtigen Richtung.
Dargestellt würden dann alle Objekte mit Bezug zur Kommunikation, wie Masten, Funkstrecken, Verteiler stationen, ect..

Prince Kassad wrote:

Das liegt aber auch daran, dass die Tags sehr konfus sind und keiner wirklich durchblickt

Full ack 😄

Prince Kassad wrote:

Die Hauptkarte rendert keins von beiden...

Masten werden auch auf der Hauptkarte gerendert, allerdings erst auf Zoomstufen >= 17.

free_as_a_bird wrote:

Masten werden auch auf der Hauptkarte gerendert, allerdings erst auf Zoomstufen >= 17.

Die OpenTopoMap rendert Türme und Masten schon auf kleineren Zoomstufen, weil es prima Landmerkmale sind.

derstefan wrote:

Die OpenTopoMap rendert Türme und Masten schon auf kleineren Zoomstufen, weil es prima Landmerkmale sind.

Ja, da hast du recht. Mir ist bloss aufgefallen, die map wird nur ca 1*jährl. upgedatet. Oder nicht?
Das sehr unterschiedliche tagging der Funkstandorte liegt wohl hauptsächlich an der stiefmütterlichen Behandlung aller Maps dieser doch in der Landschaft markanten Punkte.
Eigentlich sieht jeder Wanderer schon von weitem diesen oder jenen Funkturm, deren Höhe meißt zwischen 30-60 m liegt.
Natürlich, wenn diese Punkte in fast keiner Karte erscheinen, ist die Bereitschaft, diese ordnungsgemäß zu taggen, gen 0 tendierend.
Das einiges weiter oben beschriebene Darstellen der Antennen an diesen Standorten wird wohl erst mal Wunschtraum bleiben.
Eigentlich ist das ja hauptsächlich ein 3D Ding. Die Funkmasten könnten durchaus erstmal einheitlich mit einem Durchmesser von 1m und einer Höhe von 40m. dargestellt werden. Den Mappern ist es nicht zuzumuten, das alles händisch zu taggen, weil die Standorte meißt abgesperrt sind und man nicht Maß nehmen kann.
Allerdings gibt es meißt kleine Technikgebäüde und auch Outdoorgehäuse, die dazu gehören. Auch hier wird nirgendwo was gezeichnet.
Apropos Outdoorgehäuse, da hab ich noch einiges an Diskussionsbedarf. Auch innerstädtisch.

Gruß Rolf