ArcGIS Desktop nach ArcGIS online (Koordinatentransformation)

Nahmd,

Köcky wrote:

ArcGIS Dektop erkennt die OSM Daten als WGS84 geografisch, was ja eigentlich schon falsch ist!

Wieso falsch?

Die OSM-Daten sind im WGS84-Bezugssystem angegeben.

Nach einer Projektion / Transformation sind die Daten kaputt. Es wird z.B. nur noch ein Bruchteil der Straßen dargestellt.

Fehlen zufällige Straßen? Oder wird nur noch ein Ausschnitt der Welt dargestellt?

Wie projeziert / transformiert man die OSM Daten?

Ein beliebter Fehler, den ich normalerweise nicht kommentiere; für Dich als Fachmann aber bitte “projizieren”.

Wieso stellt ArcGIS sie schon von Beginn an im falschen Koordinatensystem dar?

Siehe oben: WGS84 ist richtig.

Gruß Wolf

Es fehlen zufällige Straßen, total wild durcheinander.

Wie projiziert / transformiert ihr denn eure OSM Daten?

ArcGIS online möchte die Daten in WGS 1984 Web Mercator (Auxiliary Sphere).prj darstellen.

Nahmd,

Köcky wrote:

Es fehlen zufällige Straßen, total wild durcheinander.

Dann hat es eher nichts mit einer Projektion zu tun.

Wie projiziert / transformiert ihr denn eure OSM Daten?

Gar nicht.

Die Slippymaps verwenden intern Spherical Mercator; OpenLayers und Leaflet haben entsprechende Konversionsroutinen.

Gruß Wolf

Hallo,

mir kommt so in den Sinn, daß das Ganze irgendwie mit diesem Pseudo-Mercator zu hat:

http://de.wikipedia.org/wiki/European_P … up_Geodesy
http://georepository.com/crs_3857/WGS-8 … cator.html

Denn reines WGS 84 ist es nicht, denn dann wären die Daten in Deutschland in Nord-Süd-Richtung gestaucht.

meint Sven,

ArcGis-Nutzer, aber nicht in Zusammenhang mit OSM und ArcGis Online 😐

Warum geht es dann nicht?

Mein Ablauf:

- Datei Bezirksregierung-Arnsber.pbf von der Geofabrik
- Mit osmconvert.exe in *.osm konvertiert und AOI über Koordinaten auswählen
- *.osm Datei mit FME in ArcGIS importieren

Nahmd,

streckenkundler wrote:

Reines WGS 84 ist es nicht, denn dann wären die Daten in Deutschland in Nord-Süd-Richtung gestaucht.

Selbstverständlich sind die OSM-Daten in WGS84. Sonst wäre die Übernahme von Tracks aus GPS-Empfängern kaum möglich.

Ein wenig geschlampt wird bei der Umrechung auf die Slippymap-Positionen, indem die ellipsoiden WGS84-Koordinaten einfach als sphärisch betrachtet werden, bevor sie auf Merkator umgerechnet werden. Der dadurch verursachte Fehler ist aber für unsere Anwendungen zu vernachlässigen.

Gruß Wolf

Hallo Sven,

ja, das denke ich auch.

Es nennt sich in ArcGIS WGS 1984 Web Mercator (Auxiliary Sphere) und wenn man den Layer (Datenrahmen) auf von geografisch WGS84 auf diese Projektion WGS 1984 Web Mercator (Auxiliary Sphere) stellt ändert sich auch die Darstellung. Also kann es nicht das Gleiche sein.

Dann liege ich doch richtig ... warum stellt ArcGIS sie als geografisch dar, wenn es eigentlich eine Projektion ist und warum kann man die Daten nicht umprojizieren ... bzw. warum zerstört man sie dann???

Hallo Wolf,

du kannst doch eine Projektion nicht mit einer geografischen Abbildung gleichstellen.

http://wiki.openstreetmap.org/wiki/EPSG:3857

http://www.dekho.com.au/wgs-1984-web-me … is-server/

Hallo Wolf,

Netzwolf wrote:

Selbstverständlich sind die OSM-Daten in WGS84. Sonst wäre die Übernahme von Tracks aus GPS-Empfängern kaum möglich.

