Re: [gdal-dev] Release of a GDAL 2.0.x and 2.1.x Visual Studio 2010 Solution (static and dynamic lib)

2016-08-05 Thread Jan Heckman 
Hi,
Great stuff here!
A minor point: please add quotes to the copy path in post-build event.
Often people (like me) will have spaces in the project path,
e.g. C:\Users\jan\Documents\Visual Studio
2015\Projects\GDAL_2.1.x_VC-master\libgdal-2.1.1.
copy
$(Projectdir)$(PlatformShortName)\$(Configuration)\$(TargetName)$(TargetExt)
$(SolutionDir)binaries\lib\$(PlatformShortName)\$(Configuration)\$(TargetName)$(TargetExt)
becomes
copy
"$(Projectdir)$(PlatformShortName)\$(Configuration)\$(TargetName)$(TargetExt)"
"$(SolutionDir)binaries\lib\$(PlatformShortName)\$(Configuration)\$(TargetName)$(TargetExt)"
Can confirm it works fine in VS2015 and full lists of (re)source and header
files are indeed present. Neat!
Jan

On Fri, Aug 5, 2016 at 1:30 PM, Jeff McKenna 
wrote:

> On 2016-08-04 6:44 PM, Mateusz Loskot wrote:
>
>>
>>> Can we make sure to document these steps, so they are not lost in emails?
>>> Somewhere on the BuildHints wiki would be great.  Possibly here?
>>> https://trac.osgeo.org/gdal/wiki/BuildingOnWindows
>>>
>>
>> https://trac.osgeo.org/gdal/wiki/BuildingOnWindows#Generatin
>> gVisualStudioproject
>>
>>
> Thanks.
>
> -jeff
>
>
>
> --
> Jeff McKenna
> MapServer Consulting and Training Services
> http://www.gatewaygeomatics.com/
>
>
>
> ___
> 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] No SONAME in libgdal.so when building with --without-libtool

2016-08-05 Thread Gareth Francis 
Encountered on Centos 6, x86_64

configured with --without-libtool, resulting libgdal.so has no SONAME entry

The link command for libgdal.so uses the variable 'GDAL_SLIB_SONAME' which
isn't defined in GDALmake.opt.in

The attached patch fixes the issue, and I believe will generate the same
name as libtool.

Thanks
Gareth Francis
Index: GDALmake.opt.in
===
--- GDALmake.opt.in (revision 34928)
+++ GDALmake.opt.in (working copy)
@@ -135,6 +135,7 @@
 GDAL_LIB   =   $(GDAL_ROOT)/libgdal.a
 GDAL_SLIB  =   $(GDAL_ROOT)/libgdal.$(SO_EXT)
 GDAL_SLIB_LINK =   -L$(GDAL_ROOT) -lgdal
+GDAL_SLIB_SONAME = -Wl,-soname,libgdal.$(SO_EXT).@GDAL_VERSION_MAJOR@
 
 # Mac OS X Framework definition
 MACOSX_FRAMEWORK = @MACOSX_FRAMEWORK@
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Release of a GDAL 2.0.x and 2.1.x Visual Studio 2010 Solution (static and dynamic lib)

2016-08-05 Thread Jeff McKenna 

On 2016-08-04 6:44 PM, Mateusz Loskot wrote:


Can we make sure to document these steps, so they are not lost in emails?
Somewhere on the BuildHints wiki would be great.  Possibly here?
https://trac.osgeo.org/gdal/wiki/BuildingOnWindows


https://trac.osgeo.org/gdal/wiki/BuildingOnWindows#GeneratingVisualStudioproject



Thanks.

-jeff



--
Jeff McKenna
MapServer Consulting and Training Services
http://www.gatewaygeomatics.com/



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

Re: [gdal-dev] Feasibility of expanding VRT schema to allow users to specify X/Y dimension for HDF data?

2016-08-05 Thread Even Rouault 
Frank,

From what I understand from Joe's needs, it looks like simple transposing of a 
2D raster wouldn't be enough. Here we would need to "transpose" pixels 
scattered through different subdatasets due to the Nd > 2 dimensionality of the 
original dataset, which would be impractical to express at the VRT level, and 
likely inefficient.

Something I've thought about would be to make Nd > 2 rasters native objects at 
the GDAL level, but this would have likely deep implications on the code base 
and should be considered carefully, and would be of interest for a limited set 
of drivers (netCDF, HDF4, HDF5, Rasdaman).

Even

