Proposal: Einschränkungen von Beschränkungen

mmd · 2012-08-05 20:17:39

.

Last edited by mmd (2012-10-19 17:51:53)

chris66 · 2012-08-05 20:19:05

@SunCobalt
Ja, sowas schwebte mir auch schon vor:
http://www.mail-archive.com/talk-de@ope … 92031.html

Last edited by chris66 (2012-08-05 20:24:25)

SunCobalt · 2012-08-05 20:20:02

mmd wrote:

SunCobalt wrote:
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.

mmd · 2012-08-05 20:27:46

.

Last edited by mmd (2012-10-19 19:20:29)

GeorgFausB · 2012-08-06 11:57:32

Moin,

SunCobalt wrote:

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-06 12:43:23

chris66 wrote:

@SunCobalt
Ja, sowas schwebte mir auch schon vor:
http://www.mail-archive.com/talk-de@ope … 92031.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: … eed_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-06 12:57:28

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.

mmd · 2012-08-06 13:13:15

.

Last edited by mmd (2012-10-19 17:51:19)

aighes · 2012-08-06 13:27:48

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.

mmd · 2012-08-06 13:41:10

.

Last edited by mmd (2012-10-19 17:51:32)

MasiMaster · 2012-08-06 14:58:21

aighes wrote:

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

Last edited by MasiMaster (2012-08-06 14:58:54)

Tordanik · 2012-08-06 16:16:26

MasiMaster wrote:

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/Prop … _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-09 23:56:15

Tordanik wrote:

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/Prop … _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.

mmd · 2012-08-10 07:10:38

.

Last edited by mmd (2012-10-19 17:49:41)

MetiorErgoSum · 2012-08-10 08:12:53

Auf der Tagging-Liste hat jemand einen neuen Proposal-Versuch angekündigt: http://wiki.openstreetmap.org/wiki/Prop … strictions. Variable Bedingungen sind dabei im Wert. Klingt in etwa wie das, was SunCobalt in Post http://forum.openstreetmap.org/viewtopi … 62#p262462 erwähnt.

Fabi2 · 2012-08-10 12:15:04

mmd wrote:

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-10 12:17:54

MetiorErgoSum wrote:

http://wiki.openstreetmap.org/wiki/Prop … strictions. Variable Bedingungen sind dabei im Wert. Klingt in etwa wie das, was SunCobalt in Post http://forum.openstreetmap.org/viewtopi … 62#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-10 12:25:13

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-10 12:42:08

SunCobalt wrote:

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

MasiMaster · 2012-08-10 13:35:42

Tordanik wrote:

MasiMaster wrote:
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/Prop … _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.

Hab mir dein Proposal + Talkseite mal angeschaut. In mehreren Fällen wurde das ":if" kritisiert. Wenn ich es richtig sehe, bezieht du dich nur auf Abbiegebschränkungen und nicht auf Allgemeine (oder bei mit kommst nur so an).
Wurde zumindest gefordert: "What about highway=pedestrian with access=delivery from 10:00-18:00?"

Im Grunde gefällt mir das Proposal, bis auf das ":if" und die Begrenzung auf Abbiegebschränkungen.

SunCobalt · 2012-08-10 16:00:07

jetzt hat Eckhart wieder sein altes abgelehntes Proposal rausgeholt und eine RFC (Request for Comments) Mail verschickt.

flaimo · 2012-08-10 16:08:47

Wenn ich das richtig interpretiere ist man aber auf eine condition beschränkt, oder? oder schreibt man dann access:condition2, 3, 4...?

wambacher · 2012-08-10 17:06:38

SunCobalt wrote:

jetzt hat Eckhart wieder sein altes abgelehntes Proposal rausgeholt und eine RFC (Request for Comments) Mail verschickt.

meinen Comment kann er gerne haben - kann er sich aber auch denken, denn ich bin mit sicher, dass er hier klammheimlich mitliesst.

