Proposal: Einschränkungen von Beschränkungen

aighes · 2012-06-29 12:16:44

Michael, über sowas hab ich auch erst nachgedacht. Sicherlich ist das Schema nicht der Weisheit letzte Schluss. Aber es gibt auch zu dem Thema keine Erfahrung bei den Mappern. Jeder hat Bedenken, Verbesserungen, etc. aber keiner hat sowas mal an die Masse gerichtet, es auszuprobieren, wie es in der Praxis ist. Erst wenn viele, verschiedene Leute mit unterschiedlichen Erfahrungsleveln damit arbeiten wird man echte Schwächen aufdecken und kann diese Verbessern.

Ich denke, es ist erstmal ein guter Ansatz, den man sicherlich noch verbessern kann. Aber es grenzt hoffentlich den Wildwuchs in diesem Gebiet ein. Und sollte dann irgendwann DIE Erkenntnis da sein, wie man es besser macht, kann man das alte Schema in das neue per Bot überführen.

r-michael · 2012-06-29 12:30:22

wambacher wrote:

Kleine Verwelchslung, die mir leider auch passiert ist: es ist nicht von Tordanik sondern von Eckhart Wörner.
Eckhart hat eine drei Jahre alte Leiche von Tordanik reaninimiert und quasi gekapert.

...und soetwas verlangt nicht nach einer zumindest gelben Karte ?

aighes wrote:

Ich denke, es ist erstmal ein guter Ansatz, den man sicherlich noch verbessern kann. Aber es grenzt hoffentlich den Wildwuchs in diesem Gebiet ein. Und sollte dann irgendwann DIE Erkenntnis da sein, wie man es besser macht, kann man das alte Schema in das neue per Bot überführen.

Wenn das hier nun so lief wie Walter schrieb, so ist's kein Ansatz sondern mehr ein schlechter Witz.
Es sollte erstmal etwas Ansatzfähiges geschaffen werden ohne dass sich ein paar Leute die Köppe einhauen und dann schauen wir mal weiter.
"Wildwuchs einzugrenzen" ist nach Aussagen wie "Jeder kann tun was er will" einem Kampf gegen Windmühlen gleich.

aighes · 2012-06-29 12:37:17

r-michael wrote:

"Wildwuchs einzugrenzen" ist nach Aussagen wie "Jeder kann tun was er will" einem Kampf gegen Windmühlen gleich.

Sicherlich wird man den Wildwuchs nicht stoppen. Aber schau dir die Realität an. Da kommt einer und fragt im Forum: Wie soll ich X eintragen. Dann wird dieser mit 3 Proposals und 5 weiteren Vorschlägen "abgespeißt" und sucht sich dann etwas aus. Evtl. sogar eine neue Variante 9. Sollte es einen konkreteren Ansatz geben (ich denke schon das das ein Ansatz ist), kann man dem Frager diesen Ansatz guten Gewissens empfehlen.

r-michael · 2012-06-29 13:07:24

aighes wrote:

Aber schau dir die Realität an. Da kommt einer und fragt im Forum: Wie soll ich X eintragen. Dann wird dieser mit 3 Proposals und 5 weiteren Vorschlägen "abgespeißt" und sucht sich dann etwas aus. Evtl. sogar eine neue Variante 9.

Da muß ich auch zumeist schmunzeln, denn ein großer Prozentsatz davon ursacht schlicht auf Faulheit die Suchfunktion zu nutzen bzw. dem Unvermögen mal auf jener Seite nachzuschauen, welche eigentlich Jeder pflichtmäßig gespeichert haben müsste.:

http://wiki.openstreetmap.org/wiki/DE:Map_Features

Eine gepflegte "Gebrauchsanleitung" beantwortet fast alle Fragen.

Sollte es einen konkreteren Ansatz geben (ich denke schon das das ein Ansatz ist), kann man dem Frager diesen Ansatz guten Gewissens empfehlen.

Eigentlich schon, aber nicht auf diese Art und Weise wie es hier gelaufen scheint.
Wie kann denn ein Proposal welches 3 Jahre auf Eis lag plötzlich durch Jemanden zum Voting freigegeben werden; dies fordert eigentlich eine gewisse Handbewegung heraus (Scheibenwischer).
Es sollte hier unter Federführung von Tordanik, welcher dies mal ursprünglich erstellte, nochmal versucht werden einige Vorschläge mit einzuarbeiten und dann kann's frisch zum Voting raus.
Es müssen doch nicht wieder drei Jahre vergehen; wenn man sich gewissenhaft dranhängt, so kann es doch in ein paar Wochen wieder raus.

Meines Erachtens nach ist es auch ein Manko, dass es zu solchen Proposals zwar eine "talk page" gibt, aber dort läuft alles zumeist nur in Englisch, auch wenn sich an der Diskussion fast ausschließlich nur deutsche User beteiligen.
Ich habe zwar mit Englisch keine größeren Probleme, aber bei solchen ausführlichen Diskussionen ödet mich soetwas an und so mag es sicherlich auch vielen anderen gehen.
Ich muß meine Gedanken übersetzen und der Empfänger es wieder zurückübersetzen - Hallo?, geht's auch noch komplizierter?
Eben schon bei solchen Sachen müßte man mal die Zange ansetzen um Erleichterungen zu schaffen.

MasiMaster · 2012-06-29 14:49:23

fkv wrote:

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

+1
Das war die gleiche Idee, die auch mir gestern kam (aber noch nicht geschrieben hatte).

Vorteil ist, das es ein relativ einfaches Schema ist, und der Nutzer nicht programmieren können muss, oder sich in komplexe Tags mit Klammern usw. einlesen muss. mMn sogar die einzige Möglichkeit 2 Values in "einem" Tag unterzubringen.
(Das derzeitige Schema aus Key & Value scheint ja nur für die allereinfachsten Sachen gut brauchbar, so dass wir jetzt schon sub- und subsubkeys haben.)

SunCobalt · 2012-06-29 15:08:41

und bei mehreren Bedingungen dann
maxspeed:forward:cond1:cond2 = 70
cond1:hours = Mo-Su 08:00-18:00; Apr 10-15 off; Jun 08:00-14:00; Aug off; Dec 25 off
cond2:weight=>5.5

?
Find ich nicht so schön, aber wenns mehrheitsfähig wäre......

Tordanik · 2012-06-29 15:27:17

r-michael wrote:

Wie kann denn ein Proposal welches 3 Jahre auf Eis lag plötzlich durch Jemanden zum Voting freigegeben werden; dies fordert eigentlich eine gewisse Handbewegung heraus (Scheibenwischer).

Ich finde das Vorgehen von Eckhard auch ein bisschen fragwürdig, denn ich hätte schon erwartet, dass er mich mindestens vorher anschreibt, wenn er das Proposal in die Abstimmungs-Phase verschieben will. "Plötzlich" war die Freigabe allerdings nicht wirklich, denn das Thema wurde auf der Tagging-Mailingliste ausführlich diskutiert. Diese laufende Diskussion hatte ich in diesem Thread auch verlinkt. Und es war für jeden Beteiligten erkennbar, dass sich die dortige Diskussion totgelaufen hatte und ein weiteres Abwarten nichts an der Lage geändert hätte.

Auch generell ist es ja nicht so, dass das Thema drei Jahre lang nicht diskutiert worden wäre. Im Gegenteil ist dieses Thema immer wieder aufgetaucht, regelmäßig auch in diesem Forum. Die Diskussionen haben viel Zeit verschlungen, dennoch kamen schon lange keine grundlegend neuen Impulse mehr. Die verschiedenen Konzepte sind bekannt, die Argumente auch und man kann allenfalls noch etwas Feintuning betreiben - ob ein Fragezeichen nun ein besseres Trennzeichen wäre als ein Doppelpunkt oder vergleichbare Kleinigkeiten.

Aus diesen Gründen werde ich das etwas seltsame Zustandekommen der Abstimmung ignorieren, das Ergebnis abwarten und daraus meine Schlüsse ziehen. Wenn das Proposal akzeptiert werden sollte, können wir uns auf kleinere Verbesserungen konzentrieren, was bessere Aussichten auf Erfolg hat als jedes Mal wieder von neuem eine Grundsatzdiskussion anzufangen. Wenn das Proposal hingegen, wie es derzeit aussieht, tatsächlich vor allem aus dem Grund abgelehnt wird, dass variable Schlüssel unerwüscht sind (was m.E. dann aber auch gegen Schlüssel wie :cond5 spricht!), dann sehe ich nicht, wie das Einarbeiten von Änderungsvorschlägen daran etwas ändern könnte.- denn Bedingungen im Schlüssel sind ein Kernbestandteil des Proposals. In diesem Fall würde ich mich an der Entwicklung einer Lösung beteiligen, die auf Bedingungen im Wert setzt.

r-michael · 2012-06-29 17:06:47

Tordanik wrote:

Wenn das Proposal akzeptiert werden sollte, können wir uns auf kleinere Verbesserungen konzentrieren, was bessere Aussichten auf Erfolg hat als jedes Mal wieder von neuem eine Grundsatzdiskussion anzufangen.

Ach Sch..., nun mußte ich mein Voting doch nochmal auf JA korrigieren im Sinn der Sache.
O.k., dabei nehme ich dich beim Wort, dass das Ganze noch Verbesserungen unterliegen wird.
Vielleicht fällt mir ja auch noch etwas Förderliches ein.
Wäre schön wenn Andere bezüglich deines Kommentares auch nochmal ihr Voting überdenken hinsichtlich eines Vorankommens der Angelegenheit.

mmd · 2012-06-29 17:17:58

.

Last edited by mmd (2012-10-19 19:26:02)

flaimo · 2012-06-29 17:27:19

MasiMaster wrote:

fkv wrote:
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
+1
Das war die gleiche Idee, die auch mir gestern kam (aber noch nicht geschrieben hatte).
Vorteil ist, das es ein relativ einfaches Schema ist, und der Nutzer nicht programmieren können muss, oder sich in komplexe Tags mit Klammern usw. einlesen muss. mMn sogar die einzige Möglichkeit 2 Values in "einem" Tag unterzubringen.
(Das derzeitige Schema aus Key & Value scheint ja nur für die allereinfachsten Sachen gut brauchbar, so dass wir jetzt schon sub- und subsubkeys haben.)

womit wir dann eh wieder bei den self-defined conditions meines proposals angelangt wären ;-)

r-michael · 2012-06-29 18:04:39

mmd wrote:

Mich würde nebenbei mal interessieren, ob es irgendeine Anwendung (außer Eckhards Beispiel) gibt, die heute schon unmittelbar von diesem Proposal profitiert. ....

Die Frage ob, wo und wann überhaupt diese Daten ausgewertet werden scheinen doch sowieso keine all zu große Relevanz zu haben.
Wieviele Daten schwirren schon in OSM herum wo man sich ebenfalls diese Frage stellen muß.
Ebenso wie es schöne Phrase gibt "Wir mappen nicht für den Renderer" könnte man auch sagen "Wir mappen nicht für Garmin".
Dass man heute noch Karten auf Garmin konvertiert um sie anwendbar zu machen ist wohl sowieso mehr eine aus der Not geborene Erfindung.
Das Bestreben sollte darauf hinauslaufen, dass OSM einen derartigen Stand an Qualität erreicht, welches es für kommerzielle GPS-Geräte-Hersteller attraktiv macht und so eventuell in Zukunft auch Geräte entwickelt werden welche OSM-Rohdaten auswerten könnten.
Dass die gerenderten OSM-Karten schon Einzug in viele kommerzielle Anwendungen gefunden haben ist schon ein großer Fortschritt, warten wir ab was uns die Zukunft bringt.

flaimo wrote:

womit wir dann eh wieder bei den self-defined conditions meines proposals angelangt wären ;-)

Hab's nur mal kurz überflogen, sieht auch nicht schlecht aus.
...und warum wirft man nun nicht alle Proposals in einen Topf und macht das Beste daraus?
Wir veranstalten doch hier keinen Wettbewerb der Proposals, sondern sollten Alle an einem Strick ziehen!
...oder gibt's bei Olympia neuerdings Medaillen dafür?

aighes · 2012-06-29 18:40:13

@mmd: Es ist immer ein Henne-Ei-Problem: Was nutzt es Dinge einzutragen, die keiner auswertet vs. Was nutzt es Dinge auszuwerten, die keiner einträgt. Ansonsten sehe ich das schon auch teilweise für Garminkarten als hilfreich an. Evtl. bringt es dir nicht viel, weil du keinen LKW fährst etc. Von daher wäre ich immer auch etwas Vorsichtig mit der Bezeichnung "Spezialkarte". Denn letzlich ist jede Karte nur eine Spezialkarte, da sie nur ein Spektrum abdeckt.

mmd · 2012-06-29 19:13:41

"Spezialkarte" war natürlich nicht abwertend gemeint, sondern einfach nur eine Karte für eine definierte Benutzergruppe. Für LKW und Garmin kenne ich da aktuell nur die Karte von Win32netsky. Kann aber gut sein, dass es da noch weitere gibt, die mir einfach nicht bekannt sind.

Ich muß schon sagen, dass ich gerade mit den komplexen opening_hours im Key oder auch im Value so meine Probleme habe und dort recht heftigen Wildwuchs befürchte, wenn da nicht von Anfang an rigide Prüfungen im Editor vorgesehen werden. Natürlich kann man jetzt argumentieren, dass die opening_hours an anderer Stelle schon etabliert sind, das macht sie aber nicht unbedingt einfacher zu editieren oder gar interpretieren. Zum aktuellen Zeitpunkt würde ich diesen Teil des Proposals eher ausklammern wollen.

Ansonsten finde ich das Proposal eigentlich ganz vernünftig und kann mir auch gut vorstellen, dass man verschiedene Karten und Router in überschaubarem Zeitraum entsprechend anpassen kann.

Last edited by mmd (2012-06-29 19:19:27)

aighes · 2012-06-29 19:22:24

Wobei jetzt eine Radkarte nicht unspezieller ist als eine LKW-Karte oder eine Wanderkarte. Evtl. weniger populär. Wanderkarten und Radkarten werden wahrscheinlich eher weniger davon profitieren, weil die Einschränkungen ja eher den Kraftverkehr betrifft. Ob halt die Höchstgeschwindigkeit an Schultagen 30 ist oder nicht ist für Radler und Fußgänger eher uninteressant.

Wildwuchs befürchte ich da nicht groß. Klar wird es flexibel sein, aber diese Flexibilität wird sich in den Grenzen des opening_hours-Schema befinden. Klar ist, dass man mit einem Parser, der String=String vergleicht bei solchen Tags nicht weit kommt. Da muss der Parser dann mehr Intelligenz mitbringen. Aber die bräuchte er auch, wenn er die variablen Teile im Value auswerten müsste.

Last edited by aighes (2012-06-29 19:22:40)

mmd · 2012-06-29 21:26:43

.

Last edited by mmd (2012-10-19 19:25:39)

wambacher · 2012-06-29 22:25:27

mmd wrote:

Tipp: Einfach mal etwas über Europa navigieren und die Fehler bewundern. Ähnliche Bugs würden demnächst dann auch in den Access-Tags zu finden sein.

ja und?

Das betrifft doch nur die komplizierteren Situationen, die bisher sowieso nicht korrekt drin waren. Die waren zwar syntaxisch ok aber dennoch inhaltlich falsch.
Oder sie fehlten ganz.
Geschätzte 95% der Fälle sind eh trivial und werden mit den jetzigen Verfahren abgedeckt.

Der Vergleich mit opening_hours hinkt insofern, da dort kein einziger Fall trivial ist: "Mo-Fr 08:00-18:30" bietet schon genug Fehlermöglichkeiten, access=private dagegen fast keine (z.B. access=privat oder acess=private, ...)

In anderen Worten: ich erwarte häufige Anfängerfehler in den Situationen, die bisher nicht erfasst werden konnten.

Gruss
Walter

p.s. unsere "Nachputzer" wollen ja auch was zu tun haben, seien es Mapper oder Bots

mmd · 2012-06-29 22:49:35

.

Last edited by mmd (2012-10-19 19:25:07)

Basstoelpel · 2012-07-01 14:42:40

Da die eine Gruppe die condition nicht im key haben möchte und die andere Hälfte dagegen ist, daß sie in den value kommt, ist es mal an der Zeit, eine Erweiterung der Struktur zu fordern: Dort, wo Konditionen nötig sind statt dem <key>-<value> Paar das Triplett <key>-<condition>-<value> verwenden.

Schöne Grüße,

Baßtölpel

EvanE · 2012-07-01 15:38:56

Basstoelpel wrote:

Da die eine Gruppe die condition nicht im key haben möchte und die andere Hälfte dagegen ist, daß sie in den value kommt, ist es mal an der Zeit, eine Erweiterung der Struktur zu fordern: Dort, wo Konditionen nötig sind statt dem <key>-<value> Paar das Triplett <key>-<condition>-<value> verwenden.

Hallo Baßtölpel

Das würde aber einen kompletten Umbau der Datenstruktur und damit der API erfordern. Darüber hinaus müssten alle Editoren entsprechend angepasst werden. Ebenso müssten eine ganze Menge Tagging der neuen Variante angepasst werden.

Dort wo die Bedingung ein einfacher Wert ist, kann man mMn gut mit Key:Condition=Wert klar kommen. Aber wenn die Condition über bekannte Werte wie wet, hgv usw. hinausgeht, also selber aus variablen Werten besteht (Zeit, Gewicht, ..), wird es unangenehm.

Der schon mehrfach geäußerte Vorschlag variable Bedingungen per Key:cond1/.../cond9=Wert plus cond1/... /cond9=Bedingung zu kodieren scheint mir sehr viel zielführender zu sein und deutlich besser in das Schema Schlüssel=Wert zu passen, als das rumgeeiere mit variablen Werten im Schlüssel oder zwei unterschiedlichen Werten (Bedingung und eigentlicher Wert) als Wert.

Edbert (EvanE)

aighes · 2012-07-01 16:36:49

Edbert, ich versteh das Problem nicht bzw. sehe für die Auswertung keinen Unterschied darin, ob da nun cond1 in der Bedingung steht und die dann woanders aufgelöst wird oder ob die Auflösung direkt darin steht. Auch ob das nun im key oder im value steht macht für die Auswertung keinen Unterschied. Beim Eintragen ist es auch egal...der normale Mapper gewöhnt sich an alles.

Für die Auswertung macht es keinen Unterschied, weil der String ja der gleiche ist. Da ist das mit cond1 eher noch umständlicher, weil man sich das ganze erst noch zusammensuchen muss. Vorallem ist es sehr gefährlich, wenn man filtert. Wer kommt schon auf die Idee, cond* in den Daten zu lassen, wenn er maxspeed auswerten möchte?

Das Key-Value-Paar ist deutlich einfacher, wenn man die Bedingungen in den Key packt. Andernfalls ist es sehr wahrscheinlich, dass man im value mehrere Bedingungs-Ketten hat. Da kommt dann erst Freude auf. Key=Bedingung11:Bedingung12:Value1;Bedingung21:Bedingung22:Value2

Last edited by aighes (2012-07-01 16:39:44)

fkv · 2012-07-01 17:46:22

aighes wrote:

Wer kommt schon auf die Idee, cond* in den Daten zu lassen, wenn er maxspeed auswerten möchte?

