Blitzer erfassen; muss es eine Relation sein?

oje… ich sehe gerade, dass im Kanton Fribourg, Waadt und Bern einige Blitzer noch gar nicht eingetragen sind… seufz… Habe gerade heute abgeklärt, ob man einen bestimmten Datenbestand in OSM importieren dürfte (damit wären die Blitzer in meiner Gegend wohl allesamt abgedeckt gewesen). Aber leider lässt das Nutzungsrecht diesen Import nicht zu. tja… Dann werde ich wohl in nächster Zeit wieder vermehrt auf die Blitzer achten (und weiterhin eine separate Datei mit allen Blitzern in Navit nutzen).

Nahmd,

Ich kann minZoom und limit= rausnehmen. Dann tötet es Deinen Browser.

Was für Relationen? Ich habe Punkt-Features, Line-Features und Area-Features. Wodurch die in den OSM-Rohdaten repräsentiert werden? Who cares! Ich denke nur noch in “Features” und habe mich vom Denken in Geometrien (node, way, relation) verabschiedet. Alle Features haben einen Center-Point, und nur am ersten Zeichen der unifizierten Id kann man erkennen, was dahinter steckt.

Wer eine Karte rendert, der weiss, dass die Rohdaten aus der Datenbank aufbereitet werden müssen, bevor man sie nutzen kann. Ich finde es erstaunlich, dass man bei POI-Karten erwartet, anzeigefertige Daten vom Rohdaten-Server abrufen zu können.

Und es ist eine Schande, dass ein geniales Teil wie der Overpass-Server immer wiederholt mit komplexen Anfragen belastet wird zu Daten, die sich kaum jemals ändern. Nehmen wir die Blitzer, nehmen wir das gestern laufende Thema der Autobahnauffahrten. Beides sind fast statische Datenbestände, und für beide ist eine tägliche Aktualisierung mehr als ausreichend. Und schon spielt der Rechenaufwand zur Erstellung der POI-Listen praktisch keine Rolle mehr.

Bei den Autobahnabfahrten hab ich mir mal den Spaß gemacht und alle Übergangspunkte vom “normalen” Straßennetz zum Autobahnnetz suchen lassen: die Abfrage lief zwar mehrere Minuten, dafür hab ich jetzt ein korrekt gerechnetes Ergebnis, das man lokal vorhalten und mit dem man eine Seite versorgen kann. Ohne andauernd den OP damit zu belasten.

Also zusammengefasst: ich bin für das jeweils angemessene Komplexitätslevel. Relationen sind weder die Silberkugel zur Lösung aller Probleme noch der Inbegriff des Bösen.

Jetzt aber zu den Enforcement-Relationen: da stimme ich Dir zu, dass man auf die meisten verzichten könnte.

Ich muss da ein bisschen weiter ausholen: vor geraumer Zeit habe ich mich über einen Forenbeitrag von Nop geärgert, in dem er schrieb, dass er Wanderwegweiser auf den Weg stellt und nicht daneben. Ich hab aber nichts gesagt, sondern stattdessen nachgedacht (yeah!) mit dem Ergebnis: er hat recht.

Begriffsdefinition: bei Möblierung entlang von Straßen und Wegen unterscheide ich zwischen “am Straßenrand” und “neben der Straße”. Ein Verkehrsschild, eine Ampel, eine Bank am Wegesrand, eine Bushaltestelle: sie liegen am Straßenrand. Der Jägersitz ein paar Meter neben der Straße liegt zufällig neben der Straße oder dem Weg und hat nichts damit zu tun.

Ich denke, dass Objekte, die am Straßenrand liegen, als Nodes in den Weg aufgenommen gehören:

  • Strukturelle Zusammenhänge sollten nicht durch eine “liegt in der Nähe”-Suche gefunden werden müssen. Die ist extrem aufwendig und dabei fehleranfällig.

  • Wenn ein Objekt (Ampel, Wegweiser, Verkehrsschild) sich auf den Weg bezieht, dann soll es entweder Bestandteil des Weges sein (als Node im Way) oder durch eine Relation an den Weg angebunden sein. Es soll sich also durch eine exakte DB-Abfrage finden lassen und nicht eine NEAR-Suche erfordern.

  • Die Position neben der Straße ist meist zufällig gewählt: ich hab schon eine Bushaltestelle auf einem Friedhof gefunden und eine Bank 40m vom Weg weg im Wald. Offensichtlich werden die Objekte in einer gefühlten Entfernung vom Way plaziert, und je nach Zoomlevel beim Editieren kann das auf der Fahrbahn sein oder auf der anderen Seite des Tales.

  • Oder die Objekte werden, da die Straßen und Wege auf Karten überbreit dargestellt werden, absichtlich zu weit entfernt platziert, damit sie OMMMMM nicht auf den Weg gerendert werden.

