[gdal-dev] GDAL 1.10 build fails on FreeBSD

2013-09-03 Thread Frank Broniewski

Hi all,

I tried updating Gdal to the latest version on my FreeBSD system, but 
the build fails:


snip
c postgisrasterdataset.cpp  -fPIC -DPIC -o ../o/.libs/postgisrasterdataset.o
postgisrasterdataset.cpp: In function 'void GDALRegister_PostGISRaster()':
postgisrasterdataset.cpp:2096: error: 'GDAL_DMD_SUBDATASETS' was not 
declared in this scope

gmake[2]: *** [../o/postgisrasterdataset.lo] Error 1
gmake[2]: Leaving directory 
`/usr/ports/graphics/gdal/work/gdal-1.10.1/frmts/postgisraster'

gmake[1]: *** [postgisraster-install-obj] Error 2
gmake[1]: Leaving directory 
`/usr/ports/graphics/gdal/work/gdal-1.10.1/frmts'

gmake: *** [frmts-target] Error 2
*** [do-build] Error code 1
/snip

PostGIS is
POSTGIS=1.5.3 GEOS=3.3.8-CAPI-1.7.8 PROJ=Rel. 4.8.0, 6 March 2012 
LIBXML=2.7.8 USE_STATS (procs from 1.5 r5385 need upgrade)


so apparently no raster support ...

Is this a GDAL issue or shall I report this to the FreeBSD crew? Or is 
my PostGIS too old ???



Frank


--
Frank BRONIEWSKI

METRICO s.à r.l.
géomètres
technologies d'information géographique
rue des Romains 36
L-5433 NIEDERDONVEN

tél.: +352 26 74 94 - 28
fax.: +352 26 74 94 99
http://www.metrico.lu
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GTiff stack to NetCDF

2013-09-03 Thread Etienne Tourigny
what you want is probably outside the scope of gdal. It would require some
clever metadata management so that gdal_translate puts them in a single
file...

I would advise you convert them all to netcdf using gdal_translate and then
use python-netcdf4 (not the one from numpy/scipy) to stack them in the
temporal dimension.


On Mon, Sep 2, 2013 at 7:09 PM, David Shean dsh...@gmail.com wrote:

 Hi list,
 I'm trying to package a timeseries of GTiff rasters with identical
 projection/extent/resolution as a single NetCDF file for distribution.
  I've spent the past hour consulting the online doc and playing with
 gdal_translate, gdalbuildvrt and gdalwarp without any success.

 Is there an easy way to do this using existing gdal command line
 utilities?  I figured I'd ask before resorting to a custom solution using
 the NetCDF Python API.

 Thanks.
 -David
 ___
 gdal-dev mailing list
 gdal-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/gdal-dev

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 1.10 build fails on FreeBSD

2013-09-03 Thread Vincent Schut
On Tue, 03 Sep 2013 14:55:20 +0200
Frank Broniewski b...@metrico.lu wrote:

 Hi all,
 
 I tried updating Gdal to the latest version on my FreeBSD system, but 
 the build fails:
 
 snip
 c postgisrasterdataset.cpp  -fPIC -DPIC
 -o ../o/.libs/postgisrasterdataset.o postgisrasterdataset.cpp: In
 function 'void GDALRegister_PostGISRaster()':
 postgisrasterdataset.cpp:2096: error: 'GDAL_DMD_SUBDATASETS' was not
 declared in this scope gmake[2]: *** [../o/postgisrasterdataset.lo]
 Error 1 gmake[2]: Leaving directory 
 `/usr/ports/graphics/gdal/work/gdal-1.10.1/frmts/postgisraster'
 gmake[1]: *** [postgisraster-install-obj] Error 2
 gmake[1]: Leaving directory 
 `/usr/ports/graphics/gdal/work/gdal-1.10.1/frmts'
 gmake: *** [frmts-target] Error 2
 *** [do-build] Error code 1
 /snip
 
 PostGIS is
 POSTGIS=1.5.3 GEOS=3.3.8-CAPI-1.7.8 PROJ=Rel. 4.8.0, 6 March
 2012 LIBXML=2.7.8 USE_STATS (procs from 1.5 r5385 need upgrade)
 
 so apparently no raster support ...
 
 Is this a GDAL issue or shall I report this to the FreeBSD crew? Or
 is my PostGIS too old ???

