Hi, für die Bielefeld interessierten. Ich habe jetzt auch ein view für den Vergleich von ALKIS der Stadt Bielefeld (Aus dem WFS) und OpenStreetMap. https://osm.zz.de/dbview/?db=alkisdiff-bielefeld&layer=buildingnotinosm Gleichzeitig sind die Daten auch in dem "plbuildings" zeugs so das für die die Gebäude mit dem Josm und dem "zzbuildings" plugin updaten die auch bekommen. Die bekommen dann ein: source:building=OpenData Bielefeld - WFS Aus dem WFS Update ich wöchentlich. (Dienstags) und die differenzkarte wird jeden Morgen neu erzeugt. Es gibt da akutell noch einen Fehler mit unterirdischen Gebäuden - Gebäudefunktion 3094 - was UBahnhöfe sind. Die muss ich noch rausfiltern. Flo -- Florian Lohoff f@zz.de Any sufficiently advanced technology is indistinguishable from magic.
Hola, On Mon, Feb 23, 2026 at 02:54:52PM +0100, Florian Lohoff wrote:
Hi, für die Bielefeld interessierten. Ich habe jetzt auch ein view für den Vergleich von ALKIS der Stadt Bielefeld (Aus dem WFS) und OpenStreetMap.
https://osm.zz.de/dbview/?db=alkisdiff-bielefeld&layer=buildingnotinosm
So - und hier gibts dann auch das Differenz WMS - Auch täglich neu: https://osm.zz.de/geoserver/zz/wms Layer "bielefeld_building_delta" So das wenn man sich das ALKIS WMS (Land NRW) + DOP + ALKIS Diff WMS zusammenbaut das im Josm so aussieht. https://tmp.zz.de/20260223-SchnappsStrategic/Screenshot_from_2026-02-23_15-1... Rot sind Gebäude(-teile) die im ALKIS sind aber nicht in OSM. Blau sind Gebäude(-teile) die in OSM sind aber nicht im ALKIS Wobei ich gerade spannenderweise teile sehe die ich nicht vergleiche. Ich muss doch durch meine ALKIS Gebäudefunktion Excludeliste nochmal durchgehen. Oft haben Gebäude eine Rot/Blaue umrandung. Dann ist das eben nur ein Lagefehler - typischerweise eher in OSM. Mit den richtigen Plugins im Josm - Doppelklick aufs Gebäude, Tastenkombination und schon ist das aus dem ALKIS geupdated. Flo -- Florian Lohoff f@zz.de Any sufficiently advanced technology is indistinguishable from magic.
Hallo Flo, erstmal Danke für diese wirklich hilfreichen Werkzeuge. Gerade das Nachziehen von Gebäudeumrissen ist damit unendlich viel einfacher geworden. Trotzdem eine Frage: Auf welchem Stand sind die niedersächsischen Daten? Es kommt manchmal zu Abweichungen zwischen dem von zzbuildings ermittelten Daten und dem ALKIЅ Hintergrund-Layer in josm. wms:https://opendata.lgln.niedersachsen.de/doorman/noauth/alkis_wms?FORMAT=image/png&TRANSPARENT=TRUE&VERSION=1.3.0&SERVICE=WMS&REQUEST=GetMap&LAYERS=ALKIS&STYLES=&CRS={proj}&WIDTH={width}&HEIGHT={height}&BBOX={bbox} Uwe Am Mon, Feb 23, 2026 at 02:54:52PM +0100 schrieb Florian Lohoff:
Hi, für die Bielefeld interessierten. Ich habe jetzt auch ein view für den Vergleich von ALKIS der Stadt Bielefeld (Aus dem WFS) und OpenStreetMap.
https://osm.zz.de/dbview/?db=alkisdiff-bielefeld&layer=buildingnotinosm
Gleichzeitig sind die Daten auch in dem "plbuildings" zeugs so das für die die Gebäude mit dem Josm und dem "zzbuildings" plugin updaten die auch bekommen. Die bekommen dann ein:
source:building=OpenData Bielefeld - WFS
Aus dem WFS Update ich wöchentlich. (Dienstags) und die differenzkarte wird jeden Morgen neu erzeugt.
Es gibt da akutell noch einen Fehler mit unterirdischen Gebäuden - Gebäudefunktion 3094 - was UBahnhöfe sind. Die muss ich noch rausfiltern.
Flo -- Florian Lohoff f@zz.de Any sufficiently advanced technology is indistinguishable from magic.
_______________________________________________ OSM mailing list -- osm@gt.owl.de To unsubscribe send an email to osm-leave@gt.owl.de %(web_page_url)slistinfo/%(_internal_name)s
-- MMK GmbH, Fleyer Str. 196, 58097 Hagen Uwe.Steinmann@mmk-hagen.de Tel: 02331 840446 Fax: 02331 843920
Hola, On Mon, Feb 23, 2026 at 03:51:29PM +0100, Uwe Steinmann wrote:
Hallo Flo,
erstmal Danke für diese wirklich hilfreichen Werkzeuge. Gerade das Nachziehen von Gebäudeumrissen ist damit unendlich viel einfacher geworden. Trotzdem eine Frage: Auf welchem Stand sind die niedersächsischen Daten? Es kommt manchmal zu Abweichungen zwischen dem von zzbuildings ermittelten Daten und dem ALKIЅ Hintergrund-Layer in josm.
Aeh ja - Laut dem Shape files die ich aus dem Open Data Portal des LGNL habe: flo@m3:~/projects/osm/hausumringe-ni/hausumringe/202601$ grep datum info-ni.txt Auslesedatum: 2025-12-03 Das problem ist ja - Du baust ein Haus. Nach Bauabnahme wird das Eingemessen. Dann landen die Daten bei deiner Katasterbehörder. Die geben das alle 6 Monate an das Land ab. D.h. es kann schnell passieren das es 12 Monate oder länger dauert bis das da drin landet. Deshalb versuche ich ja durchaus die Open Data exporte der Katasterbehörden direkt zu benutzen. Die exportieren mitunter Wöchentlich oder haben via WFS einen Tagesaktuellen Zugang. Das Problem ist das das unendlich Arbeit ist. Jede der Behörden exportiert das anders. Einige Kreise haben NAS files, andere nur shapes oder WFS. Dann jeweils mit unterschiedlichen Attributen. Ich mache das ja schon seit jahren für den Kreis GT - Die exportieren wöchentlich NAS files (Große XMLs mit den gesamten ALKIS daten ohne Eigentümer) - Das konvertieren/importieren der NAS files für den Kreis GT oder Kreis PB dauert dann ein paar Stunden. Ist aber nicht wild. Das mache ich einmal die Woche. Dann Speicher ich mir den postgres/gis dump weg. Und wenn ich dann täglich das diffe dann importiere ich nur die dumps und die Minuten aktuellen OSM PBF files für die Kreise. Flo -- Florian Lohoff f@zz.de Any sufficiently advanced technology is indistinguishable from magic.
Am Mon, Feb 23, 2026 at 06:07:45PM +0100 schrieb Florian Lohoff:
Hola,
On Mon, Feb 23, 2026 at 03:51:29PM +0100, Uwe Steinmann wrote:
Hallo Flo,
erstmal Danke für diese wirklich hilfreichen Werkzeuge. Gerade das Nachziehen von Gebäudeumrissen ist damit unendlich viel einfacher geworden. Trotzdem eine Frage: Auf welchem Stand sind die niedersächsischen Daten? Es kommt manchmal zu Abweichungen zwischen dem von zzbuildings ermittelten Daten und dem ALKIЅ Hintergrund-Layer in josm.
Aeh ja - Laut dem Shape files die ich aus dem Open Data Portal des LGNL habe:
flo@m3:~/projects/osm/hausumringe-ni/hausumringe/202601$ grep datum info-ni.txt Auslesedatum: 2025-12-03
Das problem ist ja - Du baust ein Haus. Nach Bauabnahme wird das Eingemessen. Dann landen die Daten bei deiner Katasterbehörder. Die geben das alle 6 Monate an das Land ab.
D.h. es kann schnell passieren das es 12 Monate oder länger dauert bis das da drin landet. Da wird es vermutlich dran liegen. Ich habe trotzdem nochmal einen Screenshot angehängt. Da sind mehrere Gebäude, die leicht versetzt sind und ein paar Meter weiter passt es dann wieder.
Uwe
Hola, On Mon, Feb 23, 2026 at 06:36:30PM +0100, Uwe Steinmann wrote:
Da wird es vermutlich dran liegen. Ich habe trotzdem nochmal einen Screenshot angehängt. Da sind mehrere Gebäude, die leicht versetzt sind und ein paar Meter weiter passt es dann wieder.
Puh spannend. Ich tippe drauf das das WMS richtig ist. Ich traue den Katasterbehörden da mehr Koordinaten/Spheroid know how zu als mir ;) Also - das kann verschiedene Ursachen haben und da müsste man jetzt suchen. Sind das aktuelle Daten oder ist das zeugs von 2008 oder so ein Alter? Denn wenn wir das 2008 (Bzw 10+ Jahre) aus dem ALKIS übernommen haben dann haben wir seit dem eine Kontinentaldrift. Im ALKIS wird ja mit UTM32 gearbeitet das einen kontinentalen Nullpunkt hat. D.h. der driftet mit. Bei WGS84/EPGS:4326 wie bei OSM haben wir das nicht. D.h. bei OSM kommt über die Jahre ein Fehler rein. Ich meine das sich Europa mit 1-2cm im Jahr verschiebt. Seit 2008 sind das also ggfs schon 36cm "Lagefehler" aller Daten die so alt sind. Es kann auch sein das da irgendwo ein Fehler in der Koordinatentransformation stattgefunden hat. D.h. beim import/weitergabe an den JOSM macht ja meine API eine UTM32 -> EPSG:4326 transformation. Das überlasse ich der Postgis - also ST_Transform() und da hätte ich behauptet die wissen was sie tun. Aber - wer weiss. Auch möglich ist das die verschobenen Gebäude noch mit dem alten JOSM "tracer2" übernommen wurde und der einen Fehler aus den Bildern errechnet hat. Hast du mal einen Link zu der gegend? Flo -- Florian Lohoff f@zz.de Any sufficiently advanced technology is indistinguishable from magic.
Am Mon, Feb 23, 2026 at 07:06:25PM +0100 schrieb Florian Lohoff:
Hola,
On Mon, Feb 23, 2026 at 06:36:30PM +0100, Uwe Steinmann wrote:
Da wird es vermutlich dran liegen. Ich habe trotzdem nochmal einen Screenshot angehängt. Da sind mehrere Gebäude, die leicht versetzt sind und ein paar Meter weiter passt es dann wieder.
Puh spannend. Ich tippe drauf das das WMS richtig ist. Ich traue den Katasterbehörden da mehr Koordinaten/Spheroid know how zu als mir ;)
Also - das kann verschiedene Ursachen haben und da müsste man jetzt suchen. Sind das aktuelle Daten oder ist das zeugs von 2008 oder so ein Alter? In diesem Fall wurden die Gebäude gerade erst von mir mit Hilfe von zzbuildings erzeugt. Da musst die Diskrepanz also zwischen den Daten die zzbuildings aktuell nutzt und dem WMS liegen. Da beide aus dem Open Data Portal des LGNL kommen, hatte ich unterschiedliche Versionstände vermutet.
Etwas seltsam ist die lokale Begrenzung dieser Differenz. Im gleichen Ort ein paar hundert Meter weiter, passt es schon wieder.
Denn wenn wir das 2008 (Bzw 10+ Jahre) aus dem ALKIS übernommen haben dann haben wir seit dem eine Kontinentaldrift. Im ALKIS wird ja mit UTM32 gearbeitet das einen kontinentalen Nullpunkt hat. D.h. der driftet mit. Bei WGS84/EPGS:4326 wie bei OSM haben wir das nicht. D.h. bei OSM kommt über die Jahre ein Fehler rein.
Ich meine das sich Europa mit 1-2cm im Jahr verschiebt. Seit 2008 sind das also ggfs schon 36cm "Lagefehler" aller Daten die so alt sind. Das würde in diesem Fall bei einigen Gebäuden ganz gut passen, aber hundert Meter weiter ist die Verschiebung dann wieder weg oder zumindest deutlich kleiner.
Es kann auch sein das da irgendwo ein Fehler in der Koordinatentransformation stattgefunden hat. D.h. beim import/weitergabe an den JOSM macht ja meine API eine UTM32 -> EPSG:4326 transformation. Das überlasse ich der Postgis - also ST_Transform() und da hätte ich behauptet die wissen was sie tun. Aber - wer weiss. Das dürfte sich auch nicht nur lokal auswirken, sondern müsste doch ganz Niedersachen betreffen.
Auch möglich ist das die verschobenen Gebäude noch mit dem alten JOSM "tracer2" übernommen wurde und der einen Fehler aus den Bildern errechnet hat.
Hast du mal einen Link zu der gegend? Das ist in Ottenstein, z.B. dieses Gebäude
https://www.openstreetmap.org/way/390886185#map=19/51.944917/9.412997 Habe ich gestern mit zzbuildings nachgezeichnet. Uwe
Hola, On Tue, Feb 24, 2026 at 07:07:24AM +0100, Uwe Steinmann wrote:
In diesem Fall wurden die Gebäude gerade erst von mir mit Hilfe von zzbuildings erzeugt. Da musst die Diskrepanz also zwischen den Daten die zzbuildings aktuell nutzt und dem WMS liegen. Da beide aus dem Open Data Portal des LGNL kommen, hatte ich unterschiedliche Versionstände vermutet.
Etwas seltsam ist die lokale Begrenzung dieser Differenz. Im gleichen Ort ein paar hundert Meter weiter, passt es schon wieder.
Korrekt - das kann das nicht an der Kontinentaldrift hängen. Ich tippe fast auf absichtliche Lagefehler in den LGNL Daten. Ansonsten kann ich mir das nicht erklären.
Es kann auch sein das da irgendwo ein Fehler in der Koordinatentransformation stattgefunden hat. D.h. beim import/weitergabe an den JOSM macht ja meine API eine UTM32 -> EPSG:4326 transformation. Das überlasse ich der Postgis - also ST_Transform() und da hätte ich behauptet die wissen was sie tun. Aber - wer weiss. Das dürfte sich auch nicht nur lokal auswirken, sondern müsste doch ganz Niedersachen betreffen.
Ja - Aber unterschiedlich stark je nachdem WANN die transformation von UTM32 zu WGS84 stattgefunden hat.
Hast du mal einen Link zu der gegend? Das ist in Ottenstein, z.B. dieses Gebäude
https://www.openstreetmap.org/way/390886185#map=19/51.944917/9.412997
Habe ich gestern mit zzbuildings nachgezeichnet.
Okay - ich habe mir mal im QGIS das WMS und auch das original Shape vom LGNL hintereinander gelegt und habe denselben Lagefehler. https://tmp.zz.de/20260224-TrailsideDiner/Screenshot_from_2026-02-24_12-30-5... D.h. das LGNL Shape ist schrott - oder deren WMS. Fehler beim LGNL. Ah - ich hab nochmal das WFS mir dahintergelegt - Das ist wieder heile. D.h. deren Shapefile sind kaputt und haben den lagefehler. Ich gucke mal ob ich mir das aus dem WFS hole für den Vergleich. Das mache ich für NRW ja auch schon weil bei denen der Shape export seit ewigkeiten kaputt ist. Flo -- Florian Lohoff f@zz.de Any sufficiently advanced technology is indistinguishable from magic.
Hola, On Tue, Feb 24, 2026 at 12:36:02PM +0100, Florian Lohoff wrote:
Ah - ich hab nochmal das WFS mir dahintergelegt - Das ist wieder heile. D.h. deren Shapefile sind kaputt und haben den lagefehler. Ich gucke mal ob ich mir das aus dem WFS hole für den Vergleich. Das mache ich für NRW ja auch schon weil bei denen der Shape export seit ewigkeiten kaputt ist.
Also nicht nur das die Shapes kaputt sind - der WFS server ist auch "kaputt" - Einfach mal alle objekte über paging holen wird nicht so einfach. Das dingen returned random mäßig mal einfach 503 und dann bricht ogr2ogr ab auch mit -skipfailure und co ... Ich bastel mir mal was drumherum mit parsen vom logfile und restart ab dem richtigen feature und co. Das wird also wieder eine riesen Puzzelei. Open Data my ass. Flo -- Florian Lohoff f@zz.de Any sufficiently advanced technology is indistinguishable from magic.
On Tue, Feb 24, 2026 at 02:31:57PM +0100, Florian Lohoff wrote:
Das wird also wieder eine riesen Puzzelei.
Open Data my ass.
Okay - das ist durchgelaufen und in der plbuildings api sind jetzt die daten aus dem LGNL WFS - D.h. da kommen jetzt richtige Daten. Jetzt muss ich das noch in das ganze diff map zeugs bauen. Flo -- Florian Lohoff f@zz.de Any sufficiently advanced technology is indistinguishable from magic.
Am Tue, Feb 24, 2026 at 04:12:56PM +0100 schrieb Florian Lohoff:
On Tue, Feb 24, 2026 at 02:31:57PM +0100, Florian Lohoff wrote:
Das wird also wieder eine riesen Puzzelei.
Open Data my ass.
Okay - das ist durchgelaufen und in der plbuildings api sind jetzt die daten aus dem LGNL WFS - D.h. da kommen jetzt richtige Daten. Heisst das, dass ich zzbuildings jetzt nochmal auf die Problemgebäude laufen lassen kann? Aktuell kommt ein Connection Error.
Uwe
Am Tue, Feb 24, 2026 at 05:06:19PM +0100 schrieb Uwe Steinmann:
Am Tue, Feb 24, 2026 at 04:12:56PM +0100 schrieb Florian Lohoff:
On Tue, Feb 24, 2026 at 02:31:57PM +0100, Florian Lohoff wrote:
Das wird also wieder eine riesen Puzzelei.
Open Data my ass.
Okay - das ist durchgelaufen und in der plbuildings api sind jetzt die daten aus dem LGNL WFS - D.h. da kommen jetzt richtige Daten. Heisst das, dass ich zzbuildings jetzt nochmal auf die Problemgebäude laufen lassen kann? Aktuell kommt ein Connection Error. Jetzt ist alles bestens und die Gebäudeumrisse passen zum WMS. Danke.
Uwe
participants (2)
-
Florian Lohoff -
Uwe Steinmann