> Brian / Even,
> 
> Certainly it is desirable for the HDF (and perhaps other super
> flexible formats like netcdf) to support an open option to select
> alternative axes.  But the ability to transpose a dataset could also
> be quite valuable in the VRT driver to "fix" any input transposed
> dataset.
> 
> I'm also not entirely certain why one couldn't supply an appopriately
> transposed geotransform to accomplish something similar.  This could
> be done without any code changes in the existing VRT format.
> 
> Best regards,
> Frank
> 
> On Thu, Aug 4, 2016 at 3:32 PM, Even Rouault  
wrote:
> > On Thursday 04 August 2016 16:31:25 H. Joe Lee wrote:
> >> Hi,
> >> 
> >>   My name is Joe Lee and I'm very interested in improving GDAL's
> >> 
> >> capability to access NASA HDF4/HDF5 data so that users can work with
> >> HDF easily through GDAL. For example, my goal is to allow users to
> >> translate any HDF data into GeoTIFF via gdal_translate.
> >> 
> >>   I've worked with diverse NASA HDF products and provided solution for
> >> 
> >> visualizing data correctly through Python/MATLAB/IDL/NCL [1] and I
> >> know that many products, other than HDF-EOS, may not work well with
> >> GDAL because HDF is flexible and NASA data producers do not
> >> necessarily follow the conventions that GDAL uses.
> >> 
> >>   By default, GDAL HDF4/HDF5 driver uses the following convention for
> >> 
> >> unknown products.
> >> 
> >> For HDF4 (frmts/hdf4/hdf4imagedataset.cpp):
> >> 
> >> // Search for the starting "X" and "Y" in the names or take
> >> // the last two dimensions as X and Y sizes
> >> iXDim = nDimCount - 1;
> >> iYDim = nDimCount - 2;
> >>   
> >>   For HDF5 (frmts/hdf5/hdf5imagedataset.cpp):
> >> int GetYIndex() const { return IsComplexCSKL1A() ? 0 : ndims - 2;
> >> }
> >> int GetXIndex() const { return IsComplexCSKL1A() ? 1 : ndims - 1;
> >> }
> >>  
> >>  The above code works well as long as Unknown HDF product follows the
> >> 
> >> above convention. However, in reality, HDF data can have an arbitrary
> >> 
> >> order in terms of Band, X and Y dimension like this:
> >>   dset4D[XDim=360][YDim=180][Band1=2][Band2=3]
> >>   dimindex:0  12 3
> >>   
> >>   Since ndims=4, ndims-2 becomes 2 and ndims-1=3. In such case, GDAL
> >> 
> >> generates 360x180 bands of 2x3 images, instead of the desired 2x3
> >> bands of 360x180 images.
> >> 
> >>   Thus, I'm wondering if GDAL can expand VRT schema so that VRT allows
> >> 
> >> users to specify the correct dimension index because specifying
> >> dimension order for each different NASA product in [1]  is
> >> impractical. For example, I'd like suggest a new tag like
> >> 
> >> "SourceDimension" like below:
> >>   
> >>   
> >>   
> >>  >> 
> >> relativeToVRT="0">HDF4_SDS:UNKNOWN:"DATA_WITH_4D_DATASET.hdf":7 >> len ame> 
> >> 
> >> 1
> >>  >> 
> >> DataType="UInt16" BlockXSize="360" BlockYSize="180" />
> >> 
> >>...
> >>   
> >>   
> >> 
> >> 
> >> 
> >>   Once user specifies correct dimensions by editing VRT, it can be
> >> 
> >> used by GDAL HDF4/HDF5 drivers and the HDF drivers read the data
> >> correctly for GDAL's image buffer.
> >> 
> >>   Do you think it's right and feasible approach to solve wrong X/Y
> >> 
> >> dimension order problem? Or do you have any other existing solution
> >> that can mitigate this problem in GDAL? The GEE project team has
> >> experimented the idea by creating another separate XML file [2] but I
> >> think it's time to sync with GDAL development team and come up with
> >> the most elegant solution. In my opinion, VRT looks best and I wish
> >> GDAL development team can give me some feedback on this idea.
> > 
> > Joe,
> > 
> > I would rather suggest to add open options to the drivers and pass them
> > with the exiting VRT OpenOptions element, rather than adding a new
> > element in the VRT that would be specific of a few drivers
> > 
> >  
> >  
> > 
> > 
> > relativeToVRT="0">HDF4_SDS:UNKNOWN:"DATA_WITH_4D_DATASET.hdf":7 > ename>> 
> >
> >
> >   0
> >   1
> >
> >
> >
> > 1
> >  > DataType="UInt16"
> > 
> > BlockXSize="360" BlockYSize="180" />
> > 
> >...
> >   
> >   
> > 
> > Which is equivalent to:
> > 
> > gdalinfo