Blitzer erfassen; muss es eine Relation sein?

Finde ich gut. Wir mappen zwar die Realität, aber eine Karte ist immer auch eine Vereinfachung der Realität. Bei einem Verkehrsschild zur Geschwindigkeitbegrenzeung wird auch meist nicht das Schild selt gemappt, sondern es wird ein maxspeed an den Way geheftet. Daher finde ich es analog auch richtig für einen Blitzer einen Node am Way zu erstellen, statt daneben und dies dann in Beziehung (um das Wort Relation zu vermeiden) zum Way zu setzen, zwecks Richtungsangabe.

Gruß
unixasket

hurdygurdyman wrote:

Wie Ampeln werden Blitzer grundsätzlich als node auf den überwachten way gesetzt (und nicht daneben, wo das Gerät steht)

An und für sich wird ja die Realität getaggt, somit "sollte" der Blitzer auch neben die Strasse gesetzt werden... eigentlich.
Auch wenn ich dieses Taggingschema einigermassen gut finde, bin ich dennoch grundsätzlich für Relationen. Schliesslich kann man in einer enforcement-Relation mehr Infos unterbringen als in einem Node.
Und z.b. bei einer Abschnittskontrolle (was bereits in x Ländern im Einsatz ist und zukünftig immer häufiger anzutreffen sein wird) bringt ein Node nichts, das müsste man dann schon an den Way setzen. Aber: Problem hier ist dann aber wieder, wenn eine Abschnittskontrolle über mehrere Ways (Beispiel ein Teil hat 2 Lanes, der andere Teil hat 3 Lanes) stattfindet. Wenn die maxspeed-Sachen dann an den Ways dran ist, ist es dann doch sehr schwierig auszuwerten, ob da nun 2 verschiedene Abschnittskontrollen sind, oder nur eine Kontrolle. Bei einer Relation ist dieses Problem nicht vorhanden.

efred wrote:

An und für sich wird ja die Realität getaggt, somit "sollte" der Blitzer auch neben die Strasse gesetzt werden... eigentlich.
Auch wenn ich dieses Taggingschema einigermassen gut finde, bin ich dennoch grundsätzlich für Relationen. Schliesslich kann man in einer enforcement-Relation mehr Infos unterbringen als in einem Node.
Und z.b. bei einer Abschnittskontrolle (was bereits in x Ländern im Einsatz ist und zukünftig immer häufiger anzutreffen sein wird) bringt ein Node nichts, das müsste man dann schon an den Way setzen. Aber: Problem hier ist dann aber wieder, wenn eine Abschnittskontrolle über mehrere Ways (Beispiel ein Teil hat 2 Lanes, der andere Teil hat 3 Lanes) stattfindet. Wenn die maxspeed-Sachen dann an den Ways dran ist, ist es dann doch sehr schwierig auszuwerten, ob da nun 2 verschiedene Abschnittskontrollen sind, oder nur eine Kontrolle. Bei einer Relation ist dieses Problem nicht vorhanden.

Nun ja, die Wiki sieht ja hier http://wiki.openstreetmap.org/wiki/DE:R … _Verfahren weiterhin die einfache Erfassung von speed_camera als node vor. Mir geht es darum, soweit wie möglich auf eine enforcement-relation zu verzichten. Sicher wird es Fälle geben, bei denen dies nicht möfglich sein wird, aber nach pareto ( http://de.wikipedia.org/wiki/Paretoprinzip ) dürfte wohl für die Masse der Blitzer die vereinfachte Erfassung als node (edit: oder way für Abschnittskontrollen) ausreichen und somit dem Normal-Mapper entgegenkommen.

Soooo kompliziert finde ich die enforcement-Relation nicht. Ich bin also dafür das jetzige Schema beizubehalten und nicht noch
ein drittes einzuführen.

Chris

hurdygurdyman wrote:

Nun ja, die Wiki sieht ja hier http://wiki.openstreetmap.org/wiki/DE:R … _Verfahren weiterhin die einfache Erfassung von speed_camera als node vor.

ah o.k., wenn es nur um die "einfache Erfassung" geht, kann ich mich sehr gut mit diesem Taggingschema anfreunden. Ich hatte es so aufgefasst, dass es die Relationen komplett ersetzen sollte, was mir aber nicht passen würde, da ich selber doch weiterhin die Blitzer als Relationen erfassen möchte (sofern ich genaueres weiss über den Blitzer).

Ich sehe nur das Problem, wenn Mapper1 einen Blitzer als Node auf dem Way setzt und Mapper2 anschliessend es ändert auf einen Blitzer neben der Strasse mit Relation...
Jetzt gerade ist es ja so, dass bei beiden Varianten die Realität gemappt wird, also ein Blitzer-Node neben der Strasse. Wenn dann aber plötzlich bei einer Variante (einfaches Tagging) der Blitzer auf der Strasse getaggt wird und bei der anderen Variante (Relation) der Blitzer neben der Strasse (wie es in der Realität auch aussieht), könnte es dann zu Editwars führen (mit Revert, Änderung, Revert, Änderung) und dann mit riesigem Rumgeheule in den Foren und MLs...

chris66 wrote:

Soooo kompliziert finde ich die enforcement-Relation nicht. Ich bin also dafür das jetzige Schema beizubehalten und nicht noch
ein drittes einzuführen.

Chris

sehe ich auch so. die enforcement-Relationen sind ja wirklich einfach handzuhaben.

efred wrote:

sehe ich auch so. die enforcement-Relationen sind ja wirklich einfach handzuhaben.

Fred,

das ist aber schön, dass das so einfach ist. Machst mir mal grad eine Overpass-API-Abfrage für alle Blitzer in Deutschland?

LG,

-moenk

www.overpass-api.de/api/interpreter?data=[out:json];relation[enforcement="maxspeed"](47.7,13,47.9,13.1);out;

Bounding box für D bitte selber anpassen...

XAPI-Nachtrag:

http://overpass-api.de/api/xapi?relation[enforcement=maxspeed][bbox=13,47.7,13.1,47.9][@meta]

Moin,

btw: Vielleicht hat noch jemand sachdienliche Hinweise zu meinem kleinen SQL-Dings mit man aus einer PostGIS-Datenbank im Osmosis-Schema eine Enforcement-Tabelle erstellen kann?
https://github.com/moenk/osmosis-layers … cement.sql
Funktioniert soweit ganz gut. Wäre das wohl ok wenn man nun überall das fehlendende Tag "highway=speed_camera" ergänzt?

LG,

-moenk

Thomas,

haste das mal ausprobiert? Den XAPI-Kram lassen wir mal besser, den wollen die Overpass-Leute eher ungern weil er Ressourcen frisst, bleiben wir bei dem QL-Ding. Ich kriege dann zwar die Relationen, aber keine Liste mit Koordinaten der Devices, wie man sie dann für die POI-Datei brauchen würde.

LG,

-moenk

Dann frag doch einfach die nodes der devices ab.

Oder kannst du das auch nicht?

Thomas,

das ist mir nicht klar, wie ich das mit der Overpass-API machen soll. Allerdings habe ich gerade festgestellt, dass es mit den Relationen gar nicht mehr so übel aussieht. In einigen Fällen fehlt bei dem Device auch das Tag am Node, aber das war mal schlimmer. Die Thematik habe ich mir vor einiger Zeit das letztemal angeschaut, da hat wohl jemand was gemacht, vielleicht kümmer ich mich noch irgendwann mal darum. Wenn alle Device-Nodes zusätzlich "highway=speed_camera" getaggt sind solls mir recht sein, dann kann man die Nodes einfach abfragen.

LG,

-moenk

Wieder an meinem Standard-Beispiel:

www.overpass-api.de/api/interpreter?data=[out:json];node[highway="speed_camera"](47.7,13,47.9,13.1);out;

Klar ist es eine Frage der präzisen Eingabe beim Taggen - aber das Problem besteht bei einer Relation genauso wie bei einem simplen node... Wird da oder dort was falsch gemacht, klappt es nicht...

Thomas,

genau diese Abfrage der Nodes geht eben nur dann, wenn die Device-Nodes auch als speed_camera getaggt sind. Ich habe gerade einige Nodes gefunden bei denen dies nicht der Fall war und das Tag ergänzt. Nun sollte sich sehr einfach eine Radarwarner-POI mit der Overpass-API herstellen lassen. Für Anfänger sollte es völlig reichen nur die POI zu mappen, der ganze Relationsquark ist optional und steht es auch im englischen Wiki.

LG,

-moenk

moenk wrote:

Funktioniert soweit ganz gut.

Stimmt 😉

eine winzige Kleinigkeit: Ich frage immer so ab, ob ein tag im hstore existiert

alt:␣where␣r.tags->'enforcement'!=''
neu:␣where␣r.tags␣?␣'enforcement'

bringt zwar nix an Performance, erscheint mir aber übersichtlicher.

Gruss
Walter

Nahmd,

alle Blitzer in Deutschland?

Alle Blitzer in Deutschland.

Gruß Wolf

Eh klar - kommt der Wolf, kommt eine Komplettlösung... :-)

Wäre aber schon komplett vorhanden gewesen... ;-) http://frink.bplaced.de/blitzer/

Hallo,
Oh, Blitzer in Biebersdorf fehlt... Merke ich mir...

So ist das, wenn man Auswertekarten zu bestimmten Themen bekommt, und einem auffällt, was fehlt...

Danke,

Sven

Netzwolf wrote:

Alle Blitzer in Deutschland.Gruß Wolf

Wolf,

das sind genau genommen gar nicht alle - Du lädst immer nur einen Teil ein, nämlich wenn man im passenden Zoomlevel ist für diese Region. Oder ist da irgendwo noch ein versteckter Knopf oder Link der mit entgangen ist?

Aber Du zeigst sehr schön dass Du Relationen auseinanderfusseln musst um dann nur Punkte anzuzeigen. Ja, man kann das tun. Ist so wie mit den Polygonen, aber das ist ein anderes Thema.

LG,

-moenk

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,

moenk wrote:

das sind genau genommen gar nicht alle - Du lädst immer nur einen Teil ein, nämlich wenn man im passenden Zoomlevel ist für diese Region. Oder ist da irgendwo noch ein versteckter Knopf oder Link der mit entgangen ist?

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

Aber Du zeigst sehr schön dass Du Relationen auseinanderfusseln musst um dann nur Punkte anzuzeigen. Ja, man kann das tun. Ist so wie mit den Polygonen, aber das ist ein anderes Thema.

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,

efred wrote:

oje... ich sehe gerade, dass im Kanton Fribourg, Waadt und Bern einige Blitzer noch gar nicht eingetragen sind... seufz...

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

Gruß Wolf

Netzwolf wrote:

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.

+1

Nahmd,

moenk wrote:

Netzwolf wrote:

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.

+1

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

Gruß Wolf

Nahmd,

tunnelbauer wrote:

Wäre aber schon komplett vorhanden gewesen... ;-) http://frink.bplaced.de/blitzer/

Und wo ist der CSV-Download? 😛

Gruß Wolf

Netzwolf wrote:

Nahmd,

efred wrote:

oje... ich sehe gerade, dass im Kanton Fribourg, Waadt und Bern einige Blitzer noch gar nicht eingetragen sind... seufz...

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

Gruß Wolf

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

Netzwolf wrote:

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.
  

[...]

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/..."

Und was machst du mit einem Blitzer, der

• auf die Strasse gerichtet ist (da wird ja auch zu schnell gefahren ;-) ),
• 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?

Netzwolf wrote:

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

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

mfg~ray

moenk wrote:

Wäre das wohl ok wenn man nun überall das fehlendende Tag "highway=speed_camera" ergänzt?

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

FvGordon wrote:

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

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

FvGordon wrote:

und welche maxspeed würdet Ihr da eintragen?

Für beide Beispiele '0' 😛

rayquaza wrote:

FvGordon wrote:

und welche maxspeed würdet Ihr da eintragen?

Für beide Beispiele '0' 😛

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

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

FvGordon wrote:

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

Moin Franz,

warum das so ist frag mal den Florian ;-) 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... 😉

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

LG,

-moenk

moenk wrote:

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.

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

moenk wrote:

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

Was haltet ihr vom key "traffic_controll" statt "highway" um speed_camera usw. zu erfassen, damit das bei highway verschwindet 🤔

hurdygurdyman wrote:

Was haltet ihr vom key "traffic_controll" statt "highway" um speed_camera usw. zu erfassen, damit das bei highway verschwindet hmm

Eigentlich finde ich es nicht gut, wenn man einen etablierten Tag ändern möchte. Schliesslich müssen aufgrund solch einer Änderung dann all Renderer und Programme, die diese Tags auswerten, entsprechend geändert werden. Aber in solch einem Fall, würde es schon sinnvoll sein.
Mach doch diesbezüglich mal ein Proposal - mal schauen, was die Leute denken, die nicht hier lesen. Denn auch wenn man hier im deutschsprachigen Forum einen Konsens erreichen würde, heisst das noch lange nicht, dass auch die anderen es so sehen.

