Uso le mie "regole empiriche" intuitive ... È utile per una decisione rapida,
Informazioni sul DATABASE : se le caratteristiche e / o l'analisi spaziale sono su scala continentale e richiedono precisione (applicazioni serie), utilizzare la geografia . Altrimenti usa la geometria: quando tutto il database è sulla stessa regione ( su scala urbana ) o non hai bisogno di precisione, ecc. Hai bisogno solo della geometria.
Vedi regole simili nella lezione di suggerimento di @underdark .
Informazioni sulle vostre esigenze in termini di PRESTAZIONI / BILANCIO DI PRECISIONE : la geometria è più veloce; se hai bisogno di prestazioni e pensi di usare la geografia, fai prima i benchmark.
Concetti chiave
In questa pagina, vediamo alcune parole chiave e l'attenzione su alcuni concetti: precisione , prestazioni e qualcosa come flessibilità / merce d'uso .
Come ricordato da altri, la differenza, per negozio e calcoli, è l'uso della sfera in geografia e del piano in geometria:
- la sfera (geografia) è migliore, più precisa. Vedi l'esempio di Los Angeles / Parigi .
- evoluzione della geografia: come dice @DavidF, "il tipo di geografia è stato aggiunto di recente, quindi sono supportate / implementate meno funzioni".
Forse nel 2020 tutti i database GIS saranno impostati sullo stesso SRID / EPSG standard (equivalente al codice 4326 di oggi, per WGS84). Oggi la geografia non è una scelta predefinita a causa delle prestazioni e dei limiti funzionali.
Discussione
Secondo me si tratta di "migliori pratiche", non di un profondo problema tecnico / teorico.
Precisione
Dopo aver stimato l'errore sui tuoi dati, fai i test e confronta i risultati: i guadagni di precisione con la geografia sono superiori all'errore dei dati? La funzione ST_Distance (con aggregatori MAX e AVG ) è il riferimento principale in questo tipo di esperimento.
Prestazione
Esempi di parametri di riferimento in un'area urbana di ~ 100 km2 (diametro ~ 11 km), tutti memorizzati come geometria, in un sistema di coordinate UTM planare. NOTA: a partire dalla conversione geometria / geografia utilizzata di frequente, spesso perché alcune funzioni non esistono e altre, come ST_Buffer e ST_Intersection, effettuano la conversione internamente.
Panchina n. 1: un tavolo con ~ 87000 poligoni che rappresentano lotti urbani, ognuno con poli con (avg) ~ 13 punti,
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.
quindi, geography_time = 6 * geometry_time.
Panchina n. 2: una tabella con ~ 3500 poligoni che rappresentano blocchi urbani, ognuno con poli con (avg) ~ 50 punti: 0.6s contro 2.7s, geography_time = 4.5 * geometry_time.
Panchina n. 3: ~ 10000 linee che rappresentano strade urbane, ognuna con ~ 5 punti. ~ 0.87s vs ~ 0.36s, geography_time = 2.4 * geometry_time.
Torna alla panchina n. 2, creando le tabelle ed eseguendo query,
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
Conclusione: per piccoli compiti e buon hardaware, i tempi convergono nel "tempo accettabile-stesso", ma per i grandi compiti, ci sono valutazioni delle prestazioni da considerare.
Flessibilità / Commodity
Sui benchmark faccio un lavoro quotidiano, controllando il numero di punti (per ST_NPoints) ... È un esempio di operazione che non esiste per la geografia, ha bisogno di essere lanciata. Il "cast geografia / geometria" è un compito fastidioso per programmatori, maestri, ecc.
Quando si riutilizzano le librerie delle funzioni SQL e PL / pgSQL, la geografia necessita di adattamenti. E, se si desidera ottimizzare il codice o evitare problemi di precisione con molte conversioni intermedie, l'assenza di un set completo di funzioni integrate, con la geografia, è un altro problema. Programma per la geografia, non è un compito facile.
Solo processo, scambio dati, ecc.
Per richieste non usuali, senza utenti intensi come Mapserver, quando il tuo unico lavoro (PostGIS) è elaborare dati di input e restituire in qualsiasi momento (come ore o giorni) i dati elaborati, la regola empirica è "usa la geografia se sono comodi! " (vedi "Flessibilità / Merce" sopra). In caso contrario, controlla le normali regole.
NOTA: ovviamente, se il tuo compito (non abituale) è mostrare solo i dati da PostGIS a Mapserver, senza necessità di processo, per preservare la stessa (geometria o geografia) dei tuoi dati di input, è una decisione migliore.
Credo che la centralizzazione dei dati sia un altro compito in cui la geografia è migliore: nel contesto in cui la diversità dei formati di input e dei sistemi di riferimento sono usuali, l'uso di uno standard, come quello applicato dalla geografia, è vantaggioso ... La convenzione sulla configurazione è un buon principio quando la centralizzazione e lo scambio di dati sono al centro dell'attività (vedi Google Maps!).