Proposal: Einschränkungen von Beschränkungen

Mondschein · 2012-07-05T12:49:30.000Z

Seoman:

Obiges klingt für mich aber nach einem K.O.-Kriterium.

Das scheint mir leider auch so.
Außerdem halte ich das mögliche Vorkommen von Doppelpunkten “:” im Key, welche nicht den bisherigen Zweck haben, für unglücklich.

Andererseits finde ich die Idee hinter dem Vorschlag gut.

Lässt sich das Problem irgendwie sinnvoll lösen, ohne die API zu ändern?

Gruß,
Mondschein

Mondschein · 2012-07-24T22:04:29.000Z

Abstimmung ist beendet?

wambacher · 2012-07-24T22:12:31.000Z

Mondschein:

Abstimmung ist beendet?

könnte sein:

+8 / + 2 halbe / -17 → 9/17

danach gescheitert? http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for_access_tags

Gruss
walter

chris66 · 2012-08-05T18:39:41.000Z

mmd:

Das sollte eigentlich recht intuitiv zu verstehen sein

Also ich versteh’s net…

aighes · 2012-08-05T19:02:54.000Z

Ob ein bisschen variabel oder komplett variabel macht nicht den Unterschied. Entweder kommt eine Software mit variablen Keys zurecht oder nicht. Wenn nicht, ist es auch egal, wie variabel er ist.

SunCobalt · 2012-08-05T19:10:50.000Z

was gehen würde, wäre maxspeed=80 + maxspeed:conditional=langer String mit Conditions bspw conditional=[wet=80];[hgv:wet=50];[(22:00-06:00) =50]
man hättest das “normale” Maxspeed da wo es immer ist und würde alle komplizierten Bedingungen in den Value auslagern. Über [] () , und ; Trenner müsste man sich halt noch streiten.

chris66 · 2012-08-05T19:19:05.000Z

@SunCobalt
Ja, sowas schwebte mir auch schon vor:
http://www.mail-archive.com/talk-de@openstreetmap.org/msg92031.html

SunCobalt · 2012-08-05T19:20:02.000Z

mmd:

SunCobalt:

was gehen würde, wäre maxspeed=80 + maxspeed:conditional=langer String mit Conditions bspw conditional=[wet=80];[hgv:wet=50];[(22:00-06:00) =50]

Technisch würde das schon dem Wunsch entsprechen, möglichst nur fest definierte Schlüssel zu verwenden, allerdings bin ich mir nicht sicher, ob sich das noch leicht pflegen lässt und ob man in der History später schön nachverfolgen kann, welche Teilbedingung wie geändert/neu hinzugefügt wurde. Daher die Idee, die einzelnen Teilbedingungen auf verschiedene Schlüssel mit fest definierter Struktur zu verteilen.

Der Wunsch vieler (ob ich ihn teile oder nicht) war halt, keine variablen Keys. Du hast variable Keys, die sind zwar nur ein wenig variabel, aber sie sind es.

GeorgFausB · 2012-08-06T10:57:32.000Z

Moin,

SunCobalt:

was gehen würde, wäre maxspeed=80 + maxspeed:conditional=langer String mit Conditions

im Prinzip stimme ich Dir zu - aber ich halte nicht viel von “Wahrscheinlichkeitswerten als lautere Wahrheit”.

Wenn ein maxspeed von Bedingungen abhängt, dann bringt es nichts, einen vermeintlichen, geschätzten, per Wahrscheinlichkeitsrechnung bestimmten Wert im (Haupt-)Key abzulegen.
Der ist dann gemäß Murphy grundsätzlich falsch, wenn es drauf an kommt - trotz aller Beteuerungen der Wahrscheinlichkeitsrechnung.

Dann kann man gleich den Key “maxspeed” mit den Bedingungswerten verwenden.

Es ist doch egal, ob

eine Routingsoftware Zeiten schätzen muss, weil sie mit den Bedingungen im Wert nix anfangen kann
der Planer schätzen muss, ob die Zeiten nun wirklich für seinen Fahrzeitpunkt stimmen
der Fahrer schätzen muss, ob die Geschwindigkeitsvorgabe an seinem Navi ihn nun zum Verkehrshindernis macht oder ein Ticket verschafft

Software wie Fahrer müssen entweder den ‘korrekten’ Wert zur Verfügung haben oder eh nach bestem Gewissen verfahren.
Letzteres müssen sie zwar sowieso meist - aber man sollte ihnen nicht auch noch wissentlich etwas vorgaukeln.

Gruß
Georg

MasiMaster · 2012-08-06T11:43:23.000Z

chris66:

@SunCobalt
Ja, sowas schwebte mir auch schon vor:
http://www.mail-archive.com/talk-de@openstreetmap.org/msg92031.html

Ein ähnlicher Vorschlag währe folgender:
maxspeed=50
maxspeed:time=30;Mo-Fr 8:00-19:00;Sa 9:00-15:00

