Quali sono i pro ei contro della geografia e dei tipi di geometria di PostGIS?


86

La mia azienda utilizza il tipo di dati geometry( the_geom) per l'archiviazione di dati geospaziali.

Di recente ho conosciuto il concetto di tipo di dati geography( the_geog) che, a quanto ho capito, memorizza SRIDinsieme alla geometria.

Quali sono le differenze tra geographye geometrye c'è qualche vantaggio nell'usarne uno in database di grandi dimensioni?


Ancora un paio di risposte a questa duplice domanda: gis.stackexchange.com/questions/26082/…
Arto Bendiken,

Risposte:


74

Le funzioni geografiche sono sempre memorizzate in WGS84 prima di PostGIS 2.2; da allora è possibile utilizzare qualsiasi sistema di riferimento spaziale basato su lon / lat. Le misurazioni basate sulle caratteristiche geografiche saranno in metri anziché in unità CRS e PostGIS utilizzerà calcoli geodetici anziché geometria planare.

Non tutte le funzioni supportano la geometria, ma è possibile eseguire il cast tra geometria e geografia. Per l'elenco delle funzioni correnti, consultare: https://postgis.net/docs/PostGIS_Special_Functions_Index.html#PostGIS_GeographyFunctions

Non credo sia possibile raccomandare né la geografia né la geometria per database di grandi dimensioni. Dipende da cosa stai facendo con i tuoi dati. Poiché i calcoli sulla sfera sono più complicati, mi aspetto che le analisi siano più lente sulle caratteristiche geografiche. Devi anche trasformare tutti i tuoi dati in WGS84 per usare la geografia.

Se si eseguono molte misurazioni e, ad esempio, si devono confrontare dimensioni di grandi poligoni, sarebbe logico utilizzare la geografia anziché la geometria.

Ho trovato utile quanto segue: http://postgis.net/workshops/postgis-intro/geography.html

L'argomento è anche trattato in "PostGIS in azione" (ISBN: 9781935182269).


"La geografia è supportata da ..." è aggiornato?
Chris Anderson,

@ChrisAnderson l'elenco è più lungo ora: postgis.net/docs/...
Sottosuolo

41

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!).


@Peter Per quanto riguarda la standardizzazione dei dati, la geometria sarebbe il modo preferito di combinare i dati da molte fonti a volte con sistemi di riferimento di coordinate personalizzati (CRS) in un singolo tipo di dati? Le funzioni di trasformazione piacciono ST_GeomFrom*e ST_As*sembrano molto utili, specialmente in combinazione con la capacità di definire CRS personalizzati, permettendo a PostGIS di gestire le trasformazioni durante le query e le esportazioni in un singolo CRS?
David LeBauer,

@Peter Ehi, mi chiedevo, c'è un inchiostro che contiene tutte le funzioni geografiche? Le funzioni geometriche sono qui immagino, ma dove sono le funzioni geografiche? Grazie. Incredibile risposta tra l'altro, davvero un bel lavoro
slevin

11

Ritengo che la differenza più significativa sia che con il tipo di geografia, i calcoli vengono eseguiti su una sfera che rappresenta la terra rispetto alla superficie piana utilizzata nei calcoli effettuati sulle caratteristiche del tipo di geometria.

I documenti sono abbastanza buoni: http://postgis.net/docs/manual-1.5/ch04.html#PostGIS_Geography

Il tipo di geografia è stato aggiunto di recente, quindi sono supportate / implementate meno funzioni.


9

Forse trovi che questa funzione - e la risposta - è inutile, ma uno dei vantaggi di lavorare con le geometrie è che puoi lavorare senza alcun riferimento spaziale (ovvero, SRID impostato su -1).

Attualmente sto lavorando in un'applicazione che filtra i dati LiDAR dispersi nell'aria, tra le sue fonti di dati c'è un database PostGIS, che fornisce indicizzazione spaziale di prima classe ( RTree su GiST ) e gestisce un volume elevato di dati senza problemi. Poiché tale applicazione non richiede la manipolazione o l'analisi delle funzionalità geografiche, non è necessario alcun SRID, evitando così il sovraccarico che può portare.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.