Die Datenhaltung wir sicher in reinem WGS84 sein. Die Projektion aber nicht:

WGS84 hat den EPSG-Code: http://spatialreference.org/ref/epsg/4326/
Das verwendete "Pseudo-Mercator": http://georepository.com/crs_3857/WGS-8 … cator.html

Code 4326 ist unprojiziert
Code 3857 ist projiziert.

z.B. hat JOSM in der Standardeinstellung das EPSG 3857 gesetzt...

Sven

Nahmd,

streckenkundler wrote:

Die Datenhaltung wir sicher in reinem WGS84 sein. Die Projektion aber nicht:

WGS84 hat den EPSG-Code: http://spatialreference.org/ref/epsg/4326/
Das verwendete "Pseudo-Mercator": http://georepository.com/crs_3857/WGS-8 … cator.html

Code 4326 ist unprojiziert
Code 3857 ist projiziert.

z.B. hat JOSM in der Standardeinstellung das EPSG 3857 gesetzt...

Das ist die Darstellung von JOSM. So gewählt, damit keine Formen verzerrt werden, also quadratische Objekte auch als quadratisch dargestellt werden. Aber was hat die Anzeige von JOSM mit dem Extrakt der Geofabrik zu tun?

Also noch einmal zum Mitschreiben:

Die OSM-Daten sind im WGS84-Bezugssystem angegeben.

Die OSM-Daten der Extrakte der Geofabrik sind auch in WGS84 angegeben.

Gruß Wolf

genau ... und wie liegen die Daten von der Geofabrik vor (Code 4326 oder 3857)? Ich denke die Darstellung in ArcGIS ist mit 4326 richtig, da ArcGIS online auch 3857 nutzt und es dann keine Probleme geben würde.

Stellt sich immer noch die Frage warum ich sie nicht von 4326 nach 3857 projiziert bekomme ... sollte doch eigentlich kein Problem sein, da es im gleichen geodätischem Datum ist.

@Wolf
WGS84 ist hier beides ... es geht um die Projetion oder um die geografische Darstellung.

@Sven
Kannst Du es bitte mal selbst in ArcGIS testen? Es handelt sich bei mir um einen Datensatz von Dortmund

Nahmd,

Köcky wrote:

genau ... und wie liegen die Daten von der Geofabrik vor (Code 4326 oder 3857)?

In WGS84. Wie oft soll ich das noch schreiben?

WGS84 WGS84 WGS84 WGS84 WGS84 WGS84 WGS84 WGS84

Jetzt oft genug?

Und WGS84 = EPGS:4326

Gruß Wolf

Hallo Wolf,

Netzwolf wrote:

Das ist die Darstellung von JOSM.

Da haben wir uns wohl etwas missverstanden...:)

Netzwolf wrote:

So gewählt, damit keine Formen verzerrt werden, also quadratische Objekte auch als quadratisch dargestellt werden.

genau das macht die Projektion der Daten. Das muß man aber auch vor allem beim Weiterverarbeiten vor allem bei ArcGis immer im Hinterkopf haben.

Ich glaube insgesamt, daß diese Projektionsgeschichte ein durchaus guter Hinweis auf das Problem des Beitragserstellers war. In verschiedener Hinsicht habe ich die Erfahrung gemacht, daß es manchmal am besten ist, aus vorhandenen Daten die Projektionsinformation rauszuschmeißen; z.B. in reines WGS84 umzuwandeln und dann weiter zuverarbeiten... Es kommt aberimmer darauf an, mit welcher Projektion man arbeitet und wohin die Daten sollen!!! Das ist sein Problem. Mangels Erfahtung mit ArcGis Online kann ich aber nicht weiterhelfen. Ich hab noch keine Zeit gehabt, mich damit auseinanderzusetzen... 🙁

Sven

Nahmd,

streckenkundler wrote:

Netzwolf wrote:

Das ist die Darstellung von JOSM.

Da haben wir uns wohl etwas missverstanden...:)

Netzwolf wrote:

So gewählt, damit keine Formen verzerrt werden, also quadratische Objekte auch als quadratisch dargestellt werden.

genau das macht die Projektion der Daten. Das muß man aber auch vor allem beim Weiterverarbeiten vor allem bei ArcGis immer im Hinterkopf haben.

Nein, muss man nicht.

Es ist völlig egal, wie bei OSM etwas dargestellt wird.
Egal ob Slippymap, egal ob JOSM, egal ob irgendwas.

Wichtig ist, in welchem Bezugssystem die Daten vorliegen.
Denn die sollen weiterverarbeitet werden. Und die liegen in WGS84 vor.

Dazu was in ArcGIS oder dessen Importer angegeben werden muss, kann ich nichts sagen.

Ich kann aber sagen, dass die OSM-Daten im WGS84-Bezugssystem vorliegen.
Und das habe ich oft genug gesagt.

Deshalb gebe ich an dieser Stelle auf.

Gruß Wolf

@Wolf
Ja, das bringt schon etwas Licht ins dunkle ... aber mein Problem liegt in der Projektion nach WGS 1984 Web Mercator (Auxiliary Sphere).

@Sven
Du kannst mir auch abseits ArcGIS online bitte helfen. Stelle bitte die OSM Daten in ArcGIS Desktop dar und projiziere sie nach WGS 1984 Web Mercator (Auxiliary Sphere). Wenn das klappt, dann geht auch die Überführung ins online System.

Wenn Du das schaffst, ist mein Problem gelöst. 🙂

Ich stelle die Daten übrigens als einzelne Objektklassen (highway, aeroway, railway usw.) in ArcGIS dar und nicht nur als node, line und polygon.

Hallo Wolf,

Netzwolf wrote:

Nein, muss man nicht.

Solange man sich nur innerhalb OSM bewegt stimmt das sicher. Aber in Bezug auf ArcGis sage ich:
Doch muß man!! Kennst du ArcGis? Ich arbeite täglich damit und habe es oft mit Daten unterschiedlicher Projektionen zu tun: Bessel-Ellipsoid, Gauss-Krüger Streifen 3,4,5, ETRS89 UTM 32,33, 6stellige,7stellige,8tellige x-Koordinaten, GPX-Tracks in WGS84... ect... Alles muß möglichst lagegetreu übereinander.

Es geht dem Beitragsersteller um ArcGis und die korrekte Transformation der Daten, so daß sie in ArcGis Online korrekt angezeigt werden.
Es gibt sehr große Unterschiede im Umgang der Programme (z.B. ArcGis und JOSM oder auch QGis) mit unprojizierten und projizierten Daten.

Zum Thema.

ArcGis bietet doch das entsprechende Koordinatensystem an. zu finden unter: Projizierte Koordinatensysteme-> Welt->WGS 1984 Web Mercator (auxiliary shere) Das hat den EPSG-Code 3857 und entspricht meiner Ansicht nach dessen, was OSM bereitstellt. Getestet hab ich es mit OSM-Extrakten (wie Netzwolf richtig schrieb in WGS84) meiner Heimatstadt.

Was ich jetzt eben nicht mehr weis, was ArcGis Online an dieser Stelle benötigt. An der Stelle fehlt mir das Wissen, auch wenn ich mit ArcGis10.1 die Möglichkeit hätte. Allein die Zeit fehlte mir bisher.

Sven

Sven Du bringst es auf den Punkt!
Ich arbeite nun 1,5 Jahr mit ESRI, vorher 5 Jahre bei der Bundeswehr mit GeoMedia und das ist noch empfindlicher. Dort kann man nicht einfach die Daten per Drag 'n Drop reinziehen. Erst muss das Koordinatensystem angegeben werden und wenn es nicht mit den Daten übereinstimmt ist alles für die Katz. ESRI ist da noch recht einfach zu händeln.

Ja, ich weiß wo ich es finde und genau so habe ich es ja auch gemacht. Danach sind allerdings z.B. die featureClass Straßen defekt (total unvollständig)!!!
Kann morgen gerne ein Screenshot machen und hier einstellen.

Mit diesen restlichen Daten (also nach der Projektion) funktioniert dann auch die Überführung nach ArcGIS online.

Vorher komme ich gar nicht zu der Darstellung im online System, da schon der Upload die Fehlermeldung ausgibt.

Genau da ist das Problem. Anscheinend hat bei dir ja die Projektion geklappt. Stimmt auch noch der Maßstab? Das hatte ich auch mal, die Daten kamen richtig rüber, aber im Maßstab 1 : 0,1

Hallo,

Köcky wrote:

Du kannst mir auch abseits ArcGIS online bitte helfen. Stelle bitte die OSM Daten in ArcGIS Desktop dar und projiziere sie nach WGS 1984 Web Mercator (Auxiliary Sphere). Wenn das klappt, dann geht auch die Überführung ins online System.

Wenn Du das schaffst, ist mein Problem gelöst. smile

Ich stelle die Daten übrigens als einzelne Objektklassen (highway, aeroway, railway usw.) in ArcGIS dar und nicht nur als node, line und polygon.

Wie ich schrieb, habe ich auf die Schnelle nur geofabrik-Extrakte zur Verfügung.

Mein Prozess zum Umprojizieren:

ArcGis Starten-> leerer Datenrahmen.
Bei den Eigenschaften des Datenrahmens das Koordinatensystem auf Projizierte Koordinatensysteme-> Welt->WGS 1984 Web Mercator (auxiliary shere)
gesetzt.
Daten werden "entzerrt" dargestellt. (ich teste das immer gerne mit einem Kartenblatt, um zu sehen, daß ich keinen Lageversatz habe) [In diesem Speziellen Fall ist eine Angabe bei "Transformation" nicht nötig]
Dann auf das Thema gehen-> rechte Maustaste-> Daten exprtieren->Option "Gleiches Koordinatensystem verwenden wie: der Datenrahmen wählen... Dateiname vergeben-> fertig.

Neue Daten sind fest umprojiziert.

Wichtig an der Stelle ist (um nicht durcheinader zu kommen), daß zuerst das Zielkoordinatensystem eines leeren Datenrahmens festgelegt wier, erst dann die Daten laden und dann beim Export beachten, daß für die zu exportierenden Daten das Koordinatensystem des Datenrahmens verwendet wird. (übrigens, bei QGis ist das ähnlich)

Wie ich schrieb, hab ich das während des Schreibens mit meinem Geofabrik-Extrakt gemacht.... keine Probleme.

Hoffe, das holft.

Sven

Köcky wrote:

Ich arbeite nun 1,5 Jahr mit ESRI, vorher 5 Jahre bei der Bundeswehr mit GeoMedia und das ist noch empfindlicher. Dort kann man nicht einfach die Daten per Drag 'n Drop reinziehen. Erst muss das Koordinatensystem angegeben werden und wenn es nicht mit den Daten übereinstimmt ist alles für die Katz.

klingt zwas jetzt etwas Ketzerisch, aber ArcGis ist eine ganz andere Liga... 😄 Man muß aber auch gleich dazu sagen, daß das der Zweck ein anderer ist. Ich komme mit JOSM und der Bearbeitung meiner Region bestens zurecht. Das ist für seinen Zweck ein sehr guter GIS-Editor!!!
Auf Arbeit, mit ArcGis habe ich aber auch ganz andere Anforderungen, die andere Programme in Hinblick auch Vielfältigkeit, Funktionsumfang und vor allem Performance nicht leisten können...

Sven... der nun in Bett geht.

Mich wurmt die ganze Sache ... ich habe soeben nochmal an meinem eigenen PC getestet. Ich habe hier ebenfalls von der UNIGIS Salzburg für mein Studium eine Version von ArcInfo und FME. Die Projektion klappt hier ohne Probleme. 🙂

Hat jemand Ahnung von FME? Ich habe nun nur noch die Erklärung, dass es evtl. an der FME im Büro liegen kann. Dort wird aus irgendeinem Grund nur die File Geodatabase API freigeschaltet und die normale File Geodatabase ArcObjects funktioniert (grau ausgeblendet) nicht. Die ArcGIS Lizenz würde fehlen kommt als Fehlermeldung ... was natürlich quatsch ist!!!

Eine andere Fehlerquelle kann es eigentlich nicht mehr sein.

Köcky wrote:

Eine andere Fehlerquelle kann es eigentlich nicht mehr sein.

Hi,
als jemand, der sich von Koordinatenprojektionen ehrfürchtig fern hält, hab ich doch einen kleine Vorschlag:

Da die Kollegen in "deinem" Büro ArcGIS produktiv einsetzen, werden die ja auch einen Service-Vertrag mit dem Hersteller/Distributor oder sonst wem haben. Frag den doch mal, warum sich die dortige Installation so "seltsam" verhält. Nachher fehlt da ein Modul oder eine Lizenz oder irgendwas ist falsch konfiguriert.

https://customers.esri.com/index.cfm?event=login.show

Gruss
walter

Guten Morgen,

Köcky wrote:

Eine andere Fehlerquelle kann es eigentlich nicht mehr sein.

oder doch? eine ganz krude Idee: welches Betriebssystem? Dienstlich hab ich die Arc-Editor-Lizenz Ver. 10.0 auch einem 32bittigen Vista... Hier hab ich festgestellt, daß einige Dinge ,z.B. im Zusammenhang mit WFS-Diensten nich funktionieren... Vista halt... Der Rechner meiner Kollegin, auf Windows 7 64bit macht keine Probleme... Auch an anderen Stellen hat sich Vista schon als Problematisch erwiesen.

Sven

@Walter
Ja, es gibt sogar eine Hotline als Support. Werde dort heute anrufen wenn es nach wie vor nicht funktioniert.

@Sven
Das Betriebssystem kann es eigentlich nicht sein, da ich zu Hause und hier im Büro Win7 64 Bit habe und zu Hause scheint es ja zu gehen. Dort habe ich wegen der geringeren Leistung des PC's allerdings nicht den kompletten Datensatz von Dortmund projiziert. An einem kleinen Ausschnitt ging es aber.

Ich stelle gleich mal ein paar Screenshots ein.

Irgendwie ist der Datensatz Dortmund schrott ... wenn ich ein anderes Gebiet nehme geht es.

Gibt es noch eine andere Quelle als download oder nur die Geofabrik? Der Bereich den ich als Export in der Karte auswählen kann ist zu klein.

@Sven
Wie importierst Du die Daten nach ArcGIS

Köcky wrote:

Gibt es noch eine andere Quelle als download oder nur die Geofabrik? Der Bereich den ich als Export in der Karte auswählen kann ist zu klein.

http://planet.openstreetmap.org/ und dort "Latest Weekly Planet File".
Wenn "der Datensatz Dortmund schrott" ist, würde ich als erstes Deine eigene Verarbeitungskette hinterfragen. Probleme mit den Geofabrik-Extrakten sind äußerst selten.

Und keine Sorge wegen der Prüfung, 2015 ist ja noch eine Weile hin.

Die Quelle habe ich gesehen, ich wollte nur keine 19 GB der ganzen Welt ziehen. Ich frage mich soundso wieso das Angeboten wird. Wie soll man das denn verarbeiten? ArcGIS macht ja schon schlapp wenn ich ich nur ganz Dortmund einlade.

Ich denke auch, dass es eigentlich nicht an der Datenquelle liegen kann. In meiner Verarbeitungskette kann aber eigentlich kein Fehler sein.

- pbf ziehen
- mit osmconvert entpacken, über Eckkoordinaten AOI auswählen und als *.osm Datei ausgeben
- mit der Data Interoperability Connection (FME) in ArcGIS importieren.

Wieso Prüfung 2015??? Sie ist jetzt im März!

Köcky wrote:

Ich frage mich soundso wieso das Angeboten wird. Wie soll man das denn verarbeiten?

Na, zum Beispiel indem man eine Datenbank analog zu der von OSM aufsetzt. Oder indem man Teilbereiche ausschneidet. Oder mit Programmen, die Objekt für Objekt verarbeiten anstatt den ganzen Klumpatsch gleichzeitig in den Speicher zu laden.

Köcky wrote:

- mit osmconvert entpacken, über Eckkoordinaten AOI auswählen und als *.osm Datei ausgeben

Dumme Frage: AOI - Abwasserverband Obere Iller? Flughafen Ancona?

Ja, eine Datenbank mit OSM Daten macht Sinn, aber in meinen Augen nur wenn sich die Daten automatisch aktualisieren. Ein Dienst wäre schön an den ich dann eine Oracle Datenbank hängen kann und die Daten automatisch befüllt? Ein WMS Dienst den wir hier selbst auf unseren Server aufsetzen wäre natürlich das Beste. Gibt es da zufällig ein Template? Selbst einen WMS Dienst zu programmieren dauert ewig.

Welche Programme können denn Objekt für Objekt bearbeiten? So gut kenne ich mich mit den OSM Daten noch nicht aus. Habe zwar schon hier und da eine Karte erstellt, aber in die Tiefe bin ich nicht eingestiegen.

Sorry, ich dachte AOI wäre auch hier ein fester Begriff ... Area of Interest (also Eckkoordinaten in osmconvert eingeben)

Ich habe inzwischen einen anderen Weg getestet die Daten zu importieren. Eine Toolbox von ESRI mit der man die Daten importiert.

Nun habe ich nur 3 Objektklassen

- node
- line
- polygon

und muss alles filtern ... ist ja kein Problem. Aber es gibt für Straßen nur das Attribut highway und wie erkenne ich nun ob es eine Brücke oder Tunnel ist, um es kartografsich korrekt darzustellen???

Köcky wrote:

Ja, eine Datenbank mit OSM Daten macht Sinn, aber in meinen Augen nur wenn sich die Daten automatisch aktualisieren.

Von alleine tun die Daten das nicht, man muß schon noch nachhelfen. Aber auch dafür werden (seit Menschengedenken) die nötigen Daten zur Verfügung gestellt: http://planet.openstreetmap.org/replication/

Köcky wrote:

Aber es gibt für Straßen nur das Attribut highway und wie erkenne ich nun ob es eine Brücke oder Tunnel ist, um es kartografsich korrekt darzustellen???

Am Tag bridge bzw. tunnel.

Schon klar ... tunnel und bridge gibt es aber nicht.

Kannst Du mir zu der automatischen Aktualisierung der Datenbank bitte mehr schreiben (nur der Link hilft mir hier leider nicht) oder einen Link wo man sich einlesen kann? Es ist also möglich einmal einen weltweiten Datensatz zu laden, ihn zu generalisieren und symbolisieren und dann die Aktualisierung automatisch laufen zu lassen?

Ich habe noch einen Datensatz einer anderen Stadt getestet. Dort habe ich auch das Problem ... aus irgendeinem Grund kann ich die Daten nicht mehr verarbeiten wenn sie zu groß werden (zu viele Objekte).

@Sven
Wie groß sind die Gebiete die du einlädst? Teste mal bitte ein größeres Gebiet und projiziere sie in das komische WGS84 Web Format.
Wie importierst du die Daten in ArcGIS?

Köcky wrote:

Schon klar ... tunnel und bridge gibt es aber nicht.

Selbst in Dortmund gibt es Brücken, z.B. diese (mit bridge=yes); OSM-weit wird bridge fast 1,7 Millionen Mal verwendet. Wenn dieses Tag ("Attribut") dort in Deinen Daten fehlt, ist in der Verarbeitung was faul, oder Du bekommst nur eine Teilmenge der vorhandenen Informationen angezeigt.

Köcky wrote:

zu der automatischen Aktualisierung der Datenbank ... einen Link wo man sich einlesen kann

Hier findet sich eine Anleitung, wie man einen eigenen Server mit Datenbank und Renderer aufsetzt, inklusive erstmaligem Import und anschließender Aktualisierung der Daten. Auf der selben Website werden auch "Komplettpakete" vorgestellt, es gibt eine noch detailliertere Anleitung zur manuellen Installation, sowie unter "Other Uses" Links zu verschiedenen Anwendungen im OSM-Universum. Ansonsten tummeln sich hier genug Experten (nicht ich), die bei Detailfragen zu Datenbankimport und Aktualisierung weiterhelfen können.

Köcky wrote:

aus irgendeinem Grund kann ich die Daten nicht mehr verarbeiten wenn sie zu groß werden (zu viele Objekte).

"Irgendein Grund" ist später im Satz doch schon recht konkret benannt: zu groß, zu viele Objekte, Software überfordert. Das ist nicht wirklich überraschend, oder?

