Anregung: Wege-Beleuchtung als Routing-Option?

Communities Deutschland (Germany)
#1

Hallo zusammen,

kurz vorweg: ich habe zwar seit Jahren ein OSM-Account, bin aber kein wirkliche aktiver User. Es ist eine sehr interessante Sache, finde bisher aber keine Zeit, mich intensiv und dauerhaft mit Änderungen, Ergänzungen und dergleichen zu beschäftigen.

Daher nutze ich sporadisch StreetComplete, wenn mir etwas auffällt. Hier wird auch die Straßenbeleuchtung abgefragt. Wäre es nicht ein Projekt, diese Daten für Routing-Optionen für Radfahrer und Fußgänger nutzen zu können? Oder anders gefragt: gibt’s das irgendwo schon? Auf openrouteservice hab ich das zumindest nicht gefunden.

Ich komme darauf, weil sich meine Tochter gestern im Dunkeln mit Goolge :roll_eyes: (ja: selbst schuld) mit dem Rad interkommunal navigieren hat lassen und dabei natürlich nicht auf die etwas weitere, dafür aber beleuchtete Alternative geschickt wurde.

#2

Schöne Idee!

Man sich sowas mit BRouter zusammen bauen, wobei natürlich irgendwie cool wäre, wenn man einfach einen Schalter hätte “beleuchtet bevorzugen”.

Bei BRouter hatte ich zum Ausprobieren eben mal im Trekking-Profil nach Zeile 213 folgendes eingefügt:


multiply ( if lit=yes then 1 else 100 )

Das ist im Teil des Profils, welches im way-Kontext den costfactor zuweist und multipliziert mit den danach ermittelten Kosten abhängig von highway=/tracktype=/…

Der Faktor 100 ist schon relativ hart (grob gesprochen: Der beleuchtete Weg darf bis zu 100 mal länger sein, als der unbeleuchteter Weg) ;).

Sinnvoller ist eventuell eine Unterteilung nach Weg-Arten (besser wäre noch nach der Flächennutzung die den Weg umgibt zu unterscheiden, aber die Information ist, glaube ich, in BRouter nicht für die Kanten vorhanden), vielleicht sowas wie


multiply ( if lit=yes then 1 else 
  switch highway=residential 10
  switch highway=path 5
  switch highway=cycleway 2 100
)

Multiplikativ behält die nachfolgende Wertung bei, was Additiv nicht machen würde – Additiv würden eigentlich erwünschte Wege überproportional bestraft – kann man natürlich auch als sinnvoll erachten (“Mir ist die beleuchtete Bundestraße lieber als der unbeleuchtete Radweg”). Whatever… Raum zum spielen ist da viel ;). Ich freue mich, bald hier ein super Profil für “beleuchtete Wege” zu sehen! :slight_smile:

Vielleicht hat noch jemand eine Inspiration wie man den unbeleuchteten Wald und das Industriegebiet stärker bestrafen kann, als das offene Feld? :slight_smile:

[Edit: Typo]

#3

In der Stadt sind je zwei Laternen so typischerweise alle 35m voneinander entfernt; in Richtung der Landkreisgrenzen geht die Positions- und Leuchtdichte immer weiter runter, das obere Ende sind Pilzleuchten mit Leuchtmittel aus dem letzten Jahrtausend in 80m Abstand zueinander.
Das Tagging mit lit=yes ist somit sehr unspezifisch, und ein bisschen so merkwürdig wie highway=trunk (in D heißt das: kreuzungsfrei) für eine Straße mit Kreuzungen zu vergeben und zu behaupten, dass sei ja trunk immer zwischen zwei Ampeln.

#4

