uhrzeitbeschränkte Zone 30

Hi!
Wie trägt man einen 30kmh-Straßenabschnitt ein, in dem man von 22-6 Uhr 50kmh fahren darf?

MfG
Okkarator

Da gibt es mehrere Vorschläge, von denen bisher keiner wirklich etabliert ist (geschweige denn irgendwo ausgewertet würde). Mein Favorit ist http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for_access_tags. Das sieht dann in der Praxis z.B. so aus: http://www.openstreetmap.org/browse/way/69154440

Ach ja, JOSM wird natürlich über die Leerzeichen im Schlüssel meckern.

Leerzeichen im Schlüssel sind ja auch nicht schön. Gibt es eigentlich schon ein vernünftiges Proposal, wo der Wert da ist, wo er hingehört, nämlich im Wert? Also etwa “maxspeed=50; (Mo-Sa 07:00-19:00):30”?

Das möchte ich erst noch einmal unterstreichen, weil es die aktuelle Situation treffend zusammenfasst.

Für jeden, der nicht am Neuerfinden von Taggingschemata interessiert ist, dürfte sich der Thread also ab hier erledigt haben…

Gibt es in ausformulierter Form meines Wissens nicht, aber Vorschläge wurden schon oft genannt und es wäre auch nicht schwer umzusetzen. Eine gängige Idee hast du ja schon genannt.

Um mal wieder meine Sicht auf die Diskussion zusammenzufassen: Es gibt einige wenige Kernideen, die in kleineren Variationen - hier ein Doppelpunkt mehr, dort ein anderer Schlüsselname - seit gut zwei Jahren immer wieder aufkommen. Das sind:

A. Bedingungen in den Schlüssel

maxspeed = 30
maxspeed:(22:00-06:00) = 50

B. Bedingungen in den Wert

maxspeed = 30; (22:00-06:00):50

C. Bedingte Tags in eine Relation

maxspeed = 30

if:time = 22:00-06:00
maxspeed = 50

D. Verschiedene Versuche, Tag-Gruppen zu bauen, ohne eine Relation verwenden zu müssen.

Alle diese Konzepte haben Vor- und Nachteile, funktionieren kann prinzipiell jedes davon. Zu jedem wird sich jemand finden, der es nur so für logisch hält, weil dann die Bedingung dort ist, “wo sie hingehört”. :wink:

Weil du ja speziell B genannt hast: B und C haben den Vorteil gegenüber A, dass es nur endlich viele Keys und keine Sonderzeichen in Keys gibt. B hat neben den im Extremfall langen Tags vor allem den Nachteil, dass ein Programm, das mit diesem System nichts anfangen kann, nicht einmal die Information für den “Normalzustand” mehr auswerten kann.

Wobei der Nachteil von B dadurch ausgeglichen werden kann, dass man einen zweiten Key einführt (bspw. maxspeed_hours in Anlehnung an opening_hours - für andere Bedingungen müssten dann natürlich weitere Schlüssel her - oder maxspeed:conditional o.ä. der in dann sehr komplexem Schema auch weitere Bedingungen aufnehmen kann), der dann zusätzlich zum Standardwert gesetzt wird und eben mehre Bedingungen im Wert aufnehmen kann. Lange Werte sehe ich nicht direkt als Problem: Für ein Programm macht es keinen nennenswerten Unterschied und für den Mapper werden sich Möglichkeiten finden, dass zum zusammenklicken zu machen, bzw. zu visualisieren, wenn einem das Schreiben zu doof ist. Aber eigentlich sollte es nicht viel schlimmer als bei den opening_hours sein - im Gegenteil, denn solche Bedingungen sind meist einfacher strukturiert.

Bei A sehe ich nur den Vorteil, dass man eben den Standardwert vom Spezialwert sauber trennt, was der Lesbarkeit durchaus hilft, ist aber auswertungstechnisch IMO eine Katastrophe. C ist ein Missbrauch von Relationen, denn Relationen sind für Zusammenhänge (also Relationen) zwischen Objekten da und nicht für Eigenschaften von Objekten. D scheint mir keine Vorteile gegenüber A und B zu bieten.

Grundsätzlich wäre ich ja dafür, dass man, ausgehend am Besten vom opening_hours Schema, eine Schema erstellt, mit dem abhängig von Bedingungen (Datum, Uhrzeit, Witterung, etc.) verschiedene Werte für einen Schlüssel definiert werden können und das dann für alle Schlüssel allgemein zugelassen wäre. Das würde einen Haufen Fälle mit einem einzigen Konzept ermöglichen. Aber nachdem leider noch nichtmal die ;-Notation mehrerer Werte bis jetzt bei den Programmen angekommen ist, sehe ich leider schwarz für so einen Ansatz.

Das wäre eine durchaus sinnvolle Lösung. Da man dann nichts mehr “kaputt macht”, kann man auch problemlos mal damit anfangen und sehen, ob es sich durchsetzt.

Das hängt stark von der Architektur der auswertenden Anwendung ab. Wenn du versuchst, die Tags 1:1 in eine Datenbank-Tabelle zu stecken oder so - ja, dann ist es eine Katastrophe.

Aus meiner Sicht der Hauptgrund für A ist, dass bei “einfacheren” Fällen ohne Bedenken zu dieser Lösung gegriffen wird. oneway:bicycle, maxspeed:forward oder so etwas. Die Frage ist, ob man das den Mappern abgewöhnen kann. Wenn nicht, hat man mit jeder Lösung außer A zwei parallele Systeme. Denn deiner Variante von B zufolge sollte man da ja eher
oneway:conditional = yes; bicycle:no
verwenden.

Na ja, technisch gesehen kann man mit Relationen so ziemlich alles machen. Die Abbildung von “Zusammenhängen zwischen Objekten” ist einfach nur eine übliche Erklärung der Frage “was ist eine Relation” und nicht mal eine besonders gute. Ein Wanderweg, ein Firmengelände, eine Brücke mit mehreren Verkehrswegen - das sind alles selber “Objekte”, nicht bloß Zusammenhänge.

Eine Relation als Attributscontainer einzusetzen ist in der Tat ein wenig fragwürdig. Ähnlich wie D wäre das aber auch eher eine Lösung, die versucht, das Beste aus den aktuellen Fähigkeiten der API zu machen. Zum Vergleich: Multipolygone sind auch ein Missbrauch von Relationen, aber es gab bisher nichts besseres - und mit der nächsten API-Version ersetzt man sie vielleicht mit einer sauberen Lösung für Flächen.

Das könnten wir gerne versuchen, zumindest von Seiten der Mapper scheint der Bedarf ja zu bestehen. Wenn man für mehrere unterschiedliche Varianten dann ausformulierte Proposals hat, kann man vielleicht auch mal einen Vergleich mit den Vor- und Nachteilen erstellen und eine Umfrage machen, was besser ankommt. Denn ich denke immer noch, dass das zu einem großen Teil auch einfach eine Geschmacksfrage ist.

Übrigens: Die “;”-Notation ist so eine Sache … das würde ich auch nicht unterstützen wollen, weil es keine definierte Bedeutung hat und meistens vom Datenmodell her einfach Quatsch ist. Es macht schon einen Unterschied, ob ein Wert per Definition eine bestimmte Syntax verwendet (wie opening_hours), die dann eben geparst werden muss und kann, oder ob ein Mapper einfach mal unsinnigerweise die Bank und den darin stehenden Geldautomaten per Semikolon zu einem Objekt zusammenfasst.

Du hast Recht, oneway=yes;bicycle:no halte ich wirklich für eine sinnvolle, weil allgemein anwendbare und damit sehr mächtige Lösung. Man könnte allerdings für den Fall, dass die Menge der möglichen Bedingungen sehr klein ist (also im Allgemeinen immer dann, wenn es im Wiki eine Liste dazu gibt, die den Anspruch erhebt zumindest weitgehend vollständig zu sein), erlauben, dass die aktuelle Schreibung zulässig ist. Viel besser macht es das aber IMO nicht wirklich.

Zu Relationen: “Als Relation […] wird im Allgemeinen eine bestimmte Beziehung zwischen Gegenständen […] bezeichnet.” (Zitat Wikipedia). Eine Relation existiert (und sollte damit datentechnisch umgesetzt werden) genau dann, wenn es mindestens zwei Objekte gibt (C kann das verletzen), die in einer “bestimmten Beziehung” stehen (und das ist bei C eben im Allgemeinen nicht der Fall). Für Multipolygone gilt das durchaus (mindestens ein inner und ein outer, Beziehung: Diese Wege formen eine bestimmte Fläche), insofern sehe ich das nicht so kritisch, auch wenn ein Flächendatentyp die Sache wohl vereinfachen würde. Unabhängig von der Relationsdefinition kann natürlich das, was die Relation darstellt wieder ein Objekt sein (genaugenommen dürfte es sogar immer ein Objekt sein).