p.s. seh ich das richtig, das der Herr alle Votings entfernt hat? Oder ist das formal ok so?
naja, hab sie nach längerem Suchen unter first Votings gefunden.

Last edited by wambacher (2012-08-10 17:20:12)

Mondschein · 2012-08-21 17:55:19

wambacher wrote:

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.

Ja, der neue Vorschlag hört sich sehr gut an.

flaimo wrote:

Wenn ich das richtig interpretiere ist man aber auf eine condition beschränkt, oder? oder schreibt man dann access:condition2, 3, 4...?

Die Beispiele sollten helfen:
http://wiki.openstreetmap.org/wiki/Prop … s#Examples

Gruß,
Mondschein

MetiorErgoSum · 2012-09-17 09:13:22

MetiorErgoSum wrote:

Auf der Tagging-Liste hat jemand einen neuen Proposal-Versuch angekündigt: http://wiki.openstreetmap.org/wiki/Prop … strictions. Variable Bedingungen sind dabei im Wert.

Tordanik wrote:

Ich halte es für eine sehr gute Lösung und den logischen nächsten Schritt nach der Reaktion auf Extended Conditions.

SunCobalt wrote:

gefällt mir auch

wambacher wrote:

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.

Mondschein wrote:

Ja, der neue Vorschlag hört sich sehr gut an.

Auf der Proposal-Seite hat die Abstimmung begonnen. Wäre schön, wenn sich möglichst viele Mapper beteiligen, die mit dem Thema befasst sind.

Announcement

#101 2012-08-05 20:17:39

Re: Proposal: Einschränkungen von Beschränkungen

#102 2012-08-05 20:19:05

Re: Proposal: Einschränkungen von Beschränkungen

#103 2012-08-05 20:20:02

Re: Proposal: Einschränkungen von Beschränkungen

#104 2012-08-05 20:27:46

Re: Proposal: Einschränkungen von Beschränkungen

#105 2012-08-06 11:57:32

Re: Proposal: Einschränkungen von Beschränkungen

#106 2012-08-06 12:43:23

Re: Proposal: Einschränkungen von Beschränkungen

#107 2012-08-06 12:57:28

Re: Proposal: Einschränkungen von Beschränkungen

#108 2012-08-06 13:13:15

Re: Proposal: Einschränkungen von Beschränkungen

#109 2012-08-06 13:27:48

Re: Proposal: Einschränkungen von Beschränkungen

#110 2012-08-06 13:41:10

Re: Proposal: Einschränkungen von Beschränkungen

#111 2012-08-06 14:58:21

Re: Proposal: Einschränkungen von Beschränkungen

#112 2012-08-06 16:16:26

Re: Proposal: Einschränkungen von Beschränkungen

#113 2012-08-09 23:56:15

Re: Proposal: Einschränkungen von Beschränkungen

#114 2012-08-10 07:10:38

Re: Proposal: Einschränkungen von Beschränkungen

#115 2012-08-10 08:12:53

Re: Proposal: Einschränkungen von Beschränkungen

#116 2012-08-10 12:15:04

Re: Proposal: Einschränkungen von Beschränkungen

#117 2012-08-10 12:17:54

Re: Proposal: Einschränkungen von Beschränkungen

#118 2012-08-10 12:25:13

Re: Proposal: Einschränkungen von Beschränkungen

#119 2012-08-10 12:42:08

Re: Proposal: Einschränkungen von Beschränkungen

#120 2012-08-10 13:35:42

Re: Proposal: Einschränkungen von Beschränkungen

#121 2012-08-10 16:00:07

Re: Proposal: Einschränkungen von Beschränkungen

#122 2012-08-10 16:08:47

Re: Proposal: Einschränkungen von Beschränkungen

#123 2012-08-10 17:06:38

Re: Proposal: Einschränkungen von Beschränkungen

#124 2012-08-21 17:55:19

Re: Proposal: Einschränkungen von Beschränkungen

#125 2012-09-17 09:13:22

Re: Proposal: Einschränkungen von Beschränkungen

Board footer