Ich würde sie erstmal als local_name= erhalten.
Edit: Danke für die Korrektur - man sollte tags nicht aus dem Kofp hinschreiben.
Grüße, Georg
PS:
Hausnummern im Navi können das dortige Sicherheitsrisiko auch ohne Straßennamen senken - so denn die Technik den Rettungskräften zur Verfügung steht.
Doch, natürlich. Du kannst inzwischen (auch dank Plugins) in jeder Projektion in JOSM arbeiten. Es ist mein liebsten Tool zur Digitalisierung und Bearbeitung von Geodaten geworden.
Ich predige mittlerweile seit Jahren, auf Gauß-Krüger-Koordinaten voll und ganz zu verzichten, wo es nach Möglichkeit geht. Gerade das OSM-Umfeld ist eines, wo der Verzicht nicht schmerzen dürfte… eben jenem Transformationsproblem.
Hmm. Ich predige seit Jahren, die Original-GK-Koordinaten solange wie möglich irgendwo mitzuschleifen (im Wiki natürlich, nicht an den Datensätzen, aber dann mit einer permanenten Zuweisungsmöglichkeit). Die BeTA ist sehr gut für unser Vorhaben, es gibt noch bessere, welche aber den Landes- und Katasterbehörden vorenthalten sind. Da hat man dann Genauigkeit im Millimeterlevel (>= 7. Stelle in den WGS84-Koordinaten); ; vielleicht können wir diese in Zukunft ebenfalls nutzen und dann wäre es halt schön, weiterhin auf die Originaldaten zugreifen zu können. Da wir hier aber auf volle Meter gerundete Eingangskoodinaten haben, ist BeTA aber das Maß aller Dinge.
Ich rate von GK nur ab, wenn das Original nicht in GK kommt. Wenn das Original in GK kommt, sollten die Originale irgendwo gespeichert werden. ETRS89/UTM32N/33N hat halt den Vorteil, dass die Koordinaten bei uns so identisch sind, dass man damit viel mehr machen kann, als damals mit DHDN(Potsdam)/GK1-3.
Naja, mag sein, daß man hier in Brandenburg gelegentlich etwas verwöhnt ist… Die Einführung von ETRS89 (dessen GRS80 Ellipsoid ist +/- Synonym zu WGS84) wurde deutschlandweit um 1994 (!!) von den Landesvermessungverwaltungen beschlossen. In Brandenburg begann dann die Einführung ca. 2 Jahre (!!) später. Gauß-Krüger und ETR89 wurde dann aber (aus Kompaktibilitätsgründen), weil die anderen Bundesländer diese Beschlüsse ignoriert haben, parallel weitergeführt.
Ich selbst arbeite jetzt seit 10 Jahren intensiv im GIS-Bereich und habe seit dem genügend Probleme mit Gauß-Krüger gesehen…
Das größte war vor Jahren https://www.protectedplanet.net/ Brandenburg hatte (für sich als Normal betrachtend) Schutzgebietsgrenzen für diesen Dienst geliefert… in ETRS89 Zone 33 (Brandenburg hatte da der x-Koordinate eine führende “3” für Zone 33" mitgegeben). Für den Kartendienst wurd das aber als Gauß-Krüger im 3ten Streifen interpretiert, eben mit dem dann daraus resultierenden Lageversatz… Nach meiner Fehlermeldung wurde das stillschweigend geändert, ohne Danke zu sagen… Fehler gibt eben leider keiner gerne zu… Da könnte ich aber noch mehr erzählen…
Hier in Brandenburg dürfte Gauß-Krüger mittlerweile recht gut ausgerottet sein… Auch Meck-Pom hat recht zeitig umgestellt, dort aber mit einer führenden “33” vor der x-Koordinate… Berlin hat lange an selnem "Schweine"Soldner festgehalten… noch was anders…
Ich selbst treffe auf GK-Koordinatewn nur noch bei ganz alten Daten, Daten der LMBV, oder Punktdaten von Tier- und Pflanzerfassungsdaten eines bestimmten Programmes…
Wir in Niedersachsen nutzen ja auch gerne EPSG:4647 (UTM32 mit führender 32), dummerweise sind quasi alle anderen auf EPSG:25832 (ohne führende 32), was dann öfter “Ja, aber wir liefern den WMS doch in UTM32!!!1” -Ja, aber im falschen… nach sich zieht.
An unseren Datensätzen steht aber eigentlich immer noch die Originalkoordinate dran, in welchem System die auch immer kam. Gearbeitet wird dann mit UTM.
Die überwiegenden Geodaten Brandenburgs werden mittlerweile ausschließlich in EPSG 25833 ausgeliefert, mit korrekter Projektionsdatei (!)… Zum Glück… Langezeit war die Projektionsdatei fehlerhaft, was dazu geführt hat, daß einige Transformationen nicht geklappt haben…
Alte und fehlerhafte Daten halten sich aber immer noch recht lange…
Da sich hier mehrere Mapper zu Wort gemeldet haben, aber niemand Nachbesserungen gefordert hat, gehe ich davon aus, dass es keine Bedenken gibt.
Letztendlich geht es darum festzustellen, ob es Vorbehalte gegen das Vorhaben gibt und ggf. nachzubessern.
Da es jetzt seit Tagen keine weitere Diskussion gibt und kein Nachbesserungsbedarf angemeldet wurde, gehe ich davon aus, dass die Freigabe als erteilt gelten kann, insofern bis morgen nicht doch noch jemand Bedenken vorbringt oder Diskussionsbedarf sieht.
Da inzwischen durch mehrere Mapper mehr als ca. 95 Prozent der Gebäude erfasst wurden, steht auch der Übernahme der Adressen an die Hausumringe (durch deren Nichtvorhandensein) nichts mehr im Weg.
Wer sich noch zur Umsetzung des Vorhabens äußern will, ob zustimmend oder ablehnend, der möge damit bitte nicht mehr warten und dies jetzt tun!
Diese Datei beinhaltet immer noch WGS84-Koordinaten aus nicht nachvollziehbarer Quelle. Da die GK-Koordinaten metergenau angegeben sind, gehe ich davon aus, dass diese die Primärquelle darstellen.
Du möchtest also die WGS84-Koordinaten möglichst exakt in GK-Koordinaten umrechnen?
Kannst du gerne machen, ich habe da nichts dagegen.
Fragt sich nur, welchen Sinn das letztendlich haben soll, denn die Adressen sollen doch an die Gebäude.
Da dort die Bebauung nicht gerade dicht ist, sind die zugehörigen Gebäude auch bei einer Abweichung von einigen Metern eindeutig zu identifizieren.
Ich habe jedenfalls keinen Fall gefunden, bei dem die Zuordnung zu einem Gebäude nicht möglich gewesen wäre.
Ah, wird das noch nachbearbeitet? Ich habe nur Stichproben aus der OSM-Daten gezogen, die hier gepostet wurde. Dort haben die Koordinaten mit den “falschen” übereingestimmt. Wenn das noch händisch aktualisiert wird, super
1.) Die Gebäudeumringe werden (mittels Bing-Bildern) erfasst, dies wurde schon von mehreren Mappern zu über 97% erledigt, ca. 10 Neubauten sind noch nicht auf den Bildern ersichtlich, evtl. wurden maximal ca. 5 weitere Gebäude übersehen oder sind durch Bäume verdeckt und deshalb nicht sichtbar.
Somit schon erledigt.
3.) Benötigt wird das UtilsPlugin2, welches direkt in JOSM unter Bearbeiten → Einstellungen → Plugins → utilsplugin2 installiert werden kann.
Die Adressen aus der OSM-Datei werden jeweils einzeln von den Adressknoten auf das passende Gebäude (heruntergeladen in 2.), soweit vorhanden (siehe 1.), übertragen.
Hierfür werden durch Anklicken bei gleichzeitig gedrückt gehaltener Strg-Taste jeweils der Adressknoten und das dazugehörigen Gebäude ausgewählt und anschließend mit Strg+Shift+G (“Geometrie ersetzen”) die Adressdaten auf des Gebäude übertragen.
Der nun überflüssige Adressknoten wird hierbei automatisch von JOSM entfernt.
Hierbei werden die Adressen manuell mit schon in OSM vorhandenen Adressen abgeglichen, so dass Dopplungen vermieden und Fehler beseitigt werden.
Die Knoten dienen hier also nur als Träger der Adressinformationen und werden selbst (bis auf evtl. die ca. 10 Ausnahmen, siehe 1.) nicht hochgeladen.
Es wäre natürlich auch möglich, die Gebäude und Adressknoten vom OSM-Server herunterzuladen, die Punkte 2. und 3. durchzuführen und die Datei dann nochmals vor dem Hochladen hier zur Diskussion zu stellen.
Allerdings bestünde hier dann die Gefahr, dass zwischenzeitlich von anderen Mappern Änderungen an den OSM-Daten auf dem Server vorgenommen werden, so dass Bearbeitungskonflikte beim Hochladen entstehen könnten.
Deshalb möchte ich davon eher absehen.
edit:
3. Benutzung von “Geometrie ersetzen”
2. genauer beschrieben
Geht das nicht schneller mit: Knoten und Gebäude markieren, dann Strg+Shift+G (Geometrie ersetzen) ?
Dadurch werden alle Daten vom Knoten auf den Umriss übertragen und der Knoten gleichzeitig gelöscht.
Danke für den Hinweis!
Ich hatte das schonmal erfolglos probiert, jetzt geht es auch bei mir.
Vielleicht hatte ich da etwas falsch gemacht oder “Geometrie ersetzen” funktioniert noch nicht so lange mit Punkten…
Benötigt wird übrigens das UtilsPlugin2, welches direkt in JOSM unter Bearbeiten → Einstellungen → Plugins → utilsplugin2 installiert werden kann.
