Polygone in Bildern Serialisieren / Extrahieren

streckenkundler · 2014-11-13 09:57:57

selphiron wrote:

Hmm okay.. also wenn ich das richtig verstanden habe, werden die alten Daten auch übernommen. Oder werden nur die neuen Daten in Alkis sein? Danke jedenfalls für die Info ich glaub ich kann mir dadurch eine Meeeeeenge sinnlose Arbeit erpsaren.

Die AAA-Einführung bedeutet, daß SÄMTLICHE Geodaten nach ETRS89 (für Berlin UTM-Zone 33; EPSG 25833) überführt werden, also Liegenschaftsdaten genauso wie Basis-DLM, Rastersaten ect. Mit der AAA-Einführung wird auch an der Dateninternen Struktur einiges verändert.

Im Ergebnis wird Nur noch mit den AAA-Daten und in ETRS89 gearbeitet...

Sven

Last edited by streckenkundler (2014-11-13 10:12:41)

TobWen · 2014-11-13 10:11:01

selphiron wrote:

TobWen wrote:
Die Senatsverwaltung für Stadtentwicklung und Umwelt hat ein "offizielles" Tool für den Übergang unter OpenData bereitgestellt. Leider wieder nicht für uns nutzbar, da die erzeugten und modifizierten Daten einen BY-Hinweis besitzen müssen... juhuu...
darf ich fragen, wie das Tool heißt bzw. wo ich es herkriege?

Google, 1. Eintrag: http://www.stadtentwicklung.berlin.de/g … ware.shtml

TobWen · 2014-11-13 10:11:57

streckenkundler wrote:

Mit der AAA-Einführung wird auch an der Dateninternen Struktur einiges verändert.

Ich sag ja schon den Leuten seit über 10 Jahren: Metadaten! Füllt die Metadaten aus!

streckenkundler · 2014-11-13 10:17:58

TobWen wrote:

Ich sag ja schon den Leuten seit über 10 Jahren: Metadaten! Füllt die Metadaten aus!

Wer ein klein wenig Zeit hat, kann sich die GeoInfoDok reinziehen...

TobWen · 2014-11-14 23:37:06

streckenkundler wrote:

TobWen wrote:
GeoInfoDok reinziehen...

Hast du mal mit EDBS-Daten von ATKIS gearbeitet? So ein sche... das Parsen der komplexen Objekte ist der Horror, unsere Relationen sind nix dagegen, weil sie recht eindeutig sind

TobWen · 2014-11-14 23:39:53

[falscher thread]

Last edited by TobWen (2014-11-14 23:40:21)

maxbe · 2014-11-15 00:07:40

streckenkundler wrote:

selphiron wrote:
Hmm okay.. also wenn ich das richtig verstanden habe, werden die alten Daten auch übernommen. Oder werden nur die neuen Daten in Alkis sein? Danke jedenfalls für die Info ich glaub ich kann mir dadurch eine Meeeeeenge sinnlose Arbeit erpsaren.
Die AAA-Einführung bedeutet, daß SÄMTLICHE Geodaten nach ETRS89 (für Berlin UTM-Zone 33; EPSG 25833) überführt werden, also Liegenschaftsdaten genauso wie Basis-DLM, Rastersaten ect. Mit der AAA-Einführung wird auch an der Dateninternen Struktur einiges verändert.
Im Ergebnis wird Nur noch mit den AAA-Daten und in ETRS89 gearbeitet...

Ich wäre nicht so optimistisch...

Zum einen könnte so ein Umstieg einige Zeit dauern, und bis irgendwas für die Öffentlichkeit auch zugänglich ist, dauert es noch mal. Und ob das Ergebnis dann brauchbarer ist, ist auch nicht sicher.

Berlin bietet ja schon einen WMS-Dienst mit EPSG:4326 an, nur ist der leider an den Kachelgrenzen schief, sobald man einen grossen Ausschnitt aufruft. Richtig funktioniert der WMS nur mit EPSG:3068. Warum sollte das nach dem Umstieg auf UTM anders sein? Auch wenn der Dienst mit UTM läuft, ist zwar die Umrechnung genauer (worauf es hier nicht ankommt), der Aufwand ist aber der gleiche und die reingesteckte Arbeit wiederverwendbar. Es ändern sich nur ein paar Parameter für die Umrechnerei.

