Re: [gdal-dev] vector VRT: Warning 1: Line 2: Attribute value should be single or double quoted.

VRT is an XML file, and to be valid XML all attribute values in the VRT need to be quoted. e.g In your VRT, your relativeToVRT attribute value is not quoted. Change to Luke -- View this message in context: http://osgeo-org.1560.x6.nabble.com/vector-VRT-Warning-1-Line-2-Attribute-value-

Re: [gdal-dev] error parsing metadata from HDF5 dataset

On Thu, Sep 3, 2015 at 5:41 PM, Even Rouault wrote: > > Sure. The patch is for 1.11 branch. Should I generate the same for trunk > > also? > > Yes please > > > > > As we are on the subject of metadata in hdf5 dataset, there is Header > too > > long. .. Truncated warning appearing when type is d

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

increasing the limit of MAX_METADATA_LEN is acceptable? On Tue, Sep 1, 2015 at 8:07 PM, Rashad M wrote: > > > 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 wh

Re: [gdal-dev] problem with datatype in python

On 3 September 2015 at 17:42, Even Rouault wrote: > Le jeudi 03 septembre 2015 17:34:27, Luca Delucchi a écrit : >> target_ds = gdal.GetDriverByName('MEM').Create('', xcount, ycount, >> gdal.GDT_UInt32) > > You should add ,1, between ycount and gdal.GDT_UInt32. This is the band count. > Thanks a

Re: [gdal-dev] problem with datatype in python

Le jeudi 03 septembre 2015 17:34:27, Luca Delucchi a écrit : > Hi devs, > > I'm trying to rasterize a vector layer and convert it to numpy array. > I'm using the gdal.RasterizeLayer function but I have problem to set > the right datatype. I would like to have UInt32 but I got every time > Byte, th

Re: [gdal-dev] error parsing metadata from HDF5 dataset

> Sure. The patch is for 1.11 branch. Should I generate the same for trunk > also? Yes please > > As we are on the subject of metadata in hdf5 dataset, there is Header too > long. .. Truncated warning appearing when type is double which now has > format specifier as %.16g > > using simply %g

Re: [gdal-dev] How to deal with IIP image via WMS minidriver?