Hei,

Köcky wrote:

@Sven
Wie groß sind die Gebiete die du einlädst? Teste mal bitte ein größeres Gebiet und projiziere sie in das komische WGS84 Web Format.
Wie importierst du die Daten in ArcGIS?

So, nach 4 Stunden Möbel aufbauen... zurück am Arbeitsplatz.
Ich habe bisher nur die Shape-Variante genutzt und dann jeweils Brandenburg Landesweit. Für meine Zwecke brauche nichts anderes. Und auch davon brauche ich nicht alles. Meinen Projektionsweg habe ich bei #18 beschrieben. Danach waren die Daten projiziert und beim Einlagen von ODM als Hintergrundebene passte alles.

Sven

Ja, ich kenne das Attribut bridge = yes und wenn ich die Daten über FME importiere existiert es auch.

Also schließe ich den anderen schon mal aus ...

Ich kann mir nicht vorstellen das ArcGIS mit einer Datenbank von 50 MB überfordert ist. Da gibt es Projekte wo sie wesentlich größer ist.

Na ja, ich werde am Sonntag mal zum Dortmunder Mitgliedertreffen gehen.

Vielen Dank für deine Hinweise.

@Sven
Wo steckst Du? 😉

Hallo,

Köcky wrote:

Ich kann mir nicht vorstellen das ArcGIS mit einer Datenbank von 50 MB überfordert ist. Da gibt es Projekte wo sie wesentlich größer ist.

Das denke ich auch nicht. Ich werde von Zu hause mal einen anderen Weg probieren. Ich lade mir eine osm-Datei und schaue, was der ArcGis-Editor for OSM (http://esriosmeditor.codeplex.com/ )damit veranstaltet.

Das wollte ich sowieso schon mal testen. 🙂

Sven

Edit... auf dem Heimweg...

Hei,

also: ich habe mir die osm-Datei von Berlin heruntergeladen (war ne kleine Datei und sollte erst mal nicht so lange dauern) und mit den ArcEditor-Tools for OSM in eine File-Geodatabase gepackt. Andere (Enterprise-) SDE's gehen auch.

Ein paar Eckdaten:

berlin.osm.bz2 07-Feb-2013 18:09 34M
File-Geodatabase-Größe: 728 MB

geladene Punkte: 1.714.404
geladene Ways: 319,121
2859 Relationen geladen.
1 Element aufrund kurzer Segmente repariert,
25 Elemente aufgrund falscher Ringanordnung repariert.

Importdauer: 1 Stunde, 1 Minute, 27 Sekunden.

In der Regel waren beim Import 2, mal 3 CPU's aktiv, aber nicht voll ausgelastet. Etwas gebremst haben könnte der Arbeitsspeicher: hier 4GB.

Die Daten in der File-Geodatabase liegen als WGS84 vor (EPSG: 4326)
Eine Projektion onTheFly klappt reibungslos, ein Export nach WGS_1984_Web_Mercator_Auxiliary_Sphere (Berechtigungscode: 3857 (EPSG)) auch.

Der Bildaufbau z.B. beim Maßstab 1:150.000 dauert etwas... sind ja auch eine Menge Objekte.

so... mach was draus... 😄

In dem Fall war es ein Erst-Import. Für spätere Fälle würde man dann die Daten mit den Diff-Files aktuell halten (Korrekt, liebe OSM- Profis?) 🙂

Sven, der wieder was gelernt hat.

Edit: fehlende Buchstaben und Leerzeichen ergänzt...

Hallo zusammen,

mal eine kurze Zwischenmeldung zu dem Thema. Auf bilateralem Weg (= Telefon und Mail) sind wir weitergekommen.
Vorläufiges Ergebnis ist: auf manchen Rechnerkonfigutationen scheint ein entsprechendes Umprojizieren aus OSM-Daten nicht sauber zu funktionieren.
Standard-Voraussetzungen beim Test waren: ArcGis 10.0 bzw. 10.1 und installierte und aktivierte Erweiterung "Data Interoperability" Mit dieser ist ArcGis in der Lage *.osm Daten direkt zu laden und man ist dann auch in der Lage die Vektordaten entsprechend den Wünschen sich darstellen zu lassen.

Das Problem war nun, daß nach dem Umprojizieren der Daten (aus noch nicht bekannten Gründen) nicht alle Sachinformationen zum Vektorobjekt mitgenommen worden. Dadurch was es dem Beitragsersteller nicht möglich gewesen, z.B. eine Straße als Brücke oder Tunnel darzustellen, schlicht weg, weil die entsprechenden Sachinformationen fehlten. In den Original-Daten sind sie enthalten...

Die Geofrabrik-Extrakte bringen in der Shape-Variante nicht alle Informationen mit, wohl aber bei *.osm (*.pbf hab ich nicht getestet).
Auch ArcGIS Editor for OpenStreetMap scheint nach dem Einlesen einer osm-Datei in eine File-Geodatabase nicht alle Sachinformationen bereitzustellen.

Der dritte Weg war nun die Erweiterung "Data Interoperability".

Ich habe es an Berlin.osm aus den Geofabrik-Extrakten getestet. Es dauert zwar etwas, bis alles geladen ist, aber es funktionierte, auch ein Umprojizieren und festes umrechnen der Daten in ein anders Referenzsystem. Dieser Test funktionierte auf meinem Privatrechner als auch auf Köcky's Privatrechner. Ancheinend alle Sachinformationen waren in der Attibuttabelle vorhanden.

Damit lassen sich ausschließen:
es liegt nicht an den Daten oder an der (Quell- oder Ziel-)Georeferenzierung der Daten (wäre auch ein Wunder)
Es liegt nicht am Verarbeitungsweg.

Was ich mir vorstellen kann:

unterschiedliche Programmversionen; noch vorhandene Bug's (v.a. Service-Packs)
Netzwerk (wenn die Daten von einem Server geladen werden (weiß nicht, ob das real ist...)
unterschiedliche Hardware-Vorraussetzungen ( Prozessor, Arbeitsspeicher; ob real??)

Der Lösung näher gekommend,

Sven

Komisch, ich hatte mit ArcGIS und OSM-Daten nie diese Probleme :-(

Aber schön, dass deine Probleme behoben sind - so muss ich mich heute doch nicht zum Treffen durch den Schnee kämpfen 😄

Ja, es scheint irgendwie an dem PC im Büro zu liegen. Zu Hause geht es bei mir auch ...

Jetzt teste ich es an einem anderen PC beim Kollegen ...

@Sven
Hast Du meine Emails nicht bekommen? Habe dir auch Screenshots dazu gelegt.

Guten Morgen

Köcky wrote:

Hast Du meine Emails nicht bekommen? Habe dir auch Screenshots dazu gelegt.

doch, doch... darum ja mein Beitrag im Forum: siehe #39.

Die Erweiterung "Data Interoperability" war nicht installiert, hatte ich privat bis dahin nie gebraucht. Danach klappte alles: einlesen, anzeigen, projizieren, exportieren, projiziert exportieren: wie gesagt: Berlin.osm komplett. Stichprobenartig hatte ich die Attributtabelle durchgesehen und es war wohl alles da.
Darum auch meine möglichen Gründe in diesem Beitrag, warum es auf deinem Dienstrechner nicht klappt.

Sven

Kleine Korrektur ... Problem ist, dass bei der Variante über die "Data Interoperability" am Dienstrechner nicht alle Vektordaten mitkommen. Es gab so viele Möglichkeiten ... Sven kam ein wenig durcheinander 😉

Ich habe die Datenbank von zu Hause mit ins Büro genommen.
Hier ein paar Screenshots (bitte genau lesen, ist ziemlich verwirrend):

blau = Vektordaten von zu Hause
rote Bruchstücke = es werden am Büro PC in der vollen Ansicht nicht alle Straßen dargestellt, sie sind aber noch da (vor der Projektion). Dies ist hier schon merkwürdig

hier rot und blau in einem größeren Maßstab. Gut zu sehen das alle Daten da sind.

hoffentlich sieht man die gelben Bruchstücke. Diese Vektoren bleiben übrig wenn ich am Büro PC die Projektion durchführe

An einem anderen PC hier im Haus klappt es auch nicht. Ich schreibe jetzt eine Mail an den Support.