Ich habe OGR2OGR verwendet, um SRID 4326-Punktdaten in MSSQL Server zu importieren. Wusste nicht, dass standardmäßig eine Geometriespalte erstellt wird, anstatt die Daten als 4326 zu erkennen und eine Geografiespalte zu erstellen. Ich kenne den Code, um das zu umgehen, also kein Problem.
Die Daten in einer Geometriespalte werden in QGIS einwandfrei angezeigt. Muss ich die Daten also tatsächlich in eine Geografiespalte einfügen?
Vielen Dank!
Antworten:
Wenn Sie keine Abstände über dem Sphäroid messen müssen, eignet sich die Geometrie gut. Das PostGIS-Handbuch enthält verständliche Informationen zu diesem http://postgis.net/docs/manual-2.0/using_postgis_dbmanagement.html#PostGIS_Geography und gilt auch für MSSQL.
Ich habe dies vor einigen Monaten versehentlich getan, obwohl es sich um Linien handelte und es sich um eine sehr große Feature-Class handelte (ich glaube, es lag in der Größenordnung von 10 Millionen Features). Ich erinnere mich auch nicht, ob es SQL Server 2008 oder 2012 war.
Eine Sache, die mir in ArcMap aufgefallen ist, war, dass alles sehr, sehr langsam war. Ich habe es profiliert. Es wurde die Abfrage gefunden, die die Langsamkeit verursacht hat, und in SSMS eingefügt. Dabei wurde festgestellt, dass die Filtermethode der Schuldige war (iirc, ArcMap verwendet Filter mit einem Umschlag, um OIDs abzurufen). SQL Server brachte jede einzelne Zeile in der Tabelle zurück !!
Als ich zur Geografie wechselte, gab Filter die richtige Anzahl von Features für die angegebene Geometrie zurück.
Ich erinnere mich nicht an andere Methoden, die sich schlecht verhalten, aber ich habe die 4326-Daten nicht lange genug in der SQL-Geometrie belassen, um dies herauszufinden.
Wenn Ihre Tischgröße nicht sehr groß ist, spielt dies möglicherweise keine Rolle. Bei größeren Tischen ist dies jedoch zu beachten. Es wäre auch egal, ob QGIS nicht verwendet Filter.