Le jeudi 03 septembre 2015 17:17:58, Carlo A. Bertelli (Charta s.r.l.) a écrit : > Hello, > > is there a way -- maybe using the WMS minidriver -- to open an IIP streamed > picture? > The online service is well documented ( > http://iipimage.sourceforge.net/documentation/) but unfortunately it sho

[gdal-dev] problem with datatype in python

Hi devs, I'm trying to rasterize a vector layer and convert it to numpy array. I'm using the gdal.RasterizeLayer function but I have problem to set the right datatype. I would like to have UInt32 but I got every time Byte, this is my code target_ds = gdal.GetDriverByName('MEM').Create('', xcount,

Re: [gdal-dev] error parsing metadata from HDF5 dataset

Hello Even, On Thu, Sep 3, 2015 at 5:13 PM, Even Rouault wrote: > Le jeudi 03 septembre 2015 16:58:34, Rashad M a écrit : > > Hello all, > > > > I have an problem when reading metadata information of HDF5 dataset. some > > of the values are not parsed properly by GDAL. Below is the relevant part

[gdal-dev] How to deal with IIP image via WMS minidriver?

Hello, is there a way -- maybe using the WMS minidriver -- to open an IIP streamed picture? The online service is well documented ( http://iipimage.sourceforge.net/documentation/) but unfortunately it shows that the protocol is not at all compliant with the WMTS or TMS or Google/SlippyMap schemas,

Re: [gdal-dev] error parsing metadata from HDF5 dataset

Le jeudi 03 septembre 2015 16:58:34, Rashad M a écrit : > Hello all, > > I have an problem when reading metadata information of HDF5 dataset. some > of the values are not parsed properly by GDAL. Below is the relevant part > of output from gdalinfo > > > > Azimuth_Processing_Number_of_Loo

[gdal-dev] error parsing metadata from HDF5 dataset

Hello all, I have an problem when reading metadata information of HDF5 dataset. some of the values are not parsed properly by GDAL. Below is the relevant part of output from gdalinfo Azimuth_Processing_Number_of_Looks= Bits_per_Sample= S01_B001_Azimuth_Ramp_Code= Sam

Re: [gdal-dev] Store also native geometry into Elastic Search?

Le jeudi 03 septembre 2015 15:04:13, Adam Estrada a écrit : > Even, > > This would have been around version 0.16.x. Not really sure which one > exactly but I don't think any changes to the geometry support happened > until 2012-2013? Ah sorry, my fault for embedding you in a thread with a dedicat

Re: [gdal-dev] Store also native geometry into Elastic Search?

Even, This would have been around version 0.16.x. Not really sure which one exactly but I don't think any changes to the geometry support happened until 2012-2013? VERY cool about all the modifications you guys have made! This is very exciting! http://gdal.org/drv_elasticsearch.html Adam On Th

Re: [gdal-dev] Store also native geometry into Elastic Search?

Le jeudi 03 septembre 2015 14:47:16, Adam Estrada a écrit : > Even, > > I think the reason to store everything by default was just to be on > the safe side and it satisfied some of the project requirements at the > time. That was back in 2011 so ElasticSearch and this driver are > probably not in

Re: [gdal-dev] Store also native geometry into Elastic Search?

Even, I think the reason to store everything by default was just to be on the safe side and it satisfied some of the project requirements at the time. That was back in 2011 so ElasticSearch and this driver are probably not in sync any longer. There is a lot of work that can be done to the driver t

Re: [gdal-dev] Store also native geometry into Elastic Search?

Le jeudi 03 septembre 2015 12:49:30, Jukka Rahkonen a écrit : > Hi, > > What if somebody would like to put and deliver some official spatial data > (cadastral data) which are not in EPSG:4326 with Elastic Search? Could it > be possible to translate the geometries into EPSG:4326 and store and index

[gdal-dev] Store also native geometry into Elastic Search?

Hi, What if somebody would like to put and deliver some official spatial data (cadastral data) which are not in EPSG:4326 with Elastic Search? Could it be possible to translate the geometries into EPSG:4326 and store and index them as geo_shape, but also keep the native geometries and save them in

Re: [gdal-dev] gdalwarp different results (vrt vs direct)

Stefan, > We have a lot of aerial images. Each image has a size of 8000x8000 pixels > and the resolution is 12.5cm/pixel (-> 1 sqkm). They form a mosaic w/o any > gaps and overlaps. For transforming them into a new reference frame I'm > creating an vrt first and then using gdalwarp for the transfo

Re: [gdal-dev] The histogram results from a vrt datsource when the rasters are partially overlapped

Le jeudi 03 septembre 2015 09:03:29, Andrea Peri a écrit : > Hi, > I have a VRT datasource, with more raster inside. > Each raster is partially overlapped to the two near rasters. > > My dubt is how the histogram retrieved using the API GetDefaultHistogram, > is counting the overlapping. > > Infa

[gdal-dev] gdalwarp different results (vrt vs direct)

Hi We have a lot of aerial images. Each image has a size of 8000x8000 pixels and the resolution is 12.5cm/pixel (-> 1 sqkm). They form a mosaic w/o any gaps and overlaps. For transforming them into a new reference frame I'm creating an vrt first and then using gdalwarp for the transformation (in a

[gdal-dev] The histogram results from a vrt datsource when the rasters are partially overlapped

Hi, I have a VRT datasource, with more raster inside. Each raster is partially overlapped to the two near rasters. My dubt is how the histogram retrieved using the API GetDefaultHistogram, is counting the overlapping. Infact the overlapping portin is more NULL values, but also there is portion f