Informationen zu Städten / Dörfern ... eintragen

Eventuell habe ich es übersehen aber wie kann ich eine Homepage für Städte eintragen? Ich würde z.B. folgendes nutzen:

url=http://www.muenchen.de

Wie schaut es mit der PLZ aus? Werden diese auch hinterlegt? Bringt dies Vorteile, damit man weiß welche PLZ für den Ort verfügbar ist oder sollte man dies nur bei Straßen nutzen? Sind halt so kleine Fragen die beim arbeiten mit OSM aufkommen.

Hallo, genau so ist es richtig

PLZs solltes Du an konkrekte Objekte heften, wie Gebäude und Briefkästen. Bei einem Ort kannst Du es machen, wenn der komplete Ort die gleiche PLZ hat. Zu mindest in größeren Orten mit mehreren PLZs ist es für Straßen problematisch, weil es ja keine frei verfügbaren Informationen gibt, welche Straße welcher PLZ zugeordnet ist und das sich im Verlauf der Straße sogar änder kann. Grüßle, detlef

Hi Vielen Dank für deine Antwort

Sehr gut

War mir schon klar - wollte nur wissen ob ich so bei Dörfern oder Stadtteilen verfahren kann die über eine PLZ verfügen. Hast mir sehr weitergeholfen.

Postleitzahlen halte ich als ein Paradebeispiel für eine Relation… http://wiki.openstreetmap.org/wiki/Relation:postal_code leider hat sich das bisher gar nicht durchgesetzt… (derzeit 15 Relationen mit postal code in Europa)

Hallo, wird die Relation dann noch irgendwie der Stadt zugeordnet oder hängt die dann in der Luft ? Grüße.

Hallo, bei Postleitzahlen halte ich von Relationen nicht viel. Sie nur für Wege zu nutzen ist inkonsistent, da sie auch noch an Gebäuden kleben. Alle Gebäude mit rein zu nehmen würde dann allerdings wieder zu absolut nicht handhabbaren Monsterrelationen führen. Ich bin deshalb dafür, das jedes Objekt seine volle Adresse bekommt.Das ist nicht nur für den Benutzer sondern auch für Programme gut zu handhaben. Grüßle, detlef

Also bekommen dann z.B. 10000 Objekte die Plz. 12345 per Hand eingetragen ? Dann lieber eine Relation als diesen Datenwulst pflegen. Grüße.

Der Relation müsstest du auch alle 1000 Objekte hinzufügen … da ist doch der Aufwand der selbe, oder?

Außerdem sind Gebiete für eine PLZ teilweise so groß, das sie mit Rechnern mit nicht üppiger Speicherausstattung in JOSM nahezu nicht mehr zu bearbeiten sind. Mein “Hauptrechner” hat “nur” ein GB RAM, wovon ich maximal 500 MB JOSM zur Verfügung stellen kann, damit ich noch vernünftig arbeiten kann. Ein gut gefülltes PLZ-Gebiet ist hierfür einfach zu groß. Auf der anderen Seite ist es problemlos möglich sich das Gebiet Stück für Stück zu laden und zu bearbeiten. Man sollte bei sochen Entscheidungen auch immer im Auge behalten, das die Programme auch für Leute nutzbar bleiben, die eine Rechner einsezten (wollen / müssen) der vielleicht schon drei, vier Jahre alt ist (bei dem wollen / müssen geht es nicht nur um das “sich leisten können”, sondern z.B. auch darum, das es aus Umweltaspekten häufig Wahnsinn ist einen älteren Rechner zu entsorgen).

Die einzelnen Objekte sind natürlich ein Teil der Relation. Einen Index auf eine Relation zu setzen spart Speicher und kann auch schneller sein. An jedes Objekt einen dicken Datenwulst hängen finde ich für ein absolutes no-go Kriterium und spart durch mehrfache Datenpflege und Speicherverbrauch keine Zeit und auch keinen Speicher. Ich beziehe mich auf aktuelle Datenbankstrukturen und dort wird es nicht anders gemacht. Das die aktuellen Programme nicht effizient sind, dafür kann hier wohl keiner etwas, aber man sollte sich über diese Elementaren Strukturen vorher Gedanken machen und nicht die Zeit von den freien Mitarbeitern verpulvern.

