Proposal: Einschränkungen von Beschränkungen

SunCobalt · 2012-06-15 17:47:10

ich habe das Proposal wieder gelöscht. Mit solchen Unsymphaten wie Eckhart will ich nichts zu tun haben. @Tordanik: Ich habe mich vorhin auf der ML aus Versehen als Autor Deines alten Proposals bezeichnet, statt des auf Deinem aufbauenden, leicht erweitertem neuen Proposals. Bin mit den Bezeichungen durcheinander bekommen. Tut mir leid.

aighes · 2012-06-27 17:45:50

Das Proposal von Tordanik steht aktuell zur Abstimmung...

http://wiki.openstreetmap.org/wiki/Prop … ccess_tags

wambacher · 2012-06-27 18:36:07

SunCobalt wrote:

ich habe das Proposal wieder gelöscht. Mit solchen Unsymphaten wie Eckhart will ich nichts zu tun haben.

Na ja, zumindest hat er sogar als erster approved
...
und 3 Stunden später angelehnt, ohne das Approval zu löschen.

scheint noch nicht einmal für sich zu wissen, was er wirklich will

mal sehen, ob er es merkt.

Gruss
Walter

Last edited by wambacher (2012-06-27 18:49:33)

Tordanik · 2012-06-27 18:42:12

wambacher wrote:

SunCobalt wrote:
ich habe das Proposal wieder gelöscht. Mit solchen Unsymphaten wie Eckhart will ich nichts zu tun haben.
Na ja, zumindest hat er sogar als erster approved

Er hat nicht nur als erster approved, er hat das Voting gestartet. Ich hab damit nichts zu tun.

und 3 Stunden später angelehnt, ohne das Approval zu löschen.

Das ist nur ein Kommentar zu Pierens Ablehnung.

wambacher · 2012-06-27 18:50:24

JO, bin leider etwas durcheinander gekommen. Heute irgendwie nicht mein Tag.

Last edited by wambacher (2012-06-27 18:51:38)

SunCobalt · 2012-06-27 20:08:05

er muss damit durchkommen, da er schon eine Weile Tags in dieses Schema ändert. Ich weiß noch nicht was ich mache. Einerseits könnten meiner Meinung nach noch ein paar Verbesserungen rein aber mit dem ..... kann man ja nicht reden. Anderseits wäre das schonmal ein großer Schritt vorwärts. Der Pierren kommt mit tag, value und condition durcheinander. Das hatte ich extra erläutert, da es nicht auf den ersten Blick ersichtlich ist, was wo hin gehört wenn man nicht lange drüber nachdenkt. Ist ja noch ein bissl Zeit und wenns auf der Kippe steht, stimme ich zu

Last edited by SunCobalt (2012-06-27 20:08:39)

wambacher · 2012-06-27 21:31:36

SunCobalt wrote:

Ist ja noch ein bissl Zeit und wenns auf der Kippe steht, stimme ich zu

Warten wir's mal ab.

Womit ich so meine Probleme habe, sind die variablen keys (z.B access:(weigth>3.5)=* oder auch access:weigth>3.5 in Tordaniks Vorschlag). Damit kann ich mich überhaupt nicht anfreunden und werde daher wohl ablehnen. Das Blöde ist, dass ich selber auch keine passable Lösung habe

Gruss
Walter

Fabi2 · 2012-06-27 21:33:29

Muß ich leider ablehnen, siehe Pieren, weil wenn sollte der Key relativ fest/konstant sein und dann sollte es imo maximal einen Subkey (z.B. *:hgv=*, etc.) geben, weil sonst wird das einfach zu variabel um das noch überhaupt sinnvoll automatisch auswerten zu können.

SunCobalt · 2012-06-28 05:31:25

wambacher wrote:

Womit ich so meine Probleme habe, sind die variablen keys (z.B access:(weigth>3.5)=* oder auch access:weigth>3.5 in Tordaniks Vorschlag). Damit kann ich mich überhaupt nicht anfreunden und werde daher wohl ablehnen. Das Blöde ist, dass ich selber auch keine passable Lösung habe

Beim Key access:*= ist halt nur yes, destination,... ein gültiger Value. Das 5.5 ist die Condition. Ich hatte es in maxweight:destination=5.5 geändert. Hier passt dann der Value 5.5 zu dem Key maxweight:*=
Aber ganz sauber empfand ich es auch nicht. U.A. da es sich manchmal nicht vermeiden lässt, scheinbare Values als Condition in den Key zu schieben. Bsp: bicycle :(07:00-18:00)=no. Der passende Basekey zu 07:00-18:00 wäre opening_hours. Will man nun die Zeiten in den Value schieben, muss man den passenden Basekey benutzen. Das wäre dann opening_hours:bicycle= 07:00-18:00
Auch unschön

