problema v.in.ogr

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

problema v.in.ogr

Iacopo Zetti-2
chiedo scusa per la poca conoscenza di grass in anticipo.
Lanciando il comando v.in.ogr ho questo risultato:

WARNING: Datum 'unknown' not recognised by GRASS and no parameters found.                                  
         Datum transformation will not be possible using this projection                                    
         information.                                                                                      
Over-riding projection check.                                                                              
Proceeding with import...                                                                                  
Layer: nodi_edificato_valdera                                                                              
Importing map 156390 features...                                                                            
*** buffer overflow detected ***: v.in.ogr terminated                                                      
======= Backtrace: =========                                                                                
/lib/libc.so.6(__fortify_fail+0x37)[0x7f6755daa2c7]                                                        
/lib/libc.so.6[0x7f6755da8170]                                                                              
/lib/libc.so.6[0x7f6755da77ab]                                                                              
/lib/libc.so.6(__snprintf_chk+0x7b)[0x7f6755da767b]                                                        
/usr/lib/libgdal1.5.0.so.1(_ZN10OGRFeature16GetFieldAsStringEi+0x346)
[0x7f6756ace296]                      
v.in.ogr(main+0x13e9)[0x405729]                                                                            
/lib/libc.so.6(__libc_start_main+0xe6)[0x7f6755cc95a6]                                                      
v.in.ogr[0x4037a9]

dato che uso l'opzione over-riding projection e che non è la prima volta che
uso il comando il messaggio di erroe non mi dice molto.
Mi par di capire che è la proiezione la fonte del problema, ma quale, quella
dello shp di partenza o quella di grass? E se di grass perché dato che in
passato non ho avuto problemi?

Grazie in anticipo per l'aiuto.

Iacopo Zetti

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.faunalia.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
Reply | Threaded
Open this post in threaded view
|

Re: problema v.in.ogr

Raffaele Morelli
Il giorno 23 giugno 2009 13.14, iacopo<[hidden email]> ha scritto:

> chiedo scusa per la poca conoscenza di grass in anticipo.
> Lanciando il comando v.in.ogr ho questo risultato:
>
> WARNING: Datum 'unknown' not recognised by GRASS and no parameters found.
>         Datum transformation will not be possible using this projection
>         information.
> Over-riding projection check.
> Proceeding with import...
> Layer: nodi_edificato_valdera
> Importing map 156390 features...
> *** buffer overflow detected ***: v.in.ogr terminated
> ======= Backtrace: =========
> /lib/libc.so.6(__fortify_fail+0x37)[0x7f6755daa2c7]
> /lib/libc.so.6[0x7f6755da8170]
> /lib/libc.so.6[0x7f6755da77ab]
> /lib/libc.so.6(__snprintf_chk+0x7b)[0x7f6755da767b]
> /usr/lib/libgdal1.5.0.so.1(_ZN10OGRFeature16GetFieldAsStringEi+0x346)
> [0x7f6756ace296]
> v.in.ogr(main+0x13e9)[0x405729]
> /lib/libc.so.6(__libc_start_main+0xe6)[0x7f6755cc95a6]
> v.in.ogr[0x4037a9]
>
> dato che uso l'opzione over-riding projection e che non è la prima volta che
> uso il comando il messaggio di erroe non mi dice molto.


non credo che la proiezione sia la fonte del problema (c'è un override
come vedi)

il buffer overflow (suppongo) potrebbe essre causato dal numero troppo
elevato di poligoni...
prova intanto con un v.in.ogr -c o con un v.external per verificare

-r
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.faunalia.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
Reply | Threaded
Open this post in threaded view
|

Re: problema v.in.ogr

Iacopo Zetti-2
Ci capisco sempre meno. Ho provato v.external e funziona, poi ho provato
v.in.ogr con uno shp contenente un solo punto (prima erano 150000 circa).
Il messaggio di errore rimane identico. Overflow con 1 punto?

Iacopo

On Tuesday 23 June 2009 14:26:03 Raffaele Morelli wrote:
> Il giorno 23 giugno 2009 13.14, iacopo<[hidden email]> ha
scritto:

