Bedingte Access Beschränkungen

GeoCounter · 2010-12-13 18:07:10

Wie ich in dem langen Thread zum Thema opening_hours schon angedeutet habe, frage ich mich, ob sich dieses Schema nicht auch auf access_restrictions anwenden lässt.

Zu diesem Thema gibt es im Wiki neben dem ursprünglich angedachten Schema mittels hour_on / hour_off zwei Proposals (Conditions_for_access_tags und Extended_conditions_for_access_tags), die aber beide meiner Ansicht nach Probleme aufweisen (diese wurden zum Teil auch auf den entsprechenden Talk Seiten diskutiert).

Ersters basiert auf hour_on / hour_off und benötigt damit zwei Schlüssel/Wert Paare, aus denen außerdem nicht klar hervorgeht, wie die Beschränkung zwischen diesen Zeitpunkten genau aussieht. (Beispielsweise lässt sich so eine Geschwindigkeitsbegrenzung nicht darstellen).

Beide Probleme werden in dem zweiten Proposal gelöst, allerdings wandert dabei der Zeitbereich aus dem Wert in den Schlüssel was die Auswertung erschwert. Zudem werden im Schlüssel keine Leerzeichen zugelassen, zumindest meckert der JOSM Validator.

In den Kommentaren taucht häufig der Wunsch auf, statt hour_on / hour_off das Schema der opening_hours zu verwenden.

Mit dem modifizierten opening_hours Schema von Netzwolf lassen sich die genannten Probleme lösen, indem von der Möglichkeit, Texte als Rückgabe zu verwenden, Gebrauch gemacht wird.

Beispielsweise ließe sich eine zeitbedingte Geschwindigkeitsbeschränkung für LKWs schreiben als:
maxspeed:hgv = 22:00-06:00 "30"; "50"
Zwischen 22:00 und 06:00 Uhr wären demnach für LKWs nur 30km/h erlaubt, ansonsten aber 50km/h.

Oder aber eine zeitlich wechselnde Einbahnstraße (gibt es z.B. bei mir im Nachbarort):
oneway = 00:00-12:00 "yes"; "-1"
Die Einbahnstraße zeigt zwischen 00:00 und 12:00 Uhr in Wegrichtung, ansonsten aber gegen die Wegrichtung.

Ich denke, dass sich zeitliche Beschränkungen (auch komplexerer Art) so recht elegant schreiben ließen. Es bliebe aber zu überlegen, ob Gewichts,- Höhen,- ... beschränkungen in ähnlicher Weise modelliert werden können.

Gruß
GeoCounter

Netzwolf · 2010-12-13 20:02:08

Nahmd,

GeoCounter wrote:

Beispielsweise ließe sich eine zeitbedingte Geschwindigkeitsbeschränkung für LKWs schreiben als:
maxspeed:hgv = 22:00-06:00 "30"; "50"
Zwischen 22:00 und 06:00 Uhr wären demnach für LKWs nur 30km/h erlaubt, ansonsten aber 50km/h.

Alternativvorschlag für ein sanftes Upgrade, um die Routing-Programm nicht zu verärgern:
Ich würde die "härteste" Einschränkung ganz normal deklarieren:

maxspeed:hgv = 30

und dann versuchen, eine allgemeine Schreibweise für Ausnahmen einzuführen:

maxspeed:hgv/1 = 50 @ 06:00-22:00

(Hinweis: die Schreibweise dient nur zur Darstellung der Idee und keinesfalls als Vorschlag zu sehen)

Dann können die Router "fail save" normal weiterarbeiten.

Gruß Wolf

PS: bei der alternierenden Einbahnstraße interessiert mich: wie ist die in käuflichen Stadtplänen dargestellt?

GeoCounter · 2010-12-13 20:50:33

Netzwolf wrote:

Alternativvorschlag für ein sanftes Upgrade, um die Routing-Programm nicht zu verärgern:
Ich würde die "härteste" Einschränkung ganz normal deklarieren:
maxspeed:hgv = 30

Stimmt, das macht natürlich Sinn.

Netzwolf wrote:

und dann versuchen, eine allgemeine Schreibweise für Ausnahmen einzuführen

Würdest du dein opening_hours Schema dafür verwenden? Es ist natürlich im Normalfall für einfache Zeitbeschränkungen überdimensioniert, aber wenn ich z.B. an Parkkonditionen (z.B. Mo-Sa 07:00-19:00 "parking_disc") denke, geht es schon wieder sehr stark in die Richtung.

Netzwolf wrote:

PS: bei der alternierenden Einbahnstraße interessiert mich: wie ist die in käuflichen Stadtplänen dargestellt?

Soweit ich es überblicke wird es ignoriert (auch beim Routen). Wobei es in meinem Fall genaugenommen keine Einbahnstraße ist, sondern eine entsprechende Ampel, die zweimal täglich die Richtung umschaltet (die Zeiten sind aber fest und beschildert).
Beim Recherchieren ist mir gerade allerdings aufgefallen, dass im November die Schaltung geändert wurde (im Zeitungsartikel ist allerdings die Regelung aber noch erkennbar).

Gruß
GeoCounter

Mueck · 2010-12-14 00:00:02

Netzwolf wrote:

PS: bei der alternierenden Einbahnstraße interessiert mich: wie ist die in käuflichen Stadtplänen dargestellt?

Die Buchläden haben sicherlich zwei Versionen vorätig und je nach Uhrzeit, wann Du die Karte erwirbst ... ;-)

Tordanik · 2010-12-14 00:53:24

Zu diesem Thema gibt es im Wiki neben dem ursprünglich angedachten Schema mittels hour_on / hour_off zwei Proposals (Conditions_for_access_tags und Extended_conditions_for_access_tags), die aber beide meiner Ansicht nach Probleme aufweisen (diese wurden zum Teil auch auf den entsprechenden Talk Seiten diskutiert).
Beide Probleme werden in dem zweiten Proposal gelöst, allerdings wandert dabei der Zeitbereich aus dem Wert in den Schlüssel was die Auswertung erschwert. Zudem werden im Schlüssel keine Leerzeichen zugelassen, zumindest meckert der JOSM Validator.

Ich bin der Autor der beiden ursprünglichen Proposals, habe aber feststellen müssen, dass die Leute anscheinend an ihrem beschränkten Schlüsselraum hängen.

Allerdings möchte ich klarstellen, dass die Proposals prinzipiell funktionieren. Sie sind mit dem aktuellen Datenmodell kompatibel (das erlaubt Leerzeichen in Schlüsseln) und die Auswertung ist möglich - vielleicht muss man ein paar Annahmen in seinem Programm ändern, aber sie ist möglich.

Ich habe nichts gegen eine andere Herangehensweise, aber sie sollte ebenso mächtig sein und auch ein paar andere Anforderungen erfüllen. Wünschenswerte Eigenschaften des "Extended Conditions"-Vorschlags sind aus meiner Sicht unter anderem:

Das Schema kann praktisch alle auftretenden Situationen beschreiben.
Es kann verwendet werden, ohne Konflikte mit dem simpleren "Basistagging" zu produzieren.
Es gibt eine klare Auswerteregel (der Wert mit spezifischeren Bedingungen überschreibt den mit allgemeineren)
Es ist für "einfache" und "komplizierte" Fälle identisch zu verwenden - es werden nicht z.B. manche Bedingungen in den Schlüssel und manche in den Wert geschrieben.

GeoCounter wrote:

Wie ich in dem langen Thread zum Thema opening_hours schon angedeutet habe, frage ich mich, ob sich dieses Schema nicht auch auf access_restrictions anwenden lässt.

Das habe ich mich auch schon gefragt, zumal Wolf die Öffnungszeiten ja tatkräftig angegangen ist. Eine "öffnungszeiten-ähnliche" Alternative ohne komplexe Schlüssel, die ich schon früher ähnlich diskutiert gesehen habe, wäre:

Schlüssel = Bedingungen Wert; Bedingungen Wert; ...

Am Beispiel:
vehicle = no; Mo-Fr 08:00-10:00 delivery
maxspeed = 120; hgv Sa,Su 80
oneway = 00:00-12:00 yes; -1

Mit so etwas könnte ich wohl leben, falls das den allgemeinen Geschmack eher trifft. Details wie die Trennzeichen zwischen und nach den Bedingungen müsste man natürlich noch klären.

Netzwolf wrote:

Alternativvorschlag für ein sanftes Upgrade, um die Routing-Programm nicht zu verärgern:
Ich würde die "härteste" Einschränkung ganz normal deklarieren:
maxspeed:hgv = 30
und dann versuchen, eine allgemeine Schreibweise für Ausnahmen einzuführen:
maxspeed:hgv/1 = 50 @ 06:00-22:00

Da bin ich mir nicht sicher, ob ich das richtig verstehe: Du ziehst eine Bedingung in den Schlüssel, nämlich hgv - warum speziell diese? Weil Verkehrsmittel ein "enum" sind, im Gegensatz zu z.B. Zeitintervallen? Außerdem das "maxspeed:hgv/1" - wofür steht die "1"? Eine Ganzzahl in den Schlüssel einzubauen, würde ja gerade den häufigsten Kritikpunkt an den Extended Conditions (dass es keine endliche Schlüsselmenge mehr gibt) nicht entkräften?

Sorry, wenn ich gerade etwas auf dem Schlauch stehe. Aber von den seit zwei Jahren immer mal wieder auftretenden Diskussionen zu dem Thema habe ich vermutlich schon völlig verknotete Denkbahnen...

viw · 2010-12-14 10:54:56

Tordanik wrote:

Netzwolf wrote:
Alternativvorschlag für ein sanftes Upgrade, um die Routing-Programm nicht zu verärgern:
Ich würde die "härteste" Einschränkung ganz normal deklarieren:
maxspeed:hgv = 30
und dann versuchen, eine allgemeine Schreibweise für Ausnahmen einzuführen:
maxspeed:hgv/1 = 50 @ 06:00-22:00
Da bin ich mir nicht sicher, ob ich das richtig verstehe: Du ziehst eine Bedingung in den Schlüssel, nämlich hgv - warum speziell diese? Weil Verkehrsmittel ein "enum" sind, im Gegensatz zu z.B. Zeitintervallen? Außerdem das "maxspeed:hgv/1" - wofür steht die "1"? Eine Ganzzahl in den Schlüssel einzubauen, würde ja gerade den häufigsten Kritikpunkt an den Extended Conditions (dass es keine endliche Schlüsselmenge mehr gibt) nicht entkräften?
Sorry, wenn ich gerade etwas auf dem Schlauch stehe. Aber von den seit zwei Jahren immer mal wieder auftretenden Diskussionen zu dem Thema habe ich vermutlich schon völlig verknotete Denkbahnen...

Also ich denke er verfolgt damit zwei Ziele.
Erstens alle bisherigen Programme rechnen mit dem ersten Schlüssel funktionstüchtig weiter. Damit sie nicht zu optimistisch sind mit dem restriktivsten.
Nachher kommen als zweites Ausnahmeregeln hinzu. Die Nummerierung würde zum einen der Übersichtlichkeit zum anderen aber auch der Abgrenzung gegenüber dem gewöhnlichen Schlüssel dienen. Damit können dann nur neuere Programme umgehen und ältere ignorieren diese Schlüssel einfach.

Netzwolf · 2010-12-14 12:31:37

Nahmd,

Mueck wrote:

Netzwolf wrote:
PS: bei der alternierenden Einbahnstraße interessiert mich: wie ist die in käuflichen Stadtplänen dargestellt?
Die Buchläden haben sicherlich zwei Versionen vorätig und je nach Uhrzeit, wann Du die Karte erwirbst ... ;-)

[_] Diese Anwort war hilfreich.

Ich habe bereits Angaben zur Öffnungszeit einer Straße in einer Karte gesehen. Das war allerdings eine recht feine (1:25k) und in den Bergen (wenig Infrastruktur=viel Platz für Text).

Ein Stadtplan ist aber ohnehin übervoll - daher bin ich neugierig, ob/welche Lösung da gefunden wurde.

Gruß Wolf

Netzwolf · 2010-12-14 12:57:17

Nahmd,

Tordanik wrote:

Netzwolf wrote:
Alternativvorschlag für ein sanftes Upgrade, um die Routing-Programm nicht zu verärgern:
Ich würde die "härteste" Einschränkung ganz normal deklarieren:
maxspeed:hgv = 30
und dann versuchen, eine allgemeine Schreibweise für Ausnahmen einzuführen:
maxspeed:hgv/1 = 50 @ 06:00-22:00
Da bin ich mir nicht sicher, ob ich das richtig verstehe: Du ziehst eine Bedingung in den Schlüssel, nämlich hgv - warum speziell diese?

Nein.

Ich habe lediglich das Beispiel übernommen:

Netzwolf wrote:

GeoCounter wrote:
Beispielsweise ließe sich eine zeitbedingte Geschwindigkeitsbeschränkung für LKWs schreiben als:
maxspeed:hgv = 22:00-06:00 "30"; "50"
Zwischen 22:00 und 06:00 Uhr wären demnach für LKWs nur 30km/h erlaubt, ansonsten aber 50km/h.
Alternativvorschlag für ein sanftes Upgrade, um die Routing-Programm nicht zu verärgern:
Ich würde die "härteste" Einschränkung ganz normal deklarieren:
maxspeed:hgv = 30
und dann versuchen, eine allgemeine Schreibweise für Ausnahmen einzuführen:
maxspeed:hgv/1 = 50 @ 06:00-22:00
(Hinweis: die Schreibweise dient nur zur Darstellung der Idee und keinesfalls als Vorschlag zu sehen)

Ich kann statt mit "maxspeed:hgv" gerne auch mit dem Beispiel "maxshoesize" arbeiten:

Netzwolf wrote:

Alternativvorschlag für ein sanftes Upgrade, um die Routing-Programm nicht zu verärgern:
Ich würde die "härteste" Einschränkung ganz normal deklarieren:
maxshoesize = 34
und dann versuchen, eine allgemeine Schreibweise für Ausnahmen einzuführen:
maxshoesize/1 = 48 @ 06:00-22:00
(Hinweis: die Schreibweise dient nur zur Darstellung der Idee und keinesfalls als Vorschlag zu sehen)

Tordanik wrote:

Weil Verkehrsmittel ein "enum" sind, im Gegensatz zu z.B. Zeitintervallen? Außerdem das "maxspeed:hgv/1" - wofür steht die "1"?

Da zitiere ich doch glatt noch mal mich selbst:

Netzwolf wrote:

(Hinweis: die Schreibweise dient nur zur Darstellung der Idee und keinesfalls als Vorschlag zu sehen)

Tordanik wrote:

Eine Ganzzahl in den Schlüssel einzubauen, würde ja gerade den häufigsten Kritikpunkt an den Extended Conditions (dass es keine endliche Schlüsselmenge mehr gibt) nicht entkräften?
Sorry, wenn ich gerade etwas auf dem Schlauch stehe. Aber von den seit zwei Jahren immer mal wieder auftretenden Diskussionen zu dem Thema habe ich vermutlich schon völlig verknotete Denkbahnen...

Ok, neuer Versuch:

name = Dr. Jekyll
name/1 = Mr. Hide @ 22:00-04:00

maxspeed = 30
maxspeed/1 = 50 @ 08:00-20:00

access = public
access/1 = vampires @ sunset-sunrise

Oder der Parkplatz, der am zweiten Mittwoch Monat zum Marktplatz wird:

access = public
access/1 = no @ We[2] 7:00-18:00

Hehe, oder die beliebte kombinierte Tannenbaum/Erdbeerbude:

shop/1 = xmastree @ Dec 25 - Su -21 days - Dec 24 08:00-18:00
shop/2 = strawberries @ Apr-Jun 10:00-14:00
shop/3 = mushrooms @ Oct: 16:00-17:00

oneway = alternating
oneway/1 = yes @ 8:00-12:00
oneway/2 = -1 @ 12:00-16:00

Idee also: statt einzelne Keys zeitabhängig zu machen, führen man doch gleich eine universelle Notation ein. Sinnigerweise aber kompatibel, also mit einem nichtzeitabhängigen Defaultwert (für Tiles, gedruckte Karten und bestehende Router).

Gruß Wolf

errt · 2010-12-14 13:20:16

Ich bin mir nicht sicher, ob es wirklich eine gute Idee ist, den stärker beschränkenden Wert in das bisherige Tag zu packen und andere Beschränkungen in ein neues. Besonders deutlich finde ich das hier:

Netzwolf wrote:

maxspeed = 30
maxspeed/1 = 50 @ 08:00-20:00

Auf dieser Straße wären 50% des Tages 50km/h, und zwar auch während der Hauptverkehrszeiten. Also sollte ein Router auch am ehesten 50km/h annehmen. Verwendet man nur einen Schlüssel, hat man den Vorteil, dass Programme, die die erweiterten Bedingungen nicht verstehen wenigstens erkennen können, dass sie mit dem Wert nichts anfangen können und deshalb besser auf ihre Standardwerte zurückgreifen, als etwas falsches anzunehmen. Und da Trennung durch ';' für alle Tags durchaus üblich ist, sollten wahrscheinlich auch Programme mit maxspeed=50;20:00-08:00 30 zumindest den ersten Wert korrekt auswerten können, auch wenn sie das erweiterte Schema nicht verarbeiten können. Dann geht zwar der oben genannte Vorteil wieder verloren, aber zumindest liegt die Entscheidung dann mehr in der Hand des Anwendungsprogrammierers.

Netzwolf · 2010-12-14 14:12:09

Nahmd,

errt wrote:

Ich bin mir nicht sicher, ob es wirklich eine gute Idee ist, den stärker beschränkenden Wert in das bisherige Tag zu packen und andere Beschränkungen in ein neues.
Besonders deutlich finde ich das hier:
Netzwolf wrote:
maxspeed = 30
maxspeed/1 = 50 @ 08:00-20:00
Auf dieser Straße wären 50% des Tages 50km/h, und zwar auch während der Hauptverkehrszeiten. Also sollte ein Router auch am ehesten 50km/h annehmen.

Dann dreh es halt rum:

maxspeed = 50
maxspeed/1 = 30 @ 20:00-08:00

errt wrote:

Verwendet man nur einen Schlüssel, hat man den Vorteil, dass Programme, die die erweiterten Bedingungen nicht verstehen wenigstens erkennen können, dass sie mit dem Wert nichts anfangen können und deshalb besser auf ihre Standardwerte zurückgreifen, als etwas falsches anzunehmen.

Warum ist Standardwert richtiger als einer der beiden vor Ort erfassten?

errt wrote:

Und da Trennung durch ';' für alle Tags durchaus üblich ist, sollten wahrscheinlich auch Programme mit maxspeed=50;20:00-08:00 30 zumindest den ersten Wert korrekt auswerten können, auch wenn sie das erweiterte Schema nicht verarbeiten können.

Ich sehe das als semantische Panscherei. Wenn ich schreibe

tag=wert1; wert2; wert3

dann gehe ich davon aus, dass ein Überprüfungsprogamm, das "tag=wert" überprüfen kann, genutzt werden kann, indem man nacheinander "tag=wert1", "tag=wert2", "tag=wert3" prüft. Oder mit anderen Worten: jede einzelne der durch ";" getrennten Werte sollte der Überprüfung standhalten. Oder nochmal anders ausgedrückt: die ";"-Schreibweise steht für ein Array mit Elementen eines bestimmten Typs.

Mir persönlich gefiele am besten etwas in dieser Art:

maxspeed = 50
maxspeed[nachts] = 30
cond:nachts = 20:00-08:00

shop = books
access = public
shop[nachts] = books; schweinkram
access[nachts] = adult
cond:nachts = 22:00-06:00

Vorteil: kompatibel, der Namensraum der Tags bleibt sauber, die Wertefelder sind klar typisiert und validierbar, eine Bedingung kann mehrfach genutzt werde, die Bedeutung von ";" in den Werten bleibt unberührt, die Feldwerte werden nicht überlang.
Nachteil: mehr Tags. Und ich mach mich als Typsauberkeitsextremist zum Monk.

errt wrote:

Dann geht zwar der oben genannte Vorteil wieder verloren, aber zumindest liegt die Entscheidung dann mehr in der Hand des Anwendungsprogrammierers.

Hmm. Also.
Wie eine nicht-zeitabhängig-getaggt-enabled Applikation mit erweiterten Daten umgeht, kann nur der Mapper entscheiden durch Vorgabe eines Default-Wertes. Das ist deshalb nicht Entscheidung des Anwendungsprogrammieres, weil es die erweiterte Form während der Programmierung der Anwendung noch nicht gab. Und ich erwarte nicht, dass jemand Code nachrüstet, um eine erweiterte Darstellung zu erkennen *ohne sie dann auch vollständig zu nutzen*.

Gruß Wolf (heute inkarniert als Monk)

Tordanik · 2010-12-15 21:36:15

Netzwolf wrote:

Mir persönlich gefiele am besten etwas in dieser Art:
maxspeed = 50
maxspeed[nachts] = 30
cond:nachts = 20:00-08:00

Gegen diese Schreibweise hätte ich nicht allzu viel, allerdings finde ich die Auslagerung in bestimmten Fällen ein wenig umständlich. Ein

maxspeed[sonntags] = ...
sonntags = Su"

ist doch ein ziemlicher Aufwand im Vergleich zu einem maxspeed[Su] (oder, per "Extended Conditions"-Syntax, maxspeed:Su).

Vorteil: kompatibel, der Namensraum der Tags bleibt sauber, die Wertefelder sind klar typisiert und validierbar, eine Bedingung kann mehrfach genutzt werde, die Bedeutung von ";" in den Werten bleibt unberührt, die Feldwerte werden nicht überlang.
Nachteil: mehr Tags. Und ich mach mich als Typsauberkeitsextremist zum Monk.

Kompatibilität, keine Überladung des Semikolons, kurze Werte und die validierbaren Wertefelder gibt es auch mit "Extended Conditions" (wobei dort das Zeitintervall natürlich kein Wertefeld ist), und die Anzahl der Tags ist bei EC geringer. Ich glaube ehrlich gesagt nicht, dass eine Mehrfachverwendung von Bedingungen so häufig vorkommt - zumal dadurch auch nur dann ein Vorteil entsteht kommt, wenn der "Variablenname" deutlich kürzer als die Bedingung selbst ist.

Um die Sicht auf das Problem zu vervollständigen: Dieser ganze Thread hat ja als Aufhänger die Behauptung, dass Zeitintervalle aus Sicht der Auswertung im Schlüssel nicht wünschenswert sind:

GeoCounter wrote:

Beide Probleme werden in dem zweiten Proposal gelöst, allerdings wandert dabei der Zeitbereich aus dem Wert in den Schlüssel was die Auswertung erschwert.

Aber es fehlt noch die Begründung dafür. Könnte man die evtl. noch nachreichen?

GeoCounter · 2010-12-16 01:32:17

Tordanik wrote:

Aber es fehlt noch die Begründung dafür. Könnte man die evtl. noch nachreichen?

Eine Schwierigkeit die mir spontan einfällt ist, dass z.B. die Darstellung in Tagwatch erschwert wird. Ansonsten hast du natürlich recht, dass umfangreiche Bedingungen im Key ungewohnt erscheinen und deshalb erst mal "unheimlich" sind.

Tordanik wrote:

Du ziehst eine Bedingung in den Schlüssel, nämlich hgv - warum speziell diese? Weil Verkehrsmittel ein "enum" sind, im Gegensatz zu z.B. Zeitintervallen?

Stimmt das ist auch eine Bedingung, aber solche einfache Schachtelungen von Keys sind ja recht verbreitet.

Ich muss sagen, dass ich die Komplexität dieser Thematik etwas unterschätzt habe. Mein Ansatz war nur, das Wertefeld als "Funktion" aufzufassen, die in Abhängigkeit von Bedingungen den Endwert zurückgibt. Für zeitliche Bedingungen könnte man dafür das opening_hours Schema direkt verwenden.

Deine Erläuterungen finde ich recht überzeugend. Letztlich ist es wohl eine Abwägung, ob man die Bedingung im Schlüssel oder im Wert unterbringt. Beides war ursprünglich nicht dafür gedacht (kann man das so sagen?) und eine optimale Lösung gibt es wohl nicht.

Hast du das Voting im Wiki nicht eröffnet weil einige Fragen nicht endgültig ausdiskutiert waren? Nach näherer Betrachtung erscheint es mir recht ausgereift, hältst du es für sinnvoll es auch ohne formale Einigung anzuwenden?

Gruß
GeoCounter

Netzwolf · 2010-12-16 02:39:05

Moin,

noch ein paar Gedanken:

→ Ich sehe in "maxspeed:hgv" einen Key und nicht einen Key mit einer "Bedingung".

Ich würde gerne bei Keys dieser Form das erste Element als eine Art Typ betrachten: "maxspeed" macht klar, dass die rechte Seite mit den Regeln für "maxspeed" validiert wird, der eigentliche Key aber bleibt "maxspeed:hgv". Bei dieser Sichtweise würde man auch "time:service" statt service_times und "times:collection" statt collection_times schreiben und förderte die Kreativität der Mapper: "times:departure". Das ist aber eine ganz andere Baustelle.

→ Ich sehe keinen Gewinn darin, so unterschiedliche Konzepte wie Öffnungszeiten (mit ihrer sehr großen Wertemenge) und Attribute von Verkehrsteilnehmern (mit einer sehr überschaubaren Menge) zusammenzuwerfen.

→ Ich möchte (insbesondere längere) Daten lieber im Value als im Key sehen.

→ Ich mag Namensraumpanscherei nicht: ist "maxspeed:su" die Höchstgeschwindigkeit für Sonder-U-Bahnen (SU), für russische Fahrzeuge (SU), oder an Sonntagen (SU)?

Beobachtungen bei der Auswertung der opening_hours–Werte:

→ Klammern und Escaping sind in der Theorie etwas feines, in der Praxis überfordern sie den Mapper.
→ Lieber geschwätzigere Eingaben als fehlerträchtige Kurzschreibweisen.
→ Ein Feld, ein Typ. In einem Feld Daten aus verschiedenen Bereichen mischen (z.B. Key, Bedingung, Zeit) schreit geradezu nach Fehltagging.

Gruß Wolf

dt2 · 2010-12-16 05:08:21

Tordanik wrote:

GeoCounter wrote:
Beide Probleme werden in dem zweiten Proposal gelöst, allerdings wandert dabei der Zeitbereich aus dem Wert in den Schlüssel was die Auswertung erschwert.
Aber es fehlt noch die Begründung dafür. Könnte man die evtl. noch nachreichen?

Man muss eben statt nur nach z.B. den Schlüsseln "maxspeed" und "maxspeed:except" zu suchen, nach "maxspeed" bzw. "maxspeed:*" suchen. Je nach Voraussetzungen kann das sehr einfach über weniger effizient bis hin zu unmöglich sein. Hat man die Bedingungen im Wert, kann man eben den Tag ansich erstmal leicht finden. Auswerten muss man die Bedingung natürlich so oder so, aber im Wert scheint es mir schon etwas schöner.

Bei Bedingungen wie "hgv" die in der Anzahl beschränkt sind, bin ich mir allerdings nicht so sicher. Da hat es dann eventuell wieder Vorteile, das im Schlüssel zu haben. Wenn man die Geschwindigkeit für LKW haben möchte, schaut man eben erst nach maxspeed:hgv=* und falls der nicht existieren sollte nach maxspeed=*. Wäre alles in maxspeed=* mit entsprechenden Bedingungen, müsste man eben erstmal bisschen rumparsen.

Netzwolf wrote:

Ich würde gerne bei Keys dieser Form das erste Element als eine Art Typ betrachten: "maxspeed" macht klar, dass die rechte Seite mit den Regeln für "maxspeed" validiert wird, der eigentliche Key aber bleibt "maxspeed:hgv". Bei dieser Sichtweise würde man auch "time:service" statt service_times und "times:collection" statt collection_times schreiben und förderte die Kreativität der Mapper: "times:departure". Das ist aber eine ganz andere Baustelle.

Dann könnte man auch "speed:max" schreiben, der Typ ist ja eine Geschwindigkeit. Und was wäre dann "times"? Immer einer odere mehrere Zeitpunkte? Oder könnten es auch Intervalle sein?

Netzwolf wrote:

→ Ich mag Namensraumpanscherei nicht: ist "maxspeed:su" die Höchstgeschwindigkeit für Sonder-U-Bahnen (SU), für russische Fahrzeuge (SU), oder an Sonntagen (SU)?

Was ist mit :forward/:backward, das ist auch mit maxspeed benutzbar. (Sicherlich nicht so leicht zu verwechseln, aber trotzdem eine andere "Klasse" an der gleichen Stelle.)

Netzwolf wrote:

→ Klammern und Escaping sind in der Theorie etwas feines, in der Praxis überfordern sie den Mapper.
→ Lieber geschwätzigere Eingaben als fehlerträchtige Kurzschreibweisen.
→ Ein Feld, ein Typ. In einem Feld Daten aus verschiedenen Bereichen mischen (z.B. Key, Bedingung, Zeit) schreit geradezu nach Fehltagging.

Was meinst du damit genau? Kannst du Beispiele nennen?

Tordanik · 2010-12-16 08:39:06

dt2 wrote:

Man muss eben statt nur nach z.B. den Schlüsseln "maxspeed" und "maxspeed:except" zu suchen, nach "maxspeed" bzw. "maxspeed:*" suchen. Je nach Voraussetzungen kann das sehr einfach über weniger effizient bis hin zu unmöglich sein. Hat man die Bedingungen im Wert, kann man eben den Tag ansich erstmal leicht finden.

Ok, so hatte ich das dann auch verstanden.
Allerdings funktioniert das auch z.B. bei Wolfs Vorschlag mit maxspeed[nachts]=... + cond:nachts=... nicht. Nicht nur muss man dort ebenfalls nach maxspeed[ *] suchen, man kann sogar nicht mal mehr nur anhand des einzelnen Schlüssels entscheiden, ob der Tag für maxspeed relevant ist. Dazu müsste man erst alle maxspeed-Tags dahingehend auswerten, welche Bedingungen dort referenziert werden, um dann noch die Bedingungs-Tags zu sammeln.

Bei Bedingungen wie "hgv" die in der Anzahl beschränkt sind, bin ich mir allerdings nicht so sicher. Da hat es dann eventuell wieder Vorteile, das im Schlüssel zu haben. Wenn man die Geschwindigkeit für LKW haben möchte, schaut man eben erst nach maxspeed:hgv=* und falls der nicht existieren sollte nach maxspeed=*. Wäre alles in maxspeed=* mit entsprechenden Bedingungen, müsste man eben erstmal bisschen rumparsen.

Richtig, da ist aus "praktischer" Sicht das maxspeed:hgv=* gar nicht so schlecht. Letztlich gibt es bei den Bedingungen recht unterschiedliche Problemausprägungen:

einzelne "beschränkte" Bedingungen, wie maxspeed:hgv
mehrere "beschränkte" Bedingungen, wie maxspeed:hgv:wet (oder maxspeed:wet:hgv ...)
einzelne oder mehrere "unendliche" Bedingungen, wie maxspeed:(08:00-20:00)

Ich hätte ursprünglich gerne alle auf die gleiche Weise ausgedrückt, zugunsten der Konsistenz. Aber vielleicht ist es ja pragmatischer, hier zu unterschiedlichen Lösungen zu greifen? Für den ersten Fall scheint sich das Konzept von "Conditions for access tags" ja schon so gut eingeprägt zu haben, dass er nicht mal mehr als "Bedingung" wahrgenommen wird.

Netzwolf wrote:

Klammern und Escaping sind in der Theorie etwas feines, in der Praxis überfordern sie den Mapper.

Und du glaubst, Variablendefinitionen überfordern den Mapper nicht? Versteht der Mapper, dass in deinen Beispielen "nacht" auch "winter" heißen könnte, ohne dass sich die Bedeutung ändert? Kann sein, aber meiner Einschätzung nach ist auch das kein allgemein intuitiv verständliches Konzept.

Zu ein paar anderen Stellen hat dt2 schon nachgefragt, das würde mich auch interessieren.

GeoCounter wrote:

Letztlich ist es wohl eine Abwägung, ob man die Bedingung im Schlüssel oder im Wert unterbringt. Beides war ursprünglich nicht dafür gedacht (kann man das so sagen?) und eine optimale Lösung gibt es wohl nicht.

Genau darin sehe ich nach längerer Beschäftigung mit dem Thema auch das allgemeine Problem: Es gibt einfach keine Lösung, bei der man nicht auf bestimmte wünschenswerte Features verzichten muss.

Wenn man z.B. am wichtigsten findet, dass man sowohl eine endliche Menge von Schlüsseln als auch gut "typisierte" Werte hat, dann wird man wohl bei einer Relation herauskommen - das wurde auch in vergangenen Diskussionen durchaus vorgeschlagen. Und in der Tat wäre in dieser Hinsicht eine Relation auch optimal:

maxspeed = 80
cond:vehicle = hgv
cond:time = 08:00-20:00

Hätte aber eben wieder andere Nachteile. Insbesondere kann man es von Hand schwer bearbeiten.

Hast du das Voting im Wiki nicht eröffnet weil einige Fragen nicht endgültig ausdiskutiert waren? Nach näherer Betrachtung erscheint es mir recht ausgereift, hältst du es für sinnvoll es auch ohne formale Einigung anzuwenden?

Es gab leider ziemlich viel Widerstand in der vorausgehenden Diskussion, auch von verschiedenen "prominenten" Entwicklern. Angesichts der schwachen Stellung der Wiki-Votes allgemein würde eine erfolgreiche Abstimmung kaum ernst genommen oder gar als bindend gesehen werden. Eine gelungene Umsetzung in einer praktischen Anwendung hätte wohl weit mehr Gewicht, aber derzeit habe ich bei diesem Thema so etwas nicht in der Hand.