aighes · 2012-06-28 08:42:39

Außerdem kann es auch andere Bedingungen geben, die mehrere Values als Bedingung haben. Bspw. maxspeed:(7:00-16:00)=30. Statt der zeitlichen Beschränkung kann es natürlich auch eine Beschränkung übers Gewicht geben. Bspw. maxspeed:(weight>20)=30

fkv · 2012-06-29 01:37:01

SunCobalt wrote:

er muss damit durchkommen, da er schon eine Weile Tags in dieses Schema ändert.

Ach so, das erklärt einiges. Auch warum er im Voting auf alle Ablehnungen antwortet und dabei hartnäckig auf seiner Meinung beharrt.

Ich verstehe nicht, warum so viele was gegen zusammengesetzte Keys haben. Im Zeitalter von regular expressions sind die genauso leicht auswertbar wie fixe Keys. Vielleicht sind die Ablehner keine Programmierer.

Was ich am Proposal aber gar nicht gut finde, sind die Klammerausdrücke. Ich hab das im Voting schon erklärt, aber dort ist nicht der richtige Platz zum Diskutieren, daher spreche ich das hier nochmals an. Laut Eckhart sollen die Klammern die Lesbarkeit erhöhen; ich finde aber, dass genau das Gegenteil bewirkt wird. Je länger, desto schwerer lesbar. Außer wenn man Leerzeichen (nach den Doppelpunkten) einfügt - das könnte man andenken. Anwendungen tun sowieso gut daran, Leerzeichen nach anderen Trennzeichen zu akzeptieren.

So oder so - die beste Lesbarkeit nützt nichts, wenn beim Erfassen Fehler passieren. Und die sind mit den Klammern vorprogrammiert. Die Klammern müssen im Normalfall händisch eingegeben werden. Da wird mal auf die rechte Klammer vergessen, mal wird die falsche Taste erwischt... Ein Graus! Darum bitte wenn möglich die Syntax einfach halten, d.h. ohne Klammern.

Aber auch ohne Klammern sehe ich in der vorgeschlagenenen Syntax Probleme:
1.) Vergleichsoperatoren: Wenn > und < erlaubt sind, werden Leute auch >= und <= eingeben. Ich glaube, ihr werdet mehrheitlich mit mir übereinstimmen, dass ein "=" im Key problematisch ist.
2.) Zeitangaben: Die sollten mit irgendeinem Keyword beginnen, damit sie von den anderen conditions sicher unterschieden werden können. Evtl. könnte man hier doch auf Klammern - () oder [] - zurückgreifen. Die Gefahr bei den Zeitangaben ist, dass ihre Syntax ziemlich komplex ist und vielleicht sogar noch erweitert werden wird. Wenn dort Zeichen wie :=()[] dazukommen, gibts in den Keys Probleme. Dann müssten diese Syntaxelemente in Keys verboten werden, womit das Vorhaben, einfach auf die opening-hours-Syntax verweisen zu können, fehlgeschlagen ist.

Wie sich das am besten lösen lässt, weiß ich nicht. Vielleicht komplexere Syntax in andere Tags auslagern, z.B.:

maxspeed:forward:cond1 = 70
cond1:hours = Mo-Su 08:00-18:00; Apr 10-15 off; Jun 08:00-14:00; Aug off; Dec 25 off

mmd · 2012-06-29 06:55:41

Ist für dieses Proposal eine benutzerfreundliche Pflege in JOSM geplant? Also ein Klicki-Bunti-Assistent, mit dem man sich die entsprechenden Regeln zusammenklicken kann, ohne sich mit der Syntax auseinandersetzen zu müssen. Ich denke da an nach einer Woche fehlerfrei aus dem Gedächtnis anwenden. Gleiches gilt für die Prüfung auf zulässige Werte vor dem Hochladen.

Prinzipiell ist die Idee nicht schlecht, fühlt sich aber etwas over-engineered an. Da könnte man ja auch gleich eine Formel im Excel-Style in den Wert packen: maxspeed=if(wet;80;100) - wobei damit die Verarbeitung schon extrem aufwändig wird.

Last edited by mmd (2012-06-29 07:00:06)

wambacher · 2012-06-29 07:20:46

mmd wrote:

Da könnte man ja auch gleich eine Formel im Excel-Style in den Wert packen: maxspeed=if(wet;80;100) - wobei damit die Verarbeitung schon extrem aufwändig wird.

