Re: [gdal-dev] Motion: request 2000 USD from OSGeo for GDAL

2020-01-10 Thread Tamas Szekeres
+1

Tamas

Even Rouault  ezt írta (időpont: 2020. jan.
10., P, 18:43):

> Hi,
>
> Motion: the GDAL project requests to OSGeo a 2000 USD budget for 2020
>
> ~
>
> +1
>
> 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 mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: request 2000 USD from OSGeo for GDAL

2020-01-10 Thread jratike80
+1

-Jukka Rahkonen-


Even Rouault-2 wrote
> Hi,
> 
> Motion: the GDAL project requests to OSGeo a 2000 USD budget for 2020
> 
> ~
> 
> +1
> 
> Even
> 
> -- 
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> ___





--
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: request 2000 USD from OSGeo for GDAL

2020-01-10 Thread Norman Barker
+1 normanb

On Fri, Jan 10, 2020 at 11:43 AM Even Rouault 
wrote:

> Hi,
>
> Motion: the GDAL project requests to OSGeo a 2000 USD budget for 2020
>
> ~
>
> +1
>
> 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 mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: request 2000 USD from OSGeo for GDAL

2020-01-10 Thread Daniel Morissette

+1

Daniel

On 2020-01-10 12:43, Kurt Schwehr wrote:

+1 KurtS

On Fri, Jan 10, 2020 at 9:43 AM Even Rouault > wrote:


Hi,

Motion: the GDAL project requests to OSGeo a 2000 USD budget for 2020

~

+1

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 mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev




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

Re: [gdal-dev] Motion: request 2000 USD from OSGeo for GDAL

2020-01-10 Thread Mateusz Loskot
+1

Mateusz

On Fri, 10 Jan 2020 at 18:43, Even Rouault  wrote:
> Hi,
>
> Motion: the GDAL project requests to OSGeo a 2000 USD budget for 2020
>
> ~
>
> +1
>
> 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



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

Re: [gdal-dev] Motion: request 2000 USD from OSGeo for GDAL

2020-01-10 Thread Kurt Schwehr
+1 KurtS

On Fri, Jan 10, 2020 at 9:43 AM Even Rouault 
wrote:

> Hi,
>
> Motion: the GDAL project requests to OSGeo a 2000 USD budget for 2020
>
> ~
>
> +1
>
> 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 mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Motion: request 2000 USD from OSGeo for GDAL

2020-01-10 Thread Even Rouault
Hi,

Motion: the GDAL project requests to OSGeo a 2000 USD budget for 2020

~

+1

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] XLS file can't be opened with gdal 3

2020-01-10 Thread Even Rouault
On vendredi 10 janvier 2020 10:21:52 CET Frédéric Trastour wrote:
> Hi Tobias,
> 
> Yes, gdal is linked against FreeXL 1.0.5 – and reports support for XLS.
> 
> Note that some other XLS files can be used without problem.
> This one, which is included in out test suite doesn’t.

Same FreeXL version in your 2 GDAL builds ?
Looking quickly at the diff on the GDAL side in the ogr/ogrsf_frmts/xls, the 
changes seem to be purely cosmetic.

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] Why COG does not support predictor=3?

2020-01-10 Thread Even Rouault
Jukka,

> The cloud optimized GeoTIFF generator has a creation option PREDICTOR=YES
> that is Boolean. Tiffinfo reveals that it means that predictor=2 is used
> "Predictor: horizontal differencing 2 (0x2)". However, for floating point
> images predictor=3 could give much better compression. In a quick test with
> regular GeoTIFFs the difference between predictor=2 and predictor=3 was 218
> kB vs. 148 kB. The difference when using no predictor at all vs.
> predictor=2 was much less, only 227 kB vs. 218 kB.  Is there some special
> reason for dropping the predictor=3 support from COG?

Adressed by
https://github.com/OSGeo/gdal/commit/0c520d04d17669499cbbfc3c2d87258144263947

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] GDAL python bindings memory usage

2020-01-10 Thread Evert Etienne (SITEMARK)
I actually have no idea what the extra code in your examples is doing, can you 
explain?

For the behavior: it is the same as psutil (makes sense since memory_profiler 
uses psutil by default). You can see it reach max cache by logging psutil 
values in the Translate callback. I also saw the same behavior by looking at 
the memory usage using top.

Is there another way you know that works that I can try to see if I can 
replicate the memory usage values?

Thank you

> On 27 Dec 2019, at 21:45, Even Rouault  wrote:
> 
> I question the reliability of memory_profiler
> 
> See
> 
> Line #Mem usageIncrement   Line Contents
> 
>27  112.125 MiB  112.125 MiB   @profile
>28 def test2():
>29  112.676 MiB0.551 MiB   gdal.SetCacheMax(1000 * 1024 * 1024)
>30 1101.855 MiB  989.180 MiB   gdal.Translate('/tmp/out.tif', 
> 'byte.tif', options = '-co TILED=YES -outsize 10 1')
>31 1101.855 MiB0.000 MiB   dummy = 1
> 
> vs
> 
> Line #Mem usageIncrement   Line Contents
> 
>28  109.336 MiB  109.336 MiB   @profile
>29 def test2():
>30  109.336 MiB0.000 MiB   gdal.SetCacheMax(1000 * 1024 * 1024)
>31 1098.309 MiB  988.973 MiB   gdal.Translate('/tmp/out.tif', 
> 'byte.tif', options = '-co TILED=YES -outsize 10 1')
>32 1098.309 MiB0.000 MiB   h = ctypes.cdll.LoadLibrary(None)
>33 1098.309 MiB0.000 MiB   h.malloc.argtypes = [ctypes.c_size_t]
>34 1098.309 MiB0.000 MiB   h.malloc.restype = ctypes.c_void_p
>35 1098.309 MiB0.000 MiB   h.free.argtypes = [ctypes.c_void_p]
>36 1098.309 MiB0.000 MiB   h.free.restype = None
>37 1098.309 MiB0.000 MiB   size = 1024 * 1024
>38 1098.309 MiB0.000 MiB   x = h.malloc(size)
>39  117.422 MiB0.000 MiB   h.free(x)
>40  117.422 MiB0.000 MiB   dummy = 1
> 
> vs
> 
> Line #Mem usageIncrement   Line Contents
> 
>28  111.305 MiB  111.305 MiB   @profile
>29 def test2():
>30  111.852 MiB0.547 MiB   gdal.SetCacheMax(1000 * 1024 * 1024)
>31  188.504 MiB   76.652 MiB   gdal.Translate('/tmp/out.tif', 
> 'byte.tif', options = '-co TILED=YES -outsize 10 1')
>32  188.504 MiB0.000 MiB   h = ctypes.cdll.LoadLibrary(None)
>33  188.504 MiB0.000 MiB   h.free.argtypes = [ctypes.c_void_p]
>34  188.504 MiB0.000 MiB   h.free.restype = None
>35  188.504 MiB0.000 MiB   h.free(None)
>36  188.504 MiB0.000 MiB   dummy = 1
> 
> vs
> 
> Line #Mem usageIncrement   Line Contents
> 
>28  112.164 MiB  112.164 MiB   @profile
>29 def test2():
>30  112.164 MiB0.000 MiB   gdal.SetCacheMax(1000 * 1024 * 1024)
>31  112.770 MiB0.605 MiB   h = ctypes.cdll.LoadLibrary(None)
>32  112.770 MiB0.000 MiB   h.free.argtypes = [ctypes.c_void_p]
>33  112.770 MiB0.000 MiB   h.free.restype = None
>34 1101.918 MiB  989.148 MiB   gdal.Translate('/tmp/out.tif', 
> 'byte.tif', options = '-co TILED=YES -outsize 10 1')
>35 1101.918 MiB0.000 MiB   h.free(None)
>36 1101.918 MiB0.000 MiB   dummy = 1
> 
> That doesn't make much sense to me.
> 
> Even
> 
> -- 
> Spatialys - Geospatial professional services
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.spatialys.comdata=01%7C01%7Cevert.etienne%40sitemark.com%7C39f1fc8e39b14a21169d08d78b0da8ab%7Cfc89adff07ac47008853b7b7e906068e%7C0sdata=Mg1ztmCAuQnlKkFq3Ny00bE%2BfmzljlV0cWVRrYyU8PQ%3Dreserved=0

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

Re: [gdal-dev] XLS file can't be opened with gdal 3

2020-01-10 Thread Tobias Wendorff
Hey,

Am Fr, 10.01.2020, 10:58 schrieb Frédéric Trastour:
>
> It works fine with the older version but can't be read with the new new
> one.

XLS support is based on FreeXL

Did you link it against it and installed the library?

Best regards,
Tobias

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

[gdal-dev] RE : XLS file can't be opened with gdal 3

2020-01-10 Thread Frédéric Trastour
Hi Tobias,

Yes, gdal is linked against FreeXL 1.0.5 – and reports support for XLS.

Note that some other XLS files can be used without problem.
This one, which is included in out test suite doesn’t.

BR,
Fred.

Provenance : Courrier pour 
Windows 10


De : Tobias Wendorff 
Envoyé : Friday, January 10, 2020 11:17:56 AM
À : "Frédéric Trastour" 
Cc : gdal-dev@lists.osgeo.org 
Objet : Re: [gdal-dev] XLS file can't be opened with gdal 3

Hey,

Am Fr, 10.01.2020, 10:58 schrieb Frédéric Trastour:
>
> It works fine with the older version but can't be read with the new new
> one.

XLS support is based on FreeXL

Did you link it against it and installed the library?

Best regards,
Tobias

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

[gdal-dev] XLS file can't be opened with gdal 3

2020-01-10 Thread Frédéric Trastour
Hi all,
porting an application from gdal 2.2 to gdal 3.0, I'm facing a regression 
problem with an XLS file.
It works fine with the older version but can't be read with the new new one.

Here are the details : https://pastebin.com/QxWqDG4y.
I'm wondering there is any known possible regression in this driver ?
Best regards,
Fred.



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

[gdal-dev] Why COG does not support predictor=3?

2020-01-10 Thread Rahkonen Jukka (MML)
Hi,

The cloud optimized GeoTIFF generator has a creation option PREDICTOR=YES that 
is Boolean. Tiffinfo reveals that it means that predictor=2 is used "Predictor: 
horizontal differencing 2 (0x2)". However, for floating point images 
predictor=3 could give much better compression. In a quick test with regular 
GeoTIFFs the difference between predictor=2 and predictor=3 was 218 kB vs. 148 
kB. The difference when using no predictor at all vs. predictor=2 was much 
less, only 227 kB vs. 218 kB.  Is there some special reason for dropping the 
predictor=3 support from COG?

-Jukka Rahkonen-


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