[Gfoss] Intersezione Spaziale MOLTO Pesante

[Alessandro_Gentili]

Salve a tutti.

Come ho descritto nell’oggetto ho un problema con l’intersect di una grossa mole di dati con un altro layer vettoriale. Cerco di spiegare.

Ho da correggere dei dati proveniente da un rilievo batometrico (multibeam e singlebeam) con un grigliato che ho generato con dei valori di correzioni rispetto all’escursione della marea.
Il processo attualmente consiste nel:

• Prendere lo shp del rilievo fare l’intersect con il grigliato per assegnare il valore di correzione
• Fare il field calculator in un nuovo campo calcolando il nuovo punto batimetrico
  Purtroppo la dimensione del rilievo è decisamente grande (45mb) con qualcosa come 1.600.000 record che durante i due punti sopra descritti il tempo che passa si conta in ore e non in minuti.

Volevo sapere se c’era qualche soluzione alternativa che possa permettermi di fare queste operazioni (una spaziale, una di DB) in maniera relativamente veloce.
Gia cominciare a parlare di “minuti di elaborazione” sarebbe un grosso progresso.

N.B. Ho la possibilità di usare anche ArcGis ma voglio evitare di farlo finchè posso

Grazie a tutti in anticipo

Alessandro Gentili

email: alessandrogentili_7@hotmail.com

[a.furieri]

On Tue, 15 Nov 2011 15:29:54 +0100, Alessandro Gentili wrote

Purtroppo la dimensione del rilievo è decisamente grande (45mb)
con qualcosa come 1.600.000 record che durante i due punti sopra
descritti il tempo che passa si conta in ore e non in minuti.

perchè non usi uno Spatial DBMS ? p.es. PostGis o SpatiaLite
per uno Spatial DBMS 45 MB di dati, 1.600.000 righe, sono
decisamente "numeri piccoli e ragionevoli".

Volevo sapere se c'era qualche soluzione alternativa che
possa permettermi di fare queste operazioni (una spaziale,
una di DB) in maniera relativamente veloce.

appunto: se usi uno Spatial DBMS ti rimane esclusivamente
una banale serie di operazioni SQL: la parte "spaziale"
sparisce magicamente imboscata dentro a SQL
non hai affatto bisogno di fare "due" cose; ne basta
semplicemente una sola.

Gia cominciare a parlare di "minuti di elaborazione"
sarebbe un grosso progresso.

direi a naso che usando saggiamente gli spatial index
probabilmente forse potresti addirittura aspirare a
parlare di "decine di secondi".
sicuramente non oltre i pochi minuti anche nel caso
peggiore, considerate le dimensioni del tuo problema.

ciao Sandro

[Alessandro_Gentili]

Si… ho sia Postgis che Spatialite ma, come dire, ci sto entrando per mia volontà e soprattutto perchè so che è possibile farlo in Opensource e lo voglio fare in quella maniera.
Unico problema è che la mia conoscenza di SQL è un pò limitata sia perchè non ci lavoro molto spesso, sia perchè è da poco che lavoro in ambiente e materia Gis.

Ho provato a scrivere questa queri in Postgis ma mi restituisce un errore (vado a memoria su quanto ho scritto)

SELECT *
FROM vector1
WHERE ST_Intersections(‘vector1.the_geom’,‘vector2.the_geom’)

Solo mi rendo anche io conto per quel poco che conosco che non è corretta ma non so come correggerla purtroppo.
Sto cercando di trovare la soluzione nel mezzo ad altre cose quindi la ricerca della soluzione è lenta.

Vorrei sapere se c’è qualche guida/sito su internet in grado di aiutarmi a migliorare
Qualche consiglio?

From: a.furieri@lqt.it
To: gfoss@lists.gfoss.it; alessandrogentili_7@hotmail.com
Subject: Re: [Gfoss] Intersezione Spaziale MOLTO Pesante
Date: Tue, 15 Nov 2011 15:57:03 +0100

On Tue, 15 Nov 2011 15:29:54 +0100, Alessandro Gentili wrote

Purtroppo la dimensione del rilievo è decisamente grande (45mb)
con qualcosa come 1.600.000 record che durante i due punti sopra
descritti il tempo che passa si conta in ore e non in minuti.

perchè non usi uno Spatial DBMS ? p.es. PostGis o SpatiaLite
per uno Spatial DBMS 45 MB di dati, 1.600.000 righe, sono
decisamente “numeri piccoli e ragionevoli”.