Klar ist lit=yes relativ unspezifisch für manche Anwendungen, aber es ist eine sehr robuste Auszeichnung mit hohem Informationsgehalt: Jeder hat eine Vorstellung zur Bedeutung, was es mMn sehr unanfällig für wirklich schlechtes Mapping macht und gleichzeitig ermuntert das, es einzusetzen. Das ist mEn deutlich mehr wert, als sich in jede Spezialanwendung zu verlieren und am Ende keine flächendeckenden sinnvollen Daten zu haben.

Einzelne Straßenlaternen zu mappen hilft für die Routing-Anwendung bspw. nur sehr marginal – vor allem, wenn dann zwar die Straßenlaternen mit Operator und Leuchtmittel, Höhe und Material gemappt werden, die Straße daneben aber ‘dunkel’ bleibt, weil dort lit=* nicht gesetzt ist [1]. Kommt wirklich überraschend häufig vor[2].

Natürlich gibt es Unterschiede in der Beleuchtung; ich glaube fast, dass das auch so gewollt ist: Die Augen gleichen einen hohen Umfang an Helligkeitsunterschied aus – da wäre es aus meiner Sicht kontraproduktiv, jeden Feldweg so hell auszuleuchten wie die Stadt.

Aber eigentlich ging es hier im Thema auch gar nicht darum, wie gut oder schlecht lit=* ist, sondern darum, wie man die vorhandenen Daten ins Routing einbeziehen kann :).

BRouter berücksichtigt übrigens nur lit=yes (siehe lookups.dat), sodass man die übrigen im Wiki angegebenen Werte nicht verwenden kann. :confused:

Grüße
t.

[1] Stichwort Router: Die Laternenknoten sind natürlich nicht Teil der Ways, sodass sie auch nicht im Routing-Graphen auftauchen. Wer fordert, dass die Router das doch irgendwie “sehen” könnten, wenn man das nur mal gescheit programmieren würde, der sei auf das (im Vergleich) einfachere Problem der Zuordnung separat gemappter Gehwege verwiesen, welches sich schon nicht einfach lösen lässt.

[2] Genau genommen habe ich gerade auf die schnelle keine Stadt gefunden, in der alle Straßen für die Straßenlaternen gemappt waren auch mit lit=* ausgezeichnet waren.

#5

Nu in Deiner Lösung musst Du noch irgendwie mit dem Konsistenzproblem.umgehen.

Der Ansatz “kein lit tag = keine Beleuchtung” ist jedenfalls etwas hart. Vielleicht schaffst Du resistential Strassen ohne lit tag den Kostenfaktor 1,5 zuzuweisen und den anderen Strassen ausserorts 3 - das Siedlungsstraßen beleuchtet sind ist ja wahrscheinlicher als andere Strassentypen

#6

Es gab mal eine lit-Karte, wo Straßen und Laternen dargestellt waren. Habe sie aber nicht mehr gefunden.

#7

Ich kenne die Lichtkarte, die aber seit Jahren nicht mehr aktualisiert wurde, und dann gab es u. a. dazu eine QS-Karte von itoworld, die leider alles eingestampft haben.

#8

Oh ja, das müssen wir wohl noch irgendwie :).

Vor allem ist die 100 hart :D. Ich habe meine Handreichung eher als Zutaten-Liste verstanden; danke aber für deinen Input. Für Außerorts habe ich spontan vor allem unclassified als ‘Nachts zu meiden’ im Wiki ausgemacht.

Mir ist noch aufgefallen, dass man das source:maxspeed-Tagging, bzw. maxspeed heranziehen kann, um Innerorts/Außerorts zu unterscheiden. BRouter’s lookup beinhaltet allerdings leider kein source:maxspeed, immerhin maxspeed=urban kann man aber verwenden und Tempo-30 kommt Außerorts vielleicht auch nicht so häufig vor.

Damit sähe der Code in etwa so aus:


multiply ( if or lit=yes not nightdriver then 1 else 
  switch isresidentialorliving 1.5
  switch cycleway=cyclestreet or bicycle_road=yes 1.5
  switch maxspeed=urban|30 1.5
  switch highway=unclassified 3 2
)

