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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
Free forum by Nabble | Edit this page |