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 _______________________________________________ Talk-at mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-at