Zur ;-Notation: Wo siehst du das Fehlen der Definition? IMO ist die Defintion so: Dieses (Datenbank-)Objekt erfüllt gleichzeitig die Anforderungen von key=value1 und key=value2. Bei der Bank kann man darüber streiten, ob es nicht besser wäre, den Geldautomaten getrennt zu erfassen, dann mit Relation an die Bank gekoppelt - aber erstmal ist das eine Abstraktion: Ich stelle beide (Real-)Objekte in einem (Datenbank-)Objekt dar, weil sie stark zusammengehören und in praktisch absoluter räumlicher Nähe sind. Noch logischer wird diese Definition, wenn man sich ander Schlüssel anschaut, z.B. cuisine (Es ist nunmal nur ein reales Restaurant, dass sowohl italienische wie auch griechische Speisen verkauft⦆. Ganz interessant auch für den gerade aktuellen Fall mit Jerusalem: Der name-key enthält den Namen eines Objekts in der Landessprache. Jerusalem wird nun von zwei Ländern beansprucht (und das ist mehr oder weniger international akzeptiert), also gehören theoretisch beide Namen in den Schlüssel. Mit ;-Notation wäre sofort klar, wie die Situation ist (auch wenn es dann wahrscheinlich trotzdem Disput gäbe, ob nun das eine oder das andere vorne hin soll). Andere Lösung um die ;-Notation zu umgehen, wäre, das API so zu ändern, dass ein Schlüssel mehrfach vergeben werden kann. Ob das wirklich besser ist, sei dahingestellt. Im Prinzip ist es ein Spezialfall des oben vorgeschlagenen: Getrennt durch Semikola stehen Werte, die der Schlüssel für dieses Objekt unter bestimmten Bedingungen annimmt. Werte ohne Bedingung sind Standardwerte, die angenommen werden, wenn die Bedingungen der anderen Werte nicht gelten. In diesem Spezialfall gibt es keine Werte mit Bedingungen, aber zwei ohne Bedingungen: Es gelten also immer beide Werte.

http://wiki.openstreetmap.org/wiki/Proposed_features/access_restrictions_1.5#Self_defined_conditions

Das ist ein Schema im Schlüssel. Und das ist für mich absolutes No-Go.

und kannst du diese dogmatische sicht auch mit argumenten untermauern? was macht einen key im value feld besser, so wie in deinem bicycle beispiel oben?

Es ist für die Auswertung schlicht unpraktisch.

  1. Muss ich dann, wenn mich der Wert für Schlüssel xy nicht interessiert vielleicht 10 oder auch 100 Schlüssel xy:z betrachten, um festzustellen, dass sie mich nicht interessieren.
  2. Wenn mich der Wert von xy (unter Bedingungen) interessiert muss ich erst alle Schlüssel xy:z finden, das z extrahieren und betrachten.
    Wenn die Werte alle im Wert sind, dann geht das einfacher: Es gibt nur einen Schlüssel xy, wenn mich der nicht interessiert muss ich nur einen Schlüssel links liegen lassen und wenn er mich interessiert, kann ich eine allgemeine Hilfsfunktion verwenden, die die Bedingungen auswertet.
    Und ansonsten: Wofür hat man denn ein Datenmodell Schlüssel->Wert, wenn man Werte in den Schlüssel schreibt?

das müsste ein programmierer bewerten, aber ich würde mal vermuten, dass das dein konzept nicht schneller ist. in deinem fall müsste der algorithmus immer key und value durchforsten, nochdazu die ganzen strings von vorne bis hinten. in meinem konzept jedoch nur den key. da eine applikation vermutlich eher einen index auf den key als den value hat und dort die anzahl der eindeutigen werte geringer ist, kann ich mir nicht vorstellen, dass zusätzliche keys im value feld hier schneller zu durchsuchen wären auch wenn eine geringere anzahl an tags evaluiert werden muss.

ausserdem hat das verlinkte konzept auch den vorteil dass strings im key von vorne nach hinten geprüft werden können. sollte ein routingprogramm zB nur informationen für ein auto als fortbewegungsmittel benötigen, braucht es nur die ersten zeichen des keys auf “access” und “access:car” bzw bei bedingungen auf die einmal definierte condition prüfen und alles andere sofort verwerfen. im falle des Extended_conditions proposals müsste man immer den ganzen key durchsuchen, da das fortbewegungsmittel ja irgendwo mittendrinn stehen kann. in deinem fall sogar auch noch den value. bei der evaluierung eines einzelnen elements wird das zeitmäßig vermutlich nicht auffallen, wenn ich aber von england nach italien will und einige millionen elemente geprüft werden müssen, würde ich schon vermuten, dass mein konzept performanter ist. aber wie gesagt, dass müssten diejenigen beurteilen die routingsoftware schreiben.

deinen letzten satz kann ich übrigens genauso umdrehen: “Wofür hat man denn ein Datenmodell Schlüssel->Wert, wenn man Schlüssel in die Werte schreibt?” die reine lehre lässt sich mit diesem einfachen flachen datenmodel in OSM weder auf die eine oder andere art sauber abbilden.

Eine Bedingung (bei der Fahrzeugtyp-Bedingung mag man ja darüber streiten, aber bei Dingen wie Zeitangaben ist das IMO eindeutig) ist doch wohl eher Wert als Schlüssel.