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

[H. Joe Lee]

Thank you so much, Even! OpenOptions sounds like a perfect match for
this case. I'll try it with HDF drivers and see how it goes with
gdal_translate.

Best Regards,



On Thu, Aug 4, 2016 at 5: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> 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
>
>   0
>   1
>
> 1
>  BlockXSize="360" BlockYSize="180" />
>...
>   
>
> Which is equivalent to:
>
> gdalinfo HDF4_SDS:UNKNOWN:"DATA_WITH_4D_DATASET.hdf":7 -oo RASTERXDIM=0 -oo
> RASTERYDIM=0
>
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.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?

[Frank Warmerdam]

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> 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
>
>   0
>   1
>
> 1
>  BlockXSize="360" BlockYSize="180" />
>...
>   
>
> Which is equivalent to:
>
> gdalinfo HDF4_SDS:UNKNOWN:"DATA_WITH_4D_DATASET.hdf":7 -oo RASTERXDIM=0 -oo
> RASTERYDIM=0
>
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev



-- 
---+--
I set the clouds in motion - turn up   | Frank Warmerdam, warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| Geospatial Software Developer
___
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?

[Even Rouault]

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 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
   
  0
  1
   
1

   ...
  

Which is equivalent to:

gdalinfo HDF4_SDS:UNKNOWN:"DATA_WITH_4D_DATASET.hdf":7 -oo RASTERXDIM=0 -oo 
RASTERYDIM=0


Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Error Compiling GDAL with ESRI FileGeodatabase Support On Ubuntu 16.04

[Even Rouault]

On Thursday 04 August 2016 17:00:29 Andrew Joseph wrote:
> using ./configure CXXFLAGS="-D_GLIBCXX_USE_CXX11_ABI=0" results in:
> 
[...]
Looks like you must drop the mongo, podofo and kea dependencies, or recompile 
them with  -D_GLIBCXX_USE_CXX11_ABI=0 as well.

> and ./configure CXXFLAGS="-std=C++03 -D_GLIBCXX_USE_CXX11_ABI=0" results in:
> configure: error: "You don't have a working C++ compiler." (I'm a java
> developer so not very familiar with c/c++ compilation)

Hum, migt be case sensitive "-std=c++03 -D_GLIBCXX_USE_CXX11_ABI=0", but after 
thinking I don't think this is worth trying. The issue is more on the ABI than 
the version of C++.

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Error Compiling GDAL with ESRI FileGeodatabase Support On Ubuntu 16.04

[Andrew Joseph]

using ./configure CXXFLAGS="-D_GLIBCXX_USE_CXX11_ABI=0" results in:

/tmp/gdal/gdal/libgdal.so: undefined reference to
`PoDoFo::PdfMemDocument::SetPassword(std::string
const&)'
/tmp/gdal/gdal/libgdal.so: undefined reference to
`mongo::client::Options::setSSLPEMKeyFile(std::string
const&)'
/tmp/gdal/gdal/libgdal.so: undefined reference to
`mongo::client::Options::setSSLCRLFile(std::string
const&)'
/tmp/gdal/gdal/libgdal.so: undefined reference to
`mongo::DBClientWithCommands::auth(std::string const&, std::string const&,
std::string const&, std::string&, bool)'
/tmp/gdal/gdal/libgdal.so: undefined reference to `mongo::msgasserted(int,
std::string const&)'
/tmp/gdal/gdal/libgdal.so: undefined reference to
`mongo::BulkOperationBuilder::BulkOperationBuilder(mongo::DBClientBase*,
std::string const&, bool, bool)'
/tmp/gdal/gdal/libgdal.so: undefined reference to
`kealib::KEAImageIO::setGCPs(std::vector >*, std::string)'
/tmp/gdal/gdal/libgdal.so: undefined reference to
`kealib::KEAImageIO::createKEAImage(std::string,
kealib::KEADataType, unsigned int, unsigned int, unsigned int,
std::vector*,
kealib::KEAImageSpatialInfo*, unsigned int, unsigned int, int, unsigned
long long, unsigned long long, double, unsigned long long, unsigned long
long, unsigned int)'
/tmp/gdal/gdal/libgdal.so: undefined reference to `mongo::BSONObjBuilder::
numStrs'
/tmp/gdal/gdal/libgdal.so: undefined reference to `kealib::KEAImageIO::
getGCPProjection()'
/tmp/gdal/gdal/libgdal.so: undefined reference to
`mongo::client::Options::setSSLCAFile(std::string
const&)'
/tmp/gdal/gdal/libgdal.so: undefined reference to `mongo::client::Options::
setSSLPEMKeyPassword(std::string const&)'
/tmp/gdal/gdal/libgdal.so: undefined reference to
`kealib::KEAImageIO::getImageBandMetaData(unsigned
int)'
/tmp/gdal/gdal/libgdal.so: undefined reference to
`mongo::DBClientWithCommands::getCollectionNames(std::string const&,
mongo::BSONObj const&)'
/tmp/gdal/gdal/libgdal.so: undefined reference to `kealib::KEAImageIO::
isKEAImage(std::string)'
/tmp/gdal/gdal/libgdal.so: undefined reference to
`kealib::KEAImageIO::setImageMetaData(std::string,
std::string)'
/tmp/gdal/gdal/libgdal.so: undefined reference to
`kealib::KEAImageIO::openKeaH5RDOnly(std::string,
int, unsigned long long, unsigned long long, double, unsigned long long,
unsigned long long)'
/tmp/gdal/gdal/libgdal.so: undefined reference to
`mongo::DBClientWithCommands::getDatabaseNames()'
/tmp/gdal/gdal/libgdal.so: undefined reference to
`kealib::KEAImageIO::openKeaH5RW(std::string,
int, unsigned long long, unsigned long long, double, unsigned long long,
unsigned long long)'
/tmp/gdal/gdal/libgdal.so: undefined reference to
`mongo::ConnectionString::parse(std::string
const&, std::string&)'
/tmp/gdal/gdal/libgdal.so: undefined reference to `kealib::KEAImageIO::
getImageMetaData()'
/tmp/gdal/gdal/libgdal.so: undefined reference to
`mongo::ConnectionString::connect(std::string&,
double) const'
/tmp/gdal/gdal/libgdal.so: undefined reference to
`mongo::Status::toString() const'
/tmp/gdal/gdal/libgdal.so: undefined reference to `mongo::OID::toString()
const'
/tmp/gdal/gdal/libgdal.so: undefined reference to `mongo::BSONElement::
jsonString(mongo::JsonStringFormat, bool, int) const'
/tmp/gdal/gdal/libgdal.so: undefined reference to `kealib::KEAImageIO::
getImageBandDescription(unsigned int)'
/tmp/gdal/gdal/libgdal.so: undefined reference to
`mongo::BSONObj::jsonString(mongo::JsonStringFormat, int, bool) const'
/tmp/gdal/gdal/libgdal.so: undefined reference to
`kealib::KEAImageIO::setImageBandMetaData(unsigned
int, std::string, std::string)'
/tmp/gdal/gdal/libgdal.so: undefined reference to `kealib::KEAImageIO::
setImageBandDescription(unsigned int, std::string)'
/tmp/gdal/gdal/libgdal.so: undefined reference to
`mongo::OID::init(std::string const&)'
collect2: error: ld returned 1 exit status
make[1]: *** [gdalinfo] Error 1

and ./configure CXXFLAGS="-std=C++03 -D_GLIBCXX_USE_CXX11_ABI=0" results in:
configure: error: "You don't have a working C++ compiler." (I'm a java
developer so not very familiar with c/c++ compilation)

On Thu, Aug 4, 2016 at 4:02 PM, Even Rouault 
wrote:

> On Thursday 04 August 2016 15:59:22 Andrew Joseph wrote:
> > I had originally compiled without any of those flags (thought that might
> > have been the issue), but still get an error  though it is different:
>
> You may need to pass -std=C++03 and/or -D_GLIBCXX_USE_CXX11_ABI=0 as
> CXXFLAGS.
>
> >
> > /tmp/gdal/libgdal.so: undefined reference to
> > `FileGDBAPI::Geodatabase::Delete(std::__cxx11::basic_string > std::char_traits, std::allocator > const&,
> > std::__cxx11::basic_string > std::allocator > const&)'
> > /tmp/gdal/libgdal.so: undefined reference to
> > `FileGDBAPI::Row::SetFloat(std::__cxx11::basic_string > std::char_traits, std::allocator > const&, float)'
> > 

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

[Mateusz Loskot]

On 4 August 2016 at 17:52, Jeff McKenna  wrote:
> On 2016-08-04 11:07 AM, Mateusz Loskot wrote:
>>
>> 1. makegdal_gen 10.00 32 > makegdal10.vcproj
>> 2. Launch VS2015
>> 3. File > Open > Project/Solution...
>> 4. Select makegdal10.vcproj
>> 5. Accept to upgrade
>>
>
>
>
> 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

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

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

[H. Joe Lee]

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:

  
  
HDF4_SDS:UNKNOWN:"DATA_WITH_4D_DATASET.hdf":7

1

   ...
  


  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.

  Best Regards,



[1] http://hdfeos.org/zoo/
[2] https://wiki.earthdata.nasa.gov/pages/viewpage.action?pageId=65799385
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Error Compiling GDAL with ESRI FileGeodatabase Support On Ubuntu 16.04

[Even Rouault]

On Thursday 04 August 2016 15:59:22 Andrew Joseph wrote:
> I had originally compiled without any of those flags (thought that might
> have been the issue), but still get an error  though it is different:

You may need to pass -std=C++03 and/or -D_GLIBCXX_USE_CXX11_ABI=0 as CXXFLAGS.

> 
> /tmp/gdal/libgdal.so: undefined reference to
> `FileGDBAPI::Geodatabase::Delete(std::__cxx11::basic_string std::char_traits, std::allocator > const&,
> std::__cxx11::basic_string std::allocator > const&)'
> /tmp/gdal/libgdal.so: undefined reference to
> `FileGDBAPI::Row::SetFloat(std::__cxx11::basic_string std::char_traits, std::allocator > const&, float)'
> /tmp/gdal/libgdal.so: undefined reference to
> `kmlengine::Href::Parse(std::__cxx11::basic_string std::char_traits, std::allocator > const&)'
> /tmp/gdal/libgdal.so: undefined reference to
> `FileGDBAPI::Row::SetDouble(std::__cxx11::basic_string std::char_traits, std::allocator > const&, double)'
> /tmp/gdal/libgdal.so: undefined reference to
> `FileGDBAPI::Geodatabase::GetQueryName(std::__cxx11::basic_string std::char_traits, std::allocator > const&,
> std::__cxx11::basic_string std::allocator >&) c   onst'
> /tmp/gdal/libgdal.so: undefined reference to
> `FileGDBAPI::Row::GetDouble(std::__cxx11::basic_string std::char_traits, std::allocator > const&, double&) const'
> /tmp/gdal/libgdal.so: undefined reference to
> `FileGDBAPI::Geodatabase::CreateTable(std::__cxx11::basic_string std::char_traits, std::allocator > const&,
> std::__cxx11::basic_string std::allocator > const&, FileG
> DBAPI::Table&)'
> /tmp/gdal/libgdal.so: undefined reference to
> `FileGDBAPI::Row::SetGUID(std::__cxx11::basic_string std::char_traits, std::allocator > const&,
> FileGDBAPI::Guid const&)'
> /tmp/gdal/libgdal.so: undefined reference to
> `kmlengine::KmzFile::ReadKmlAndGetPath(std::__cxx11::basic_string std::char_traits, std::allocator >*,
> std::__cxx11::basic_string std::allocator >*) const'
> /tmp/gdal/libgdal.so: undefined reference to
> `FileGDBAPI::Row::SetNull(std::__cxx11::basic_string std::char_traits, std::allocator > const&)'
> /tmp/gdal/libgdal.so: undefined reference to
> `FileGDBAPI::FieldInfo::GetFieldName(int,
> std::__cxx11::basic_string std::allocator >&) const'
> /tmp/gdal/libgdal.so: undefined reference to
> `FileGDBAPI::OpenGeodatabase(std::__cxx11::basic_string std::char_traits, std::allocator > const&,
> FileGDBAPI::Geodatabase&)'
> /tmp/gdal/libgdal.so: undefined reference to
> `FileGDBAPI::Row::GetFloat(std::__cxx11::basic_string std::char_traits, std::allocator > const&, float&) const'
> /tmp/gdal/libgdal.so: undefined reference to
> `FileGDBAPI::Row::GetDate(std::__cxx11::basic_string std::char_traits, std::allocator > const&, tm&) const'
> /tmp/gdal/libgdal.so: undefined reference to
> `FileGDBAPI::Table::GetDocumentation(std::__cxx11::basic_string std::char_traits, std::allocator >&) const'
> /tmp/gdal/libgdal.so: undefined reference to
> `FileGDBAPI::Row::SetShort(std::__cxx11::basic_string std::char_traits, std::allocator > const&, short)'
> /tmp/gdal/libgdal.so: undefined reference to
> `kmlengine::KmzFile::OpenFromString(std::__cxx11::basic_string std::char_traits, std::allocator > const&)'
> /tmp/gdal/libgdal.so: undefined reference to
> `FileGDBAPI::Geodatabase::OpenTable(std::__cxx11::basic_string std::char_traits, std::allocator > const&,
> FileGDBAPI::Table&)'
> /tmp/gdal/libgdal.so: undefined reference to
> `FileGDBAPI::Geodatabase::CreateFeatureDataset(std::__cxx11::basic_string ar, std::char_traits, std::allocator > const&)'
> /tmp/gdal/libgdal.so: undefined reference to
> `FileGDBAPI::Row::SetDate(std::__cxx11::basic_string std::char_traits, std::allocator > const&, tm const&)'
> /tmp/gdal/libgdal.so: undefined reference to
> `FileGDBAPI::Row::GetBinary(std::__cxx11::basic_string std::char_traits, std::allocator > const&,
> FileGDBAPI::ByteArray&) const'
> /tmp/gdal/libgdal.so: undefined reference to
> `FileGDBAPI::Row::SetInteger(std::__cxx11::basic_string std::char_traits, std::allocator > const&, int)'
> /tmp/gdal/libgdal.so: undefined reference to
> `FileGDBAPI::Table::DeleteField(std::__cxx11::basic_string std::char_traits, std::allocator > const&)'
> /tmp/gdal/libgdal.so: undefined reference to
> `FileGDBAPI::Geodatabase::ExecuteSQL(std::__cxx11::basic_string std::char_traits, std::allocator > const&, bool,
> FileGDBAPI::EnumRows&) const'
> /tmp/gdal/libgdal.so: undefined reference to
> `FileGDBAPI::CreateGeodatabase(std::__cxx11::basic_string std::char_traits, std::allocator > const&,
> FileGDBAPI::Geodatabase&)'
> /tmp/gdal/libgdal.so: 

Re: [gdal-dev] Error Compiling GDAL with ESRI FileGeodatabase Support On Ubuntu 16.04

[Jeff McKenna]

On 2016-08-04 5:24 PM, Andrew Joseph wrote:

I'm not able to compile GDAL with the ESRI FileGeodatabase driver (needed for
write support) on Ubuntu 16.04 with Docker (current LTS) I'm using the the
travis.yml of the 2.1_gcc5.2_sanitize coverage branch as a guide since that
seems to be the closest environment to 16.04.


I try to maintain my notes on compiling the FileGDB driver on the GDAL 
wiki at https://trac.osgeo.org/gdal/wiki/FileGDB  It would be great if 
you could add to those notes, by adding a section for Docker steps 
directly in the wiki.  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] test

[Joe Lee]

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

Re: [gdal-dev] Error Compiling GDAL with ESRI FileGeodatabase Support On Ubuntu 16.04

[Even Rouault]

Andrew,

Remove
CXX="g++ -std=c++14" CPPFLAGS="-DMAKE_SANITIZE_HAPPY -fsanitize=undefined -
fsanitize=address" LDFLAGS="-fsanitize=undefined -fsanitize=address" 

from the configure.

They are not intended for production use. More specifically the FGDB SDK 
doesn't like compiling with C++11 or 14.

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Error Compiling GDAL with ESRI FileGeodatabase Support On Ubuntu 16.04

[Andrew Joseph]

I'm not able to compile GDAL with the ESRI FileGeodatabase driver (needed for
write support) on Ubuntu 16.04 with Docker (current LTS) I'm using the the
travis.yml of the 2.1_gcc5.2_sanitize coverage branch as a guide since that
seems to be the closest environment to 16.04.

However, during GDAL make, I received the following soul-destroying error
when attempting to compile using the standard build-essential package (see 
GIS StackExchange

  
post for my build commands):

In file included from /usr/local/include/FileGDBAPI.h:28:0,
 from filegdbsdk_headers.h:39,
 from ogr_fgdb.h:50,
 from FGdbDatasource.cpp:33:
/usr/local/include/GeodatabaseManagement.h:56:1: error: expected
constructor, destructor, or type conversion before '(' token
 EXT_FILEGDB_API fgdbError CreateGeodatabase(const std::wstring& path,
Geodatabase& geodatabase);
 ^
/usr/local/include/GeodatabaseManagement.h:64:1: error: expected
constructor, destructor, or type conversion before '(' token
 EXT_FILEGDB_API fgdbError OpenGeodatabase(const std::wstring& path,
Geodatabase& geodatabase);
 ^
/usr/local/include/GeodatabaseManagement.h:69:1: error: expected
constructor, destructor, or type conversion before '(' token
 EXT_FILEGDB_API fgdbError CloseGeodatabase(Geodatabase& geodatabase);
 ^
/usr/local/include/GeodatabaseManagement.h:77:1: error: expected
constructor, destructor, or type conversion before '(' token
 EXT_FILEGDB_API fgdbError DeleteGeodatabase(const std::wstring& path);
 ^
In file included from /usr/local/include/FileGDBAPI.h:29:0,
 from filegdbsdk_headers.h:39,
 from ogr_fgdb.h:50,
 from FGdbDatasource.cpp:33:
/usr/local/include/Geodatabase.h:60:23: error: expected initializer before
'Geodatabase'
 class EXT_FILEGDB_API Geodatabase
   ^
FGdbDatasource.cpp:760:1: error: expected '}' at end of input
 }
 ^
make[3]: *** [../o/FGdbDatasource.lo] Error 1



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Error-Compiling-GDAL-with-ESRI-FileGeodatabase-Support-On-Ubuntu-16-04-tp5279578.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] missing point in MultiGeometry KML file

[Greg Minshall]

Even,

thanks very much!  i should have noticed that (but, newbie).  my input
files come from an external source (but, of course, i already have a sed
script for cleaning up bits and pieces of them, so...).

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

Re: [gdal-dev] Motion: adopt RFC 63 : Sparse datasets improvements

[James Ramm]

Excellent! Really pleased this has g one through so quick

On 4 Aug 2016 6:38 p.m., "Kurt Schwehr"  wrote:

> +1 for this change.
>
> This will be awesome!
>
> On Thu, Aug 4, 2016 at 3:12 AM, Even Rouault 
> wrote:
>
>> On Thursday 04 August 2016 12:11:18 Daniele Romagnoli wrote:
>> > That's a very valuable improvement!
>> > Thanks for that.
>> >
>> > Is there any future plan to backport it into 2.x series?
>>
>> Hi Daniele,
>>
>> No, this is a new feature and it modifies the C++ ABI, so definitely not
>> appropriate for backporting into stable series.
>>
>> Even
>>
>> --
>> Spatialys - Geospatial professional services
>> http://www.spatialys.com
>> ___
>> gdal-dev mailing list
>> gdal-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>
>
>
> --
> --
> http://schwehr.org
>
> ___
> 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] Motion: adopt RFC 63 : Sparse datasets improvements

[Kurt Schwehr]

+1 for this change.

This will be awesome!

On Thu, Aug 4, 2016 at 3:12 AM, Even Rouault 
wrote:

> On Thursday 04 August 2016 12:11:18 Daniele Romagnoli wrote:
> > That's a very valuable improvement!
> > Thanks for that.
> >
> > Is there any future plan to backport it into 2.x series?
>
> Hi Daniele,
>
> No, this is a new feature and it modifies the C++ ABI, so definitely not
> appropriate for backporting into stable series.
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>



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

Re: [gdal-dev] missing point in MultiGeometry KML file

[Even Rouault]

Greg,

Your KML file is invalid. The format for  content must be 
"X1,Y1,Z1 X2,Y2,Z2...". Here the space between triplets is replaced with a 
comma, which confuses the KML reader. The LIBKML driver is a bit more tolerant 
and successfully reads the file.

Even

> hi.  i'm a newbie, trying to do some scripting which involves reading in
> a KML file and then, after some processing, writing it out again.  i had
> noticed that when running ogrinfo(1) on my input file, i wasn't seeing
> all the point of the polygon in the MultiGeometry of my KML file, but
> thought maybe that was just some form of abbreviation.  but, that
> behavior seems to explain a problem i'm running into.  so, i tried
> "ogr2ogr -f kml", and get the same behavior, my polygons are reduced to
> a single point (the initial/terminal point).
> 
> i'm curious if it's obvious what i'm doing wrong, or if this is a known
> bug, or...
> 
> my set up is a Mac running Fink:
> 
> bash greg-minshalls-mbp-2: {1773} ogr2ogr --version
> GDAL 2.1.1, released 2016/07/07
> 
> bash greg-minshalls-mbp-2: {1774} uname -a
> Darwin greg-minshalls-mbp-2.local 15.6.0 Darwin Kernel Version 15.6.0: Thu
> Jun 23 18:25:34 PDT 2016; root:xnu-3248.60.10~1/RELEASE_X86_64 x86_64
> 
> bash greg-minshalls-mbp-2: {1775} fink --version
> Package manager version: 0.39.3
> Distribution version: selfupdate-rsync Sat Jul 30 10:25:32 2016, 10.11,
> x86_64 Trees: local/main stable/main local/injected
> 
> Copyright (c) 2001 Christoph Pfisterer
> Copyright (c) 2001-2016 The Fink Package Manager Team
> This program is distributed in the hope that it will be useful,
> but WITHOUT ANY WARRANTY; without even the implied warranty of
> MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> GNU General Public License for more details.
> 
> 
> a fairly reduced test case is running "ogr2ogr -f kml clone.kml bug.kml"
> where "bug.kml" is:
> 
> 
> http://www.opengis.net/kml/2.2;>
>   
> Soberanes
> 
>   
>   
>  
> ffff0 ll>
> -121.8595
> 39607243,36.4458603356853,0,-121.859010098152,36.4456932276546,0,-121.858129
> 504875,36.4453991811578,0,-121.857325735135,36.4448820131963,0,-121.85675971
> 936,36.4445384607921,0,-121.856809120566,36.443876500306,0,-121.856430592837
> ,36.4429020177187,0,-121.856167728728,36.4423261178737,0,-121.855775934253,3
> 6.4418654654089,0,-121.855094715237,36.4418565756417,0,-121.854381527851,36.
> 4413356919538,0,-121.853600655401,36.441184259,0,-121.852822068116,36.44
> 10692737567,0,-121.852532048225,36.4410353302927,0,-121.851959423457,36.4403
> 344818693,0,-121.85201799593,36.4398188037771,0,-121.85285513667,36.43941805
> 73464,0,-121.85328948567,36.4391070481673,0,-121.853289093379,36.43837378995
> 67,0,,-121.827771447749,36.3590241926845,0,-121.827662452176,36.358704030767
> 7,0,-121.827882572315,36.3582984116496,0,-121.828496319454,36.358129295858,0
> ,-121.82929464932,36.3580608917042,0,-121.829555373568,36.3579419054821,0 oordi nates>
> 
> 
> 
> 
> 
> thanks in advance for any clues.
> 
> Greg Minshall
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Help regarding DXF format interpretation

[Avyav Kumar]

Hi all,

I am a student who is participating under the GSoC program, and I need the
help of the community! https://trac.osgeo.org/gdal/ticket/6246 contains an
issue that I aim to resolve. However, reading the DXF format is a
difficulty (for me). I don't understand how the indexing corresponding to
codes 71, 72 etc. works for each vertex instance.
If a vertex contains the index X (for instance) under code 71, does it mean
that the said vertex is part of the POLYLINE corresponding to the index X
(in short, all the vertices of index X under code 71 are part of the same
POLYLINE)? Or have I misinterpreted the reading?

If anyone has correct answers/documentation, I would really appreciate it.

Many thanks!

Regards,

Avyav
___
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)

[Jeff McKenna]

On 2016-08-04 11:07 AM, Mateusz Loskot wrote:


1. makegdal_gen 10.00 32 > makegdal10.vcproj
2. Launch VS2015
3. File > Open > Project/Solution...
4. Select makegdal10.vcproj
5. Accept to upgrade





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


-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] missing point in MultiGeometry KML file

[Greg Minshall]

hi.  i'm a newbie, trying to do some scripting which involves reading in
a KML file and then, after some processing, writing it out again.  i had
noticed that when running ogrinfo(1) on my input file, i wasn't seeing
all the point of the polygon in the MultiGeometry of my KML file, but
thought maybe that was just some form of abbreviation.  but, that
behavior seems to explain a problem i'm running into.  so, i tried
"ogr2ogr -f kml", and get the same behavior, my polygons are reduced to
a single point (the initial/terminal point).

i'm curious if it's obvious what i'm doing wrong, or if this is a known
bug, or...

my set up is a Mac running Fink:

bash greg-minshalls-mbp-2: {1773} ogr2ogr --version
GDAL 2.1.1, released 2016/07/07

bash greg-minshalls-mbp-2: {1774} uname -a
Darwin greg-minshalls-mbp-2.local 15.6.0 Darwin Kernel Version 15.6.0: Thu Jun 
23 18:25:34 PDT 2016; root:xnu-3248.60.10~1/RELEASE_X86_64 x86_64

bash greg-minshalls-mbp-2: {1775} fink --version
Package manager version: 0.39.3
Distribution version: selfupdate-rsync Sat Jul 30 10:25:32 2016, 10.11, x86_64
Trees: local/main stable/main local/injected

Copyright (c) 2001 Christoph Pfisterer
Copyright (c) 2001-2016 The Fink Package Manager Team
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.


a fairly reduced test case is running "ogr2ogr -f kml clone.kml bug.kml"
where "bug.kml" is:


http://www.opengis.net/kml/2.2;>
  
Soberanes

  
  
  
ffff0
  
-121.859539607243,36.4458603356853,0,-121.859010098152,36.4456932276546,0,-121.858129504875,36.4453991811578,0,-121.857325735135,36.4448820131963,0,-121.85675971936,36.4445384607921,0,-121.856809120566,36.443876500306,0,-121.856430592837,36.4429020177187,0,-121.856167728728,36.4423261178737,0,-121.855775934253,36.4418654654089,0,-121.855094715237,36.4418565756417,0,-121.854381527851,36.4413356919538,0,-121.853600655401,36.441184259,0,-121.852822068116,36.4410692737567,0,-121.852532048225,36.4410353302927,0,-121.851959423457,36.4403344818693,0,-121.85201799593,36.4398188037771,0,-121.85285513667,36.4394180573464,0,-121.85328948567,36.4391070481673,0,-121.853289093379,36.4383737899567,0,,-121.827771447749,36.3590241926845,0,-121.827662452176,36.3587040307677,0,-121.827882572315,36.3582984116496,0,-121.828496319454,36.358129295858,0,-121.82929464932,36.3580608917042,0,-121.829555373568,36.3579419054821,0





thanks in advance for any clues.

Greg Minshall
___
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)

[M. LATTES]

Thanks Mateusz,
my mistake.I've just tried again the "makegdal_gen.bat" and you're right.I miss 
this when I tested it.
My repositories may still be usefull for those who wants to build gdal as a 
static library, 
unless it's possible too to generate a static lib with "makegdal_gen.bat"
Best regards.
Mathieu Lattes.


 

Le Jeudi 4 août 2016 14h07, Mateusz Loskot  a écrit :
 

 On 4 August 2016 at 14:00, M. LATTES  wrote:
> Hi Mateusz,
>
> yes I was aware, but it generate workspace with only the all "makefile.vc"
> in the project properties (at least when I tested it).
> I wanted to browse among the sources and headers files in the Visual Studio
> "Solution Explorer" or in the "Class View" (when debugging for example).
> I don't think that it is possible with the "makegdal_gent.bat" but maybe I'm
> wrong ?


AFAIR, it does create "Source Files" and "Header Files" groups
with sources attached.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net


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

Re: [gdal-dev] ogrinfo not a C callable function?

[Paul Meems]

Hi Even,

Thanks for the clarification.
We will update our code accordingly.

Regards,

Paul

*Paul Meems *
Release manager, configuration manager
and forum moderator of MapWindow GIS.
www.mapwindow.org

Owner of MapWindow.nl - Support for
Dutch speaking users.
www.mapwindow.nl


*The MapWindow GIS project has moved to GitHub
!*


Download the latest MapWinGIS mapping engine.


Download the latest MapWindow 5 open source desktop application.


2016-08-04 13:41 GMT+02:00 Even Rouault :

> On Thursday 04 August 2016 13:25:19 Paul Meems wrote:
> > Hi,
> >
> > When I look at RFC 59.1 (
> > https://trac.osgeo.org/gdal/wiki/rfc59.1_utilities_as_a_library) I see
> > gdalinfo,exe, ogr2ogr.exe are all C callable functions now.
> >
> > But I don't see ogrinfo?
> > Do I understand it right that ogrinfo.exe is not a C callable function?
>
> Yes
>
> > If so is there a specific reason for that or will it be implemented in
> the
> > near future?
>
> The most uses of ogrinfo output features in the console with the
> DumpFeature()
> call, which doesn't make sense for a library function, so a librarified
> version
> would just address the metadata part. Which you can easily access through
> the
> C/C++ API already.
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
>
___
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)

[Mateusz Loskot]

On 4 August 2016 at 15:41, Ivan Lucena  wrote:
> Hi Mateusz,
>
> I far as I know the project generated by makegdal_gen.bat does not work with 
> newer version of VS.
>
> It used to be the case that we can import the project to newer version of VS 
> but I think that MS dropped the support for that feature.
>
> Have one of you manage to load the generated .vcproj into VS > 2010? I would 
> like to know how to do that!

Ivan,

1. makegdal_gen 10.00 32 > makegdal10.vcproj
2. Launch VS2015
3. File > Open > Project/Solution...
4. Select makegdal10.vcproj
5. Accept to upgrade

I can confirm it works for me.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
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)

[Ivan Lucena]

Hi Mateusz,

I far as I know the project generated by makegdal_gen.bat does not work with 
newer version of VS. 

It used to be the case that we can import the project to newer version of VS 
but I think that MS dropped the support for that feature.

Have one of you manage to load the generated .vcproj into VS > 2010? I would 
like to know how to do that!

Best regards,
Ivan


> On Aug 4, 2016, at 8:08 AM, Mateusz Loskot  wrote:
> 
>> On 4 August 2016 at 14:00, M. LATTES  wrote:
>> Hi Mateusz,
>> 
>> yes I was aware, but it generate workspace with only the all "makefile.vc"
>> in the project properties (at least when I tested it).
>> I wanted to browse among the sources and headers files in the Visual Studio
>> "Solution Explorer" or in the "Class View" (when debugging for example).
>> I don't think that it is possible with the "makegdal_gent.bat" but maybe I'm
>> wrong ?
> 
> 
> AFAIR, it does create "Source Files" and "Header Files" groups
> with sources attached.
> 
> Best regards,
> -- 
> Mateusz Loskot, http://mateusz.loskot.net
> ___
> 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] Release of a GDAL 2.0.x and 2.1.x Visual Studio 2010 Solution (static and dynamic lib)

[Mateusz Loskot]

On 4 August 2016 at 14:00, M. LATTES  wrote:
> Hi Mateusz,
>
> yes I was aware, but it generate workspace with only the all "makefile.vc"
> in the project properties (at least when I tested it).
> I wanted to browse among the sources and headers files in the Visual Studio
> "Solution Explorer" or in the "Class View" (when debugging for example).
> I don't think that it is possible with the "makegdal_gent.bat" but maybe I'm
> wrong ?


AFAIR, it does create "Source Files" and "Header Files" groups
with sources attached.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
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)

[M. LATTES]

Hi Mateusz,
yes I was aware, but it generate workspace with only the all "makefile.vc" in 
the project properties (at least when I tested it).I wanted to browse among the 
sources and headers files in the Visual Studio "Solution Explorer" or in the 
"Class View" (when debugging for example).I don't think that it is possible 
with the "makegdal_gent.bat" but maybe I'm wrong ?
Best regards.

Mathieu Lattes
 

Le Jeudi 4 août 2016 12h51, Mateusz Loskot  a écrit :
 

 On 4 August 2016 at 12:02, M. LATTES  wrote:
> Hi Everybody,
>
> for some Visual Studio 2010 projects I've made a few time ago, I needed to
> update the GDAL lib that I was using into those projects to the GDAL version
> 2.
> I could make it with the GDAL Visual Studio Makefile projects as described
> in the wiki, but I like to have the "full project" with all the sources.
>
> As I was not able to find one online, and as I read that the GDAL team
> did'nt intented to provide one I decided to make it myself.
>
> I'm releasing it publicly, so feel free to download it and use it if you
> think it could help you.
>
> You can find the repositories here :
>
> GDAL 2.0.3 : https://github.com/MattLatt/GDAL_2.0.x_VC
> GDAL 2.1.1 : https://github.com/MattLatt/GDAL_2.1.x_VC

You might not be aware, but there is a script that can generate VS projects:

https://svn.osgeo.org/gdal/trunk/gdal/makegdal_gen.bat

It does it in non-intrusive manner to build configuration
as it uses the official makefiles.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net


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

Re: [gdal-dev] ogrinfo not a C callable function?

[Even Rouault]

On Thursday 04 August 2016 13:25:19 Paul Meems wrote:
> Hi,
> 
> When I look at RFC 59.1 (
> https://trac.osgeo.org/gdal/wiki/rfc59.1_utilities_as_a_library) I see
> gdalinfo,exe, ogr2ogr.exe are all C callable functions now.
> 
> But I don't see ogrinfo?
> Do I understand it right that ogrinfo.exe is not a C callable function?

Yes

> If so is there a specific reason for that or will it be implemented in the
> near future?

The most uses of ogrinfo output features in the console with the DumpFeature() 
call, which doesn't make sense for a library function, so a librarified version 
would just address the metadata part. Which you can easily access through the 
C/C++ API already.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] ogrinfo not a C callable function?

[Paul Meems]

Hi,

When I look at RFC 59.1 (
https://trac.osgeo.org/gdal/wiki/rfc59.1_utilities_as_a_library) I see
gdalinfo,exe, ogr2ogr.exe are all C callable functions now.

But I don't see ogrinfo?
Do I understand it right that ogrinfo.exe is not a C callable function?
If so is there a specific reason for that or will it be implemented in the
near future?

I ask this because we use these functions in MapWinGIS (
https://github.com/MapWindow) and we are now in the process to change our
implementation to the new C callable functions.

Thanks,

Paul
___
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)

[Mateusz Loskot]

On 4 August 2016 at 12:02, M. LATTES  wrote:
> Hi Everybody,
>
> for some Visual Studio 2010 projects I've made a few time ago, I needed to
> update the GDAL lib that I was using into those projects to the GDAL version
> 2.
> I could make it with the GDAL Visual Studio Makefile projects as described
> in the wiki, but I like to have the "full project" with all the sources.
>
> As I was not able to find one online, and as I read that the GDAL team
> did'nt intented to provide one I decided to make it myself.
>
> I'm releasing it publicly, so feel free to download it and use it if you
> think it could help you.
>
> You can find the repositories here :
>
> GDAL 2.0.3 : https://github.com/MattLatt/GDAL_2.0.x_VC
> GDAL 2.1.1 : https://github.com/MattLatt/GDAL_2.1.x_VC

You might not be aware, but there is a script that can generate VS projects:

https://svn.osgeo.org/gdal/trunk/gdal/makegdal_gen.bat

It does it in non-intrusive manner to build configuration
as it uses the official makefiles.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: adopt RFC 63 : Sparse datasets improvements

[Daniele Romagnoli]

That's a very valuable improvement!
Thanks for that.

Is there any future plan to backport it into 2.x series?
Regards,
Daniele


On Thu, Aug 4, 2016 at 12:03 PM, Even Rouault 
wrote:

> On Tuesday 26 July 2016 17:00:51 Even Rouault wrote:
> > Hi,
> >
> > I move to adopt RFC 63 : Sparse datasets improvements
> >
> > https://trac.osgeo.org/gdal/wiki/rfc63_sparse_datasets_improvements
> >
> > ---
> >
> > Starting with my +1
>
> I declare this motion passed with +1 from DanielM and myself. The work has
> just been committed into trunk.
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev




-- 
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:  +39 0584 1660272

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

---

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.



The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility  for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: adopt RFC 63 : Sparse datasets improvements

[Even Rouault]

On Tuesday 26 July 2016 17:00:51 Even Rouault wrote:
> Hi,
> 
> I move to adopt RFC 63 : Sparse datasets improvements
> 
> https://trac.osgeo.org/gdal/wiki/rfc63_sparse_datasets_improvements
> 
> ---
> 
> Starting with my +1

I declare this motion passed with +1 from DanielM and myself. The work has 
just been committed into trunk.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

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

[M. LATTES]

Hi Everybody,
for some Visual Studio 2010 projects I've made a few time ago, I needed to 
update the GDAL lib that I was using into those projects to the GDAL version 
2.I could make it with the GDAL Visual Studio Makefile projects as described in 
the wiki, but I like to have the "full project" with all the sources.

As I was not able to find one online, and as I read that the GDAL team did'nt 
intented to provide one I decided to make it myself.
I'm releasing it publicly, so feel free to download it and use it if you think 
it could help you.

You can find the repositories here :
GDAL 2.0.3 : https://github.com/MattLatt/GDAL_2.0.x_VCGDAL 2.1.1 : 
https://github.com/MattLatt/GDAL_2.1.x_VC

There is both dynamic lib project (aka dll) and static lib project and each one 
is configured for both x64 and x86 platform. I've kept the gdal source package 
almost as downloaded in a separate folder (see the readme file for the two 
slight modification).You can find it in the folder "gdal-2.y.z" of each 
repository.

All the Visual Studio 2010 workspaces are in the "libgdal-2.y.z" folder of each 
repository
All the 3rd part drivers libraries linked to the VC10 workspaces are in the 
"3rdpart" folder.In the "master" branches the following drivers are provided 
(curl, ecw, expat, geos, proj.4 and sqlite).For some there is just binaries 
(dll and lib) and for some there is a Visual Studio workspace.
I started with the GDAL 2.0.2 and 2.1.0 version so there is also a branch with 
the previous GDAL version for each repositories, but they will not be updated 
with new drivers.

I'v also made test projects (2 linking GDAL dynamically and 2 statically) for 
testing purpose. 3 are GDAL Utilities app and the last one is a very simple 
GDAL Drivers capabilities dump.
I intend to update those repositories with the latest GDAL releases.

So I hope it'll be usefull for someone.

Mathieu Lattes

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