Mein Vorschlag für Objekte am Straßenrand:

  1. in den Weg einbauen.
  2. die “Wirkrichtung”, so es eine gibt, angeben mit “direction=”.
  3. die Lage relativ zur Straße angeben, zum Beispiel als “position=N/NE/E/SE/S/…”

Wer die “Wirkung” der Objekte braucht zum Beispiel zur Routenplanung, bekommt sauber alle Daten, die er braucht, mit einer einfachen Anfrage ohne Suchen.

Wer das Objekt in eine Karte rendern will, weiß wie breit er die Straße rendert, und kann das Icon des Objektes in die durch “position=” angegebene Richtung±90° senkrecht zum Verlauf der Straße verschieben soweit, dass es perfekt am Straßenrand liegt. Optional noch den Wert aus “direcction=” benutzen, um das Icon geeignet zu drehen.

Das wäre ein kleiner Schritt in Richtung Generalisierung, ein Thema, bei dem OSM hinter den Profis noch weit hinterherhinkt.

Btw: ich halte im übrigen überhaupt nichts von der “forward” und “backward”-Notation und bin ein Anhänger von “direction=” mit Kompassrichtungen oder Gradzahlen. Die forward und backward sind mir zu fragil: beim Umdrehen eines Weges die Frage von JOSM falsch beantwortet, und ooops! ein Falschinfo in der Datenbank.

Das eventuelle Argument “Performance” zieht nicht: ob ein Feature vorwärts oder rückwärts wirkt, braucht keine Winkelfunktion zur Auswertung: es reicht die Abfrage, ob das Skalarprodukt zwischen Wirkrichtung und Wegrichtung positiv oder negativ ist.

Und damit zurück zum Blitzer: ein Punktfeature auf dem Weg mit Angabe von maxspeed, direction und position, und alle haben mit minimalem Aufwand alles, was sie brauchen.

Ich danke für die Aufmerksamkeit.

Wolf

PS: wenn ich hier schreibe “gehört so”, so bedeutet das natürlich nicht, dass ich bereits getaggtes Material umtagge. Ich habe Respekt vor der Arbeit anderer. Deshalb kotzen mich auch all die Prinzipielreiter an, die ohne Rücksprache mit voller Absicht die Arbeit anderer zerstören. So wie zuletzt mit meiner Alpenvereinseinteilung geschehen. Ihnen möge der Himmel auf den Kopf fallen.

Nahmd,

Nicht dass Du Dich umsonst sorgst: ich habe nach Süden nur den Bereich bis 47.26° im Datenbestand.

Gruß Wolf

+1

Nahmd,

Du hast eines übersehen: es gibt noch kein “position=”.
Wer sowohl die Position des Blitzers als auch die Wirkung erfassen will, dem bliebt nichts anderes über als…

Also schreib ein Proposal für “position=”. Meinen Text darfst Du gerne verwursten. :sunglasses:

Gruß Wolf

Nahmd,

Und wo ist der CSV-Download? :stuck_out_tongue:

Gruß Wolf

danke. ich habe aber die andere Karte angeschaut. Und dort habe ich gesehen, dass einige fehlen.

Und was machst du mit einem Blitzer, der

  • auf die Strasse gerichtet ist (da wird ja auch zu schnell gefahren :wink: ),

  • auf dem footway=sidewalk als barrier=* erfasst werden muss (versperrt den Fussweg sehr deutlich) und

  • Zwischen Strasse und Wartebereich einer Bushaltestelle ist (also highway=bus_stop - Blitzer und barrier=* - Strasse)

und dabei der Zusammenhang nicht verloren gehen soll?

Dabei helfen jetzt ja zum Glück “hochauflösende” Luftbilder (solange man nicht im Wald ist…)

mfg~ray

Nein!

Es gibt auch Rotlicht-Kameras, die wir von Geschwindigkeits-Kameras unterscheiden wollen (enforcement=traffic_signals) … und möglicherweise weitere …

Z.B. diese hier ist ein Rotlicht-Blitzer - wieso steht dort speed_camera? und welche maxspeed würdet Ihr da eintragen?