bzw. die “sichere” Beschränkung auf dein normalen tag:
maxspeed=30
maxspeed:time=50;Mo-Fr 19:00-08:00;Sa 15:00-09:00

“time” kann man auch “opening_hours” ersetzen. Der value setzt sich aus dem maxspeed-Key getrennt von dem ersten “;” (oder ein anderer Trenner, z.B. “|”) und dem “opening_hours”-Ausdruck zusammen.

ODER (mMn sogar besser:)

Wenn wir 2 oder mehr values haben und…

keinen Key im Value haben wollen

keine verknüpften Tags ala maxspeed:cond1=50 + cond1=08:00-19:00

nicht das derzeitige key-value Prinzip verändern wollen

...dann bleiben uns nur noch Relationen:

way: maxspeed=50
member: [der way mit maxspeed=50]

relation:
type=restriction
restriction=maxspeed
maxspeed=30
time=Mo-Fr 8:00-19:00;Sa 9:00-15:00
…

Man kann sogar die Richtung mit forward/backward als Rolle angeben (wie bei den Routen-Relationen, wird dann auch von JOSM erkannt und mitgeändert, wenn der Weg gedreht wird).

so ähnlich gefunden unter: http://wiki.openstreetmap.org/wiki/Key:restriction:hgv#Time_Based_Speed_Limits

Klappt sogar für die deutsche Maut:
relation:
type=restriction
restriction=toll
hgv=yes
minweight=16
toll=yes
fee=*
time=Mo-Fr 8:00-19:00;Sa 9:00-15:00

aighes · 2012-08-06T11:57:28.000Z

Hallo MasiMaster,
deine Vorschläge bringen auch keine wirkliche Verbesserung. Bei " 30 für LKW zwischen 22 und 6" scheitert es schon, weil es zwei Bedingungen gibt.

Relationen wäre eine Möglichkeit…wobei ich noch nicht so recht dran glaube, dass das für viel Begeisterung sorgt.

aighes · 2012-08-06T12:27:48.000Z

Ja, den Vorschlag gab es auch mal…jetzt stell dir das aber in einem aktuellem Editor an der Stelle vor, wo man den Tag eingibt. Das kann man kaum editieren und auf Fehler überprüfen etc.

MasiMaster · 2012-08-06T13:58:21.000Z

aighes:

Hallo MasiMaster,
deine Vorschläge bringen auch keine wirkliche Verbesserung. Bei " 30 für LKW zwischen 22 und 6" scheitert es schon, weil es zwei Bedingungen gibt.

Wie gesagt, der Vorschlag ist im Prinzip der gleiche wie der von chris66, nur dass man nicht 3 values hat, die in Klammern geschachtelt sind, sondern nur 2, welche durch ein Zeichen getrennt sind.
maxspeed:hgv:wet:time=50;Mo-Fr 19:00-08:00
Finde die Lösung aber nicht so elegant, da man keine Vorgabe der Reihenfolge hat: maxspeed:hgv:wet:time oder maxspeed:wet:hgv:time.
Also abgelehnt!

Relationen wäre eine Möglichkeit…wobei ich noch nicht so recht dran glaube, dass das für viel Begeisterung sorgt.

Klar sind Relationen ein wenig komplizierter zu verstehen, als einzelne Tags an Wegen. Aber Relationen haben nunmal ihre Berechtigungen, sei es bei Abbiegebeschränkungen, Multipolygonen oder Routen, bei denen es ohne Relationen schwierig ist sie abzubilden. Genauso sehe ich das bei den Einschränkungen/Beschränkungen. Mit Relation elegant & einfach

Tordanik · 2012-08-06T15:16:26.000Z

MasiMaster:

Relationen wäre eine Möglichkeit…wobei ich noch nicht so recht dran glaube, dass das für viel Begeisterung sorgt.

Klar sind Relationen ein wenig komplizierter zu verstehen, als einzelne Tags an Wegen. Aber Relationen haben nunmal ihre Berechtigungen, sei es bei Abbiegebeschränkungen, Multipolygonen oder Routen, bei denen es ohne Relationen schwierig ist sie abzubilden. Genauso sehe ich das bei den Einschränkungen/Beschränkungen. Mit Relation elegant & einfach

Bedingungen in Relationen zu packen hab ich auch schon mal vorgeschlagen. (Ich hab bei dem Thema wirklich schon so ziemlich alles versucht. ;))

http://wiki.openstreetmap.org/wiki/Proposed_features/Conditions_for_restriction_relations

Wurde natürlich abgelehnt, wie bekanntlich jeder Vorschlag zu Bedingungen bis zum heutigen Tage. Und das, obwohl es da um Abbiegebeschränkungen ging, wo ja nur die ohnehin vorhandenen Relationen mit zusätzlichen Tags versehen worden wären.

Fabi2 · 2012-08-09T22:56:15.000Z

Tordanik:

Bedingungen in Relationen zu packen hab ich auch schon mal vorgeschlagen. (Ich hab bei dem Thema wirklich schon so ziemlich alles versucht. ;))

http://wiki.openstreetmap.org/wiki/Proposed_features/Conditions_for_restriction_relations

Wurde natürlich abgelehnt, wie bekanntlich jeder Vorschlag zu Bedingungen bis zum heutigen Tage.

Das Proposal ist gut, habe leider die Abstrimmung nicht mitbekommen.

Der Vorschlag 2 von MasiMaster berücksichtigt nicht die Tatsache, das die Keys prinzipiell ja alle unabhängig voneinander sind, und ausgelagerte separate variable Keys (existiert cond1234=* noch und wurde vielleicht cond1233=* nur durch einen Fehler davor vergesssen?) sind es ja trotzdem.

MetiorErgoSum · 2012-08-10T07:12:53.000Z

Auf der Tagging-Liste hat jemand einen neuen Proposal-Versuch angekündigt: http://wiki.openstreetmap.org/wiki/Proposed_features/Conditional_restrictions. Variable Bedingungen sind dabei im Wert. Klingt in etwa wie das, was SunCobalt in Post http://forum.openstreetmap.org/viewtopic.php?pid=262462#p262462 erwähnt.

Fabi2 · 2012-08-10T11:15:04.000Z

mmd:

Merkwürdig. Ein User Fabi2 hatte da auch abgestimmt…

Ach, dann hatte ich da doch abgestimmt, aber weil das Proposal mir nicht perfekt genug war (ja, Verrkwehrszeichen sollte man imho auch extra also solche mappen), habe ich es damals abgelehnt, wußte ja nicht, was noch so danach an Vorschlagen kommen wird…

Tordanik · 2012-08-10T11:17:54.000Z

MetiorErgoSum:

http://wiki.openstreetmap.org/wiki/Proposed_features/Conditional_restrictions. Variable Bedingungen sind dabei im Wert. Klingt in etwa wie das, was SunCobalt in Post http://forum.openstreetmap.org/viewtopic.php?pid=262462#p262462 erwähnt.

Ja, dafür möchte ich auch noch mal Werbung machen, damit das nicht überlesen wird.

Ich halte es für eine sehr gute Lösung und den logischen nächsten Schritt nach der Reaktion auf Extended Conditions. Es gibt dabei eine definierte Liste von Schlüsseln, die keinerlei variable Anteile enthalten. Damit dürfte der Hauptkritikpunkt an anderen Vorschlägen behoben sein.

Die Idee ist dieselbe, die wir auch hier im Forum schon diskutiert haben, z.B. in dem zitierten Post: Die möglichen Fälle werden zusammen mit den Bedingungen, unter denen sie gelten, in den Wert des Tags geschrieben. Das sieht also so aus:

maxspeed = 50
maxspeed:conditional = 30:(Mo-Fr 07:00-17:00)

Mehrere Wert-Bedingungs-Paare werden durch Semikolon getrennt, die Bedingungen lassen sich über “AND” verknüpfen.

Eine Besonderheit ist, dass es einige “einfache” Bedingungen im Schlüssel belässt, nämlich Fahrzeugtypen und forward/backward. Höchstgeschwindigkeiten für hgv sähen also wie gehabt so aus:

maxspeed = 100
maxspeed:hgv = 80

Das wirkt auf den ersten Blick inkonsequent, hat aber praktische Vorteile. Unter anderem …

Es ist kompatibel mit bestehenden Praktiken, beispielsweise nutzen wir ja auch beim access-Tagging millionenfach Fahrzeugtypen im Schlüssel (bicycle=yes etc.)

Es sorgt dafür, dass die Werte nicht zu lang werden, was sowohl für die Lesbarkeit als auch aus technischen Gründen (255-Zeichen-Limit) sinnvoll ist.

Editoren können weiterhin beim Drehen von Ways darauf achten, ob forward/backward genutzt werden, ohne sämtliche anderen Bedingungen verstehen zu müssen.

Die Syntax ist etwas anders als unsere bisherigen Gedankenspiele. Wenn jemand das Konzept gut findet, aber lieber ein paar andere Sonderzeichen nutzen würde, schlage ich einen Kommentar auf der Diskussionsseite vor.

SunCobalt · 2012-08-10T11:25:13.000Z

gefällt mir auch. Evtl sollte er da noch ein komplexes Beispiel mit aufnehmen damit klarer wird, dass eine Verkettung erlaubt ist, also bspw
maxspeed=120
maxspeed:conditional=100:(Mo-Fr 07:00-17:00);80:(17:00-20:00);60:wet

wambacher · 2012-08-10T11:42:08.000Z

SunCobalt:

gefällt mir auch. Evtl sollte er da noch ein komplexes Beispiel mit aufnehmen damit klarer wird, dass eine Verkettung erlaubt ist, also bspw
maxspeed=120
maxspeed:conditional=100:(Mo-Fr 07:00-17:00);80:(17:00-20:00);60:wet

jau, das ist es!

glaube ich zumindest auf den ersten Blick - aber ich will das Kind nicht totschlagen, da es wirklich einen lebensfähigen Eindruck macht.

Gruss
walter