Volevo sapere se c’era qualche soluzione alternativa che
possa permettermi di fare queste operazioni (una spaziale,
una di DB) in maniera relativamente veloce.

appunto: se usi uno Spatial DBMS ti rimane esclusivamente
una banale serie di operazioni SQL: la parte “spaziale”
sparisce magicamente imboscata dentro a SQL
non hai affatto bisogno di fare “due” cose; ne basta
semplicemente una sola.

Gia cominciare a parlare di “minuti di elaborazione”
sarebbe un grosso progresso.

direi a naso che usando saggiamente gli spatial index
probabilmente forse potresti addirittura aspirare a
parlare di “decine di secondi”.
sicuramente non oltre i pochi minuti anche nel caso
peggiore, considerate le dimensioni del tuo problema.

ciao Sandro

[a.furieri]

On Tue, 15 Nov 2011 16:51:28 +0100, Alessandro Gentili wrote

Ho provato a scrivere questa queri in Postgis ma mi
restituisce un errore (vado a memoria su quanto ho scritto)

SELECT *
FROM vector1
WHERE ST_Intersections('vector1.the_geom','vector2.the_geom')

a) manca una tavola: casomai dovrebbe essere:
SELECT *
FROM vector1, vector2
WHERE ST_Intersections(vector1.the_geom,vector2.the_geom)

b) gli apici (') identificano le costanti testo: se scrivi
   'vector1.the_geom', non puo' capire che intendi riferirti
   alla colonna "the_geom" della tavola "vector1", ma
   capisce invece che gli stati passando un testo.
   casomai il mascheramento dei nomi SQL richiede doppi
   apici ("): "vector1"."the_geom"
   n.b.: il punto *non* deve essere mascherato tra apici,
   perchè non è un nome SQL, ma è un delimiter strutturale.

Vorrei sapere se c'è qualche guida/sito su internet in grado
di aiutarmi a migliorare
Qualche consiglio?

non posso che consigliarti di partire dal
cookbook di spatialite (in buona misura vale anche
per PostGIS, visto entrambi sono OGC-SFS)
https://www.gaia-gis.it/fossil/libspatialite/wiki?name=misc-docs

ciao Sandro

[Luca_Sigfrido_Percic]

Ciao,

Il giorno mar, 15/11/2011 alle 17.36 +0100, a.furieri@lqt.it ha scritto:

SELECT *
FROM vector1, vector2
WHERE ST_Intersections(vector1.the_geom,vector2.the_geom)

acc, per un attimo ho sperato che ST_intersections fosse una new entry
nella santa barbara del già ottimo spatialite, invece temo sia un
refuso

ST_intersects(geom1, geom2) restituisce true se due geometrie si
intersecano e in genere si usa nelle condizioni di JOIN, mentre
ST_intersection(geom1, geom2) restituisce la porzione comune ai due
oggetti:

SELECT v1.fid, v2.fid, ST_intersection(v1.the_geom, v2.the_geom)
FROM vector1 as v1, vector2 as v2
WHERE ST_Intersects(v1.the_geom,v2.the_geom)

Così ad esempio ottieni un layer con geometrie derivate dall'intersezione di quelle dei due layer originali.

Rileggendo la query mi chiedo perché a nessuno viene mai in mente di chiamare il FID "the_fid", o il nome "the_name"

Sig

_____________
PRIVACY
Le informazioni contenute in questo messaggio sono riservate e confidenziali. Il loro utilizzo e' consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora Lei non fosse la persona a cui il presente messaggio è destinato, La invitiamo ad eliminarlo dal Suo Sistema e a distruggere le varie copie o stampe, dandone gentilmente comunicazione all’indirizzo mail del mittente. Ogni utilizzo improprio e' contrario ai principi del D.lgs 196/03 e alla legislazione europea (Direttiva 2002/58/CE).

PRIVACY
Le informazioni contenute in questo messaggio sono riservate e confidenziali. Il loro utilizzo e' consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora Lei non fosse la persona a cui il presente messaggio è destinato, La invitiamo ad eliminarlo dal Suo Sistema e a distruggere le varie copie o stampe, dandone gentilmente comunicazione all’indirizzo mail del mittente. Ogni utilizzo improprio e' contrario ai principi del D.lgs 196/03 e alla legislazione europea (Direttiva 2002/58/CE).

[strk]

On Tue, Nov 15, 2011 at 05:36:29PM +0100, a.furieri@lqt.it wrote:

On Tue, 15 Nov 2011 16:51:28 +0100, Alessandro Gentili wrote
> Ho provato a scrivere questa queri in Postgis ma mi
> restituisce un errore (vado a memoria su quanto ho scritto)
>
> SELECT *
> FROM vector1
> WHERE ST_Intersections('vector1.the_geom','vector2.the_geom')
>

a) manca una tavola: casomai dovrebbe essere:
SELECT *
FROM vector1, vector2
WHERE ST_Intersections(vector1.the_geom,vector2.the_geom)

"ST_Intersections" non esiste.
"ST_Intersection" restituisce la geometria dell'intersezione
"ST_Intersects" e' un predicato

La costruttiva e' piu' lenta (e meno robusta) del predicato.
Eviterei di controllare ogni coppia due volte: A && B + B && A.

--strk;

  () Free GIS & Flash consultant/developer
  /\ http://strk.keybit.net/services.html

[strk]

On Tue, Nov 15, 2011 at 06:08:05PM +0100, Luca Sigfrido Percich wrote:

Rileggendo la query mi chiedo perché a nessuno viene mai in mente di chiamare il FID "the_fid", o il nome "the_name"

Nel 2.0 di postgis il loader cambia default da "the_geom" a "geom".
Spero sia cosa gradita

--strk;

  () Free GIS & Flash consultant/developer
  /\ http://strk.keybit.net/services.html

[Luca_Sigfrido_Percic]

Graditissima!. Io però avrei scelto un più accattivante e giovanile
"my_geom".

Con ogr2ogr ormai l'opzione geometry_name=geom la considero parte
integrante del comando. Magari hanno cambiato il default pure in GDAL e
non me ne sono accorto.

Sig

Il giorno mar, 15/11/2011 alle 18.10 +0100, Sandro Santilli ha scritto:

On Tue, Nov 15, 2011 at 06:08:05PM +0100, Luca Sigfrido Percich wrote:

> Rileggendo la query mi chiedo perché a nessuno viene mai in mente di chiamare il FID "the_fid", o il nome "the_name"

Nel 2.0 di postgis il loader cambia default da "the_geom" a "geom".
Spero sia cosa gradita

--strk;

  () Free GIS & Flash consultant/developer
  /\ http://strk.keybit.net/services.html

_____________
PRIVACY
Le informazioni contenute in questo messaggio sono riservate e confidenziali. Il loro utilizzo e' consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora Lei non fosse la persona a cui il presente messaggio è destinato, La invitiamo ad eliminarlo dal Suo Sistema e a distruggere le varie copie o stampe, dandone gentilmente comunicazione all’indirizzo mail del mittente. Ogni utilizzo improprio e' contrario ai principi del D.lgs 196/03 e alla legislazione europea (Direttiva 2002/58/CE).

PRIVACY
Le informazioni contenute in questo messaggio sono riservate e confidenziali. Il loro utilizzo e' consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora Lei non fosse la persona a cui il presente messaggio è destinato, La invitiamo ad eliminarlo dal Suo Sistema e a distruggere le varie copie o stampe, dandone gentilmente comunicazione all’indirizzo mail del mittente. Ogni utilizzo improprio e' contrario ai principi del D.lgs 196/03 e alla legislazione europea (Direttiva 2002/58/CE).

[a.furieri]

On Tue, 15 Nov 2011 18:08:05 +0100, Luca Sigfrido Percich wrote

Il giorno mar, 15/11/2011 alle 17.36 +0100, a.furieri@lqt.it ha scritto:

> SELECT *
> FROM vector1, vector2
> WHERE ST_Intersections(vector1.the_geom,vector2.the_geom)

acc, per un attimo ho sperato che ST_intersections fosse una new
entry nella santa barbara del già ottimo spatialite, invece temo
sia un refuso

sorry, ho fatto un copia/incolla al volo
concentrandomi sulle "farfaline" più vistose,
e così ci sono cascato anch'io

serva sempre di lezione: RTFM, plz
(prima di scrivere bischerate a ruora libera)
vale anche per i developers

scusate se alla fine ho contribuito
involontariamente ad aumentare la confusione

ciao Sandro