Frank, just fyi: I recently upgraded gdal on my freebsd system to 1.10,
and all went fine. My postgis is significantly newer than yours, though
(2.1 I think, or at least 2.0), so that might be the culprit indeed.

Best,
Vincent.
 
 
 Frank
 
 

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev


Re: [gdal-dev] GTiff stack to NetCDF

2013-09-03 Thread David Shean
Done:

http://gis.stackexchange.com/questions/70458/convert-timeseries-stack-of-gtiff-raster-to-single-netcdf

Thanks for the responses.  
D

On Sep 3, 2013, at 7:55 AM, Signell, Richard rsign...@usgs.gov wrote:

 David,
 If you post your question on the GIS stackexchange group
 http://gis.stackexchange.com/
 I will provide an example code that should be helpful.
 
 -Rich
 
 On Tue, Sep 3, 2013 at 10:15 AM, Etienne Tourigny
 etourigny@gmail.com wrote:
 what you want is probably outside the scope of gdal. It would require some
 clever metadata management so that gdal_translate puts them in a single
 file...
 
 I would advise you convert them all to netcdf using gdal_translate and then
 use python-netcdf4 (not the one from numpy/scipy) to stack them in the
 temporal dimension.
 
 
 On Mon, Sep 2, 2013 at 7:09 PM, David Shean dsh...@gmail.com wrote:
 
 Hi list,
 I'm trying to package a timeseries of GTiff rasters with identical
 projection/extent/resolution as a single NetCDF file for distribution.  I've
 spent the past hour consulting the online doc and playing with
 gdal_translate, gdalbuildvrt and gdalwarp without any success.
 
 Is there an easy way to do this using existing gdal command line
 utilities?  I figured I'd ask before resorting to a custom solution using
 the NetCDF Python API.
 
 Thanks.
 -David
 ___
 gdal-dev mailing list
 gdal-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/gdal-dev
 
 
 
 ___
 gdal-dev mailing list
 gdal-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/gdal-dev
 
 
 
 -- 
 Dr. Richard P. Signell   (508) 457-2229
 USGS, 384 Woods Hole Rd.
 Woods Hole, MA 02543-1598

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev


Re: [gdal-dev] GTiff stack to NetCDF

2013-09-03 Thread Signell, Richard
David,
If you post your question on the GIS stackexchange group
http://gis.stackexchange.com/
I will provide an example code that should be helpful.

-Rich

On Tue, Sep 3, 2013 at 10:15 AM, Etienne Tourigny
etourigny@gmail.com wrote:
 what you want is probably outside the scope of gdal. It would require some
 clever metadata management so that gdal_translate puts them in a single
 file...

 I would advise you convert them all to netcdf using gdal_translate and then
 use python-netcdf4 (not the one from numpy/scipy) to stack them in the
 temporal dimension.


 On Mon, Sep 2, 2013 at 7:09 PM, David Shean dsh...@gmail.com wrote:

 Hi list,
 I'm trying to package a timeseries of GTiff rasters with identical
 projection/extent/resolution as a single NetCDF file for distribution.  I've
 spent the past hour consulting the online doc and playing with
 gdal_translate, gdalbuildvrt and gdalwarp without any success.

 Is there an easy way to do this using existing gdal command line
 utilities?  I figured I'd ask before resorting to a custom solution using
 the NetCDF Python API.

 Thanks.
 -David
 ___
 gdal-dev mailing list
 gdal-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/gdal-dev



 ___
 gdal-dev mailing list
 gdal-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/gdal-dev



-- 
Dr. Richard P. Signell   (508) 457-2229
USGS, 384 Woods Hole Rd.
Woods Hole, MA 02543-1598
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev


Re: [gdal-dev] GDAL 1.10 build fails on FreeBSD