Kann man nicht einfach alle Postleitzahlen eines Stadtteils, getrennt durch Schrägstriche, aufführen? Somit umgeht man die Problematik mit den Relationen - oder würde man es sich somit zu einfach machen?

Strings parsen ist sehr sehr sehr langsam und jeder String braucht auch seinen Speicher ;-). Lieber einen Index auf die eigentlichen Daten (wie groß auch immer) nur keine Redundanzen. http://de.wikipedia.org/wiki/Normalisierung_(Datenbank)

Um Datenwüllste kommst du mit dem jetzigen System so oder so nicht herum. Ich habe da z.B. die Supermärkte. Das muss gleichzeitig ein Gebäude sein, ein Shop mit Öffnungszeiten, Name und Betreiber und zusätzlich eine Postadresse mit Ort, Straße und Nummer haben. Lustig ist es vor allem bei den Gebäuden mit mehreren Adressen und POIs. Da werden die Gebäude räumlich der Realität nach aufgeteilt und die "Räume" gefüllt. Wird zwar mit Wege nahe... angemeckert aber geht nicht anders. Lustig wird es dann in so einem Fall, wenn dann noch mehrere Etagen dazu kommen. Die Alternative dazu wären dann einzelne Nodes, unter denen du kein Gebäude mehr findest oder alles in eines zu pappen, was dann garnicht mehr zu verwalten ist. Unsere PLZ bedient z.B. mehrere Orte. Da diese aber zu unterschiedlichen Städten, Gemeinden und VGs gehören, bleiben dopplete Straßennamen nicht aus. Innerorts wurde sowas nach Eingemeindungen ja meist geändert, ansonsten nicht. Damit hat es auch doppelte Haunummern, eina fehlende da und eine zusätzliche dort. Das bringt uns zum nächsten Problem. Die Interpolation ist zumindestens bei uns nicht zu gebrauchen. Die Hausnummern sind teilweise kreuz der quere verteilt, einzelne Nummern fehlen, dann fehlen mal bis zu 50 ungerade oder gerade Nummern, neu gebautes wird mit dem Zusatz a bis z gefüllt. Sinnvollste Methode bleibt dann eine genaue Adressierung des einzelnen Gebäudes. Das ist praktikabler wie ständig die nicht wenigen Nachbarorte nach Duplikaten bzw. der Ausnahme der Regel abzusuchen. Oder für jeden Ort eine Relation in der Relation in der Relation zusätzlich im Auge haben zu müssen. Mit einer vollen Adressierung wird ein eventueller Zwilling von Anfang an verhindert und letzteres spielt keine Rolle. Relationen muss man immer wieder auf Vollständigkeit überprüfen, wenn sich etwas verändert hat. Das lässt sich in dem Fall anders wie bei Wegen nicht automatisch überprüfen. Das lohnt erst dann, wenn wenn sich die Relation innerhalb einer vorgegeben Grenze selbst aktuallisieren kann.

Eine Node (eine Adresse) kann nun mal mehrere POIs haben und die müssen dann alle dort rein. Es fehlt einfach noch das richtige Tool diese zu verwalten.

Eine Straße kann zu mehreren Orten gehören, sonst könnte man nicht von Ort A nach Ort B fahren. Und wenn wir diese Straße mal klassisch Dorfstraße nennen sehe ich kein Problem dafür sauber Relationen zu benutzen. Die Interpolation der Hausnummern konnte man von Anfang an vergessen. Ist zwar theoretisch ganz nett, hat mit der Wirklichkeit aber nicht viel zu tun.

