Im einem anderen thread kam das Thema OT zum Zuge: http://forum.openstreetmap.org/viewtopic.php?pid=304648#p304648
Ich habe dann da eine Spontanidee gepostet, die aber nicht weiter beachtet wurde, was ja auch im Sinne einer themenbezogenen Diskussion ist. Deshalb steige ich hier neu in das Thema ein und wiederhole meine Idee von dort.
Ich schrieb:
…
Eine Idee, um die “Relationskacke” zu vermeiden:
Wie Ampeln werden Blitzer grundsätzlich als node auf den überwachten way gesetzt (und nicht daneben, wo das Gerät steht)
Zusätzliche keys könnten sein:
speed_camera:forward misst in Richtung des ways, speed_camera:backward die Gegenrichtung; speed_camera=both misst beide Richtungen.
Mögliche values für diese keys:
frontside misst den in Richtung auf den Blitzer zufahrenden Verkehr, backside misst den von ihm wegfahrenden Missetäter, both misst beides.
Ein “speed_camera:forward=frontside” würde somit den in Richtung des ways fahrenden Verkehr blitzen, wenn er auf den Blitzer zufährt.
speed_camera:type=* könnte dann noch die Art der Messung erfassen.
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.
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.
Soooo kompliziert finde ich die enforcement-Relation nicht. Ich bin also dafür das jetzige Schema beizubehalten und nicht noch
ein drittes einzuführen.
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…
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/blob/master/enforcement.sql
Funktioniert soweit ganz gut. Wäre das wohl ok wenn man nun überall das fehlendende Tag “highway=speed_camera” ergänzt?
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.
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.
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…
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.
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.