Renderer sollten damit keine Probleme haben, da es meines Wissens nach nur POI-Auswertungen (DB-Abfragen) gibt, welche diese Punkte darstellen - die wären leicht von einer Änderung zu "überzeugen". Aber nichts destototz sollten wir - wie du schon richtig schreibst - nicht nur den deutschen Sprachraum abdecken, sondern das Thema gezielt international und geordnet angehen - sonst haben wir gleich wieder Wildwuchs...

Moin Michael,

bevor wir mit einem neuen Hauptkey anfangen können wir besser vorhandenes auf den Device-Node setzen. Letztlich sind alle Knipskästen auch "man_made=surveillance" mit zusätzlich ""surveillance=red_light"", das ist ein Ansatz der mir besser gefallen würde. Im Wiki steht dann wieder so ein verkopfter Quark wie "Use Relation enforcement instead!", was aber an der Sache völlig vorbei geht, die Relation ist ja meinetwege für Elitemapper ganz schick, es geht ja nur um den Device-Node.

LG,

-moenk

Waren wir uns nicht einig, dass vor einer Änderung der offizielle Weg beschritten werden soll?

http://wiki.openstreetmap.org/wiki/Tag: … =red_light <<< Ich finde nix...

http://tagwatch.stoecker.eu/Planet-late … light.html <<< 1 (in Worten: eine) Verwendung weltweit gibt keinen Standard vor

Und jetzt das? http://www.openstreetmap.org/browse/changeset/14754758

Irgendwie glaubt da wer, dass er alleine osm ist...

Der Tag "surveillance" wurde bisher nicht in Zusammenhang mit Straßenverkehrsüberwachung im Sinne von Einhaltung StVO odgl verwendet....

Moins,

Was haltet ihr vom key "traffic_controll" statt "highway" um speed_camera usw. zu erfassen, damit das bei highway verschwindet 🤔

control vs. Kontrolle ist einer der false friends, auf die ich immer wieder hereinfalle.

Unter “traffic_control” könnte man Ampeln, schaltbare Geschwindigkeitsbegrenzungen und schaltbare Spurfreigaben (diese Grünpfeil/rot X-Anzeigen über der Straße) fassen. Blitzer gehören nicht wirklich zur "Steuerung" des Verkehrs.

Ich finde “enforcement” passend.
Gruß Wolf

tunnelbauer wrote:

Und jetzt das? http://www.openstreetmap.org/browse/changeset/14754758

sowas geht jetzt aber gar nicht... ich bin für einen Revert. Was meinen die anderen?

efred wrote:

ich bin für einen Revert. Was meinen die anderen?

+1

Das Tag man_made=surveillance ist klar als Videokamera definiert. So etwas gibt es auch im Verkehrsbereich, wenn nämlich Verkehrsbehörden/Polizei kritische Stellen beobachten. In Großbritannien sehr beliebt. Die bisher definierten surveillance-Untertags behandeln allesamt nur Videokameras.

Um so etwas handelt es sich bei Rotlichtblitzern ausdrücklich nicht!

Sehr rücksichtsloser Stil, einfach automatische Edits durchzuziehen. Und das sogar, obwohl im Vorfeld von anderen Mappern extra darauf hingewiesen wurde, dass es so nicht geht.

Netzwolf wrote:

Moins,

Was haltet ihr vom key "traffic_controll" statt "highway" um speed_camera usw. zu erfassen, damit das bei highway verschwindet 🤔

control vs. Kontrolle ist einer der fals friends auf die ich immer wieder hereinfalle.

Unter “traffic_control” könnte man Ampeln, schaltbare Geschwindigkeitsbegrenzungen und schaltbare Spurfreigaben (diese Grünpfeil/rot X-Anzeigen über der Straße) fassen. Blitzer gehören nicht wirklich zur "Steuerung" des Verkehrs.

Ich finde “enforcement” passend.
Gruß Wolf