mach da noch maxspeed:if(wet;80;100) raus und ich stimme jederzeit zu.
Ich hatte schon länger -na ja, seit 1-2Tagen - daran gedacht, dass da "richtige" Formeln reinmüssten. Etwas, was eine formale Syntax hat und durch einen kleinen Parser verarbeitet werden kann. Kommt ja fast schon an die Lösung von Thomas (SunCobalt) ran.

gruss
walter

p.s. der hier kann sowas: http://ewbi.blogs.com/develops/2004/12/ … ula_p.html (allerdings nur mit = ). Einfach mal maxspeed=if(wet;80;100) eingeben.

errt · 2012-06-29 08:04:26

Und was kommt dann bei dir noch in den Value? Außerdem, bevor man so ein komisches Excel-Konstrukt nutzt, wäre doch der klassische ternäre Operator wie er in jeder zweiten Programmiersprache aussieht aussagekräftiger: "maxspeed=wet?80:100" und kommt auch ohne ";" aus, also keine Gefahr, dass jemand aus Versehen den Tag splittet, ohne das zu wollen.

aighes · 2012-06-29 08:18:24

Das mit dem If ist ja erstmal nicht schlecht und bei einer Einschränkung für den Key auch noch von normalen Menschen verständlich. Bei komplexeren Fällen mit mehreren Einschränungen für ein Basekey steigen dann aber alle nicht-Programmierer aus.

alicula · 2012-06-29 08:32:23

errt wrote:

Außerdem, bevor man so ein komisches Excel-Konstrukt nutzt, wäre doch der klassische ternäre Operator wie er in jeder zweiten Programmiersprache aussieht aussagekräftiger: "maxspeed=wet?80:100"....

das kommt doch wieder den vorgeschlagen

maxspeed=100
maxspeed:wet=80

sehr nahe, was doch in Bezug auf Lesbarkeit m.M. besser und auch eindeutiger ist.

SunCobalt · 2012-06-29 08:52:54

problematisch sind auch weniger solche Dinge wie maxspeed wet. Am meisten werden solche Dinge wie maxspeed:(Mo-Fr 07:00-17:00) = 30 kritisiert, wo der Key variable ist. Und der hier "The colon shouldn't be chosen for this as the main separator, since it already has meaning in different tags that aren't conditions, like name:en etc" hat eigentlich auch recht.
die Idee mit dem IF gefällt mir. Eventuell kann man das noch etwas abändern, also die etablierten fixen Tags von den variablen Bedingungen etwas trennen
maxspeed=130
maxpspeed:{(Mo-Fr 07:00-17:00; Su 0:00-24:00)}=120
maxspeed:AND{(Mo-Fr 07:00-17:00; Su 0:00-24:00),hgv}=100
maxspeed:OR{hgv,psv}=80
maxspeed:wet:AND{hgv,delivery}=90

chris66 · 2012-06-29 09:00:22

Ähem, läuft hier gerade ein Wettbewerb "wer erfindet das komplizierteste Schema" oder was?

SunCobalt · 2012-06-29 09:04:53

chris66 wrote:

Ähem, läuft hier gerade ein Wettbewerb "wer erfindet das komplizierteste Schema" oder was?

Vorschläge, wie man bspw zeitliche Beschränkungen einfacher darstellen kann, wären willkommen

aighes · 2012-06-29 09:20:50

Das Problem mit dem variablen Teil im Key ist ja, dass man ihn schlecht parsen kann. Wäre dafür nicht eine konstante Einleitung sinnvoll.

Bsp: maxpspeed:T(Mo-Fr 07:00-17:00; Su 0:00-24:00)=120

Man kann also nach "T(" parsen, dann bis zur nächsten Klammer und den String entweder auswerten, oder es sein lassen. Wie man halt möchte.

Könnte man dann auch für Gewischt machen maxspeed:W(>5.5)=no. Statt T und W kann man das natürlich auch ausschreiben, also time oder weight.

wambacher · 2012-06-29 11:15:45

so, meine Stimme hat er

.....

zur Kenntnis zu nehmen

Ich schätze aber, daß er solange wartet, bis er ca 15 Zustimmer hat und dann die Sache als abgesegnet betrachtet.

alicula · 2012-06-29 11:30:40

ungeachtet der Problematik einer weitergehenden Lösung von allen Ver-/Gebotsmöglichkeiten...

Ich habe hier eine Straße, die eine LKW-Verbot von 22-6 Uhr hat.

Wäre das mit dem bisherigen Schema http://wiki.openstreetmap.org/wiki/DE:K … .A4nkungen

hgv=no
hour_on=22:00:00
hour_off=06:00:00

zu lösen?

wambacher · 2012-06-29 11:39:07

alicula wrote:

Wäre das mit dem bisherigen Schema http://wiki.openstreetmap.org/wiki/DE:K … .A4nkungen
hgv=no
hour_on=22:00:00
hour_off=06:00:00
zu lösen?

garnicht, sobald nicht sicher ist, worauf sich die Zeiten beziehen.
meine Einschätzung geht nach hvg:hour_off=22:00 und hvg:hour_on=06:00 wobei man über on/off oder off/on auch schon wieder streiten diskussieren kann.

Gruss
walter

p.s. wo bleibt eigentlich Netzwolf? Der hat doch die Sache mit den Öffnungszeiten prima hingekriegt. Da dürften diese läppischen Nebenbedingungen doch wohl ein leichtes Spiel eine Herausforderung sein
duck&weg

Last edited by wambacher (2012-06-29 11:46:17)

r-michael · 2012-06-29 11:47:30

Ich bin am Überlegen ob ich das Proposal von Tordanik überhaupt vote.
Wenn man dieses Theater hier liest, so erweckt es doch den Eindruck man würde für eine Person und nicht für die Sache an sich stimmen.
Vertragt Euch, setzt Euch zusammen und bastelt etwas im Sinne der Verbesserung von OSM!
Persönliche Unstimmigkeiten helfen keinem weiter.
Wie man auch an den weiteren Verbesserungsvorschlägen hier sieht ist das Ganze wohl noch garnicht reif für ein Votum.
Ich denke mal es wäre das Beste ich stimme mit Nein und dem Wunsch "macht was Besseres draus, aber gemeinsam!".

mfG Michael

wambacher · 2012-06-29 11:52:32

r-michael wrote:

Ich bin am Überlegen ob ich das Proposal von Tordanik überhaupt vote.
l

Kleine Verwelchslung, die mir leider auch passiert ist: es ist nicht von Tordanik sondern von Eckhart Wörner. Musst halt nur mal diesen Thread richtig durchlesen.

http://forum.openstreetmap.org/viewtopi … 93#p251493 Eckhart hat eine drei Jahre alte Leiche von Tordanik reaninimiert und quasi gekapert.

gruss
walter

Last edited by wambacher (2012-06-29 11:55:46)

Announcement

#26 2012-06-15 17:47:10

Re: Proposal: Einschränkungen von Beschränkungen

#27 2012-06-27 17:45:50

Re: Proposal: Einschränkungen von Beschränkungen

#28 2012-06-27 18:36:07

Re: Proposal: Einschränkungen von Beschränkungen

#29 2012-06-27 18:42:12

Re: Proposal: Einschränkungen von Beschränkungen

#30 2012-06-27 18:50:24

Re: Proposal: Einschränkungen von Beschränkungen

#31 2012-06-27 20:08:05

Re: Proposal: Einschränkungen von Beschränkungen

#32 2012-06-27 21:31:36

Re: Proposal: Einschränkungen von Beschränkungen

#33 2012-06-27 21:33:29

Re: Proposal: Einschränkungen von Beschränkungen

#34 2012-06-28 05:31:25

Re: Proposal: Einschränkungen von Beschränkungen

#35 2012-06-28 08:42:39

Re: Proposal: Einschränkungen von Beschränkungen

#36 2012-06-29 01:37:01

Re: Proposal: Einschränkungen von Beschränkungen

#37 2012-06-29 06:55:41

Re: Proposal: Einschränkungen von Beschränkungen

#38 2012-06-29 07:20:46

Re: Proposal: Einschränkungen von Beschränkungen

#39 2012-06-29 08:04:26

Re: Proposal: Einschränkungen von Beschränkungen

#40 2012-06-29 08:18:24

Re: Proposal: Einschränkungen von Beschränkungen

#41 2012-06-29 08:32:23

Re: Proposal: Einschränkungen von Beschränkungen

#42 2012-06-29 08:52:54

Re: Proposal: Einschränkungen von Beschränkungen

#43 2012-06-29 09:00:22

Re: Proposal: Einschränkungen von Beschränkungen

#44 2012-06-29 09:04:53

Re: Proposal: Einschränkungen von Beschränkungen

#45 2012-06-29 09:20:50

Re: Proposal: Einschränkungen von Beschränkungen

#46 2012-06-29 11:15:45

Re: Proposal: Einschränkungen von Beschränkungen

#47 2012-06-29 11:30:40

Re: Proposal: Einschränkungen von Beschränkungen

#48 2012-06-29 11:39:07

Re: Proposal: Einschränkungen von Beschränkungen

#49 2012-06-29 11:47:30

Re: Proposal: Einschränkungen von Beschränkungen

#50 2012-06-29 11:52:32

Re: Proposal: Einschränkungen von Beschränkungen

Board footer