Sunday, 25 April 2010
Geolancer?
Un nuovo portale per lavori online, lanciato agli inizi di Aprile e specifico per "geo-related tasks", a differenza di Elance ed altri che potete eventualmente conoscere.
La descrizione breve nel loro sito https://www.geolancer.com/ è:
"GeoLancer.com is a complete, intuitive and easy-to-use platform which connects freelancing geo-professionals, the Geo-Providers, with Geo-Buyers who wish to outsource certain Geo-related tasks.
GIS analysis, Remote Sensing imagery processing, Hydrography, Calculations for Land Survey, Geo-referencing, Seismic Data interpretation, Side Scan Sonar mosaicking, Geo-journalism and much more..."
Ovviamente auguriamo loro di riuscire a sfondare.
Saturday, 24 April 2010
Programmi Fortran e Python: una modalità di compilazione sotto Windows
Lavoriamo con Python sotto Windows e vogliamo utilizzare delle funzioni scritte in Fortran.
Uno strumento adatto e semplice è F2PY che, attraverso la creazione semi-automatica di “signature files” (http://cens.ioc.ee/projects/f2py2e/), permette di creare moduli Python a partire da codici Fortran.
In Windows esiste però il vincolo del software proprietario utilizzato per compilare Python, e conseguentemente delle versioni delle librerie collegate. Le versioni recenti di Python (>= 2.6) sono compilate con Microsoft Visual Studio 2008 e richiedono il collegamento alla libreria msvcr90.dll di Studio 2008. Un compilatore open source come mingw32 è basato su msvcrt6.dll. Possiamo non disporre, o non voler utilizzare, le versioni commerciale o gratuita (Express, http://www.microsoft.com/express/) di Visual Studio.
Per aggirare il problema, escludendo di ricompilare l'intero codice sorgente di Python con un compilatore open source come gcc o simili, si può utilizzare Python sotto Cygwin, un emulatore di Linux per Windows, oppure più semplicemente modificare alcuni settaggi del sistema per potere utilizzare un compilatore free come gfortran.
Un esempio di questa seconda modalità è ben spiegata in questa breve pagina da SciPy, http://www.scipy.org/F2PY_Windows. Se usate Python 2.6 o 2.7 la dll da linkare è msvcr90.dll (di Visual Studio 2008), mentre se usate Python 2.5, la dll è msvcr71.dll (di Visual Studio 2003).
Nota: utilizzando subroutine Fortran, almeno nel mio caso il risultato viene trattato da Python come un Fortran object. Se invece utilizzate delle funzioni, il risultato viene immediatamente riconosciuto come oggetti Python (numeri, etc.).
Uno strumento adatto e semplice è F2PY che, attraverso la creazione semi-automatica di “signature files” (http://cens.ioc.ee/projects/f2py2e/), permette di creare moduli Python a partire da codici Fortran.
In Windows esiste però il vincolo del software proprietario utilizzato per compilare Python, e conseguentemente delle versioni delle librerie collegate. Le versioni recenti di Python (>= 2.6) sono compilate con Microsoft Visual Studio 2008 e richiedono il collegamento alla libreria msvcr90.dll di Studio 2008. Un compilatore open source come mingw32 è basato su msvcrt6.dll. Possiamo non disporre, o non voler utilizzare, le versioni commerciale o gratuita (Express, http://www.microsoft.com/express/) di Visual Studio.
Per aggirare il problema, escludendo di ricompilare l'intero codice sorgente di Python con un compilatore open source come gcc o simili, si può utilizzare Python sotto Cygwin, un emulatore di Linux per Windows, oppure più semplicemente modificare alcuni settaggi del sistema per potere utilizzare un compilatore free come gfortran.
Un esempio di questa seconda modalità è ben spiegata in questa breve pagina da SciPy, http://www.scipy.org/F2PY_Windows. Se usate Python 2.6 o 2.7 la dll da linkare è msvcr90.dll (di Visual Studio 2008), mentre se usate Python 2.5, la dll è msvcr71.dll (di Visual Studio 2003).
Nota: utilizzando subroutine Fortran, almeno nel mio caso il risultato viene trattato da Python come un Fortran object. Se invece utilizzate delle funzioni, il risultato viene immediatamente riconosciuto come oggetti Python (numeri, etc.).
Tuesday, 6 April 2010
Operazioni GIS e velocità dei processamenti con Python
Python è un linguaggio di scripting che sta vivendo un periodo di notevole popolarità grazie al suo essere un linguaggio di alto livello e poliedrico. Dal lato GIS, può essere collegato a software GIS free o commerciali, per esempio Grass o ArcGis, e in un ambiente come FWTools può svolgere processamenti GIS senza bisogno di appoggiarsi a software GIS esterni.
Disponendo di funzionalità GIS, è opportuno sempre appoggiarsi a queste, oppure per questioni di tempi di esecuzione dei programmi, può essere opportuno rinunciare a queste funzionalità e utilizzare le strutture dati e le funzionalità standard interne del linguaggio?
In questo post, riporto un caso in cui il processamento di dati GIS, puntuali, è risultato più veloce di un ordine di grandezza utilizzando un normale ciclo for su dati letti e conservati in una lista, piuttosto che utilizzando filtri spaziali (con l'estensione ogr) sugli stessi dati conservati in uno shapefile. Le operazioni di filtro spaziale con la funzione SetSpatialFilterRect applicata su varie decine di migliaia di punti richiedevano circa un secondo (100 casi in 111.5 sec), in ambiente FWTools con ogr. La stessa operazione con un normale ciclo for sullo stesso dataset in una lista richiedeva circa un decimo di secondo (100 casi in 9.6 sec). Trattandosi di operazione da ripetere per decine di migliaia di casi si capisce che si passa da tempi di decine di ore a ore, con un forte guadagno di tempi.
Per cui, è opportuno verificare, quando si devono processare notevoli quantità di dati, se piuttosto che usare eleganti funzioni GIS da estensioni come ogr, non sia più veloce usare banali operatori sui dati conservati in strutture dati di Python, come liste o simili.
Disponendo di funzionalità GIS, è opportuno sempre appoggiarsi a queste, oppure per questioni di tempi di esecuzione dei programmi, può essere opportuno rinunciare a queste funzionalità e utilizzare le strutture dati e le funzionalità standard interne del linguaggio?
In questo post, riporto un caso in cui il processamento di dati GIS, puntuali, è risultato più veloce di un ordine di grandezza utilizzando un normale ciclo for su dati letti e conservati in una lista, piuttosto che utilizzando filtri spaziali (con l'estensione ogr) sugli stessi dati conservati in uno shapefile. Le operazioni di filtro spaziale con la funzione SetSpatialFilterRect applicata su varie decine di migliaia di punti richiedevano circa un secondo (100 casi in 111.5 sec), in ambiente FWTools con ogr. La stessa operazione con un normale ciclo for sullo stesso dataset in una lista richiedeva circa un decimo di secondo (100 casi in 9.6 sec). Trattandosi di operazione da ripetere per decine di migliaia di casi si capisce che si passa da tempi di decine di ore a ore, con un forte guadagno di tempi.
Per cui, è opportuno verificare, quando si devono processare notevoli quantità di dati, se piuttosto che usare eleganti funzioni GIS da estensioni come ogr, non sia più veloce usare banali operatori sui dati conservati in strutture dati di Python, come liste o simili.
Subscribe to:
Posts (Atom)