selphirons Arbeit ist ja nicht die Koordinatentransformation, so mühsam die auch ist, sondern die Befreiung der Daten aus dem was die Ämter unter open data verstehen (das Amt malt Bilder, die sich jeder ganz offen ansehen kann) in ein wirklich freies Datenformat, mit dem man auch arbeiten kann, wenn man mehr will als nur Bilder ansehen.

Blöd wäre es natürlich, wenn die Behörden nicht nur auf UTM umsteigen, sondern sich zudem entschliessen würden, statt Bildern echte Daten zu veröffentlichen. Sobald die ihre regionale Arbeitslosenstatistik als Shapefile rausgeben, war wirklich alle bisherige Arbeit umsonst. Ob dieser Fall eintreten wird, mag ein Kenner der dortigen Behördenkultur beurteilen...

Grüße, Max

Last edited by maxbe (2014-11-15 02:23:54)

TobWen · 2014-11-15 01:16:46

maxbe wrote:

Berlin bietet ja schon einen WMS-Dienst mit EPSG:4326 an, nur ist der leider an den Kachelgrenzen schief, sobald man einen grossen Ausschnitt aufruft.

"Schief"? 4326 als Projektion zu nutzen ist ja auch abnormal

maxbe wrote:

Blöd wäre es natürlich, wenn die Behörden nicht nur auf UTM umsteigen, sondern sich zudem entschliessen würden, statt Bildern echte Daten zu veröffentlichen. Sobald die ihre regionale Arbeitslosenstatistik als Shapefile rausgeben, war wirklich alle bisherige Arbeit umsonst. Ob dieser Fall eintreten wird, mag ein Kenner der dortigen Behördenkultur beurteilen...

INSPIRE anyone? http://de.wikipedia.org/wiki/Infrastruc … _Community

Annex I, II und III der "restlichen Daten" (z.B. von Dritten) müssen doch bis Ende 2020 fertig sein (kenne jetzt nicht die genauen Daten).

streckenkundler · 2014-11-15 09:53:30

maxbe wrote:

Berlin bietet ja schon einen WMS-Dienst mit EPSG:4326 an, nur ist der leider an den Kachelgrenzen schief, sobald man einen grossen Ausschnitt aufruft. Richtig funktioniert der WMS nur mit EPSG:3068. Warum sollte das nach dem Umstieg auf UTM anders sein? Auch wenn der Dienst mit UTM läuft, ist zwar die Umrechnung genauer (worauf es hier nicht ankommt), der Aufwand ist aber der gleiche und die reingesteckte Arbeit wiederverwendbar. Es ändern sich nur ein paar Parameter für die Umrechnerei.

Hm:

http://fbinter.stadt-berlin.de/fb/berli … t&type=WMS

Koordinatensystem 25833 (das UTM Zone 33)...

ich habe die WMS-Dienste stichprobenartig durchgeschaut... zu mindestens Teilweise werden diese schon in UTM Zone 33 angeboten...
Hier die Liste der WMS-Dienste:
http://www.stadtentwicklung.berlin.de/g … itel.shtml

und die WFS-Dienste:

http://www.stadtentwicklung.berlin.de/g … /wfs.shtml

Sven

Last edited by streckenkundler (2014-11-15 11:21:47)

streckenkundler · 2014-11-15 11:19:08

TobWen wrote:

Hast du mal mit EDBS-Daten von ATKIS gearbeitet? So ein sche... das Parsen der komplexen Objekte ist der Horror, unsere Relationen sind nix dagegen, weil sie recht eindeutig sind smile

Naja man versucht hat die Eierlegende Wollmilchsau... in die ALKIS-Daten hab ich dienstlich mal etwas reingerochen... weil ich aus den NAS-Daten ich die mitgelieferten Eigentümer von Flurstücken herauskitzeln wollte... hatte aber nicht geklappt weil der NAS-Reader nicht alle Indizies korrekt umgesetzt hatte... Seitdem beziehe ich die Eigentümerdaten als Excel-Tabelle, von den NAS-Daten getrennt... klappt sehr gut.

Mit ALKIS versucht man, z.B. auch alle grundbuchlichen Dinge mit abzubilden, z.B. wenn Gebäude-Eigentum vom Gundeigentum getrennt ist und das dann auch mit der kompletten Historie... Die Tabellenverknüpfungen und -zusammenhänge sind ein Horror...

Sven

selphiron · 2014-11-16 22:11:49

streckenkundler wrote:

Hm:
http://fbinter.stadt-berlin.de/fb/berli … t&type=WMS
Koordinatensystem 25833 (das UTM Zone 33)...
ich habe die WMS-Dienste stichprobenartig durchgeschaut... zu mindestens Teilweise werden diese schon in UTM Zone 33 angeboten...
Hier die Liste der WMS-Dienste:
http://www.stadtentwicklung.berlin.de/g … itel.shtml
und die WFS-Dienste:
http://www.stadtentwicklung.berlin.de/g … /wfs.shtml
Sven

Ja da steht zwar, dass es so angeboten wird aber es funktioniert nicht richtig. Ich habe 2 benachbarte Kacheln angefragt (in EPSG:4326) und als ich diese dann manuell aneinander gehängt habe sah das Ergebnis so aus.

streckenkundler · 2014-11-16 22:37:08

selphiron wrote:

streckenkundler wrote:
Hm:
http://fbinter.stadt-berlin.de/fb/berli … t&type=WMS
Koordinatensystem 25833 (das UTM Zone 33)...
ich habe die WMS-Dienste stichprobenartig durchgeschaut... zu mindestens Teilweise werden diese schon in UTM Zone 33 angeboten...
Hier die Liste der WMS-Dienste:
http://www.stadtentwicklung.berlin.de/g … itel.shtml
und die WFS-Dienste:
http://www.stadtentwicklung.berlin.de/g … /wfs.shtml
Sven
Ja da steht zwar, dass es so angeboten wird aber es funktioniert nicht richtig. Ich habe 2 benachbarte Kacheln angefragt (in EPSG:4326) und als ich diese dann manuell aneinander gehängt habe sah das Ergebnis so aus.

Seltsam... ich hab gerade im ArcGis

http://fbinter.stadt-berlin.de/fb/wms/s … owser=true und http://fbinter.stadt-berlin.de/fb/wms/s … owser=true
aus Berlin und http://isk.geobasis-bb.de/ows/dtk10.php? aus Brandenburg übereinandergelegt... und hab keine signifikanten Abweichungen...´bzw. sie sind im Rahmen durchaus normaler Generalisierungsfehler der TK10... ich könne das auch in QGis machen... ich bin mir sicher, daß da das selbe Ergebdis rauskommen würde...

Eingestellt habe ich ausschließlich EPSG 25833 (!!). EPSG 4326 (unprojiziertes WGS84) benutze ich persönlich ausschließlich dazu, Daten GPS-Gerät-konform exportieren zu wollen.

Sven

Ach ja...Nachtrag: die Brandenburgischen Dienste stimmen definitiv... Brandenbur hat schließlich seit 1996 (!!!) Erfahrung mit ETRS89...

Last edited by streckenkundler (2014-11-16 22:38:45)

selphiron · 2014-11-17 14:40:52

Hmm also was ich meinte ist z.B. diese Karte . In den capabilities steht ja, dass auch EPSG:4326 angeboten wird aber wenn man manuell 2 benachbarte Kacheln abruft wie z.B. die 2:
http://fbinter.stadt-berlin.de/fb/wms/s … =image/png also 52.54594,13.34212,52.58283,13.41485
http://fbinter.stadt-berlin.de/fb/wms/s … =image/png also 52.54594,13.41485,52.58283,13.48758.
Und an den Koordinaten sieht man ja, dass diese benachbart sein müssten..

streckenkundler · 2014-11-17 16:13:10

selphiron wrote:

Hmm also was ich meinte ist z.B. diese Karte . In den capabilities steht ja, dass auch EPSG:4326 angeboten wird aber wenn man manuell 2 benachbarte Kacheln abruft wie z.B. die 2:
http://fbinter.stadt-berlin.de/fb/wms/s … =image/png also 52.54594,13.34212,52.58283,13.41485
http://fbinter.stadt-berlin.de/fb/wms/s … =image/png also 52.54594,13.41485,52.58283,13.48758.
Und an den Koordinaten sieht man ja, dass diese benachbart sein müssten..

Ich hab gerade folgendes gemacht:

1: ArcGis: Datenrahmen auf ETRS UTM-Zone 33N eingestellt
2. DTK-10 Dienst http://isk.geobasis-bb.de/ows/dtk10.php? geladen, der deckt ja Berlin mit ab)
3. den Dienst: http://fbinter.stadt-berlin.de/fb/berli … t&type=WMS geladen.
4. Transformation zur Sicherteit beachten: ETRS_1989_To_WGS_1984
alles liegt sauber übereinander

Oder QGis:
1. Projekt->Projekteinstellungen->KBS->ETRS89/ UTM zone 33N, Kreuz bei "Spontan-KBS-Transformation aktivieren" setzen
2. DTK-10 Dienst http://isk.geobasis-bb.de/ows/dtk10.php? geladen, der deckt ja Berlin mit ab)
3. den Dienst: http://fbinter.stadt-berlin.de/fb/berli … t&type=WMS geladen.
alles liegt sauber übereinander

Ich arbeite so ausschließlich in ETRS89 UTM-Zone 33N. Um regelmäßige Quadrate zu bekommen, kann das entweder in Soldner (EPSG 3068) oder eben in ETRS89 (EPSG 25833) gemacht werden. Beim EPSG 4326 geht das nicht. Das ist unmöglich, da ein Bereich von z.B. 52.54594° nBr.,13.34212° öL.: zu 52.58283° n.Br. ,13.41485° ö.L. niemals ein Quadrat sein kann.

Sven

maxbe · 2014-11-17 20:43:27

streckenkundler wrote:

kann das entweder in Soldner (EPSG 3068) oder eben in ETRS89 (EPSG 25833) gemacht werden.

Da die capabilities sagen

<SRS>EPSG:3068</SRS><SRS>EPSG:4326</SRS>

bleibt nur noch eines als Schnittmenge übrig.

Oder warten...

Das ist unmöglich, da ein Bereich von z.B. 52.54594° nBr.,13.34212° öL.: zu 52.58283° n.Br. ,13.41485° ö.L. niemals ein Quadrat sein kann.

Zur Not ist die ganze Kugel ein Rechteck...

Grüße, Max

streckenkundler · 2014-11-17 20:59:09

maxbe wrote:

streckenkundler wrote:
kann das entweder in Soldner (EPSG 3068) oder eben in ETRS89 (EPSG 25833) gemacht werden.
Da die capabilities sagen
<SRS>EPSG:3068</SRS><SRS>EPSG:4326</SRS>
bleibt nur noch eines als Schnittmenge übrig.

so wie ich das immer verstanden habe ist diese <SRS>*</SRS> Angabe eine Liste der EPSG-Codes, in denen die Daten bereitgestellt werden, also dem vorliegenden Fall entweder EPSG 3089 (Soldner Berlin; projiziert) oder EPSG 4326 (WGS84; unprojiziert). Nur letzteres macht es möglich die Daten auf Basis von ETRS 89 darzustellen, da das beim ETRS89 zugrundenligende Erdellipsoid "GRS80" und das Erdellipsoid "WGS84 weitestgehend als synonym betrachtet werden. Die Unterschiede sind wohl marginal um Submeterbereich. Die von mir erwähnte Transformationsmethode "ETRS_1989_To_WGS_1984" hat in allen Werten Null... spielt also keine Rolle...

maxbe wrote:

Oder warten...
Das ist unmöglich, da ein Bereich von z.B. 52.54594° nBr.,13.34212° öL.: zu 52.58283° n.Br. ,13.41485° ö.L. niemals ein Quadrat sein kann.
Zur Not ist die ganze Kugel ein Rechteck...
http://upload.wikimedia.org/wikipedia/c … ection.jpg
Grüße, Max

Auch das ist projiziert...

Viele Grüße, Sven

selphiron · 2014-11-18 11:27:43

Hmm moment mal ich bin jetzt raus Sind die Koordinaten 52.54594,13.34212,52.58283,13.41485 und 52.54594,13.41485,52.58283,13.48758 keine benachbarten Rechtecke?

maxbe · 2014-11-18 12:23:40

selphiron wrote:

Hmm moment mal ich bin jetzt raus Sind die Koordinaten 52.54594,13.34212,52.58283,13.41485 und 52.54594,13.41485,52.58283,13.48758 keine benachbarten Rechtecke?

