Adressen in Brandenburg als Hintergrund-Ebene für JOSM

Habe den Prozess nochmal laufen lassen und die Kacheln sind jetzt wieder da. Kannst die ganze Nacht durchmappen.

Mist, jetzt ist schon Morgen. Das Zeitfenster, wo es möglicherweise funktioniert hat, hat sich scheinbar schon wieder geschlossen, zumindest in Rathenow. Mach ich was falsch? :thinking:

@hfs
Du hast uns jetzt angefüttert mit diesem wirklich schicken und nützlichen Layer.
Und nun kommen wir immer wieder zur Futterstelle und schauen nach dem Futter, weil wir hungrig sind.
Kann es sein, dass es ganz zu Anfang stabiler war?
Vielleicht kann man auf die häufige Adressaktualisierung, also auf ständig neue Programmläufe verzichten. Es reicht vielleicht ein Lauf monatlich oder sogar quartalsweise.

Letztlich kann man als Mapper immer noch im Liegenschaftskataster nachschauen, wenn etwas nicht ganz stimmig zu sein scheint im Einzelfall. Bis jetzt sind wir wahrscheinlich eine Handvoll Leute, die den Layer mit den Georeferenzierten Adressen nutzen und ich schätze uns alle so ein, dass wir damit umgehen können. Es ist nun mal so: Die meisten Mapper arbeiten gar nicht mit JOSM, sondern mit ID, wo man sich das dop20c noch als Custom Hintergrund einstellen müsste, so räudig ist das dort. :crazy_face: Diese Leute wollen kein JOSM nutzen, für die ist der Layer der Georeferenzierten Adressen sowieso kein Thema. Die mühen sich lieber im ID total ab und sind dann froh, wenn sie wenigstens Straße und Hausnummer eingetragen haben, weil es in ID an vernünftigen Kopierfunktionen und plug-ins fehlt. Aber ID ist hier nicht das Thema.

Noch mal zusammen gefasst, mein Vorschlag:
Solange es nicht stabil ist, die Adressen einfach einkippen in den Layer, ohne ständig neue Programmläufe. Vielleicht hin und wieder mal hier im Thread einen Hinweis geben, wenn es ein Update gibt.

Hey @dx125, die Daten vom Durchlauf heute morgen sehen aber gut aus, denke ich. Schau doch mal auf

Es könnte sein, dass JOSM noch einen Cache der fehlerhaften Kacheln hat? In dem Fall würde es helfen den Cache zu löschen.

@hfs
Oh ja, genau so ist es gewesen. Cache gelöscht.
Geht jetzt scheinbar alles, wie es soll.
Danke für den Tipp und noch einen schönen Sonntag :smiley:

1 Like

Sollte man/frau sowas in einzelne Adressen auflösen?

Die Adressen werden auch so in Nominatim gefunden, aber im Layer Georeferenzierte Adressen Brandenburg werden sie halt rot dargestellt.

Hallo,
ich würde sagen, ja
Wenn nicht als einzelne Gebäude aufsplitten, dann zumindest als einzelne Eingänge mit Adresse auf dem Umriss.

Gruß
Danfost

2 Likes

Ja, unbedingt.
Außerdem ist das gesamte Umfeld mit Adress-Duplikaten zugekleistert (Ja, ja - das kommt vom “blind amtliche Daten abmalen” :face_vomiting:):

Och, da ist noch mehr suboptimal in Senftenberg, wie falsche Straßengeometrien aufgrund von exzessiver Spurtrennung an Verkehrsinseln.

Tztztz, da macht man Detailmapping mit getrennten Fahrbahnen sowie jedes einzelne Verkehrszeichen und dann führt man alle Wege in einem Punkt zusammen mit einer einzelnen Ampel …

Was machen wir denn mit dem „KGV Niederlehmer Werder“?

In den LGB-Daten sind alle Häuser in dieser Anlage mit dem Straßennamen KGV "Niederlehmer Werder" und einer Hausnummer 1–674 versehen.

In OSM würde man in Kleingärten normalerweise die Parzellennummer als ref eintragen und nicht als Hausnummer. Laut OSM gibt es auch gar nicht den einen Kleingartenverein Niederlehmer Werder, sondern mehrere Vereine mit unterschiedlichen Namen: OpenStreetMap.

Ich bin jetzt nur verunsichert, weil die LGB es in diesem einen Fall anders macht – habe nach KGV in allen Straßennamen gesucht. Könnte es wirklich sein, dass das „echte“ Adressen sind?

Die Stelle im Brandenburg-Viewer: BRANDENBURGVIEWER

1 Like

Jo, da bin ich auch schon drüber gestolpert. MMn muss man/frau unterscheiden zwischen Kleingartenanlagen und Wochenendsiedlungen.

Auch nett:
Senftenberg, Hörlitzer Straße 2222 gibt es genau (insert big number here) mal: :yum:

Ich habe LisMueller hierzu eingeladen, damit wir nicht nur über, sondern auch mit ihr/ihn über ein sinnvolles Tagging reden können.

@chris66
Oh, das ist nicht sehr abwechslungsreich :thinking:
In meiner Gegend gibt’s sowas nicht, hier herrscht nämlich Ordnung:

Hi,
leider gibt es in Brandenburg sehr viele unvollständige Adressen. Ein Beispiel ist, wenn die Adresse am Eingang komplett ist, aber das Haus dann nochmal mit der Adresse OHNE Hausnummer gemappt ist wie hier in Fürstenwalde.

Einwände gegen das Löschen der unvollständigen Adresse am Haus?

1 Like

Nö… wenn ich kann und wenn es ersichtlich ist, wo genau der Eingang ist, setze ich stets die Adresse am Eingang zusammen mit entrace=main. Die Position des Eingang kann man auch bei bestimmten Mehrgeschossern recht gut abschätzen.

Sven

1 Like

Einwände gegen das Löschen der unvollständigen Adresse am Haus?

prinzipiell ist eine Fläche besser weil die Ausdehnung der Adresse so enthalten ist und man bei Objekten innerhalb die Adresse ableiten kann. In Deutschland beziehen sich Adressen meist auf ein Grundstück oder ein Gebäude und nicht auf einen Eingang, daher ist das nicht die beste Abbildung.

Bei homogenen Mehrgeschossern funtioniert das aber nicht, daß ist dann eine künstliche, in der Realität nicht vorhandene Gebäudeaufteilung. So auch beim Lützow-Ring Dererlei Beispiele gibt es viele. In Wriezen wurde das gemacht, ist aber eine virtuelle Teilung, da man bei solchen Wohnblocktypen von Außen nie weiß, wie die reale Aufteilung der Wohnungen und somit der dann virtuellen Fläche wäre. Adresse am Eingang ist hier die beste aller möglichen Lösungen.

Sven

1 Like

Bei Reihenhäusern wo die Häuser einzeln gemappt sind funktioniert das natürlich.
Bei dem gezeigten Beispiel handelt es sich aber um ein Apartmenthaus.

Ich würde das begrüßen. Im Grunde ist das einfach nur redundant (Ort und PLZ in D sowieso). Falls ein Datenauswerter das wirklich (!) brauchen würde, dann könnte/müsste er das ohnehin (zusätzlich) aus den Eingangsknoten ableiten, wenn das Gebäude Adressen zu mehreren Straßen hätte :wink: Beispiel Roonstraße 1 und Deutschherrnstraße 53