Lediglich bei Geschwindigkeitskontrollen ist die vereinfachte Form mit einem node als “highway=speed_camera” möglich. Wäre es nicht folgerichtig, auch beispielsweise eine Rotlichtkamera als einen node mit “enforcement=traffic_signals” einzutragen? Die jetzige ausschließliche Möglichkeit der Relation erscheint mir nach dem Motto: Warum einfach, wenn es auch umständlich geht. Zudem ist diese umständliche Variante im Wiki so unverständlich beschrieben. Dabei sollte alles so einfach wie möglich sein, wenn es möglichst viele Mapper verstehen sollen. Und Mapper haben wir immer noch viel zu wenig.
Man möchte ja gerne wissen, wo das Blitzgerät genau steht und wo genau enforced wird. Das sind in der Regel zwei verschiedene Punkte.
Hab gestern meinen allerersten Tempo-Blitzer gemappt und war genervt, dass ich mir from- und to-Punkte aus den Fingern saugen musste. Nach meinem Verständnis hätte da ein Punkt reichen müssen. Also einen, zusätzlich zum Blitzgerät.
Um die Relation wird man kaum herumkommen.
Wer’s nicht hinkriegt eine Relation zu bauen kann eine map-note hinterlassen, dann macht’s wer anderes.
Meiner Meinung nach ist es gerade bei 2-Wege-Biltzern unabdingbar eine Relation zu verwenden.
Für 1-Weg-Biltzer muss auch eine Relation vorhanden sein, da es durchaus vorkommen kann, das diese an eine Strecke stehen die ein oneway=no hat. Woher soll nun ein Datenauswerter wissen in welche Richtung geblitzt wird. Mit Relation und role form/to machbar, als einzelene Node doch schon schwieriger.
Wege in OSM haben eine Richtung. Man könnte also “forward” oder “reverse” eintragen.
Mein Einrichtungs-Blitzer (https://www.openstreetmap.org/relation/9447931) erfasst nur KFZ die gen Süden fahren. Am “to” dürfte der ungefähr auslösen, ist aber geraten. Das “from” ist noch mehr geraten.
Könnte man nicht in der Relation das “from” rausschmeißen und den jetzigen “to” als “forward”-Member eintragen? Bedeutet: An dem Punkt wird gemessen, wenn man den Way in OSM-Richtung fährt.
Es kommt ja nciht auf den cm oder m an. So sind tausende Blitzer-Relationen in OSM gemappt. Es ergibt sich doch klar aus “from” und “to” wo geblitzt wird.
Das alles zu ändern, sehe ich kein Vorteil. Was ist wenn dein Blitzer nächsten Monat gedreht wird? Bei uns wird einer auch aller paar Wochen “gedreht” https://www.openstreetmap.org/node/3046367678
Enforcement muss gar nicht wie oben angenommen, zwingend als Relation eingetragen werden. Das von mir im Originalposting angefragte enforment=X als node gibt es schon. Nur gibt es im Wiki bei der Relationsbeschreibung keinen Link darauf. Ich werde das ändern und auf diese einfachere Möglichkeit hinweisen.
Damit kann ich auch eintragen, was wegen des vermeintlichen Relationszwanges bisher unmöglich war:
Für den Autor einer Navigationssoftware (oder den Datenauswerter) ist beim Mappen nur mit Enforcement-Node aber ohne -Relation die Situation exakt genau so ungewiss wie für den Mapper vor Ort. Handelt es sich um einen 1,2 3, 4, …X- Weg Blitzer? Somit ist der Ist-Zustand in OSM hundertprozentig abgebildet. Der Software-Autor muss ebenso wie der Mapper entscheiden, ob er in allen möglichen Richtungen rund um den Blitzer herum warnt/aufpasst oder in keiner. Da ich als Mapper in allen Richtungen vorsichtig wäre, würde ich einem Navi-Autor das Gleiche empfehlen.
Schlussendlich muss man einem Mapper überlassen, ob er nur das Vorhandensein eines Blitzers taggt oder zudem auch nähere Eigenschaften. Auch in dem Falle kann es dann zu einem Enforcement-Knoten ohne Relation kommen. Man kann ja auch nicht vorschreiben, zusätzlich zu einem Haus auch dessen Adresse zu taggen - auch wenn das für die Navi-Software sinnvoll wäre.
In ländlichen Gebieten kann das seeeehr verbreitet bis zum St. Nimmerleinstag dauern. Außerdem: Woher soll der Mapper wissen, dass es Notes gibt, wozu sie dienen und was Du darin stehen haben willst? Insgesamt ist die Chance gering, dass es zu einer Note kommt, die dann exakt genug beschreibt, was Du wissen willst. Zigmal wahrscheinlicher bekommst Du einen Enforcement-Knoten ohne Relation. Besser den Spatz in der Hand als die Taube …
Zudem halte ich es für kritisch, wenn “wer anderes” in nicht ortsbekannten Gebieten “repariert”. Folgendes Szenario: Jemand baut das von einem Mapper vor Ort Geschaffene durch Einbau von Relationen so um, dass dieser es nicht mehr versteht. Er kann also seine eigenen Beiträge nicht mehr korrigieren, wenn sich in der Realität etwas ändert. So zum Beispiel war ich sehr unglücklich mit der Aktion, in der Vieles in Multipolygone umgewandelt wurde. Aber als einziger Anwalt der Mapper hatte ich bei der SOTM nicht die geringste Chance gegen die Übermacht der Developer. Wenn man den Mappern in ihrer Home Area das Gefühl gibt, dass man von ihnen gemappte Dinge so verkompliziert, dass sie es nicht mehr warten können, fühlen Sie sich nicht mehr willkommen. “Wenn die da oben es besser wissen, sollen sie doch Ihren Sch… in Zukunft selbst machen.” So vergrault oder verunsichert man Mapper, von denen wir jetzt schon viiiiiieeel zu wenig haben und auf dem Land Google oder Bing bei Weitem nicht das Wasser reichen können.
Letztere haben geschulte Mitarbeiter. Dort kann alles auf die Ansprüche der Informatiker optimiert werden. Anders als dort müssen wir OSM so gestalten, dass auch die/derjenige mappen kann, der tagsüber Brötchen backt oder verkauft. Geh mal in einen Supermarkt und stelle Dir vor, dass jeder unterschiedliche Charakter, den Du triffst, seine 50 bis 100 Meter ums Heim bei OSM aktuell hält und dazu wenige Minuten im Monat bräuchte. Ich nenne das: Share your local knowledge. Eigentlich wäre das für die Aktualität des Datenbestandes paradiesisch.
Das einzige, was wir diesen unseren Mappern bieten können, ist der Spass daran, ihre Heimzone mappen zu können. Und den sollten wir Ihnen nicht verderben. Und dazu müssen wir eben mit Zuständen leben, die für den Mapper so intuitiv wie möglich aber für den Informatiker möglicherweise suboptimal sind. Anders kann OSM nicht funktionieren. Ich mag aber ehrlich gesagt keine Brötchenbäcker für OSM anwerben, da ich befürchte, dass sie von denjenigen unbewusst vertrieben werden, die saubere Datenstrukturen wünschen.
Ich glaube da hast du dich verlesen. Die von dir verlinkte Seite dokumentiert enforcement=* als einen Schlüssel, der an Relationen verwendet werden soll. Man beachte z.B das durchgestrichene Node-Icon in der Infobox rechts und den Text, der bis auf die Liste der möglichen Werte eigentlich nur aus Verweisen auf die Doku der Relation besteht.
(Damit will ich jetzt nicht sagen, dass ich persönlich etwas gegen enforcement-Nodes hätte, sondern nur, dass sie eben in den aktuell dokumentieren Taggingregeln nicht vorgesehen sind.)
Zu den allgemeineren Erwägungen bezüglich Verständlichkeit des Datenmodells: Das Grundproblem ist aus meiner Sicht, dass OSM mit dem abstrakten Konzept “Relation” vieles komplizierter aussehen lässt als nötig. Ich glaube nicht, dass Beziehungen zwischen Objekten etwas sind, was aus sich heraus schwer verständlich wäre: “wo schaut dieser Blitzer hin”, “zu welchem Geschäft gehört dieser Kundenparkplatz”, “wohin darf ich von dieser Straße aus abbiegen” etc. finde ich eigentlich recht allgemeinverständliche Fragestellungen. Viel schöner wäre es m.E., wenn man von einem Node oder Way direkt auf andere Nodes und Ways “verlinken” könnte.