[gdal-dev] GDAL 2.2 planning

2017-03-30 Thread Even Rouault
Hi,

To sum up a few scattered discussions from the beginning of the year, my 
intent is to tag a GDAL 2.2.0beta1 release on 14th April. The 2.2 branch 
will be created from that to stabilize it, and trunk will be then 2.3dev. A RC 
should likely be produced end of April if things go well.

Does that sound good ?

Even

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

Re: [gdal-dev] Building GDAL on linux with minimal drivers

2017-03-30 Thread Even Rouault
On jeudi 30 mars 2017 16:51:49 CEST Mateusz Loskot wrote:
> On 30 March 2017 at 16:48, Even Rouault  wrote:
> > On jeudi 30 mars 2017 07:34:35 CEST Kurt Schwehr wrote:
> >> At one point, I had a autoconf configure setup that was pretty minimal.
> >> 
> >> While it built, it was not so much fun to work with.  Here are some
> >> 
> >> remnants of notes that might constitute the beginnings of a
> >> 
> >> sourceme-minimal.sh.  More will likely be needed depending on libs are
> >> 
> >> already installed on your machine.  And gdal without many of these libs
> >> 
> >> (e.g. proj4, geos, libz/zlib) is just frustrating.
> > 
> > As it seems several people have needs for minimized builds, perhaps they
> > should consider upstreaming their efforts with build options (like
> > --minimal and then --with- to selectively enable drivers), and the
> > potential code refactoring that might make it easy. I think a continuous
> > integration target that would test that would be needed to ensure this
> > doesn't get broken by later developments.
> 
> BTW, I'm not sure what is wrong with the manual minimal build
> https://trac.osgeo.org/gdal/wiki/BuildingOnUnixWithMinimizedDrivers

Nothing. I also tested it successfully after you update

I think somepeople want even more minimized builds, presumably for embedded 
systems, 
without most drivers that don't depend on external libraries.

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

Re: [gdal-dev] Delete implementation of OGRMemDriver

2017-03-30 Thread Even Rouault
On jeudi 30 mars 2017 12:59:09 CEST Vautour, André (INT) wrote:
> Hi all,
> 
> We recently updated from 1.11.x to 2.1.3.
> 
> Previously, GDAL had the ODrCDeleteDataSource capability, which the
> OGRMemDriver did not handle in its TestCapability implementation. So, in
> effect, the memory driver did not support deletion, which makes sense to
> me.
> 
> From what I can tell, that capability was removed in favor of every driver
> supporting delete. My question is did, should calling Delete() on the
> OGRMemDriver with an existing file name delete the file on the file system?
> That seems to be what is happening, which is not what I would have
> expected. In our workflow, we were doing a CreateCopy to copy a source to
> the memory driver, but using the same name for the destination.
> 
> I can work around the problem by setting the QUIET_DELETE_ON_CREATE_COPY
> option, but I was wondering if delete being implemented on the memory
> driver makes sense.

The mem driver is particular in the sense that there's no filename associated 
to it (that is you 
can pass an arbitrary string on creation time, but it is just known by the 
dataset object. You 
can set empty strings to several MEM datasets and they will be different). So 
as soon as you 
close the dataset handle returned by CreateDataSource(), the resources are 
effectively 
freed. I don't think there's much difference between 1.X and 2.X for that.

Even


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

[gdal-dev] Delete implementation of OGRMemDriver

2017-03-30 Thread INT
Hi all,

We recently updated from 1.11.x to 2.1.3.

Previously, GDAL had the ODrCDeleteDataSource capability, which the 
OGRMemDriver did not handle in its TestCapability implementation. So, in 
effect, the memory driver did not support deletion, which makes sense to me.

>From what I can tell, that capability was removed in favor of every driver 
>supporting delete. My question is did, should calling Delete() on the 
>OGRMemDriver with an existing file name delete the file on the file system? 
>That seems to be what is happening, which is not what I would have expected. 
>In our workflow, we were doing a CreateCopy to copy a source to the memory 
>driver, but using the same name for the destination.

