RE: [gdal-dev] GDAL ERS unable to process GDA94 under amd64
Hi All, This is the target directory when building and installing GDAL. This is then looked for when trying to open of the resource files like ecw_cs.wkt. You can overrirde this by setting the GDAL_DATA environment variable to point to the directory where those files are. It turns out that this is just a case of a beginner's mistake. Even's comment got me thinking and it turns out I was just running 'make' and not 'make install' when building gdal which was causing the required resource files to not be 'installed'. I'm currently laughing at myself for the simplicity of the solution and you can all feel free to join in :) It's probably irrelevant now but I'm still not really sure how gdal was 'working' with other datasets on the same machine that were using the same workflow. Thanks again Josh Vote ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] GDAL ERS unable to process GDA94 under amd64
Hi All, Sorry the subject is a bit of an acronym soup but I'm having an interesting problem with an ERS file under my amd64 compile of GDAL trunk (revision 22366). I may as well start by describing my problem from the beginning... The attached ERS header belongs to a 5GB ER Mapper dataset for which I've been doing all of this work. Under my Debian 32 bit machine gdalinfo on this dataset returns all the typical information you'd expect but under my Debian amd64 bit machine gdalinfo (compiled from the same trunk revision and with the same dataset) returns the following... Driver: ERS/ERMapper .ers Labelled Files: ../Radmap_2010/radmap10_filtered_dose.ers ../Radmap_2010/radmap10_filtered_dose Size is 40771, 34761 Coordinate System is `' Origin = (112.9005008,-9.0004999) Pixel Size = (0.001,-0.001) Corner Coordinates: Upper Left ( 112.9005000, -9.0005000) Lower Left ( 112.9005000, -43.7615000) Upper Right ( 153.6715000, -9.0005000) Lower Right ( 153.6715000, -43.7615000) Center ( 133.286, -26.381) Band 1 Block=40771x1 Type=Float32, ColorInterp=Undefined NoData Value=-9 Notice Coordinate System is empty. Now I'll spare you the details of my epic adventure through the gdal source code but eventually I have ended up 'ogr/ogr_srs_erm.cpp' and the 'importFromERM' function. More specifically I noticed that the code that attempts to run 'OGRSpatialReference::importFromDict' is returning OGRERR_UNSUPPORTED_SRS under amd64 but OGRERR_NONE under my 32 bit installation. Digging a little deeper the 'OGRSpatialReference::importFromDict' function is failing to find a file path for CPLFindFile( gdal, ecw_cs.wkt) under amd64 (under 32 bit Debian it returns '/usr/local/share/gdal/ecw_cs.wkt'). So my question is how exactly does CPLFindFile discover a filepath and does anyone have any clue about why it's not working under Debian amd64? Secondly how does ecw_cs.wkt end up at /usr/local/share/gdal/? Sorry if this question is horribly ignorant but I'm a complete beginner when it comes to the gdal source (and compiling packages under Linux too). Thanks for reading this wall of text Josh Vote failingheader.ers Description: failingheader.ers ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] gdal_translate segfault with large netCDF
Hi, I'm new to GDAL so please forgive any glaring ignorance :) Currently I have an 8GB ER Mapper (ERS) dataset that I want to convert to a NetCDF file with gdal_translate which always results in a segfault when using the following command. gdal_translate -of netCDF input.ers output.nc Whereas translating only a small 4B subset of the dataset works fine. Now I've been doing a bit of reading and I know that netcdf 3.6.2 and below doesn't support variables greater than 4GB however I've been doing the translations with the Debian libnetcdf6 package (which I believe includes netCDF 4.1.1 and running 'ncgen -version' confirms this). I am operating under the impression that netCDF 4.1.1 should be able to handle netCDF files of this size without trouble. Now I've tested gdal_translate from a variety of builds and they all produce the same problem * gdal-trunk revision 22206 - built from source * gdal 1.8 - built from source * Using the Debian stable/testing gdal-bin binary packages which bundle gdal 1.6.3-4 and gdal 1.7.3-2 respectively. Am I doing anything wrong/operating under incorrect pretenses regarding netCDF 4GB files or is this a genuine problem with gdal_translate? Also are there any logs I could examine for more information? Thanks for any help Josh Vote ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
RE: [gdal-dev] gdal_translate segfault with large netCDF
Thanks for the suggestions - I would like to suggest that you do a gdal_translate from a subset of the ERS file at the bottom right corner of the source just to ensure that it isn't a problem with reading past the 4GB mark in the ERS file. I just managed to run 'gdal_translate -of netCDF -srcwin 5 4 100 100 input.ers output.nc' without issue (the input ERS dataset is 50592 x 41876) Josh, As frank said, file a ticket and provide the output of ncdump -h yourfile.nc with the ticket. I will take a look at it as soon as I can, although I am pretty busy. Thanks. I may have misled people with the subject of the message, sorry about that. The issue is translating a large ER Mapper file into an equally large netCDF file (reading .ers and writing .nc) http://trac.osgeo.org/gdal/ticket/4047 I've attached the ERS dataset header to the issue for reference, please let me know if you need more info. What kind of netcdf file is causing the problem? is a netcdf4 or netcdf3 file? there is a compiling option in netcdf4 --enable-netcdf-4 Will this affect writing a netCDF? Sorry again if I've misled you, the issue is reading an ER Mapper (.ers) file and writing a NetCDF. Thanks again everyone for your assistance. Josh Vote ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
