Hallo,
wir haben in unserem Dorf jetzt von der Gemeinde neue Straßennamen und Hausnummern zugeteilt bekommen. Ich würde das gerne in OpenStreetMap eintragen, allerdings ohne die alten Adressen rauszulöschen, da die ja zur Zeit auch noch gültig und auch wesentlich verbreiteter sind. Gibt es hierfür eine Möglichkeit? Ich habe nur einen 2 Jahre alten Vorschlag finden können (Proposed Features/Multiple addresses). Oder soll ich einfach die alten Einträge drin lassen?
Hallo, senDonko
Willkommen im Forum. Ganz einfach:
Setze vor den alten addr… Einträgen nur old_ davor, also
old_addr:housenumber=2
old_addr:street=XYZ
Natürlich die neue Adresse ganz normal eintragen.
Das haben schon einige gemacht in Deutschland. Hier die Overpass Abfrage: http://overpass-turbo.eu/s/6II zu housenumber.
Allerdings werden die old_ …Adressen nicht mehr ausgewertet bzw. zu finden sein. Also vielleicht zeitnah (ist ja jetzt) arbeiten.
Vielleicht verrätst du uns noch deinen Wohnort, damit auch andere Kollegen recherchieren können. Danke.
Gruß Rolf
Meiner Meinung nach sollte man die Tag-Erweiterung immer umgekehrt machen, damit man sie besser parsen kann. Beispiel “name:DE”. Da kann man eine Spalte “name” machen und dann darunter einen hstore mit “DE=>Köln” - naja, so mache ich es jedenfalls.
Daher würde ich persönlich eher name:old= oder so wählen.
Das Problem bei Dingen wie name:old sehe ich darin, dass man dann die :-Erweiterung für Sprachen mit anderen solchen Erweiterungen in einen Topf wirft. Einfacher ist es, wenn man pro Tag nur eine solche Erweiterung hat - bei name eben z.b. die für Sprachen.
Ich habe bei den Hausnummer 218;31 und bei Straßen name=(neu); old_name=* (alt) eingetragen.
Als Adresse die neue Adresse - so wird alt und neu gefunden.
Manchmal gibt es auch einen loc_name=* (lokalen) oder einen alt_name=* (anderen) - die erhaltenswert sind.
Erweiterungen von Schlüssel finde ich nicht so gut.
Bei dem ganzen 3D-Zeugs wird das doch auch so gemacht. Wenn man “old_addr:street” einführen würde, müsste man erstmal von der Existenz von “old_addr” wissen und dann auch noch, dass es die Erweiterung “street” gibt. Wenn man “name” als Haupttag nimmt und dann einfach alle Erweiterungen ausplittet, bekommt man z.B. den aktuellen Namen, den alten Namen und alle Übersetzungen auf einen Schlag in einer Spalte.
Wo siehst du Nachteile? Ich sehe eher Nachteile, ständig neue Schlüssel einzuführen, wenn man neue aus den Grundschlüsseln erzeugen kann und immer mehr Spalten in der DB bekommt. Es gibt auch Leute, welche mit den Daten arbeiten und ich ärgere mich ständig, wenn ich vergessen habe, “Key xy” importiert zu haben - hstore macht das Ganze etwas besser, aber da geht noch mehr.
Na ja, “Zeugs” würde ich erstmal nicht als Referenz nehmen. Ich glaube die 3Dler versuchen gerade ein spezielles Problem zu lösen, das sollten wir nicht als Referenz für den Rest nehmen, generell kommt mit dem “Zeugs” eine Detailtiefe in OSM Rein, wo wir sicher in Zukunft schauen müssen, wo unsere Wartbarkeit bleibt.
old_name statt name:old hat noch den Vorteil, das man auch old_name:de und old_name:en unterscheiden kann.
name:old:de
Das würde mir dann schön in einem Array erscheinen, wenn ich es verarbeite und ich müsste den Tag “old_name” nicht kennen. Stell dir mal vor, man würde nicht mit einem Trenner arbeiten:
building = yes
roof = yes
color_roof = red
height = 10 m
roof_height = 3 m
Da muss man dann erst wieder ewig mit den Daten schaukeln… das hier wäre allerdings deutlich einfacher:
building = yes
building:roof = yes
building:height = 10 m
roof:color = red
roof:height = 3 m
Dann würde man in der DB zwei Arrays haben, mit denen man alles machen kann: building und roof
Array ?
Array ist doch schon Implementierung der Daten. Ferner halte ich es für eine gute Idee, die Datenstruktur zu kennen, bevor man sie interpretiert :-).
Das old_name stammt sicher aus Zeiten, wo der : noch nicht eingesetzt wurde. Die Frage ist, ob - weil es gerade bei der Interpretation mit Hilfe von “Arrays” praktisch ist, alles umzutaggen, und bei der nächsten Verbesserung der Client Software wieder vor dem Problem zu stehen.
Ausserdem habe ich mal - ohne es zu hinterfragen - gesehen, das 2 “:” vermieden werden sollten.
Christoph
Ist in PostgreSQL seit v9 vorhanden und sollte in Form von Arrays oder Listen eigentlich in jeder Script- und Programmiersprache vorhanden sein:
http://www.postgresql.org/docs/9.0/static/arrays.html
Haben wir nicht 'ne Baumstruktur?
Ich wollte nur andeuten, das das Datenmodell unabhängig von irgendwelchen Postgres Implementierungen logisch sein sollte. Wir mappen doch nicht für eine bestimmte Dateninterpretation :-).
Wobei logisch und gewachsenes Datenmodell in sich widersprüchlich zu sein scheint.
Nicht notwendig.
In OSM aber: ja.
Jetzt mal ehrlich: was bringt es, wenn wir tolle Daten haben, die aber kaum interpretierbar sind. Guck dir doch die komplexen Regelwerke an, die wir jetzt schon für das normale Rendering brauchen… Für komplexere Dinge, wie die Brückenauswertung im anderen Thread, wird es immer schwerer.
Da “name:DE” bereits existiert, verstehe ich die Aufregung über “name:alternative” oder “name:old” nicht. Da passen wir uns nicht an irgendwelche Datenschemen an. “old_name” ist ja auch nix weiteres, als eine Anpassung an das OSM-Schema, da Leerzeichen nicht dargestellt werden können.
Das ist aber auf der Wiki Seite klar definiert:
http://wiki.openstreetmap.org/wiki/Key:name
Da ist man zwar auch schon bei 2 : angekommen.
Dort gibt es als Beispiel: old_name:en:1921-1932 (wie abgestimmt dieser Vorschlag ist, weiss ich nicht).
Ich halte es für müßig über das Umtaggen eines etablierten Tags wie old_name:de und old_name auf name:de:old und name::old zu reden. (Passt aber in das englische Wiki Schema rein: old ist halt irgendwie gestern während 1921-1932 bestimmt gestern ist).
Wenn es aber technische Gründe gibt die massiv dafür sprechen, sollte man die Diskussion in einem sichtbareren Thread und grösserer Teilnehmerzahl anstossen.
Christoph