[Talk-de] Projekt DE des Monats - Tankstellen

Guenther Meyer d.s.e at sordidmusic.com
Di Sep 7 11:18:53 UTC 2010


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.


-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 197 bytes
Beschreibung: Digital signature
URL         : <http://lists.openstreetmap.org/pipermail/talk-de/attachments/20100907/1ad24189/attachment.sig>


Mehr Informationen über die Mailingliste Talk-de