2013-09-03 Thread Marius Jigmond
Frank,
You'll need a newer PostGIS (2.x+) if you want to compile GDAL 1.10 with PG 
support.
http://trac.osgeo.org/gdal/wiki/frmts_wtkraster.html
-marius

 Date: Tue, 3 Sep 2013 17:02:44 +0200
 From: sc...@sarvision.nl
 To: gdal-dev@lists.osgeo.org
 Subject: Re: [gdal-dev] GDAL 1.10 build fails on FreeBSD
 
 On Tue, 03 Sep 2013 14:55:20 +0200
 Frank Broniewski b...@metrico.lu wrote:
 
  Hi all,
  
  I tried updating Gdal to the latest version on my FreeBSD system, but 
  the build fails:
  
  snip
  c postgisrasterdataset.cpp  -fPIC -DPIC
  -o ../o/.libs/postgisrasterdataset.o postgisrasterdataset.cpp: In
  function 'void GDALRegister_PostGISRaster()':
  postgisrasterdataset.cpp:2096: error: 'GDAL_DMD_SUBDATASETS' was not
  declared in this scope gmake[2]: *** [../o/postgisrasterdataset.lo]
  Error 1 gmake[2]: Leaving directory 
  `/usr/ports/graphics/gdal/work/gdal-1.10.1/frmts/postgisraster'
  gmake[1]: *** [postgisraster-install-obj] Error 2
  gmake[1]: Leaving directory 
  `/usr/ports/graphics/gdal/work/gdal-1.10.1/frmts'
  gmake: *** [frmts-target] Error 2
  *** [do-build] Error code 1
  /snip
  
  PostGIS is
  POSTGIS=1.5.3 GEOS=3.3.8-CAPI-1.7.8 PROJ=Rel. 4.8.0, 6 March
  2012 LIBXML=2.7.8 USE_STATS (procs from 1.5 r5385 need upgrade)
  
  so apparently no raster support ...
  
  Is this a GDAL issue or shall I report this to the FreeBSD crew? Or
  is my PostGIS too old ???
 
 Frank, just fyi: I recently upgraded gdal on my freebsd system to 1.10,
 and all went fine. My postgis is significantly newer than yours, though
 (2.1 I think, or at least 2.0), so that might be the culprit indeed.
 
 Best,
 Vincent.
  
  
  Frank
  
  
 
 ___
 gdal-dev mailing list
 gdal-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/gdal-dev
  ___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] HFA and RAT

2013-09-03 Thread Ivan Lucena
Take any image, a screenshot of your desktop for example, save it as .bmp 
gdal_translate it to HFA, .img file, and run gdalinfo on it (trunk version). 
It's only me or at the end of the gdalinfo report do you also see 
GDALRasterAttributeTable / for each band?

Band 1 Block=64x64 Type=Byte, ColorInterp=Undefined
  Description = Layer_1
  Metadata:
LAYER_TYPE=athematic
GDALRasterAttributeTable /

Band 2 Block=64x64 Type=Byte, ColorInterp=Undefined
  Description = Layer_2
  Metadata:
LAYER_TYPE=athematic
GDALRasterAttributeTable /

Band 3 Block=64x64 Type=Byte, ColorInterp=Undefined
  Description = Layer_3
  Metadata:
LAYER_TYPE=athematic
GDALRasterAttributeTable /

It seems to me that the HFA driver is reporting incorrectly when the GDAL API 
function GDALGetDefaultRAT is called by gdalinfo.
  ___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] HFA and RAT

2013-09-03 Thread Sam Gillingham
Hi Ivan,

Yes I can see this also with the trunk version. The problem is that with
the RFC40 changes the HFA driver always returns something from
GetDefaultRAT even if it is an empty table - you can now start writing data
directly into the table with the returned object.

Below is a patch to prevent the Serialize() method returning anything when
the row and column count is zero. I will submit this as a bug report if
people think it is a good workaround.

Sam.


--- gcore/gdal_rat.cpp.orig Wed Sep  4 09:27:51 2013
+++ gcore/gdal_rat.cpp  Wed Sep  4 09:28:33 2013
@@ -502,6 +502,9 @@
 CPLXMLNode *psTree = NULL;
 CPLXMLNode *psRow = NULL;

+if( ( GetColumnCount() == 0 )  ( GetRowCount() == 0 ) )
+return NULL;
+
 psTree = CPLCreateXMLNode( NULL, CXT_Element,
GDALRasterAttributeTable );

 /*  */



On 4 September 2013 08:22, Ivan Lucena lucena_i...@hotmail.com wrote:

 Take any image, a screenshot of your desktop for example, save it as .bmp
 gdal_translate it to HFA, .img file, and run gdalinfo on it (trunk
 version). It's only me or at the end of the gdalinfo report do you also see
 GDALRasterAttributeTable / for each band?

 Band 1 Block=64x64 Type=Byte, ColorInterp=Undefined
   Description = Layer_1
   Metadata:
 LAYER_TYPE=athematic
 GDALRasterAttributeTable /

 Band 2 Block=64x64 Type=Byte, ColorInterp=Undefined
   Description = Layer_2
   Metadata:
 LAYER_TYPE=athematic
 GDALRasterAttributeTable /

 Band 3 Block=64x64 Type=Byte, ColorInterp=Undefined
   Description = Layer_3
   Metadata:
 LAYER_TYPE=athematic
 GDALRasterAttributeTable /

 It seems to me that the HFA driver is reporting incorrectly when the GDAL
 API function GDALGetDefaultRAT is called by gdalinfo.

 ___
 gdal-dev mailing list
 gdal-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/gdal-dev

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] HFA and RAT

2013-09-03 Thread Ivan Lucena
Hi Sam,

Assign the ticket to me and I will apply the patch.

Thanks,

Ivan

Date: Wed, 4 Sep 2013 09:47:48 +1200
Subject: Re: [gdal-dev] HFA and RAT
From: gillingham@gmail.com
To: lucena_i...@hotmail.com
CC: gdal-dev@lists.osgeo.org

Hi Ivan, 

Yes I can see this also with the trunk version. The problem is that with the 
RFC40 changes the HFA driver always returns something from GetDefaultRAT even 
if it is an empty table - you can now start writing data directly into the 
table with the returned object.


Below is a patch to prevent the Serialize() method returning anything when the 
row and column count is zero. I will submit this as a bug report if people 
think it is a good workaround.

Sam.



--- gcore/gdal_rat.cpp.orig Wed Sep  4 09:27:51 2013
+++ gcore/gdal_rat.cpp  Wed Sep  4 09:28:33 2013
@@ -502,6 +502,9 @@
 CPLXMLNode *psTree = NULL;
 CPLXMLNode *psRow = NULL;
 
+if( ( GetColumnCount() == 0 )  ( GetRowCount() == 0 ) )

+return NULL;
+
 psTree = CPLCreateXMLNode( NULL, CXT_Element, GDALRasterAttributeTable );
 
 /*  */




On 4 September 2013 08:22, Ivan Lucena lucena_i...@hotmail.com wrote:




Take any image, a screenshot of your desktop for example, save it as .bmp 
gdal_translate it to HFA, .img file, and run gdalinfo on it (trunk version). 
It's only me or at the end of the gdalinfo report do you also see 
GDALRasterAttributeTable / for each band?


Band 1 Block=64x64 Type=Byte, ColorInterp=Undefined
  Description = Layer_1
  Metadata:
LAYER_TYPE=athematic
GDALRasterAttributeTable /

Band 2 Block=64x64 Type=Byte, ColorInterp=Undefined

  Description = Layer_2
  Metadata:
LAYER_TYPE=athematic
GDALRasterAttributeTable /

Band 3 Block=64x64 Type=Byte, ColorInterp=Undefined
  Description = Layer_3
  Metadata:
LAYER_TYPE=athematic

GDALRasterAttributeTable /

It seems to me that the HFA driver is reporting incorrectly when the GDAL API 
function GDALGetDefaultRAT is called by gdalinfo.
  

___

gdal-dev mailing list

gdal-dev@lists.osgeo.org

http://lists.osgeo.org/mailman/listinfo/gdal-dev

  ___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev