Re: [Talk-de] Proposal: access-Tags mit Bedingungen
Am 17. Juni 2009 00:03 schrieb Tobias Knerr o...@tobias-knerr.de: Na ja, nachdem sich hier wohl sonst niemand mehr zu Wort melden wird, habe ich mal eine Komplettversion aus den Einzelbestandteilen der bisherigen Proposals erstellt und einen Poll zur Klammersyntax eingestellt. http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for_access_tags Danke, habe mal einen Crosspost auf der hießigen lokalen Liste gemacht. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Proposal: access-Tags mit Bedingungen
Am Mittwoch 17 Juni 2009 schrieb Tobias Knerr: Guenther Meyer schrieb: alle verbotszeichen die ich kenne, und jemals gesehen habe, und mit gewichten zu tun haben, sprechn von gewichten über dem angegeben wert. genau so bei laengen-, breiten, und hoehenbeschraenkungen. wenn also sowieso immer die rede von groesser ist, kann man das zeichen auch weglassen. Man lässt das Zeichen aber nicht nur weg. Man ersetzt es durch ein anderes, das weder schneller zu tippen noch kürzer ist und auch sonst keine Vorteile bringt. Bei zwei ansonsten gleichwertigen Zeichen ist auch eine noch so kleine Verbesserung der Eindeutigkeit genug, um den Ausschlag zu geben, oder? prinzipiell schon. bei laengen/hoehen/breiten machts keine unterschied, da length/width/height sowieso angegeben werden muss. aber wie bereits geschrieben, ist bei gewichtsangaben das zulaessige gesamtgewicht der standardfall, und da sehe ich durchaus eine vereinfachung: access[weight5.5t]=no -- access[5.5t]=no aber wenn's nicht gefaellt, hab ich auch kein problem damit. Na ja, nachdem sich hier wohl sonst niemand mehr zu Wort melden wird, habe ich mal eine Komplettversion aus den Einzelbestandteilen der bisherigen Proposals erstellt und einen Poll zur Klammersyntax eingestellt. http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_fo r_access_tags Passt das so (außer dem Diskussionspunkt mit den Attributen/Operatoren und der opening_hours-Syntax? Ggf. gerne noch was ändern, gerade an der Begründung/Argumentation im Syntax-Abschnitt. sieht gut aus. zwei dinge: erstens wuerde ich die uhrzeit prinzipiell ohne doppelpunkte schreiben, und zweitens generell eine einheit angeben, also t fuer gewichte, m fuer laengen/hoehen/breiten, und h fuer uhrzeiten. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Proposal: access-Tags mit Bedingungen
Guenther Meyer schrieb: erstens wuerde ich die uhrzeit prinzipiell ohne doppelpunkte schreiben, Na ja, wie schon mal geschrieben ist die Zeitsyntax ja keine Eigenentwicklung, und ich hielte es eher für sinnvoll, darüber (oder generell über Vereinfachungen/Verbesserungen der Zeitsyntax) an der Quelle, d.h. bei opening_hours, zu diskutieren. Ich finde die Syntax abgesehen davon ganz ok - legt nahe, dass es sich um eine Zeit handelt, und macht die Sache durch die optische Trennung leserlicher. Ich nehme an, es geht dir um die Verwechslungsmöglichkeit mit der Verwendung des Doppelpunkts als Namespace/Trennzeichen? und zweitens generell eine einheit angeben, also t fuer gewichte, m fuer laengen/hoehen/breiten, und h fuer uhrzeiten. Auch hier habe ich mich eigentlich ausdrücklich an vorhandene Standards gehalten, namentlich die max*-Keys. Gibt es einen Grund, warum das Angeben von Einheiten in einer Condition anders gehandhabt werden soll als bei max*-Values? Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Proposal: access-Tags mit Bedingungen
Am Donnerstag 18 Juni 2009 schrieb Tobias Knerr: Guenther Meyer schrieb: erstens wuerde ich die uhrzeit prinzipiell ohne doppelpunkte schreiben, Na ja, wie schon mal geschrieben ist die Zeitsyntax ja keine Eigenentwicklung, und ich hielte es eher für sinnvoll, darüber (oder generell über Vereinfachungen/Verbesserungen der Zeitsyntax) an der Quelle, d.h. bei opening_hours, zu diskutieren. sinnvoll, ja. Ich finde die Syntax abgesehen davon ganz ok - legt nahe, dass es sich um eine Zeit handelt, und macht die Sache durch die optische Trennung leserlicher. naja, ich finde die militaerische schreibweise auch nicht schlechter lesbar. und durch die angabe des 'h' (wie auch auf den entsprechenden verkehrszeichen) dahinter ist es eindeutig als zeitangabe identifizierbar. Ich nehme an, es geht dir um die Verwechslungsmöglichkeit mit der Verwendung des Doppelpunkts als Namespace/Trennzeichen? richtig. und zweitens generell eine einheit angeben, also t fuer gewichte, m fuer laengen/hoehen/breiten, und h fuer uhrzeiten. Auch hier habe ich mich eigentlich ausdrücklich an vorhandene Standards gehalten, namentlich die max*-Keys. Gibt es einen Grund, warum das Angeben von Einheiten in einer Condition anders gehandhabt werden soll als bei max*-Values? es wird eindeutiger. schliesslcih haben wir hier im selben bereich des tags verschiedenste angaben (laengen,breiten,hoehen,gewichte,klassen, ...) durch eine anga der einheit wird absolut klar, worum es geht. man koennte natuerlich auch argumentieren, bei weggelassener einheit bestimmte metrische standards (meter, tonnen) zu implizieren. spaetestens wenn aber imperiale groessen benutzt werden, ist die angabe zwingend. bei maxspeed ist es glaub ich aehnlich... signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Proposal: access-Tags mit Bedingungen
Guenther Meyer schrieb: alle verbotszeichen die ich kenne, und jemals gesehen habe, und mit gewichten zu tun haben, sprechn von gewichten über dem angegeben wert. genau so bei laengen-, breiten, und hoehenbeschraenkungen. wenn also sowieso immer die rede von groesser ist, kann man das zeichen auch weglassen. Man lässt das Zeichen aber nicht nur weg. Man ersetzt es durch ein anderes, das weder schneller zu tippen noch kürzer ist und auch sonst keine Vorteile bringt. Bei zwei ansonsten gleichwertigen Zeichen ist auch eine noch so kleine Verbesserung der Eindeutigkeit genug, um den Ausschlag zu geben, oder? Na ja, nachdem sich hier wohl sonst niemand mehr zu Wort melden wird, habe ich mal eine Komplettversion aus den Einzelbestandteilen der bisherigen Proposals erstellt und einen Poll zur Klammersyntax eingestellt. http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for_access_tags Passt das so (außer dem Diskussionspunkt mit den Attributen/Operatoren und der opening_hours-Syntax? Ggf. gerne noch was ändern, gerade an der Begründung/Argumentation im Syntax-Abschnitt. Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Proposal: access-Tags mit Bedingungen
Guenther Meyer schrieb: ich wuerde lieber keine doppelpunkte nehmen, das sieht fuer mich irgendwie eher nach einer mehrstufigen hierarchie aus. Das ist ein berechtigter Einwand. Zumal vor dem Hintergrund von Vorschlägen wie der left/right-Syntax und der häufigen Verwendung als Behelfs-Namespace die Doppelpunkte möglicherweise verwirrend bis irreführend sind. Ich hatte ja eigentlich auf etwas mehr Feedback und damit ein klareres Meinungsbild hinsichtlich dieser Frage gehofft. Momentan neige ich ja auch etwas dazu, hier auf eckige Klammern umzusteigen. ich wuerde das ganze auch relativ einfach schreiben: also z.B. fuer 5,5t gewicht [5.5t] Das ist aber leider nicht mehr eindeutig. Eine Längenangabe könnte eine Höhe, Breite oder Länge sein. Und eine Gewichtsangabe nicht nur für Gesamtgewicht, sondern z.B. auch für Achslast stehen. fuer zeitliche einschraenkungen z.B. [Mon-Wed] oder [0800-1200h] Das time weglassen ist machbar, da stimme ich zu - die Werte sind auch so als Zeiten erkennbar. Bei den Zeitformatierungen würde ich mich allerdings doch an die vorhandene, etwa bei opening_hours verwendete Syntax halten (also in deinen Beispielen Mo-We und 08:00-12:00). Ich halte wenig davon, sich bei jedem Tag eine andere Zeitsyntax auszudenken. Natürlich spricht nichts dagegen, die Zeitsyntax generell (also auch bei anderen Werten) zu verbessern, aber das ist dann keine unmittelbar auf mein Proposal bezogene Thematik. meine logik waere auch, dass alles was hintereinander steht, und-verknüpft ist. genauer spezifizierte einschraenkungen haben vorrang vor allgemeinen. Bei dieser Auswertungslogik stimme ich zu, das habe ich ja auch im Ursprungsproposal so dargestellt. Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Proposal: access-Tags mit Bedingungen
Am Donnerstag 11 Juni 2009 schrieb Tobias Knerr: ich wuerde das ganze auch relativ einfach schreiben: also z.B. fuer 5,5t gewicht [5.5t] Das ist aber leider nicht mehr eindeutig. Eine Längenangabe könnte eine Höhe, Breite oder Länge sein. Und eine Gewichtsangabe nicht nur für Gesamtgewicht, sondern z.B. auch für Achslast stehen. stimmt, manchmal wird ja zwischen gesamtgewicht und achslast unterschieden.. dann vielleicht eher so: [weight:7.5t] [axleload:5.5t] [lenght:14m] [height:3.9m] [width:1.9m] wobei ich bei einer gewichtsangabe ohne schluessel automatisch weight, also das gesamtgewicht implizieren wuerde; ist nunmal das meistgebrauchte gewicht... fuer zeitliche einschraenkungen z.B. [Mon-Wed] oder [0800-1200h] Das time weglassen ist machbar, da stimme ich zu - die Werte sind auch so als Zeiten erkennbar. Bei den Zeitformatierungen würde ich mich allerdings doch an die vorhandene, etwa bei opening_hours verwendete Syntax halten (also in deinen Beispielen Mo-We und 08:00-12:00). Ich halte wenig davon, sich bei jedem Tag eine andere Zeitsyntax auszudenken. ob man die wochentage jetzt mit zwei oder drei buchstaben abkuerzt, ist mir eigentlich egal. ich fand halt drei buchstaben den besten kompromiss zwischen kuerze und lesbarkeit. die doppelpunkte in zeitangaben wuerde ich definitiv weglassen, da die erstens ueberfluessig sind, und zweitens mit anderen als trenner gesetzten doppelpunkten verwechselt werden koennten. diese schreibweise ist uebrigens durchaus gebraeuchlich. das format sollte aber natuerlich fuer alle tags identisch sein, da stimme ich dir zu. Natürlich spricht nichts dagegen, die Zeitsyntax generell (also auch bei anderen Werten) zu verbessern, aber das ist dann keine unmittelbar auf mein Proposal bezogene Thematik. naja, aber das kann man dann auch gleich mitnehmen... ;-) meine logik waere auch, dass alles was hintereinander steht, und-verknüpft ist. genauer spezifizierte einschraenkungen haben vorrang vor allgemeinen. Bei dieser Auswertungslogik stimme ich zu, das habe ich ja auch im Ursprungsproposal so dargestellt. schoen, das wir uns einig sind :-) signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Proposal: access-Tags mit Bedingungen
Guenther Meyer schrieb: also z.B. fuer 5,5t gewicht [5.5t] Das ist aber leider nicht mehr eindeutig. Eine Längenangabe könnte eine Höhe, Breite oder Länge sein. Und eine Gewichtsangabe nicht nur für Gesamtgewicht, sondern z.B. auch für Achslast stehen. stimmt, manchmal wird ja zwischen gesamtgewicht und achslast unterschieden.. dann vielleicht eher so: [weight:7.5t] [axleload:5.5t] [lenght:14m] [height:3.9m] [width:1.9m] Wo ist da noch der Vorteil gegenüber [weight7.5t]? Gleiche Zeichenzahl, aber mit ist es unmissverständlicher. Ich halte Fehlinterpretationen als Gewicht bis zu etc. sonst durchaus für möglich. wobei ich bei einer gewichtsangabe ohne schluessel automatisch weight, also das gesamtgewicht implizieren wuerde; ist nunmal das meistgebrauchte gewicht... Kann man an sich schon machen. Erfordert aber dann natürlich die Einheit, um überhaupt ein Erkennungsmerkmal zu haben - die ist bei rein numerischen Werten sonst implizierbar. Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Proposal: access-Tags mit Bedingungen
Am Donnerstag 11 Juni 2009 schrieb Tobias Knerr: Guenther Meyer schrieb: also z.B. fuer 5,5t gewicht [5.5t] Das ist aber leider nicht mehr eindeutig. Eine Längenangabe könnte eine Höhe, Breite oder Länge sein. Und eine Gewichtsangabe nicht nur für Gesamtgewicht, sondern z.B. auch für Achslast stehen. stimmt, manchmal wird ja zwischen gesamtgewicht und achslast unterschieden.. dann vielleicht eher so: [weight:7.5t] [axleload:5.5t] [lenght:14m] [height:3.9m] [width:1.9m] Wo ist da noch der Vorteil gegenüber [weight7.5t]? Gleiche Zeichenzahl, aber mit ist es unmissverständlicher. Ich halte Fehlinterpretationen als Gewicht bis zu etc. sonst durchaus für möglich. alle verbotszeichen die ich kenne, und jemals gesehen habe, und mit gewichten zu tun haben, sprechn von gewichten über dem angegeben wert. genau so bei laengen-, breiten, und hoehenbeschraenkungen. wenn also sowieso immer die rede von groesser ist, kann man das zeichen auch weglassen. wobei ich bei einer gewichtsangabe ohne schluessel automatisch weight, also das gesamtgewicht implizieren wuerde; ist nunmal das meistgebrauchte gewicht... Kann man an sich schon machen. Erfordert aber dann natürlich die Einheit, um überhaupt ein Erkennungsmerkmal zu haben - die ist bei rein numerischen Werten sonst implizierbar. die einheit muss natuerlich immer notiert werden, ganz klar. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Proposal: access-Tags mit Bedingungen
Am Mittwoch 10 Juni 2009 schrieb Werner König: Hi, ich denke, zu diesen Themen sollte es Standards geben (haben sich oft bewährt, Ausnahmen bestätigen die Regel), klar beschrieben und von der Mehrheit der Mapper bevollgt werden. ach was... genau darum geht es hier doch ;-) man kann zwar durchaus ein system ausarbeiten, das funktioniert, und dieses auch bewerben. ob es allerdings von der mehrzahl der mapper angenommen wird, kann keiner sagen. wenn es aber nicht zu kompliziert ist, im wiki gut dokumentiert, und vielleicht auch noch von ein paar anwendungen (insbesondere den editoren) unterstuetzt wird, dann sind die chancen relativ hoch, denken ich. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Proposal: access-Tags mit Bedingungen
Am Dienstag 09 Juni 2009 schrieb Tobias Knerr:
Die Grundidee ist schnell erklärt: Manche Vorschriften (access,
maxspeed, oneway ...) gelten in der Realität nur unter bestimmten
Bedingungen. Die Bedingungen können dabei alles mögliche sein, etwa der
Fahrzeugtyp, die Uhrzeit oder das Wetter. Das Proposal schlägt hier vor,
diese Bedingungen (für die es natürlich auch vorgegebene Bezeichnungen
gibt) in beliebiger Reihenfolge durch Doppelpunkte getrennt an den
Basiskey (also access, maxspeed etc.) zu schreiben.
Doppelpunkte übrigens einfach deshalb, weil sie fast schon das
Default-OSM-Trennzeichen sind, ohne erkennbare Semantik. Ich hätte aber
auch nichts gegen z.B. eckige Klammern, wie sie manchmal vorgeschlagen
würden -- da wir auch zu sehr vielen anderen Zwecken Doppelpunkte
verwenden, würde das vielleicht die Unterscheidung erleichtern, und man
könnte auf das time{...} bei den Zeiten verzichten. Gerade zu solchen
syntaktischen Fragen würden mich auch einfache subjektive Meinungen also
durchaus freuen.
ich wuerde lieber keine doppelpunkte nehmen, das sieht fuer mich irgendwie
eher nach einer mehrstufigen hierarchie aus.
ich wuerde das ganze auch relativ einfach schreiben:
also z.B. fuer 5,5t gewicht [5.5t]
fuer zeitliche einschraenkungen z.B. [Mon-Wed] oder [0800-1200h]
meine logik waere auch, dass alles was hintereinander steht, und-verknüpft
ist. genauer spezifizierte einschraenkungen haben vorrang vor allgemeinen.
beispiel:
hoechstgeschwindigkeit generell beschildert mit 90km/h, fuer lkw 60, nachts
duerfen diese allerdings nur 40 fahren:
maxspeed = 90
maxspeed[7.5t] = 60
maxspeed[7.5t][2200-0600h] = 40
signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Proposal: access-Tags mit Bedingungen
Hi,
ich denke, zu diesen Themen sollte es Standards geben (haben sich oft
bewährt, Ausnahmen bestätigen die Regel), klar beschrieben und von der
Mehrheit
der Mapper bevollgt werden.
Gruß
Werner
-Ursprüngliche Nachricht-
Von: talk-de-boun...@openstreetmap.org
[mailto:talk-de-boun...@openstreetmap.org] Im Auftrag von Tobias Knerr
Gesendet: Dienstag, 9. Juni 2009 23:26
An: Openstreetmap allgemeines in Deutsch
Betreff: [Talk-de] Proposal: access-Tags mit Bedingungen
Hallo Liste,
nachdem in letzter Zeit immer mal wieder Tagging-Probleme zur Sprache
gekommen sind, wie sie mein Proposal Extended conditions for access tags
behandelt (insbesondere zeit- und gewichtsabhängige Beschränkungen), möchte
ich für das Proposal explizit um Feedback bitten
- gerne auf der Liste, ansonsten auf der Diskussionsseite im Wiki:
http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for
_access_tags
Wer es noch nicht kennt, sollte auch das Basis-Proposal berücksichtigen:
http://wiki.openstreetmap.org/wiki/Proposed_features/Conditions_for_access_t
ags
Die Grundidee ist schnell erklärt: Manche Vorschriften (access, maxspeed,
oneway ...) gelten in der Realität nur unter bestimmten Bedingungen. Die
Bedingungen können dabei alles mögliche sein, etwa der Fahrzeugtyp, die
Uhrzeit oder das Wetter. Das Proposal schlägt hier vor, diese Bedingungen
(für die es natürlich auch vorgegebene Bezeichnungen
gibt) in beliebiger Reihenfolge durch Doppelpunkte getrennt an den Basiskey
(also access, maxspeed etc.) zu schreiben.
Doppelpunkte übrigens einfach deshalb, weil sie fast schon das
Default-OSM-Trennzeichen sind, ohne erkennbare Semantik. Ich hätte aber auch
nichts gegen z.B. eckige Klammern, wie sie manchmal vorgeschlagen würden --
da wir auch zu sehr vielen anderen Zwecken Doppelpunkte verwenden, würde das
vielleicht die Unterscheidung erleichtern, und man könnte auf das
time{...} bei den Zeiten verzichten. Gerade zu solchen syntaktischen
Fragen würden mich auch einfache subjektive Meinungen also durchaus freuen.
Tobias Knerr
PS: Das kommt natürlich auch noch auf talk, aber auf den deutschsprachigen
Kanälen (ML, Forum) wird deutlich häufiger Bedarf an solchen
Ausdrucksmöglichkeiten angemeldet, warum auch immer -- daher zuerst hier.
___
Talk-de mailing list
Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