Wäre hier vielleicht statt highway=speed_camera besser highway=enforcement (als neues Tag) angebracht? (Ist erstmal irgend ein Blitzer - den Zweck sieht man im enforcement=*).

Franz

Zum Beispiel einen Blitzer, der alles was da vorbeikommt erfasst und wenn das Kennzeichen nicht in der Liste der Anwohner ist wird ein Strafzettel verschickt (ich weiss leider nicht mehr wo das war)?

Für beide Beispiele ‘0’ :stuck_out_tongue:

Da wäre maxspeed=none (=keine überprüfte Beschränkung) eher angebracht.
bei maxspeed=0 müsste jeder, der sich dort bewegt, geblitzt werden, da seine Geschwindigkeit ja größer als die eingetragene Messschwelle ist. :wink:

Edbert (EvanE)

Ist doch auch richtig so: Was schneller als 0 km/h ist wird erfasst. Im einen Fall immer, im anderen nur Zeitweise, in beiden Fällen jedoch afaik nicht bei negativer Geschwindigkeit(?, ich werde so selten geblitzt).

mfg~ray

Moin Franz,

warum das so ist frag mal den Florian :wink: Ich habe gestern bei einigen Nodes die speed_camera ergänzt, aber nur wenn die Relation auf eine solche hindeutet. Das wird noch ein Tag für Rotlichtblitzer am Device einführen sollten das sich von den Flitzerblitzern unterscheidet sehe ich auch so. Die sind mir sogar wichtiger weil hinterhältiger.

LG,

-moenk

Bitte nichts einführen. enforcement:traffic_signals ist schon das Tagging für Rotlichtblitzer. Man muss nur schauen, wo es solche Kombinationen wie von FvGordon angeführt gibt. Die sollten bereinigt werden. Aber erfunden werden muss nichts mehr.

Thomas,

es gibt nur ein Tag für die Relation, am Device ist nichts vorgesehen. Damit fallen einfache POI-Abfragen aus und es macht auch den Eintrag eines Blitzers für Anfänger schwierig, die nur einen Rotlicht-Blitzer als Punkte eintragen wollen. Ich sehen das so, dass ein Tag analog zu highway=speed_camera für das Device her muss. Hier kann man natürlich nicht highway=traffic_light verwenden, weil das eine Ampel sein sollte und nicht das Blitzer-Device.

LG,

-moenk

Nachtrag: Das richtige Tag ist gefunden - highway=red_light_camera wird verwendet, fehlt aber oft.
Als Quelle dass sich so ein Ding wirklich so nennt: http://en.wikipedia.org/wiki/Red_light_camera

“Wird verwendet” ist jetzt aber bei 7-fachen Vorkommen weltweit eher relativ… (2 davon in D)

Da sollte man vielleicht auf der Mailinglinste Rücksprache halten ob das im Sinne des Erfinders ist, das Tagging dahingehend zu erweitern (inkl. wiki-Seiten), bevor hier losgestartet wird - auch wenn ich prinzipiell Befürtworter einer solch klaren Definition bin, sollten wir uns dann schon noch an die OSM-Spielregeln halten… :wink:

Thomas,

dann mach mal. Für die Mühlen der OSM-Bürokratie bin ich zu doof. Wir diskutieren doch hier schon. Und überhaupt, ist das nicht völlig oldschool über neue Tags noch lange zu diskutieren? Ich habe überhaupt kein Problem damit, eine der diversen Notes aus der Katgegorie “dies soll ein Rotlichblitzer sein” in ein aussagekräftiges Highway-Tag zu ändern. Das war das was der Mapper damit sagen wollte und nur hilfloserweise nicht wusste wie er es machen sollte. Doof nur an dem Highway-Tag, dass es auch für die Ampel verwendet wird und als Device oft der Node der Ampel verwendet wurde. Kein Ding, dann mappen wir eben mit zwei Attributen und Semikolon. Mal gucken was der Renderer davon macht :wink:

LG,

-moenk

Ja, was der Renderer macht ist das Eine - und dass du morgen sagst, dass du das mit der API nicht abfragen kannst, das andere. Also: No go!

Somit: Mailingliste (dies wird immer vom Initiator erledigt - nicht von einem vom Initiator zu bestimmenden Handlanger).

Was haltet ihr vom key “traffic_controll” statt “highway” um speed_camera usw. zu erfassen, damit das bei highway verschwindet :confused: