Re: [gdal-dev] SRS of the Elastic Search geometries?

> > Probably that's it, the explicit SRS. I started with data that have native > SRS epsg:3067 and OpenJUMP JML format which has no means for holding SRS. > Conversion into ES gives always an empty layer, just the schema gets > inserted but no geometries, even is I use -s_srs and -t_srs. > >

[gdal-dev] gdal_polygonize.py not running

Hi, I am using the GISInternals “release-1800-x64-gdal-1-11-1-mapserver-6-4-1” and I run the SDKShell.bat. Then I tried running the gdal_polygonize.py as is and I got the following message: -

Re: [gdal-dev] hdf5 dataset. Header data too long. Truncated

On Tue, Sep 1, 2015 at 5:08 PM, Even Rouault wrote: > Le mardi 01 septembre 2015 16:50:32, Rashad M a écrit : > > Hello all, > > > > I have an the following warning from gdal when reading .h5 dataset > > > > Warning 2: Header data too long. Truncated. > > > > Looking

[gdal-dev] Problem with GDALWarp

Dear Dr. Brad/all, Thanks for your kind and prompt reply. Below are my answers/clarifications. It may also be said that the program stops execution just after the 'operation->Initialize(WO)' step. Can someone help me solve this problem. On Wed, 19 Aug 2015 04:01:32 PM user gdal wrote: Dear

Re: [gdal-dev] SRS of the Elastic Search geometries?

> I made a test and it appears to work but isn't is confusing because it > makes a different effect than with most other drivers? Manual page > http://www.gdal.org/ogr2ogr.html tells "-a_srs srs_def: Assign an > output SRS " . With Elastic Search if you use -a_srs epsg:3067 the output > SRS

Re: [gdal-dev] SRS of the Elastic Search geometries?

Even Rouault wrote: >> >> Probably that's it, the explicit SRS. I started with data that have native >> SRS epsg:3067 and OpenJUMP JML format which has no means for holding SRS. >> Conversion into ES gives always an empty layer, just the schema gets >> inserted but no geometries, even is I use

Re: [gdal-dev] Call for discussion on RFC 59 (v2): GDAL/OGR utilities as a library

On 01.09.2015 16:34, Even Rouault wrote: 2) Variant of 1). With some Python magic on **kwargs it can be automated to redirect on 1) mem_ds = gdal.Translate('', src_ds, bands = [1,2,3], format = 'MEM', progress = my_progress_method) * Other binding languages. - Perl: apparently possible

Re: [gdal-dev] SRS of the Elastic Search geometries?

Even Rouault spatialys.com> writes: > > Hi Jukka, > > but I can still save for example > > EPSG:3067 geometries without transforming them into EPSG:4326. > > On-the-fly reprojection should occur normally (provided that your source layer > has explicit SRS) Probably that's it, the explicit

Re: [gdal-dev] hdf5 dataset. Header data too long. Truncated

Le mardi 01 septembre 2015 16:50:32, Rashad M a écrit : > Hello all, > > I have an the following warning from gdal when reading .h5 dataset > > Warning 2: Header data too long. Truncated. > > Looking at frmts/hdf5/hdf5dataset.cpp there is a define for > MAX_METADATA_LEN > > #define

Re: [gdal-dev] Call for discussion on RFC 59 (v2): GDAL/OGR utilities as a library

http://www.keittlab.org/ On Tue, Sep 1, 2015 at 8:34 AM, Even Rouault wrote: > Folks, > > I'd wish we can find a solution that satisfy all parties. Here's another > iteration for a possible proposition. > > * C API: > > Principles : > - dataset objects can be passed

[gdal-dev] hdf5 dataset. Header data too long. Truncated

Hello all, I have an the following warning from gdal when reading .h5 dataset Warning 2: Header data too long. Truncated. Looking at frmts/hdf5/hdf5dataset.cpp there is a define for MAX_METADATA_LEN #define MAX_METADATA_LEN 32768 and there is a check if( CPLStrlcat(szValue,

Re: [gdal-dev] SRS of the Elastic Search geometries?

Hi Jukka, > Are the geometries which are stored into Elastic Search supposed to be in > EPSG:4326? That's my understanding of ES doc. For geo_point mapping, you can put arbitrary coordinates if I remember, but I believe the behaviour is undefined. So basically the driver is reprojecting

[gdal-dev] SRS of the Elastic Search geometries?

Hi, Are the geometries which are stored into Elastic Search supposed to be in EPSG:4326? Now I can see that the driver is writing EPSG:4326 definitions into the metadata of the ES index but I can still save for example EPSG:3067 geometries without transforming them into EPSG:4326. -Jukka

Re: [gdal-dev] Call for discussion on RFC 59 (v2): GDAL/OGR utilities as a library

Folks, I'd wish we can find a solution that satisfy all parties. Here's another iteration for a possible proposition. * C API: Principles : - dataset objects can be passed - the option structure is opaque (should address Frank's concern about exposing too much internal stuff) - the option

Re: [gdal-dev] Call for discussion on RFC 59 (v2): GDAL/OGR utilities as a library

> > In an ideal world, I would prefer a nice clean algorithms library that is > orthogonal to the command line and parsing. The utilities then simply > consist of parsing and calling this library. I would also prefer the > library to be broken down in to a set of orthogonal lower-level primitives