I can work around the problem by setting the QUIET_DELETE_ON_CREATE_COPY 
option, but I was wondering if delete being implemented on the memory driver 
makes sense.

Kind regards,
André
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Building GDAL on linux with minimal drivers

2017-03-30 Thread Dmitry Baryshnikov

Hi Gane,

You can try to use Cmake build of GDAL 
(https://github.com/nextgis-borsch/lib_gdal).


It can be configured via CMake-gui or command line.

This is an example of minimal static build of GDAL - 
https://github.com/nextgis/nextgis_datastore/blob/master/cmake/extlib.cmake#L94-L175


Best regards,
Dmitry

29.03.17 12:17, Gane R пишет:

Hi all,

I am looking for building gdal with minimal set of drivers like gdal 
with geotiff, jpg, png and sqlite gpkg


so it should do basic warp geotiff and work with geopkg raster. I 
don't need OGR part I need the core, alg and raster tif, gpkg, jpg and 
png alone is enought.

the problem is I get a fat static lib. I want to reduce its size.

I tried to follow the post 
https://trac.osgeo.org/gdal/wiki/BuildingOnUnixWithMinimizedDrivers It 
seems it is old.


When I build i get error during building the apps like gdalinfo, 
gdalwarp 


Any suggestions

my ogr/ogrsf_frmts/GNUmakefile  is
like

include ../../GDALmake.opt

SUBDIRS-yes:= \
generic rec shape

SUBDIRS-$(HAVE_DODS)+= dods
SUBDIRS-$(HAVE_DWGDIRECT) += dxfdwg
SUBDIRS-$(HAVE_FME)+= fme
SUBDIRS-$(HAVE_GRASS)+= grass
SUBDIRS-$(HAVE_IDB)+= idb

I get the following error

/home/user/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined 
reference to `TABINDFile::~TABINDFile()'
/home/user/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined 
reference to `TABINDFile::FindNext(int, unsigned char*)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`gdal_json_object_object_add'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`TABINDFile::Open(char const, char const, int)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`OGRMemLayer::CreateField(OGRFieldDefn*, int)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`gdal_json_object_to_file'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`MITABSpatialRef2CoordSys(OGRSpatialReference*)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`gdal_json_tokener_free'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`gdal_json_object_new_int64'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`gdal_json_object_get_string'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`OGRMemLayer::GetFeatureCount(int)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`TABINDFile::BuildKey(int, int)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`gdal_json_object_array_add'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`gdal_json_object_new_object'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`OGRXPlane_ExtendPosition(double, double, double, double, double*, 
double*)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`OGRMemLayer::SetNextByIndex(long long)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`OGRMemLayer::CreateGeomField(OGRGeomFieldDefn*, int)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`OGRMemLayer::ResetReading()'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`OGRMemLayer::ICreateFeature(OGRFeature*)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`OGRXPlane_Distance(double, double, double, double)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`TABINDFile::AddEntry(int, unsigned char*, int)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`gdal_json_object_put'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`json_object_new_double_with_precision'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`OGRMemLayer::TestCapability(char const*)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`OGRMemLayer::DeleteFeature(long long)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`gdal_json_object_new_int'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`TABINDFile::Close()'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`gdal_json_object_get_type'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`OGRMemLayer::GetNextFeature()'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`OGRMemLayer::OGRMemLayer(char const, OGRSpatialReference, 
OGRwkbGeometryType)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`TABINDFile::BuildKey(int, char const*)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`gdal_json_object_from_file'


Thanks
Gane


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


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

[gdal-dev] Antwort: [Newsletter] Building GDAL on linux with minimal drivers

2017-03-30 Thread Niels . vonFestenberg-Packisch . ext
Hi Gane, 
it might be slightly heretic, but I succeeded in a similar task by using 
GDAL version 1.11. In that version there seem to be much less 
interdependencies between the dlls under Windows, and I guess it will be 
the same under Unix. 
I found out by starting the projects without any GDAL-dlls and then adding 
them one by one until it worked (and I ended up with only two dlls). It's 
a hack, but it worked for me. 
Hope that helps.

Regards
Niels




Von:Gane R 
An: gdal-dev@lists.osgeo.org
Datum:  29.03.2017 11:17
Betreff:[Newsletter] [gdal-dev] Building GDAL on linux with 
minimal drivers
Gesendet von:   "gdal-dev" 



Hi all,

I am looking for building gdal with minimal set of drivers like gdal with 
geotiff, jpg, png and sqlite gpkg

so it should do basic warp geotiff and work with geopkg raster. I don't 
need OGR part I need the core, alg and raster tif, gpkg, jpg and png alone 
is enought.
the problem is I get a fat static lib. I want to reduce its size.

I tried to follow the post 
https://trac.osgeo.org/gdal/wiki/BuildingOnUnixWithMinimizedDrivers It 
seems it is old.

When I build i get error during building the apps like gdalinfo, gdalwarp 


Any suggestions 

my ogr/ogrsf_frmts/GNUmakefile  is 
like 

include ../../GDALmake.opt

SUBDIRS-yes:= \
generic rec shape

SUBDIRS-$(HAVE_DODS)+= dods
SUBDIRS-$(HAVE_DWGDIRECT) += dxfdwg
SUBDIRS-$(HAVE_FME)+= fme
SUBDIRS-$(HAVE_GRASS)+= grass
SUBDIRS-$(HAVE_IDB)+= idb

I get the following error

/home/user/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference 
to `TABINDFile::~TABINDFile()'
/home/user/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference 
to `TABINDFile::FindNext(int, unsigned char*)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`gdal_json_object_object_add'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`TABINDFile::Open(char const, char const, int)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`OGRMemLayer::CreateField(OGRFieldDefn*, int)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`gdal_json_object_to_file'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`MITABSpatialRef2CoordSys(OGRSpatialReference*)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`gdal_json_tokener_free'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`gdal_json_object_new_int64'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`gdal_json_object_get_string'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`OGRMemLayer::GetFeatureCount(int)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`TABINDFile::BuildKey(int, int)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`gdal_json_object_array_add'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`gdal_json_object_new_object'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`OGRXPlane_ExtendPosition(double, double, double, double, double*, 
double*)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`OGRMemLayer::SetNextByIndex(long long)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`OGRMemLayer::CreateGeomField(OGRGeomFieldDefn*, int)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`OGRMemLayer::ResetReading()'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`OGRMemLayer::ICreateFeature(OGRFeature*)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`OGRXPlane_Distance(double, double, double, double)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`TABINDFile::AddEntry(int, unsigned char*, int)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`gdal_json_object_put'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`json_object_new_double_with_precision'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`OGRMemLayer::TestCapability(char const*)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`OGRMemLayer::DeleteFeature(long long)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`gdal_json_object_new_int'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`TABINDFile::Close()'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`gdal_json_object_get_type'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`OGRMemLayer::GetNextFeature()'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`OGRMemLayer::OGRMemLayer(char const, OGRSpatialReference, 
OGRwkbGeometryType)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`TABINDFile::BuildKey(int, char const*)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 

[gdal-dev] Charachter encoding arabic

2017-03-30 Thread Ahmed Tolba
Dear All,

I'm using postgres database with OGR.
I have altered the database encoding to WIN1250 by using that statement ALTER 
DATABASE tinyows SET client_encoding=WIN1250;
OGR still can't read the fields, and I got an assertion that the characters 
don't lie in the range -1, 255
CPLValueType CPLGetValueType(const char* pszValue)
   for(; *pszValue != '\0'; pszValue++ )
{
if( isdigit( *pszValue))
{
bIsLastCharExponent = FALSE;
/* do nothing */
}

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