Andererseits: Eine Ablehnung in einer Abstimmung würde mir auch irgendwie wenig sagen. Ja, es gibt gute Argumente gegen den Vorschlag, aber eben auch gegen alle denkbaren Alternativen. Da ist ein schlichtes "Nein" ohne Gegenvorschlag unkonstruktiv. Wenn es ein ausdefinierten Vorschlag für eine der Alternativideen gäbe, dann wäre eine Abstimmung darüber, welche Variante mehr Gefallen findet (oder als kleineres Übel gesehen wird), sehr interessant!

Ob man es derzeit verwenden sollte? Man sollte sich im Klaren sein, dass dieses Schema womöglich nie ausgewertet werden wird. Da es bei der Auswertung des normalen Taggings nicht stört, schadet die Verwendung allerdings nicht. Zumindest ist es ein wenig besser, wenn die Information schon mal in einigermaßen unmissverständlicher und maschinenlesbarer Form vorliegt, als wenn sie gar nicht eingetragen wird.

Last edited by Tordanik (2010-12-16 08:40:03)

flaimo · 2011-03-18 11:49:13

ich finde die notation von netzwolf ansich gut, allerdings bin ich der meinung dass conditions immer auf elemente angebracht werden sollen und nicht umgekehrt. also bicycle:oneway und nicht oneway:bicycle. aus programmatischer sicht macht es auch mehr sinn die regeln nach transportmittel oder zielgruppe zu gruppieren, da zB routingprogramme so schneller zu den für das aktuelle gefährt relevanten daten kommen und nicht immer überall alle tags durchforsten müssen nach dem keyword für das transportmittel.

ich hab mir auch drüber gedanken gemacht und "my two cents" in den kommentaren zum mittlerweile angestaubten access proposal geschrieben: http://wiki.openstreetmap.org/wiki/Talk … new_scheme
die notation ähnelt dem vom netzwolf in manchen punkten mit dem unterschied, dass ich versucht habe, die daten auf weniger tags aufzulösen, die dadurch natürlich länger werden.

generell denke ich, dass wir nie zu einer lösung finden werden solange wir nach dem heiligen gral suchen. es gibt die anforderung, dass es einfach zu taggen sein muss, dass es nicht zuviele tags werden, das es präzise ist und alle noch so abstrusen situationen berücksichtigen soll. ich glaube nicht, dass es möglich ist all das abzudecken. mit dem steigenden detaillierungsgrad werden auch die tags zahlreicher, länger und komplexer und die ständige berücksichtigung von neulingen bremst die weiterentwicklung von taging schemen immer mehr. es obliegt eigentlich den editoren hier ein vernünftig bedienbares userinterface zu schaffen, dass einen möglichst einfachen tagging-zugang ermöglicht, ohne sich die ganze zeit durchs wiki graben zu müssen. auf dauer muss für den ottonormal-mapper sowieso eine abstraktionsschicht vor die tag-liste eingeschoben werden. im prinzip das, was die josm presets jetzt schon rudimentär machen. die ganze thematik ist aber nicht neu. ist ja bei wikipedia auch nicht anders gewesen. früher war es einfach wie es noch wenige user und artikel waren, jetzt gibt es einen haufen anforderungen bevor es ein artikel online schafft.

der eigentliche grund wieso ich mal wieder mit der nase in die access-problematik gestoßen wurde war, weil ich gerade mein erstes proposal für parkplätze geschrieben habe und dort die access thematik auch reinspielt (stichwort: "parken nur für kunden"). http://wiki.openstreetmap.org/wiki/Prop … es/parking

Last edited by flaimo (2011-03-18 11:49:55)

Announcement

#1 2010-12-13 18:07:10

Bedingte Access Beschränkungen

#2 2010-12-13 20:02:08

Re: Bedingte Access Beschränkungen

#3 2010-12-13 20:50:33

Re: Bedingte Access Beschränkungen

#4 2010-12-14 00:00:02

Re: Bedingte Access Beschränkungen

#5 2010-12-14 00:53:24

Re: Bedingte Access Beschränkungen

#6 2010-12-14 10:54:56

Re: Bedingte Access Beschränkungen

#7 2010-12-14 12:31:37

Re: Bedingte Access Beschränkungen

#8 2010-12-14 12:57:17

Re: Bedingte Access Beschränkungen

#9 2010-12-14 13:20:16

Re: Bedingte Access Beschränkungen

#10 2010-12-14 14:12:09

Re: Bedingte Access Beschränkungen

#11 2010-12-15 21:36:15

Re: Bedingte Access Beschränkungen

#12 2010-12-16 01:32:17

Re: Bedingte Access Beschränkungen

#13 2010-12-16 02:39:05

Re: Bedingte Access Beschränkungen

#14 2010-12-16 05:08:21

Re: Bedingte Access Beschränkungen

#15 2010-12-16 08:39:06

Re: Bedingte Access Beschränkungen

#16 2011-03-18 11:49:13

Re: Bedingte Access Beschränkungen

Board footer