Ich benutze meine intuitiven "Faustregeln" ... Es ist nützlich für eine schnelle Entscheidung,
Informationen zu Ihrer DATABASE : Wenn Features und / oder räumliche Analysen kontinentaler Größe sind und Präzision erfordern (ernsthafte Anwendungen), verwenden Sie die Geografie . Andernfalls Geometrie verwenden: Wenn sich alle Datenbanken in etwa auf derselben Region ( im Stadtmaßstab ) befinden oder Sie keine Präzision usw. benötigen, benötigen Sie nur Geometrie.
Siehe ähnliche Regel in der Vorlesung von @underdark .
Informationen zu Ihren Anforderungen hinsichtlich LEISTUNG / PRÄZISIONSGLEICHGEWICHT : Die Geometrie ist schneller. Wenn Sie Leistung benötigen und daran denken, Geografie zu verwenden, machen Sie zuerst Ihre Benchmarks.
Schlüssel Konzepte
Auf dieser Seite sehen wir einige Schlüsselwörter und den Fokus auf einige Konzepte: Präzision , Leistung und so etwas wie Flexibilität / Gebrauchsgegenstand .
Wie von anderen in Erinnerung gerufen, besteht der Unterschied bei Speichern und Berechnen in der Verwendung der Kugel in der Geographie und der Ebene in der Geometrie:
- Die Sphäre (Geographie) ist besser, genauer. Siehe das Los Angeles / Paris-Beispiel .
- Evolution der Geographie: Wie @DavidF sagt, "wurde der Geographietyp in jüngerer Zeit hinzugefügt, sodass weniger Funktionen unterstützt / implementiert werden".
Möglicherweise werden ab dem Jahr 2020 alle GIS-Datenbanken auf den gleichen Standard SRID / EPSG gesetzt (entspricht dem heutigen Code 4326 für WGS84). Heutzutage ist die Geografie aufgrund von Leistungs- und Funktionseinschränkungen keine Standardoption.
Diskussion
Meiner Meinung nach handelt es sich um "Best Practices", nicht um ein tiefgreifendes technisches / theoretisches Problem.
Präzision
Nachdem Sie den Fehler in Ihren Daten geschätzt haben, führen Sie Ihre Tests durch und vergleichen Sie die Ergebnisse: Die Genauigkeitsgewinne mit der Geographie sind höher als die Datenfehler? Die ST_Distance- Funktion (mit MAX- und AVG-Aggregatoren ) ist die Hauptreferenz für diese Art von Experiment.
Performance
Beispiele für Benchmarks in einem Stadtgebiet von ~ 100 km2 (Durchmesser ~ 11 km), die alle als Geometrie in einem planaren UTM-Koordinatensystem gespeichert sind. HINWEIS: Beginnen Sie mit der häufig verwendeten Geometrie- / Geografie-Konvertierung - häufig, weil einige Funktionen nicht vorhanden sind und andere, wie ST_Buffer und ST_Intersection, die Konvertierung intern durchführen.
Bench # 1: eine Tabelle mit ~ 87000 Polygonen, die städtische Grundstücke darstellen, jedes mit Poly mit (Durchschnitt) ~ 13 Punkten,
BEGIN; EXPLAIN ANALYSE CREATE TABLE temp_geom AS
SELECT gid, the_geom FROM urbanlots; ROLLBACK;
-- time 2080 ms ~ 2.0 s
BEGIN; EXPLAIN ANALYSE CREATE TABLE temp_geog AS
SELECT gid, Geography(ST_Transform(the_geom,4326)) AS geog
FROM urbanlots; ROLLBACK;
-- time 12374 ms ~ 12.4 s ~ 6 * geometry.
also geography_time = 6 * geometry_time.
Bank Nr. 2: Eine Tabelle mit ~ 3500 Polygonen, die Stadtblöcke darstellen, wobei jedes Poly mit (durchschnittlich) ~ 50 Punkten: 0,6 s vs 2,7 s, geography_time = 4,5 * geometry_time.
Bank Nr. 3: ~ 10000 Linien, die städtische Straßen mit jeweils ~ 5 Punkten darstellen. ~ 0,87s vs ~ 0,36s, geography_time = 2,4 * geometry_time.
Zurück zu Bench # 2, Erstellen der Tabellen und Ausführen von Abfragen,
EXPLAIN ANALYSE SELECT ST_Area(g.the_geom)+ST_Distance(g.the_geom,t.the_geom)
FROM temp_geom g, (SELECT the_geom FROM temp_geom WHERE gid=1) as t;
-- time 182 ms ~ 0.2 s
EXPLAIN ANALYSE SELECT ST_Area(g.geog)+ST_Distance(g.geog,t.geog)
FROM temp_geog g, (SELECT geog FROM temp_geog WHERE gid=1) as t;
-- time 58657 ms ~ 59 s ~ 300*geometry
-- curioselly for only distances, geography=4*geometry
Fazit: Für kleine Aufgaben und gute Kenntnisse konvergieren die Zeiten zur "akzeptablen gleichen Zeit", aber für große Aufgaben sind Leistungsbewertungen zu berücksichtigen.
Flexibilität / Ware
An den Benchmarks führe ich eine tägliche Aufgabe durch und überprüfe die Anzahl der Punkte (nach ST_NPoints) ... Dies ist ein Beispiel für eine Operation, die für die Geografie nicht vorhanden ist und gegossen werden muss. Die "Geographie / Geometrie-Besetzung" ist eine lästige Aufgabe für Programmierer, Meister usw.
Bei der Wiederverwendung von Bibliotheken mit SQL- und PL / pgSQL-Funktionen muss die Geografie angepasst werden. Wenn Sie Code optimieren oder Präzisionsprobleme mit vielen Zwischenkonvertierungen vermeiden möchten, ist das Fehlen eines vollständigen Satzes integrierter Funktionen mit geografischem Bezug ein weiteres Problem. Programm für die Geographie, ist keine leichte Aufgabe.
Nur-Prozess, Datenaustausch usw.
Bei ungewöhnlichen Anforderungen ohne intensiven Benutzer wie Mapserver lautet die Faustregel, wenn Ihre einzige Aufgabe (PostGIS) darin besteht, Eingabedaten zu verarbeiten und die verarbeiteten Daten jederzeit (z. B. Stunden oder Tage) zurückzugeben, "Geografie verwenden, wenn Sie dies möchten sind bequem! " (siehe "Flexibilität / Ware" oben). Wenn nicht, überprüfen Sie die üblichen Regeln.
HINWEIS: Wenn Ihre (nicht übliche) Aufgabe darin besteht, nur Daten von PostGIS an Mapserver zu senden, ist es natürlich besser, die Geometrie oder Geografie Ihrer Eingabedaten beizubehalten, ohne dass ein Prozess erforderlich ist.
Ich glaube , die Datenzentralisierung eine andere Aufgabe ist es, wo Geographie ist besser: in Kontext , in dem die Vielfalt von Eingabeformate und Referenzsysteme üblich sind, ist die Verwendung eines Standard, wie die durch die Geographie durchgesetzt werden , ist von Vorteil ... Konvention über Konfiguration ist Ein gutes Prinzip, wenn Zentralisierung und Datenaustausch im Mittelpunkt des Geschäfts stehen (siehe Google Maps!).