Nun ja, "traffic-control" mag nicht genau genug sein, aber "speed_control" (siehe: http://www.dict.cc/deutsch-englisch/Ges … chung.html ) für Geschwindigkeitsüberwachung könnte hinkommen.

P.S.: So ganz teile ich deine Auffassung von false friends für control nicht: http://www.dict.cc/?s=Kontrolle , aber scrutiny wäre wohl am ehesten passend 🤔

@Moenk:

Willst du nicht auch was zu deiner nicht OSM-konformen Vorgehensweise sagen oder ist seit Neuestem dein Wort OSM-Rule?

Eine Stellungnahme diesbezüglich wäre durchwegs angebracht.

Ich verweise zusätzlich noch auf:
http://wiki.openstreetmap.org/wiki/Mech … dit_Policy
http://wiki.openstreetmap.org/wiki/Import/Guidelines
http://wiki.openstreetmap.org/wiki/Auto … of_conduct

und deren weiterführenden Seiten.

efred wrote:

sowas geht jetzt aber gar nicht... ich bin für einen Revert. Was meinen die anderen?

Moin,

ich hatte das im Wiki so gelesen:

http://wiki.openstreetmap.org/wiki/Tag: … rveillance
Da steht "approved", also das ist der aktuelle Stand wie es da steht.

http://wiki.openstreetmap.org/wiki/Prop … rveillance
Da steht "proposed", das ist mehr als man für andere Tags findet, die gängig sind. Was die blöde Streichung da soll und wer die da eingebracht hat ist mir übrigens nicht klar, der Vorschlag ist IMHO sinnvoll.

Ungeheuerlich dass ich mich anmaße diese Tags zu ergänzen! Nein, so eine Unverschämtheit aber auch! Das ist ja schon fast Vandalismus! Wenn Ihr es sinnvoller findet die zusätzlichen Tags nicht drin zu haben nehmt sie gern wieder raus. Alternativ könnt Ihr das auch erstmal ausdiskutieren und dann alles ändern, kommt vermutlich aufs gleiche raus.

Ich bin bisher davon ausgegangen dass mir so ein Kindergarten wie ich ihn sonst nur vom Geocaching kenne bei OSM erspart bliebe. Jetzt gehe ich erst mal in mich und beschäftige mich mit anderen Dingen.

Ihr könnt mit diesem Thema nun ohne mich weitermachen und ich werde ab jetzt die Blitzer direkt von Garmin empfehlen. So wie die Blitzer hier seit Jahren behindert wurden kann da auch kaum noch etwas sinnvolles bei herauskommen.

LG,

-moenk

Genau hier > http://wiki.openstreetmap.org/wiki/Prop … rveillance steht: Use relation enforcement.

Und bei http://wiki.openstreetmap.org/wiki/Tag: … rveillance finde ich keinerlei Verweis auf Verkehrsüberwachung im klassischen Sinne (Rotlichblitz, Blitzer)

moenk wrote:

ich hatte das im Wiki so gelesen:

http://wiki.openstreetmap.org/wiki/Tag: … rveillance
Da steht "approved", also das ist der aktuelle Stand wie es da steht.

Dem ist so. Aber es betrifft Webcams/Überwachungskameras, was nichts mit Geschwindigkeitsüberwachung zu tun hat.

moenk wrote:

http://wiki.openstreetmap.org/wiki/Prop … rveillance
Da steht "proposed", das ist mehr als man für andere Tags findet, die gängig sind. Was die blöde Streichung da soll und wer die da eingebracht hat ist mir übrigens nicht klar, der Vorschlag ist IMHO sinnvoll.

Die Streichung wurde bereits am 20.07.2010 vorgenommen, da es überflüssig ist. Was nicht mit einem simplen Node getaggt werden kann, kann mit einer Relation:enforcement gemacht werden, welches am 17.01.2009 angenommen wurde.

Wer macht denn nun den Revert für den unsachgemäßen Schmarrn? Oder findet sich keiner?

auch wenn ich mit diesem Massenedit nicht einverstanden bin, will ich dennoch noch keinen Revert machen. Wir sind nur 2, die sich hier imThread gegen dieses Vorgehen ausgesprochen haben. Von daher muss ich annehmen, dass die anderen wohl nichts gegen diesen Massenedit haben... tja...

Naja - hurdygurdy war nicht dafür, MetiorergoSum auch nicht und Netzwolf auch nicht - macht 5; und wenn 6 miteinander reden und 5 anderer Meinung sind, dann hat - denke ich - nur einer unrecht. Und der eine hat ja klar gegen geltendes OSM-Regelwerk verstoßen...

efred wrote:

Aber es betrifft Webcams/Überwachungskameras, was nichts mit Geschwindigkeitsüberwachung zu tun hat.

+1

tunnelbauer wrote:

Naja - hurdygurdy war nicht dafür, MetiorergoSum auch nicht und Netzwolf auch nicht - macht 5; und wenn 6 miteinander reden und 5 anderer Meinung sind, dann hat - denke ich - nur einer unrecht. Und der eine hat ja klar gegen geltendes OSM-Regelwerk verstoßen...

Bin auch nicht dafür.

Gruß,
Mondschein

tunnelbauer wrote:

Naja - hurdygurdy war nicht dafür, MetiorergoSum auch nicht und Netzwolf auch nicht - macht 5; und wenn 6 miteinander reden und 5 anderer Meinung sind, dann hat - denke ich - nur einer unrecht. Und der eine hat ja klar gegen geltendes OSM-Regelwerk verstoßen...

Ich bin ebenso dafür, den offiziellen Weg einzuschlagen. Das dauert zwar länger, aber hinterher ist wenigstens auch alles gesagt, abgestimmt ud dokumentiert. Dennoch empfinde ich dies als unglücklich formuliert: 😄

tunnelbauer wrote:

Wer macht denn nun den Revert für den unsachgemäßen Schmarrn?

tunnelbauer wrote:

Naja - hurdygurdy war nicht dafür, MetiorergoSum auch nicht und Netzwolf auch nicht - macht 5; und wenn 6 miteinander reden und 5 anderer Meinung sind, dann hat - denke ich - nur einer unrecht. Und der eine hat ja klar gegen geltendes OSM-Regelwerk verstoßen...

bin für den revert - auch weil moenk sich verzogen hat und ihn die werte eh nicht mehr interessieren.

Gruss
walter

fairerweise sollte er selber den revert machen - aber das ist wohl zuviel erwartet.

@reneman

Zu dem "Schmarrn" stehe ich in aller Öffentlichkeit, denn wenn er zuvor auf die einzuschlagende Vorgehensweise hingewiesen wird und alle anderen auch konstruktive Beiträge brachten und er dann wider besseren Wissens was "Nicht-regel-konformes" macht, dann ist das ein Schmarrn. Wäre ihm ein Fehler unterlaufen, wäre es ein Hoppala - aber bei dem ignoranten Vorsatz ist kein Hoppala.

o.k. dann mache ich mich gleich mal hinter den Revert...

Edit: Revert erledigt http://www.openstreetmap.org/browse/changeset/14761289

Moin,

das war ja ein toller Einsatz, Leute! Ich hatte extra erlaubt meine Änderung zurückzudrehen. Nun ist ja alles wieder schick. Viel getan, nichts erreicht. Das eigentliche Problem ist aber immer noch nicht gelöst: Die Device-Nodes haben kein Tag. Nun wäre es aus meiner Sicht dran, es richtig zu machen. Ich werde das nicht tun, ich kapier die ganze Wiki- und Mailringlisten-Bürokratie nicht, deswegen bin ich ja hier im Forum.

LG,

-moenk

moenk wrote:

Nun wäre es aus meiner Sicht dran, es richtig zu machen. Ich werde das nicht tun, ich kapier die ganze Wiki- und Mailringlisten-Bürokratie nicht, deswegen bin ich ja hier im Forum.

Und warum formulierst du dein Problem mit dem Ganzen Procedere nicht gleich? Hätten wir uns viel Arbeit und Aufregeung gespart...

Überlege dir ein Tagging (bitte aber nicht für surveillance) und schreib's hier rein - dann können wir gerne den Rest machen...

tunnelbauer wrote:

Und warum formulierst du dein Problem mit dem Ganzen Procedere nicht gleich? Hätten wir uns viel Arbeit und Aufregeung gespart...

Thomas,

ist klar, so ein Revert ist ganz schön viel Arbeit und Aufregung ;-)

Wir waren als letztes bei highway=red_light_camera - das wäre immer noch mein Favorit, passend zur etablierten speed_cam. Also nach dem ganzen Stress hier ist es sicher eine Kleinigkeit für Euch das anzuschieben. Oder meinetwegen erst mal auszudiskutieren.

LG,

-moenk

hallo moenk,

suchst du sowas?

http://www.netzwolf.info/kartografie/karten/enforcement

grüße von lutz

lutz wrote:

suchst du sowas?http://www.netzwolf.info/kartografie/karten/enforcement

Moin Lutz,

neee - ich hab doch sowas: https://github.com/moenk/osmosis-layers … cement.sql
Ich habe kein konkretes Problem das ich nicht lösen kann. Da fehlt IMHO ein Tag für den Node bei Rotlicht-Blitzern, damit man die auch als Node eintragen kann.

LG,

-moenk