Das wird dann natürlich im Wiki beschrieben sein. Dort sollte jemand, der Auswertungen macht, unbedingt hineinsehen, erst recht wenn es maxspeed betrifft, wo man die ganzen Default- und impliziten maxpeeds je nach Land, Straßen- und Fahrzeugtyp berücksichtigen muss.

EvanE · 2012-07-01 19:14:37

aighes wrote:

ich versteh das Problem nicht bzw. sehe für die Auswertung keinen Unterschied darin, ob da nun cond1 in der Bedingung steht und die dann woanders aufgelöst wird oder ob die Auflösung direkt darin steht. Auch ob das nun im key oder im value steht macht für die Auswertung keinen Unterschied. Beim Eintragen ist es auch egal...der normale Mapper gewöhnt sich an alles.

Ich sehe da einen elementaren Unterschied. Bisher ist es so, dass man im Schlüssel einfache Worte (schlimmstenfalls Abkürzungen) oder eine Hierarchie aus einfachen Worten stehen hat. Ein spezielles Parsing außer auf den Doppelpunkt als Hierarchie Trenner ist bisher also nicht notwendig.
Im Gegensatz dazu muss je nach Schlüssel der Wert ggfs. (z.B. bei opening_hours) aufwendig analysiert (geparst) werden.

Diesen Aufwand jetzt auch in dem Schlüssel einzuführen halte ich für keine gute Sache.

aighes wrote:

Für die Auswertung macht es keinen Unterschied, weil der String ja der gleiche ist. Da ist das mit cond1 eher noch umständlicher, weil man sich das ganze erst noch zusammensuchen muss. Vorallem ist es sehr gefährlich, wenn man filtert. Wer kommt schon auf die Idee, cond* in den Daten zu lassen, wenn er maxspeed auswerten möchte?
Das Key-Value-Paar ist deutlich einfacher, wenn man die Bedingungen in den Key packt. Andernfalls ist es sehr wahrscheinlich, dass man im value mehrere Bedingungs-Ketten hat. Da kommt dann erst Freude auf. Key=Bedingung11:Bedingung12:Value1;Bedingung21:Bedingung22:Value2

Ich habe mich an das eingeführte Schema wie bei highway=construction plus construction=Highway-Wert und vielen ähnlichen Konstrukten zur Verfeinerung von Angaben orientiert. Das ist bekannt, die Auswertung dafür muss nur erweitert werden.

Übrigens wird dein Beispiel dafür aufgelöst in:
cond11=Wert1
cond12=Wert2
cond21=Wert3
cond22=Wert4
Also keine Mehrfachwerte für einen Schlüssel.

Edbert (EvanE)

Basstoelpel · 2012-07-01 19:27:03

EvanE wrote:

Basstoelpel wrote:
Da die eine Gruppe die condition nicht im key haben möchte und die andere Hälfte dagegen ist, daß sie in den value kommt, ist es mal an der Zeit, eine Erweiterung der Struktur zu fordern: Dort, wo Konditionen nötig sind statt dem <key>-<value> Paar das Triplett <key>-<condition>-<value> verwenden.
Das würde aber einen kompletten Umbau der Datenstruktur und damit der API erfordern. Darüber hinaus müssten alle Editoren entsprechend angepasst werden. Ebenso müssten eine ganze Menge Tagging der neuen Variante angepasst werden.

Hallo Edbert,

das ist mir klar.
Seit mehreren Jahren vegetiert hier ein wichtiges und gutes Proposal wegen formaler parsing-Probleme vor sich hin. Wenn die Probleme wirklich so bedeutend sind, wie die Ablehner behauptem, muß man eben auf tieferer Ebene etwas umgestalten. Eine Bedingung ist nun mal weder ein key noch ein value sondern etwas eigenständiges. Wenn man es also nicht schafft, die üblichen tools so zu erweitern, daß sich Bedingungen entweder im key oder im value als solche flexibel definieren lassen, dann muß eben die Datenstruktur geändert werden.

Baßtölpel

aighes · 2012-07-01 19:28:16