Du meinst einfacher, weil es keine besseren Tools gibt, so wird ein Schuh draus.

Eine Node auf der Node auf der Node …

Auch hier fehlt es an Eingabehilfen. Dein System ist ganz weit weg von einer ordentlichen Datenverwaltung. Auf der anderen Seite gibt es keine Tools mit denen man es gescheit anders machen könnte. Der “intelligente” Relationseditor wird z.B. in JOSM nur im einfachen Relationseditor erwähnt Grüße.

Ich arbeite nicht mit einzelnen Nodes sondern Gebäudeshapes. Dort wird alles angehängt. Zusammenhängende aber räumlich unterteilte Gebäudestrukturen werden aufgeteilt. So müsste man nochmal einzelne Nodes auf die jeweilige Position auf dem Gebäude legen, auch nicht besser.

Die Problematik ist überall eine andere, da liegt das Problem. Eine Lösung die alles einschließt muss wohl durchdacht sein. Deinen Fall haben wir hier z.B. nicht. Straßennamen enden in der Regel am Ortsausgangsschild. Dorfstraße haben wir auch, ebenso doppelt. Da hätte ich hier z.B. 4 mal Dorfstraße mit gleicher PLZ aber 4 verschiedenen Orten und Zugehörigkeiten. Unsere PLZ umfasst über 10 Orte. Das ist so schon alles aufwendig genug. Da wünscht man sich als letztes noch dutzende zusätzliche Relationen, die potentielle Fehlerquellen darstellen.

Klar ist es einfacher. Das erheben und verarbeiten der Geodaten ist schon arbeit genug. Es ist an den Datenbankspezialisten entsprechende global umfassende Lösungen anzubieten. Darüber kannst du dir als Anwender in der Praxis keinen Kopf machen. Erstens mangels wissen und zweitens weil du bis zu einer ausgearbeiteten einheitlichen Lösung ohnehin nur raten kannst wohin das ganze gehen könnte. Dein Vorschlag ist ja bisher auch nur eine Idee. Eine Idee die am sich am Ende vielleicht auch nur nicht durchsetzt. Ich Orakle nicht und ändere alle Nase lang um. Ich warte lieber auf eine fertige akzeptierte Lösung und mache das ganze in einem rutsch richtig.

Bei mir nicht. Ein Gebäude oder Gebäudeteil wo alles drinnen steckt. Genau damit wollte ich eben das begraben unter Nodes verhindern. Das Gebäude ist der Index der alle nötigen Informationen beinhaltet.

Ich bin in erster Linie Anwender und nicht für die Datenbank zuständig. Letztere müssen entsprechende Sachen anwenderfreundlich zur Verfügung stellen.

Also das die PLZ und Adresse an jedes Objekt gehaengt werden soll, finde ich persoenlich ein unding. Da das einen verwaltungstechnischen Aufwand gibt den auf die Dauer keiner pflegen kann. Man denke nur mal daran was passiert wenn sich die Postleitzahlen mal wieder aendern oder sich ein Strassenname aendert. Dann muessen Xtausend Objekte von Hand geaendert werden. Saemtliche Daten an ein Ojekt zu haengen macht nichts einfacher sondern alles wesentlich komplizierter und aufwaendiger. Mal ganz von den Tipfehlern abgesehn dieman bei 1000 Objekten machen kann. Da heisst die Karlstrassedann mal Kalstrasseund schon wird das Gebaeude nicht mehr gefunden. Wird dieser Name nur an einer Stelle gepflegt ist der Fehler 1. schneller auffindbar und 2. ruckzuck fuer alle Elemente die darauf referenzieren behebbar. Solange es in OSM hier keine richtige Loesung von Entwicklerseite aus gibt, ist es meiner Meinung nach auch voelliger Unsinn komplette Adressdaten ein zu geben. sinnvoll sind nur Daten die direkt zu dem Objekt gehoeren (Hausnummer bei Haeusern, Strassennamen bei Strassen, PLZ beim Ort/Stadtviertel/extra Area etc.). Alles andere bringt fuer die Zukunft nur unnoetig viel Arbeit mit sich und birgt wahnsinns Fehlerquellen. Lest euch mal was zu relationalen Datenbanken und den SInn dahinter durch, denn wird euch klar wie unsinnig es ist Daen wie PLZ, Ortsname, Strassenname tausendfach ein zu tragen. OSM hat derzeit einfach keine Loesung dafuer.

