[Talk-at] Bawag PSK

[Norbert Wenzel]

On 12/12/2012 05:53 AM, Erwin Pleyer wrote:
> Nochmal ein Bsp.
> Source=survey; geoimage.de <http://geoimage.de>
> .de ist natürlich falsch.
> Update tab_xy set source=geoimage.at <http://geoimage.at> where source
> like ?geoimage.de <http://geoimage.de>
> Dieses Update würde zwar das .de ersetzen, es wären aber alle anderen
> sources weg. Es konnte durchaus auch Bing;geoimage.de
> <http://geoimage.de> heißen, viele Möglichkeiten gibt es.
> Ein Update würde daher mehr kaputt machen.

Naja, wenn man falschen Code schreibt, dann kommt Mist raus. Wenn ich rm 
-Rf / eingeb, dann ist auch die Datenbank hin und das ist nicht das 
Problem der Strichpunktnotation.

Soll heißen, wenn ich mit strichpunktgetrennten Werten rechnen muss (und 
ja, das muss ich in OSM im Moment auf jeden Fall) dann kann ich so ein 
Update einfach nicht schreiben. Es komplizierter zu machen ist natürlich 
nicht mehr so schnell, aber Effizienz ist ja nicht die absolute Zeit die 
ein Befehl braucht sondern das Verhältnis zur Minimalzeit die ein Befehl 
brauchen kann um eine Operation *richtig* und *vollständig* zu 
durchzuführen.

Im konkreten Fall denk ich ist das postal_service Tag eine gute Idee, 
wenn der Fleischhauer im Ort der nebenbei zwei Packerl am Tag annimmt 
tatsächlich keine vollwertige Postfiliale ist. Für solche Fälle bietet 
sich das Zusatztag einfach an. Wie das bei den neuen Bawag/Post-Filialen 
ist weiß ich nicht. Da könnte es imo sein, dass es eine vollwertige 
Postfiliale und eine vollwertige Bawagfiliale ist die sich räumlich 
tatsächlich am selben Punkt befindet. Das spräche dann doch wieder dafür 
die amenities gleichberechtigt per Semikolon zu trennen.

Das ist natürlich alles aus DB Sicht nicht schön und schon gar nicht die 
reine Lehre, aber da wir halt in OSM erstmal keinen direkten Zugriff auf 
die DB haben sondern einen Datensatz bekommen bzw. eingeben können der 
ausschließlich aus Key=Value Paaren besteht, bleibt einem nichts anderes 
übrig als die Werte, die sich auf ein Objekt beziehen in einem Value zu 
trennen.

Also mir erscheinen diese Semikola auf jeden Fall besser als entweder 
zwei künstliche Nodes zu erzeugen für ein physisches Objekt (ok, man 
könnte sagen die linke Lade am Schalter gehört zur Post und die rechte 
zur Bawag, aber das ist irgendwie sinnlos) oder eben ein *willkürliche* 
Reihung vorzunehmen, was die Hauptfunktion eines Geschäfts ist und was 
nur nebenbei rennt. Wenn das nicht offensichtlich ist, wie beim 
Fleischhauer im Beispiel oben, dann würde mich diese bewusste 
Ungenauigkeit in den Daten, nur um Leuten das Parsen zu vereinfachen, 
auf jeden Fall mehr stören, als dass der Aufwand ein korrektes Parsing 
zu schreiben. ("Wir taggen nicht für den Renderer und schon gar nicht 
für faule Programmierer". ;-))

Norbert