Aber mit dem cond*=* ändert sich am Parsen nichts im Vergleich zu dem Proposal.

Interessiert mich der basekey, muss ich auch variable cond* parsen. Die gehen ja nicht bei 1 los und müssen auch nicht direkt auf einander folgen. Dann suche ich mir die Bedeutung von der Bedingung heraus etc.
Das kann ich aber auch gleich machen in dem String des Keys machen.

Bsp:
maxspeed=80
maxspeed:motor_vehicle:wet=60
maxspeed:hgv:wet:(Mo-Fr 07:00-16:00)=30
maxspeed:hgv:(Mo-Fr 07:00-16:00)=50

wird zu:

maxspeed=80
maxspeed=cond1:cond2=60
maxspeed=cond3:cond2:cond4=30
maxspeed=cond3:cond4=50
cond1=motor_vehicle
cond2=wet
cond3=hgv
cond4=Mo-Fr 07:00-16:00

Fabi2 · 2012-07-01 20:48:42

Basstoelpel wrote:

Da die eine Gruppe die condition nicht im key haben möchte und die andere Hälfte dagegen ist, daß sie in den value kommt, ist es mal an der Zeit, eine Erweiterung der Struktur zu fordern: Dort, wo Konditionen nötig sind statt dem <key>-<value> Paar das Triplett <key>-<condition>-<value> verwenden.

Naja, deswegen will ich ja schon eine Weile Unterstützung für baumförmige Wertzuordnungen in API 0.7 haben.

Announcement

#51 2012-06-29 12:16:44

Re: Proposal: Einschränkungen von Beschränkungen

#52 2012-06-29 12:30:22

Re: Proposal: Einschränkungen von Beschränkungen

#53 2012-06-29 12:37:17

Re: Proposal: Einschränkungen von Beschränkungen

#54 2012-06-29 13:07:24

Re: Proposal: Einschränkungen von Beschränkungen

#55 2012-06-29 14:49:23

Re: Proposal: Einschränkungen von Beschränkungen

#56 2012-06-29 15:08:41

Re: Proposal: Einschränkungen von Beschränkungen

#57 2012-06-29 15:27:17

Re: Proposal: Einschränkungen von Beschränkungen

#58 2012-06-29 17:06:47

Re: Proposal: Einschränkungen von Beschränkungen

#59 2012-06-29 17:17:58

Re: Proposal: Einschränkungen von Beschränkungen

#60 2012-06-29 17:27:19

Re: Proposal: Einschränkungen von Beschränkungen

#61 2012-06-29 18:04:39

Re: Proposal: Einschränkungen von Beschränkungen

#62 2012-06-29 18:40:13

Re: Proposal: Einschränkungen von Beschränkungen

#63 2012-06-29 19:13:41

Re: Proposal: Einschränkungen von Beschränkungen

#64 2012-06-29 19:22:24

Re: Proposal: Einschränkungen von Beschränkungen

#65 2012-06-29 21:26:43

Re: Proposal: Einschränkungen von Beschränkungen

#66 2012-06-29 22:25:27

Re: Proposal: Einschränkungen von Beschränkungen

#67 2012-06-29 22:49:35

Re: Proposal: Einschränkungen von Beschränkungen

#68 2012-07-01 14:42:40

Re: Proposal: Einschränkungen von Beschränkungen

#69 2012-07-01 15:38:56

Re: Proposal: Einschränkungen von Beschränkungen

#70 2012-07-01 16:36:49

Re: Proposal: Einschränkungen von Beschränkungen

#71 2012-07-01 17:46:22

Re: Proposal: Einschränkungen von Beschränkungen

#72 2012-07-01 19:14:37

Re: Proposal: Einschränkungen von Beschränkungen

#73 2012-07-01 19:27:03

Re: Proposal: Einschränkungen von Beschränkungen

#74 2012-07-01 19:28:16

Re: Proposal: Einschränkungen von Beschränkungen

#75 2012-07-01 20:48:42

Re: Proposal: Einschränkungen von Beschränkungen

Board footer