Re: [gdal-dev] Closing remaining open Trac tickets ?

2019-03-20 Thread Kurt Schwehr
+1

On Wed, Mar 20, 2019 at 3:28 PM Even Rouault 
wrote:

> Hi,
>
> As we have already more than 100 tickets open in github, I guess nobody no
> longer looks at old Trac tickets.
> I was wondering if we shouldn't mass close the remaining open tickets in
> Trac,
> with a message indicating that if the issue is still current, it should be
> filed on github, and assigning those tickets to a dedicated milestone
> "closed
> due to migration to github"
>
> Thoughts ?
>
> 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



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

[gdal-dev] Closing remaining open Trac tickets ?

2019-03-20 Thread Even Rouault
Hi,

As we have already more than 100 tickets open in github, I guess nobody no 
longer looks at old Trac tickets.
I was wondering if we shouldn't mass close the remaining open tickets in Trac, 
with a message indicating that if the issue is still current, it should be 
filed on github, and assigning those tickets to a dedicated milestone "closed 
due to migration to github"

Thoughts ?

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] Set gdal option at compile time

2019-03-20 Thread Armin Burger



On 20/03/2019 22:01, Even Rouault wrote:

On mercredi 20 mars 2019 21:06:21 CET Armin Burger wrote:

Dear all

is it possible to change the default value of a GDAL option at compile
time?


No
Must be done at runtime. Can be done by setting it for example as environment
variable in your batch script.

Even



Thanks for the quick reply.

When opening a file, gdal checks for various sibling files, like *.AUX,
*.aux.xml, etc. Is there a sort of configuration file that defines for
which files and file extensions gdal is searching for any file open?

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

Re: [gdal-dev] filter out wanted messages in a grib2 file

2019-03-20 Thread Zhan Zhang - NOAA Affiliate
Thanks, Even! Can gdalinfo also get all the bands info needed as 
GDALGetRasterCount() + GDALGetRasterBand() + GDALGetMetadata() + 
GDALGetDescription() ) work together?

> On Mar 19, 2019, at 12:44 PM, Even Rouault  wrote:
> 
>> On dimanche 10 mars 2019 21:19:30 CET Zhan Zhang - NOAA Affiliate wrote:
>> I have a grib2 file which contains many messages, and those messages define
>> different products on different surfaces (like z axis). For
>> instance, some messages defines "soil temperature"(product name) on a
>> surface called "depth below land surface" (surface name); and other
>> messages define "geopotential height" (product name) on a "pressure
>> surface" (surface name); etc. May I ask how I can filter out all those
>> messages that defines "soil temperature"(product name) on a surface called
>> "depth below land surface" (surface name)? Is there some grib2 tools
>> provided in gdal APIs that I can use? Thanks!
> 
> Zhan,
> 
> Multiple GRIB messages in a single file are seen by GDAL as a multi-band 
> dataset.
> So you need to iterate over the bands ( GDALGetRasterCount() + 
> GDALGetRasterBand() for the C API ) and fetch its metadata ( 
> GDALGetMetadata() 
> ) an description ( GDALGetDescription() ) to see if the band is of interest 
> for you.
> 
> The output of gdalinfo should help you understanding this
> 
> If using the Python API, you may also analyze the result of
> gdal.Info('my.grb2', format = 'json')
> which is a Python dictionary, to retrieve the band you are interested in.
> 
> Best regards,
> 
> 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] Set gdal option at compile time

2019-03-20 Thread Even Rouault
On mercredi 20 mars 2019 21:06:21 CET Armin Burger wrote:
> Dear all
> 
> is it possible to change the default value of a GDAL option at compile
> time? 

No
Must be done at runtime. Can be done by setting it for example as environment 
variable in your batch script.

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] Convert KML to Shapefile PyQGIS

2019-03-20 Thread Julierme Pinheiro
Dear Even Rouault,

I got it done. Thank you very much for your reply.

I appreciated your time

Julierme



On Tue, Mar 19, 2019 at 1:09 PM Even Rouault 
wrote:

> Julierme,
>
> the issue here is that your KML file is seen as a multi-layer dataset, with
> one feature per layer, so you can't use the logic you put below. You need
> to
> merge all the layers in a single one.
>
> You can do that with the ogrmerge.py script that comes with GDAL:
> https://www.gdal.org/ogrmerge.html
>
> $ ogrmerge.py -overwrite_ds -single -src_layer_field_name src_layer -o
> out.shp A_Cycle06.kml
>
> With released versions of the script, this will be very slow. I've just
> pushed a fix to speed that up, so grab:
>
> https://raw.githubusercontent.com/OSGeo/gdal/master/gdal/swig/python/scripts/ogrmerge.py
>
> 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] Set gdal option at compile time

2019-03-20 Thread Armin Burger

Dear all

is it possible to change the default value of a GDAL option at compile
time? I would in particular like to set the option
"GDAL_DISABLE_READDIR_ON_OPEN" to TRUE as a default since in a batch
processing environment this can cause some overload of storage systems.

Thanks in advance for any hint
Armin
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Troubles with PAM file

2019-03-20 Thread Dominique Lyszczarz
Thank you Even for these informations, that's good to know. I've added the
.aux.xml in the repository if it can be useful as reference. Finally, I got
good results with gdal_translate -gcp option following by gdalwarp. Fun
fact, in the PAM file Y image coordinates are negatives values but must be
pushed as positive number in gdal_translate command.

Le mer. 20 mars 2019 à 15:57, Even Rouault  a
écrit :

> Dominique,
> >
> > I'm trying to read a raster georeferenced with ArcGIS. It's a jpg file
> > coming with a PAM file (.aux.xml) that store GCPs and define a polynomial
> > transformation of order 3. Unfortunately GDAL does not take the PAM file
> > into account and gdalinfo does not report GCPs. After some
> investigations,
> > I found this commit
> > <
> https://github.com/OSGeo/gdal/commit/f8822eb50466fb740e228b8c6a7f066b916faa
> > 0a> that suggest PAM files are supported by GDAL but only for TIFF
> dataset.
>
> Not really. PAM files are supported for most formats, included JPEG, but
> the
> ESRI specific GCP decoding was limited for now to the GTiff format, mostly
> because of the oddity you noticed: in the case for which this was
> developed
> for
> (see https://lists.osgeo.org/pipermail/gdal-dev/2017-January/045854.html
> and
> the related email thread), pixel coordinates were indeed surprisingly in
> inches and from the bottom left origin. So I couldn't/didn't want to
> generalize that to core PAM processing.
>
> >
> > I'm a bit confused with theses PAM files, is there any technical doc from
> > ESRI?
>
> Not to my knowledge. Initially PAM was developed for GDAL itself, but it
> seems
> ESRI developed some extensions on top of it, like the one you are facing
> to.
>
> > The file can be downloaded here :
> >
> https://drive.google.com/drive/folders/1hZXncJhcfZI0Uem-oCfUsruO9mPwWD0U?usp
> > =sharing
>
> You didn't include the most interesting part, that is the .aux.xml file
> itself
>
> 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] Troubles with PAM file

2019-03-20 Thread Even Rouault
Dominique,
> 
> I'm trying to read a raster georeferenced with ArcGIS. It's a jpg file
> coming with a PAM file (.aux.xml) that store GCPs and define a polynomial
> transformation of order 3. Unfortunately GDAL does not take the PAM file
> into account and gdalinfo does not report GCPs. After some investigations,
> I found this commit
>  0a> that suggest PAM files are supported by GDAL but only for TIFF dataset.

Not really. PAM files are supported for most formats, included JPEG, but the 
ESRI specific GCP decoding was limited for now to the GTiff format, mostly 
because of the oddity you noticed: in the case for which this was developed 
for
(see https://lists.osgeo.org/pipermail/gdal-dev/2017-January/045854.html and 
the related email thread), pixel coordinates were indeed surprisingly in 
inches and from the bottom left origin. So I couldn't/didn't want to 
generalize that to core PAM processing.

> 
> I'm a bit confused with theses PAM files, is there any technical doc from
> ESRI? 

Not to my knowledge. Initially PAM was developed for GDAL itself, but it seems 
ESRI developed some extensions on top of it, like the one you are facing to.

> The file can be downloaded here :
> https://drive.google.com/drive/folders/1hZXncJhcfZI0Uem-oCfUsruO9mPwWD0U?usp
> =sharing

You didn't include the most interesting part, that is the .aux.xml file itself

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] Motion: Promote GDAL 2.4.1 rc1 for release

2019-03-20 Thread jratike80
+1

-Jukka Rahkonen-


Even Rouault-2 wrote
> Hi,
> 
> No issues were raised about this release candidate, so
> 
> ---
> 
> Motion: GDAL/OGR 2.4.1 rc1 is promoted to be the official 2.4.1 final
> release.
> 
> ---
> 
> My vote: +1
> 
> Best regards,
> 
> Even





--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: Promote GDAL 2.4.1 rc1 for release

2019-03-20 Thread Daniel Morissette

+1

Daniel

On 2019-03-20 6:40 a.m., Even Rouault wrote:

Hi,

No issues were raised about this release candidate, so

---

Motion: GDAL/OGR 2.4.1 rc1 is promoted to be the official 2.4.1 final release.

---

My vote: +1

Best regards,

Even




--
Daniel Morissette
Mapgears Inc
T: +1 418-696-5056 #201
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Motion: Promote GDAL 2.4.1 rc1 for release

2019-03-20 Thread Even Rouault
Hi,

No issues were raised about this release candidate, so

---

Motion: GDAL/OGR 2.4.1 rc1 is promoted to be the official 2.4.1 final release.

---

My vote: +1

Best regards,

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] Troubles with PAM file

2019-03-20 Thread Dominique Lyszczarz
Hi all,

I'm trying to read a raster georeferenced with ArcGIS. It's a jpg file
coming with a PAM file (.aux.xml) that store GCPs and define a polynomial
transformation of order 3. Unfortunately GDAL does not take the PAM file
into account and gdalinfo does not report GCPs. After some investigations,
I found this commit

that suggest PAM files are supported by GDAL but only for TIFF dataset. So,
I've translated my file to TIFF and now gdalinfo report the GCPs but the
file is not correctly georeferenced. Reading more carefully the commit
previously cited I can see some relevants clues : sources GPCs are
considered to be expressed in inch and so the code rely on image dpi stored
in TIFF tags to compute the pixels coordinates. Futhermore the origin of
pixels coordinates is considered to be the bottom left. I've checked my PAM
file and clearly the sources GPC are expressed directly in pixel, not inch,
with an image origin fixed to top left. I can set the dpi of my image to 1
to fix the scale but Y coordinates remains wrong.

I'm a bit confused with theses PAM files, is there any technical doc from
ESRI? My PAM file make sense for me : pixel coordinates and top left origin
(like worldfile) for sources GPC, it's seems a very common approach. But
inch !? Also is there any particular reason to limit PAM file reading to
TIFF dataset ? maybe is it related to the need to extract dpi from tags ?

For now I can't see any way to correctly read this file with GDAL, so I'm
thinking of writing my own script to parse GCPs and rectify the raster wih
gdalwarp. Not sure if it will be the best approach here, any advices?

The file can be downloaded here :
https://drive.google.com/drive/folders/1hZXncJhcfZI0Uem-oCfUsruO9mPwWD0U?usp=sharing

Thanks in advance for any feedback on this.

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

Re: [gdal-dev] gdal_rasterize and virtual rasters

2019-03-20 Thread Even Rouault
On mercredi 20 mars 2019 09:51:30 CET Guy Doulberg wrote:
> Hi guys,
> 
> I am trying my luck here,
> 
> I looked up this question in the web but no success,
> 
> Is there a file format of raster type that returns the product of
> gdal_rasterize.
> 
> I am thinking of something like a VRT file, that its attributes tell gdal
> how to run gdal_rasterize on top of vectors layers.
> 
> Then running gdalinfo, gdal_translate and any gdal raster functions work on
> that file, where the rasterization is done on the fly.
> 
> Does it make sense?

Yes, there's no such on-the-fly capability in GDAL. The closest would be to 
use your prefered WMS server (mapserver, geoserver, qgis-server etc) and 
create a GDAL WMS file from it.

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] gdal_rasterize and virtual rasters

2019-03-20 Thread Guy Doulberg
Hi guys,

I am trying my luck here,

I looked up this question in the web but no success,

Is there a file format of raster type that returns the product of
gdal_rasterize.

I am thinking of something like a VRT file, that its attributes tell gdal
how to run gdal_rasterize on top of vectors layers.

Then running gdalinfo, gdal_translate and any gdal raster functions work on
that file, where the rasterization is done on the fly.

Does it make sense?

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