Hi …

Ja. Ich denke, mittelfristig werden Relationen über geografische Polygone erfasst. Beispiel: Jedes Haus bekommt händisch eine addr:house_number=### Die Strasse wird mit zugeordnet. Die PLZ wird mit einem Polygon zugeordnet. Der Ort sowieso. Und die Software erzeugt daraus die passenden Relationen, ordnet die einzelnen Objekte ein, und speichert das Ganze regelgerecht in die Datenbank. Ich habe keinen direkten Kontakt zu den DB-Programmierern - aber ich denke, das könnte deren Plan sein. Und bis dahin verwende ich das Karlsruher-Schema: Zu jedem Haus füge ich hinzu addr:house_number=### addr:street=* (die PLZ etc. lasse ich zur Vermeidung von übermässiger Redundanz erst mal weg) Gruss, Markus

Für einen Ortskundigen sehe ich da kein Problem. Namensänderungen hatten wir hier. Da wird einmal alles mit dem Namen ausgewählt und in einem rutsch geändert. Mit JOSM ist das eine Sekunde Arbeit.

Ich mache für eine Straße ein Template, was dann mit Tags Einfügen durchweg angewendet und eben nur für die jeweilige Hausnummer oder Zusatzinformationen abgeändert wird. Die Tippfehlerfalle kann auch so überall passieren. Selbst falsch geschriebene anerkannte Tags finde ich oftmals vor, was ja mit den Presets eigentlich nicht sein dürfte. Es ist am jeweiligen Anwender da aufzupassen. Die Daten hängen nunmal von der Aufmerksamkeit des Anwenders ab. Wer liederlich arbeitet der wird auch so in die Falle tappen. Mit der Pflege an einer Stelle ist ja derzeit das Problem. Nicht selten kommt es vor, dass Leute die irgendwo ganz woanders Leben und vor 100 Jahren mal hier waren, meinen, irgendwas abändern zu müssen. Ist ja soweit kein Vorwurf. Nur wenn ich die Änderungen der letzten Jahre nicht kenne, kommt da oftmals Murks bei heraus. Bei den starren Realationen musst du diese immer im Auge haben und auf Vollständigkeit überprüfen. Eine einzelne Änderung bekomme ich sofort mit. Es fehlt die Möglichkeit intelligente Relationen anzulegen. Man bastelt z.B. ein Polygon und bringt diesem bei das alles darin dieses und jenes machen soll. Damit entfällt das händische Eintragen und die Mühsame Überprüfung auf Vollständigkeit. Man muss sich nur noch darum kümmern das Polygon und Grunddaten stimmen.

Eben weil es noch keine passende Lösung gibt, ist das derzeit die einzige sichere Lösung. Das dann umzuändern ist zumindestens in JOSM kein Ding. Alle Datensätze lassen sich mit einem Klick ändern. Wie das mit anderen Editoren aussieht kann ich nicht sagen. Sobald eine passende Lösung da ist, kann ich das mit wenigen Klicks ändern. Die Lösung muss aber erstmal da sein.

Wie schon geschrieben ist das die Aufgabe der jeweiligen Entwickler. Wenn ich mir bei jedem Node noch einen zusätzlichen Kopf um mögliche Auswirkungen im Backend machen soll, das ganze noch studieren muss, brauche ich hier garnichts mehr anfassen. Das ist eine Aufgabe für Leute die entsprechendes Wissen haben und Lösungen anbieten.