On Tue, Sep 07, 2010 at 11:39:24AM +0200, Thomas Ineichen wrote: > Hallo Guenther, > > > Die Definition war: > > - Ein Tag ohne Zeitraumangabe ist erstmal immer gueltig. > > - Einzige Ausnahme: Ist zusaetzlich nochmal derselbe Key mit einer > > Zeitraumangabe vorhanden, wird das allgemeine Tag durch das > > eingeschraenkte ersetzt. > > Das Hauptproblem bei dem Schema ist IMHO, ob/wie die Datenbank nach > Key:[Zeitraum] durchsuchbar ist. Falls ein Programm das nicht kann, > oder der Zeitraum in einem falschen Format angegeben ist, dann bleibt > Dir zur Auswertung nur der Haupt-Key, und daher wäre es vorteilhaft, > wenn dort das Minimum und nicht das Maximum drinstehen würde. >
beim derzeitigen (aeusserst eingeschraenkten) key/value-Schema von OSM ist das relativ egal, da man so oder so die Werte auf beiden Seitn irgendwie unterbringen muss. > (Bei maxspeed:wet, maxspeed:hgv sind es ja wenigstens noch feste > Begriffe, die nicht so variabel sind wie Zeitangaben.) > aber immer noch zuviele... > > mit deiner Logik waere das: > > > payment = maestro > > payment:[0700-2200h] = cash;master_card;maestro > > payment:[2200-0700h] = dkv > > > geht auch, finde ich aber unnoetig aufwaendiger... > > Aber dafür logischer. ;-) > Nicht wirklich, denn bzgl. der Logik sind die beiden Varianten absolut gleichwertig. Die Frage muesste lauten, welche ist intuitiver? > >> payment:cash = 07:00-22:00 > >> payment:mastercard = 07:00-22:00 > >> payment:dkv = 07:00-22:00 > >> payment:maestro = yes (oder 24/7) > > > das blaest das Ganze halt unnoetig auf, ohne grossen Mehrwert zu bringen. > > Ausserdem war das Ganze dazu gedacht, eben einerseits beliebige Tag- > > Kombinationen mit einer Zeitangabe zu versehen, andererseits nicht nur > > zeitliche, sondern auch andere Einschraenkungen (die natuerlich nicht fuer > > jedes Tag immer sinnvoll sind) wie Gewicht, Hoehe, Laenge, Breite anbringen > > zu > > koennen. > > Durch die Aufgeblasenheit ist es dafür die menschenlesfreundlichste > Art, die auch ein Computer noch gut verarbeiten kann. Die Subtags für > die Zahlungsarten werden sich mit der Zeit genau so standardisieren > wie die Tags für die verschiedenen Fahrzeugklassen.. > Es ist sowohl menschen- als auch computerlesbar, ja. Aber sicher nicht die menschenlesfreundlichste Art. Die haengt naemlich immer davon ab, was man einen interessiert: Will ich wissen, *WANN* ich meine Mastercard nutzen kann, oder interessiert mich, *WAS* ich zu einem bestimmten Zeitpunkt nutzen kann? > >> Hängt auch vom Anwendungsfall ab: > >> Wenn ich wissen möchte, mit welchen Mitteln ich dort bezahlen kann, > >> können Deine Tags besser ausgewertet werden, wenn mich interessiert, > >> ob ich mit *meiner* Karte bezahlen kann, dann kann mein Tagging > >> einfacher ausgewertet werden. > > > das gibt sich nicht viel... > > Das glaube ich Dir allerdings erst, wenn Du mir eine SQL-Abfrage für > Dein Schema bastelt, welche als Resultat hat, von wann bis wann ich an > einer bestimmten Tanke mit Maestero bezahlen kann. > das haengt ganz allein vom Datenbank-Schema bzw. der jeweiligen Anwendung ab. Drum kann ich dir hier keine pauschale Antwort geben. Aber es liesse sich durchaus bewerkstelligen, dass man in beide Richtungen schnell das gewuenschte Ergebnis bekommt, wenn es sein muss. Allerdings braucht es dazu mehr als ein simples key/value-Layout.
signature.asc
Description: Digital signature
_______________________________________________ Talk-de mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-de
