Das scheint mir falsch zu sein. Es gibt es zwei Möglichkeiten:
In JOSM den Adressknoten auswählen, Merkmale kopieren (aus dem Bearbeiten Menü), das Gebäude auswählen, Strg+V, den jetzt überflüssigen Adressknoten löschen.
In JOSM den Adressknoten auswählen, Strg+C, das Gebäude auswählen, Strg+Shift+V, den jetzt überflüssigen Adressknoten löschen.
Klar kann es das. 
Danke für den Hinweis auf das fehlende Shift.
Ja, bei Bildern (meist im Hintergrund) schon, aber nicht bei Knoten.
Sollte sich hier auf die OSM-Datei beziehen.
Ich würde den Adressnode nur in den Umriss verschieben
Ich fände es besser den Adressnode in den Gebäudeumriss mit einem dortigen node zu vereinen und um Entrance=* zu ergänzen.
Ist entrance=* unbekannt, dann einen Ecknode nutzen und von da kopieren und die Daten dem Umriss zufügen und aus dem Ecknode löschen.
Damit bleibt die Historie des Adressnodes erhalten.
Ist nicht geplant:
Da es sich um die Neueintragung von Adressen handelt, gibt es auch keine Historie (abgesehen von dem einen oder anderen Abgleich).
Auch existieren in OSM die fraglichen Gebäude oft noch gar nicht, also bleibt es in vielen Fälle vorerst sowieso möglicherweise nur bei einem Adressknoten.
danke whb,
ich habe die Datensätze überprüft und kann keine Fehler feststellen:
→ https://www.dropbox.com/s/kg18sjdmnbiug34/Hausnummern_Hilgermissen.osm?dl=1
Sind die Luftbilder denn hinreichend aktuell, also würde es nach eurer Import-Aktion sinnvoll sein, die Hausumringe aus Bing abzupinseln?
aktuell hängt Bing ca. 2-3 Jahre hinterher, so dass ca. 10 Häuser fehlen,
derzeit sind die google maps Luftbilder aktueller (dort fehlen maximal 1-2 Häuser)
Bis auf wenige Neubauten (die angesprochenen ca. 10 Häuser) scheint es dort bzgl. der Gebäude zu keinen Veränderungen gekommen zu sein.
Somit sollte es in Ordnung sein, die Gebäude abzumalen, auch schon vor der Übernahme der Adressen.
Dann wäre es nämlich möglich die Adressen gleich an die Gebäude anzubringen, ansonsten gäbe es dann einen Schritt mehr, was aber auch nicht schlimm wäre.
Nächste Frage wäre dann, ob die Community mit den Daten (siehe OSM-Datei) und deren Eintragung mit manuellem Abgleich (Überprüfung auf Duplikate) einverstanden ist oder ob noch Nachbesserungen erwünscht sind.
Dirk, wärst du dazu bereit nach Freigabe durch die Community, die OSM-Datei in JOSM zu öffnen, mit vorhandenen OSM-Daten abzugleichen (ggf. Fehler zu verbessern und um Duplikate zu bereinigen), ggf. die Adressen an vorhandene Gebäudeumringe zu übernehmen und hochzuladen?
Fändest du es besser, schon möglichst viele Hausumringe für die Übernahme der Adressdaten vorzufinden (die Community könnte hier relativ schnell aktiv werden ;)) oder bist du eher froh, wenn dem nicht so wäre?
Brauchst du noch technische Anleitung (z.B. zum Aufteilen der Daten, damit ggf. die Übernahme nicht sofort an einem Stück erfolgen muss)?
Sonstige Fragen?
Ja,
allerdings muss ich mich erst in JOSM einarbeiten.
(habe noch nie damit gearbeitet…)
Ja…
Edit:
sollen denn in diesem Zuge auch die dort jetzt in OSM eingetragenen “Fantasie”- bzw. historischen Straßennamen in der Gemeinde Hilgermissen entfernt werden ?
(per Gemeinderatsbeschluss gibt es ja in Hilgermissen keine Straßennamen)
→ https://www.kreiszeitung.de/lokales/nienburg/lehnt-strassennamen-2777996.html
überspitzt formuliert sind diese diese “illegal”:
→ https://www.dieharke.de/Lokales/Nordkreis/29901/Immer_mehr_private_Strassenschilder.html
Moin,
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.
Bitte loc_name=* verwenden, weitere Auswahlmöglichkeiten zu name → https://wiki.openstreetmap.org/wiki/DE:Names
Wenn alles nicht passt, dann eventuell in description:de=* hinterlegen z.B. “sollte die alte Klinke gewesen sein”
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.
WARNUNG
Die Gauß-Krüger-Koordinaten wurden in der Tabelle nicht gut in WGS84 umgesetzt. Ich habe die Koordinaten gerade per proj4 geprüft:
Eingabe (X, Y) : 3510741.00 5856931.00
Laut Tabelle (LON, LAT) : 9.1582880000, 52.8449010000
Standard-Helmert (3m genau; LON, LAT): 9.1583498, 52.84488956
BeTA2007 (submeter; LON, LAT) : 9.15835163, 52.84489527
Soll ich euch den Datensatz mal vernünftig umwandeln?
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.
Sven
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…
Sven
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… 
[/Ende OT-Exkurs]
Sven
Ich bekenne mich schuldig und habe ein paar Häuser abdigitalisiert, als Sühne.