> > chiedo scusa per la poca conoscenza di grass in anticipo.
> > Lanciando il comando v.in.ogr ho questo risultato:
> >
> > WARNING: Datum 'unknown' not recognised by GRASS and no parameters found.
> >         Datum transformation will not be possible using this projection
> >         information.
> > Over-riding projection check.
> > Proceeding with import...
> > Layer: nodi_edificato_valdera
> > Importing map 156390 features...
> > *** buffer overflow detected ***: v.in.ogr terminated
> > ======= Backtrace: =========
> > /lib/libc.so.6(__fortify_fail+0x37)[0x7f6755daa2c7]
> > /lib/libc.so.6[0x7f6755da8170]
> > /lib/libc.so.6[0x7f6755da77ab]
> > /lib/libc.so.6(__snprintf_chk+0x7b)[0x7f6755da767b]
> > /usr/lib/libgdal1.5.0.so.1(_ZN10OGRFeature16GetFieldAsStringEi+0x346)
> > [0x7f6756ace296]
> > v.in.ogr(main+0x13e9)[0x405729]
> > /lib/libc.so.6(__libc_start_main+0xe6)[0x7f6755cc95a6]
> > v.in.ogr[0x4037a9]
> >
> > dato che uso l'opzione over-riding projection e che non è la prima volta
> > che uso il comando il messaggio di erroe non mi dice molto.
>
> non credo che la proiezione sia la fonte del problema (c'è un override
> come vedi)
>
> il buffer overflow (suppongo) potrebbe essre causato dal numero troppo
> elevato di poligoni...
> prova intanto con un v.in.ogr -c o con un v.external per verificare
>
> -r
> _______________________________________________
> Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
> [hidden email]
> http://lists.faunalia.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non rispecchiano necessariamente
> le posizioni dell'Associazione GFOSS.it.


_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.faunalia.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
Reply | Threaded
Open this post in threaded view
|

Re: problema v.in.ogr

Iacopo Zetti-2
In reply to this post by Raffaele Morelli
Una soluzione per la vertà l'ho trovata: importando lo shp in postgres e poi
importando da postgres a grass funziona. I dati naturalmetne sono sempre gli
stessi.
Nella sostanza ho risolto, ma nella forma non ho capito cosa sia successo.
Però se sono l'unico a incontrare un problema con gli shp con v.in.ogr poco
male (per inciso lo shp viene dalla CTR della regione Toscana).

Saluti a tutti.

Iacopo

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.faunalia.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
Reply | Threaded
Open this post in threaded view
|

Re: problema v.in.ogr

Raffaele Morelli
In reply to this post by Raffaele Morelli
Il giorno 23 giugno 2009 15.18, iacopo<[hidden email]> ha scritto:

> Una soluzione per la vertà l'ho trovata: importando lo shp in postgres e poi
> importando da postgres a grass funziona. I dati naturalmetne sono sempre gli
> stessi.
> Nella sostanza ho risolto, ma nella forma non ho capito cosa sia successo.
> Però se sono l'unico a incontrare un problema con gli shp con v.in.ogr poco
> male (per inciso lo shp viene dalla CTR della regione Toscana).
>
> Saluti a tutti.
>
> Iacopo

il trick che hai usato è senz'altro efficace, puoi fare la stessa cosa
anche con qgis se vuoi saltare postgres
io ho avuto il problema inverso con shape esportati da grass che non
erano "appetibili" per R

ma cosa c'è scritto nel file .prj associato allo shape?

-r
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.faunalia.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
Reply | Threaded
Open this post in threaded view
|

Re: problema v.in.ogr

The lone A
In reply to this post by Iacopo Zetti-2
>Nella sostanza ho risolto, ma nella forma non ho capito cosa sia successo.
>Però se sono l'unico a incontrare un problema con gli shp con v.in.ogr poco
>male (per inciso lo shp viene dalla CTR della regione Toscana).

Ci risiamo ...

la solita frase a effetto per attirare l'attenzione.
(Ti stai berlusconizzando ?)

Capisco che e' abbastanza inutile tentare di spiegare
che nella CTR non esiste uno strato
"nodi_edificato_valdera" (e neanche uno strato "nodi_edificato").
Per cui e' evidente che se si tratta di un errore nello shapefile (per
giunta di punti), non puo' che derivare dalla elaborazione
intermedia operata per produrlo.

E capisco che e' altrettanto inutile sottolineare come questo
esemplifichi abbastanza bene
che la distribuzione incontrollata dei dati e' contro-producente.
Infatti, in barba a tutti i proclami di liberta varie, alla fine
quello che succede e' che i dati passando di mano in mano, possono
subire qualche "alterazione involontaria".
Pero' chissa' perche' la colpa finisce sempre per essere addossata al
produttore originale. :)

Comunque,
Capisco che secondo te la colpa e' dello shapefile.

Per cui intanto mi chiederei come mai, se davvero lo shapefile era
difettoso, Grass non lo gestisce e Postgres invece si....

E a tale riguardo svariati mesi fa' vi fu' un thread dove si discusse
proprio delle differenze comportamentali tra svariati softwares
GIS in presenza di shapefile difettosi.

Ciao,

--
~~~~~~~~~~~~~~~~~
§       Andrea              §
§         Peri                 §
~~~~~~~~~~~~~~~~~
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.faunalia.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
Reply | Threaded
Open this post in threaded view
|

Re: problema v.in.ogr

Iacopo Zetti-2
Non ho nessuna intenzione di dare la colpa alla sezione cartografia della
regione Toscana. Ho citato solo la fonte dei dati per dire che lo shp non ha
errori (infatti con postgress tutto funziona). Il fatto che poi l'importazione
in grass non sia satata tentata direttamente dallo shp originale, ma da uno
creato da me a partire dall'originale, naturalmente può significare che sono io
che ho introdotto qualche errore.
In realtà dunque cercavo di capire se l'erroe potesse essere causato da una
quache impostazione della location di grass o da non so qual'altro problema
nella gestione delle proiezioni.
In raltà ho provato anche a fare l'importazione attraverso i menù grass da
qgis, ma anche in questo caso non funziona.
Se qualcuno ha da imparare ad usere meglio i software gis però non significa
che i dati sia meglio non renderli liberi. Sbagliando si impara, pagando (cose
già pagate) semplicemente si spende :-)

Saluti a tutti.

iacopo

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.faunalia.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
Reply | Threaded
Open this post in threaded view
|

Re: problema v.in.ogr

Stefano Costa
In reply to this post by The lone A
Il giorno mar, 23/06/2009 alle 16.08 +0200, Andrea Peri ha scritto:
>
> Ci risiamo ...
>
> la solita frase a effetto per attirare l'attenzione.
> (Ti stai berlusconizzando ?)

Bboni... state bboni...

È difficile star dietro a tutte le discussioni, se in più ci aggrappiamo
a ogni minuzia per fare polemica la lista diventa illeggibile.
Oltretutto per le polemiche esiste uno strumento infallibile: la posta
in privato. Colpisce direttamente il vostro nemico all'insaputa degli
altri, lasciandolo privo di difese.

Ciao,
steko


--
Stefano Costa
http://www.iosa.it/ Open Archaeology

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.faunalia.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

presentata al mercato la prima integrazione tra GeoBI-GeoReport e SpagoBI

Fabio D'Ovidio-2
In reply to this post by Raffaele Morelli
Salve a tutti,
il primo risultato della collaborazione tra Engineering ed Inova [1],
articolata secondo una roadmap ben precisa, è un nuovo motore,
denominato "SpagoBIGeoreportEngine", che permette di eseguire documenti
analitici di SpagoBI [2] direttamente da GeoReport utilizzando un client
WebGIS conforme alle specifiche OGC. L'applicazione è già scaricabile,
insieme al manuale di installazione, al seguente indirizzo [3]!

L’integrazione con SpagoBI rappresenta un’evoluzione di GeoReport
evidenziandone le principali caratteristiche di flessibilità e
adattamento rispetto a nuove piattaforme di Business Intelligence.
"SpagoBIGeoReportEngine" interpreta un nuovo modo di soddisfare i
requisiti analitici di business mediante l’utilizzo congiunto di SpagoBI
e strumenti WebGIS per il trattamento strategico dell'informazione
digitale in toto, compresa la sua, ormai predominante, componente
cartografica.

Per ulteriori dettagli:

    * www.geobi.org
    * [hidden email]
    * [hidden email]
    * [hidden email]


[1]
http://www.spagoworld.org/ecm/faces/public/guest/home/partner/partners?portal:componentId=portal&portal:action=changeLanguage&portal:language=it
[2] http://spagobi-info.eng.it/
[3] http://code.google.com/p/geobi.

Grazie per l'attenzione!

--
Fabio D'Ovidio
Geospatial solutions

Inova S.r.l.
Web : http://www.inovaos.it
GeoBI Blog: www.geobi.org
Tel.: 081 197 57 600
mail: [hidden email], [hidden email]
skype: dovidio_fa

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.faunalia.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.