ja nein, weiss nicht

Vierecke, die Du in Längen- und Breitengraden angibst, sind nie Rechtecke, sondern immer irgendwas trapezartiges mit krummen Kanten. Sieht man besonders gut, wenn man weiter weg geht.

Deshalb mögen Vermessungsämter und Leute, die kreisförmige Kreisverkehre bauen müssen und Liebhaber von Planquadraten EPSG:4326 nicht besonders. Stattdessen nehmen sie UTM, und altmodische Ämter nehmen gelegentlich noch Gauß-Krüger oder Soldner. Die haben echte Rechtecke.

Unabhängig von der Projektion ist es aber auf jeden Fall ein Fehler, wenn die beiden Kanten benachbarter Ausschnitte nicht zusammenpassen. Das sollte auch dann stimmen, wenn man trapezförmige Ausschnitte zusammensetzt. Falls man das nicht kann, muss man halt auch Trapeze auf die Bilder malen und links und rechts einen Keil weiss lassen. Der Fehler ist aber entschuldbar, weil

(a) der WMS nicht dafür gedacht war, 8000 Pixel grosse Kachel zu liefern. Bei kleinen passt es ja, weil der Versatz unter der Auflösung liegt
(b) die Kachel auch bei 8000 Pixel Grösse in sich stimmig ist, so gut es halt geht. Nur kacheln kann man diese grossen Bilder nicht mehr.
(b) bei den Stadtplanern in Berlin sowieso keiner mit Längen und Breitengraden rechnet, sondern demnächst in UTM-Koodinaten und bisher in Soldner

Dummerweise passen diese Koordinatensysteme mit echten Quadraten und Metern als Einheiten grundsätzlich nie für die ganze Welt. Deshalb hat sich für globale Dinge, wie z.B. OSM EPSG:4326 durchgesetzt und Du musst umrechnen. geojson hätte eigentlich auch die Möglichkeit, andere Koordinatensysteme zu verwenden, aber vermutlich wird das kaum eine Anwendung lesen können.
UTM hätte gegenüber Soldner den Vorteil, dass das genauer umzurechnen ist. Und den Nachteil, dass es noch nicht alle Daten in UTM gibt. Der Programmieraufwand wäre aber der gleiche, du musst nur beim Umstieg die Parameter hinter cs2cs oder ogr2ogr anpassen.

Grüße, Max

Announcement

#26 2014-11-13 09:57:57

Re: Polygone in Bildern Serialisieren / Extrahieren

#27 2014-11-13 10:11:01

Re: Polygone in Bildern Serialisieren / Extrahieren

#28 2014-11-13 10:11:57

Re: Polygone in Bildern Serialisieren / Extrahieren

#29 2014-11-13 10:17:58

Re: Polygone in Bildern Serialisieren / Extrahieren

#30 2014-11-14 23:37:06

Re: Polygone in Bildern Serialisieren / Extrahieren

#31 2014-11-14 23:39:53

Re: Polygone in Bildern Serialisieren / Extrahieren

#32 2014-11-15 00:07:40

Re: Polygone in Bildern Serialisieren / Extrahieren

#33 2014-11-15 01:16:46

Re: Polygone in Bildern Serialisieren / Extrahieren

#34 2014-11-15 09:53:30

Re: Polygone in Bildern Serialisieren / Extrahieren

#35 2014-11-15 11:19:08

Re: Polygone in Bildern Serialisieren / Extrahieren

#36 2014-11-16 22:11:49

Re: Polygone in Bildern Serialisieren / Extrahieren

#37 2014-11-16 22:37:08

Re: Polygone in Bildern Serialisieren / Extrahieren

#38 2014-11-17 14:40:52

Re: Polygone in Bildern Serialisieren / Extrahieren

#39 2014-11-17 16:13:10

Re: Polygone in Bildern Serialisieren / Extrahieren

#40 2014-11-17 20:43:27

Re: Polygone in Bildern Serialisieren / Extrahieren

#41 2014-11-17 20:59:09

Re: Polygone in Bildern Serialisieren / Extrahieren

#42 2014-11-18 11:27:43

Re: Polygone in Bildern Serialisieren / Extrahieren

#43 2014-11-18 12:23:40

Re: Polygone in Bildern Serialisieren / Extrahieren

Board footer