[osgeo4w-dev] Clash between GDAL and netCDF4 on Windows

Mon Aug 27 23:53:50 PDT 2012

Etienne

Yes, I see version 3.6 was released in early 2007 - over 5 years ago!  What route could we follow to perhaps sponsor a change... or would someone be interested enough to upgrade it now?

As to the usage.  We are working on an extension package for a software system called "VisTrails". We are providing geospatial components ("modules") for that workflow environment.  Our code is hosted at http://code.google.com/p/eo4vistrails/ . The file that uses netcdf4 is http://code.google.com/p/eo4vistrails/source/browse/trunk/dataanalytics/netcdf4.py although, following VisTrails requirements, the initialisation happens here http://code.google.com/p/eo4vistrails/source/browse/trunk/dataanalytics/init.py . 

Under Linux, which is where all our development and testing is taking place, there is no conflict problem (as we do not need OSGeo4W) - however I have been tasked with ensuring the software also runs under Windows.

I appreciate your interest in this matter, and any ideas you have for us to avoid this conflict (at least until OSGeo4W is upgraded to handle netCDF4) would be welcome.

Thanks
Derek

>>> Etienne Tourigny <etourigny.dev at gmail.com> 27/08/12 7:07 PM >>>
Hi,

On Mon, Aug 27, 2012 at 12:05 PM, Derek Hohls <dhohls at csir.co.za> wrote:
> Etienne
>
> Thanks for your reply and very useful insights.  Perhaps one of the other
> developers might be able to give an indication as to when osgeo4w might
> support netcdf4.

pleasure to be of help. I have suggested a few times upgrading to
netcdf-4 (current version is 4.2.1.1  and osgeo4w version ships with
venerable 3.6) but it seems no one is available to do the task.
Maybe if someone could sponsor it it would get done quicker. I confess
I don't use windows, so it's a bit out of my league.

>
> From looking at various GDAL examples, it seems it would be possible to use
> GDAL for our current purpose.  I have a module written by a colleague (as
> part of a larger suite of tools we are developing) that uses the netCDF4
> Python package.  All it does, right now, is read the metadata from any
> netcdf file, in order to read the "variables" and "dimensions" and allow the
> user to extract selected data from the file as a numpy array.  I am sure
> that it would be possible to rewrite portions of our existing code to work
> with "pure" GDAL, given the somewhat parallel examples I have seen for, say,
> TIFF files.  If there is any guidance, or working examples, that you could
> provide in this direction, I'd appreciate your further input.

It really depends on what you wish to do, it would be easier if you
use either netcdf-4 OR gdal, not mix both.
If you are only dealing with netcdf files, my suggestion would be to
stick with netcdf-4, (because it's easier to deal with metadata) and
use numpy for the calculations.
GDAL supports netcdf metadata, but using the gdal metadata model.
Creating/manipulating variables and metadata

May I ask which you are mixing netcdf-4 and gdal in your script? If
you like, send me your script directly and I can help you out.

For examples, it really depends on which route you go:

netcdf-4 / scipyt/netcdf:
http://www.esr.org/~chjiang/python.html

gdal:
trac.osgeo.org/gdal/wiki/GdalOgrInPython

cheers
Etienne

>
> Thanks
> Derek
>
>
>>>> Etienne Tourigny <etourigny.dev at gmail.com> 27/08/12 2:33 PM >>>
>
> Hi,
>
> gdal in osgeo4w comes with netcdf-3, so that is the source of the
> conflict, although I don't know how to resolve it though, sorry.
>
> You might want to use, instead of python-netcdf4, the netcdf routines
> that come with scipy. This will not cause the conflict, but it doesn't
> support netcdf-4 files, only netcdf-3 files.
>
> By the way - why do you want to mix gdal and netcdf in the same
> script? gdal can import netcdf files by itself, but will expose them
> as gdal datasets.
>
> Etienne
>
> On Mon, Aug 27, 2012 at 9:01 AM, Derek Hohls <dhohls at csir.co.za> wrote:
>> Hi
>>
>> I am hoping some one can help with this.
>>
>> I have a "vanilla" Windows XP, into which I have installed the latest
>> version of OSGeo4W. I then used the "register-python" script
>> (http://code.google.com/p/maphew/source/browse/register-python/register-python.py)
>> to make the OSGeo4W the system Python. I then installed the NetCDF4 package
>> (available in binary form from
>> http://www.lfd.uci.edu/~gohlke/pythonlibs/#netcdf4). Now I can import one or
>> the other but not both packages into Python.
>>
>> GDAL first:
>>
>>>>> import gdal
>>>>> import netCDF4
>> Traceback (most recent call last):
>> File "", line 1, in
>> ImportError: DLL load failed: The specified procedure could not be found.
>>
>> NetCDF first:
>>
>>>>> import netCDF4
>>>>> import gdal
>> Traceback (most recent call last):
>> File "", line 1, in
>> File "C:\OSGeo4W\apps\Python27\lib\site-packages\gdal.py", line 2, in
>> from osgeo.gdal import deprecation_warn
>> File "C:\OSGeo4W\apps\Python27\lib\site-packages\osgeo\__init__.py", line
>> 21,
>> in
>> _gdal = swig_import_helper()
>> File "C:\OSGeo4W\apps\Python27\lib\site-packages\osgeo\__init__.py", line
>> 17,
>> in swig_import_helper
>> _mod = imp.load_module('_gdal', fp, pathname, description)
>> ImportError: DLL load failed: The specified procedure could not be found.
>>
>> If anyone can suggest how to resolve this in a straightforward manner
>> (i.e. without doing builds-from-scratch, and just using standard installers
>> - I need these as part of another install, which will be aimed at a much
>> wider, non-programming audience), I'd appreciate it.
>>
>> Thanks
>> Derek
>>
>>
>>
>>
>> --
>> This message is subject to the CSIR's copyright terms and conditions,
>> e-mail legal notice, and implemented Open Document Format (ODF) standard.
>> The full disclaimer details can be found at
>> http://www.csir.co.za/disclaimer.html.
>>
>> This message has been scanned for viruses and dangerous content by
>> MailScanner,
>> and is believed to be clean.
>>
>> Please consider the environment before printing this email.
>>
>> _______________________________________________
>> osgeo4w-dev mailing list
>> osgeo4w-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/osgeo4w-dev
>
> --
> This message is subject to the CSIR's copyright terms and conditions, e-mail
> legal notice, and implemented Open Document Format (ODF) standard.
> The full disclaimer details can be found at
> http://www.csir.co.za/disclaimer.html.
>
> This message has been scanned for viruses and dangerous content by
> MailScanner,
> and is believed to be clean.
>
> Please consider the environment before printing this email.
>
>
>
> --
> This message is subject to the CSIR's copyright terms and conditions, e-mail
> legal notice, and implemented Open Document Format (ODF) standard.
> The full disclaimer details can be found at
> http://www.csir.co.za/disclaimer.html.
>
>
> This message has been scanned for viruses and dangerous content by
> MailScanner,
> and is believed to be clean.
>
>
> Please consider the environment before printing this email.

-- 
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. 
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.

This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.

Please consider the environment before printing this email.

-- 
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. 
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.

This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.

Please consider the environment before printing this email.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/osgeo4w-dev/attachments/20120828/5a262b95/attachment.html>