Um das in einem Profil zu verwenden siehe Anmerkungen in meinem ersten Post und füge irgendwo oben


assign nightdriver = true

ein.

Erläuterung:
Ein beleuchteter Weg ist ‘ideal’, verursacht also keine Mehrkosten.

  • residential, wie auch Fahrradstraßen werden wohl halbwegs häufig halbwegs gut beleuchtet sein, weil innerorts

  • wenns innerorts “gescheites” Tempotagging gibt, dann werte das mal so wie highway=residential

  • unclassified ist doof (kleinere, schlecht ausgebaute Straßen außerorts)

  • wenn davon gar nichts zutrifft: Faktor 2

Auch das dürfte noch etwas hart sein, wenn man bedenkt, dass statt einer 1km unclassified-Straße ein 3km beleuchteter Weg genommen würde. Wahrscheinlich muss man die Faktoren also noch etwas stauchen um das auch noch fahren zu wollen.

@KaOb, vielleicht magst du ein dir vorschwebendes Beispiel in die Runde werfen, mit welchem wir mal testen könnten…? :wink:

Ich treffe hier ein paar Annahmen über Innerorts und Außerorts und freue mich, wenn Leute mit mehr Wissen über das benutzte Tagging da im Zweifelsfall kurz einhaken und meine Annahmen berichtigen :).

[EDIT: assign nightdriver und isresidentialorliving eingebaut]

#9

Als Abhilfe hier eine schnell zusammengebastelte Overpass-Abfrage, die zumindest die Laternen in 10m Umkreis zu einer lit=yes Straße ausfiltert. Geht bestimmt schicker und besser.

#10

Ich sabbere fast, weil die Jungs hinter brouter.de/brouter-web einfach so großartig sind :).

Mit folgendem Code


assign nightdriver = true # %nightdriver% | Fahre nachts? | boolean

erscheint im “Optionen”-Reiter dann ein Haken mit dem man, wenn wie oben beschrieben dieser multiply-Teil ins Profil eingebaut ist, schnell und einfach zwischen ‘lit=’-Routing und normalem Routing umschalten kann.

#11

Man könnte im Routingalgorithmus zunächst jeden Laternenknoten mit einem trivialen Quadrat (z.B.) 20x20m logisch ausstatten, dann im 2. Schritt Highways, die durch ein solches Quadrat verlaufen, logisch splitten, um dann Gewichte zuweisen, je nachdem, ob sie in oder außerhalb der beleuchteten Zone liegen. Step 3: Mit diesem Set an (High-)Ways nun das “normale” Routing durchführen.

Ich kann mir vorstellen, dass das Ergebnis richtig gut werde, ohne grübeln zu müssen, ob eine Straße (auch subjektiv!) “hell genug” ist, um ihr das Prädikat “lit=yes” zu überreichen oder nicht.

#12

Klingt interessant, auch wenn ich, vielleicht Berufsbedingt, Stolperstellen sehe; wie wäre es mit einer Referenzimplementation? Vielleicht auf Rostock begrenzt, dort sind etwas über 20.000 Straßenlaternen gemappt, das klingt (für mich, ohne näher draufgeschaut zu haben) nach einer soliden Datenbasis. Mit Sechsecken lässt sich übrigens auch prima eine disjunkte Überdeckung bauen.

Subjektiv ist auch die Entscheidung von 20x20m, die Gewichte, … :slight_smile: in deinem Vorschlag. Das wenig subjektive “ein Weg hat eine (dedizierte) Beleuchtung” für lit=yes finde ich zunächst mal einen großen Informationsgewinn. Jemand aus dem Straßenbau wird das aufgrund sicher existierender Verordnungen sicher anders sehen, aber bevor die OSM sich auf Spezialanwendungen stürzt, wäre doch ein flächendeckendes Tagging für 0815-Nutzen, wie den des Threaderöffners, prima.