date:20210427

Re: [gdal-dev] PROJ context and threads

2021-04-27 Thread Alan Snow

By default pyproj uses the autoclose option and provides this option for
users who want better performance and know they have a single threaded
application: https://pyproj4.github.io/pyproj/stable/api/global_context.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] PROJ context and threads

2021-04-27 Thread Alan Snow

You are correct. Here is the related issue:
https://github.com/OSGeo/PROJ/issues/1565

The solution would be to use proj_context_set_autoclose_database. This can
reduce performance for single threaded applications, so it would probably
be good to have a way to toggle it on for multi-threaded applications.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 3.3.0 RC1 available

2021-04-27 Thread Sean Gillies

Hi Even,

I see that there's also a 3.2.3 candidate. Usually we discontinue the
previous minor version, right? Why in this case are we have a 3.3.0rc1 and
a 3.2.3rc1?

On Mon, Apr 26, 2021 at 6:57 AM Even Rouault 
wrote:

> Hi,
>
> I have prepared a GDAL/OGR 3.3.0 release candidate. The feedback on beta1
> was useful to spot and fix a few bugs.
>
> The changes between beta1 and RC1 are identified in:
>
> https://github.com/OSGeo/gdal/commit/a882173d688e6042c9dc7b1b57d8d169b04abe2b
> Note a potential impact on packaging recipees regarding a few esoteric
> untested/undocumented python scripts,
> now moved as "samples" scripts of the gdal-utils package
>
> Pick up an archive among the following ones (by ascending size):
>
>https://download.osgeo.org/gdal/3.3.0/gdal-3.3.0rc1.tar.xz
>https://download.osgeo.org/gdal/3.3.0/gdal-3.3.0rc1.tar.gz
>https://download.osgeo.org/gdal/3.3.0/gdal330rc1.zip
>
> A snapshot of the gdalautotest suite is also available :
>
>https://download.osgeo.org/gdal/3.3.0/gdalautotest-3.3.0rc1.tar.gz
>https://download.osgeo.org/gdal/3.3.0/gdalautotest-3.3.0rc1.zip
>
> A snapshot of the documentation is at:
>
>https://download.osgeo.org/gdal/3.3.0/gdal330doc.zip
>
> GDAL-GRASS plugin:
>
>https://download.osgeo.org/gdal/3.3.0/gdal-grass-3.3.0.tar.gz
>
> NEWS at:
>
>https://github.com/OSGeo/gdal/blob/v3.3.0RC1/gdal/NEWS
>
> I'll call for a vote promoting it to final later this week if no
> serious problems are reported before.
>
> release/3.3 branch has been created for bug fixes and master is now
> 3.4.0dev
>
> Best regards,
>
> Even
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>


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

Re: [gdal-dev] Nitf Metadata parsing

2021-04-27 Thread Matthew Baran

Hi,

Please note that the DES related PR was merged after the 3.2 release -
hence no 3.2.x packages will have the xml:DES metadata domain or the DES
related objects.

To access the xml:DES metadata domain you will either have to build the
source code from the current master branch, or use the nightly docker
build, or wait for 3.3 packages to be released.

If you use the latest source from master you do not need to enable the
ESRI_BUILD flag to access DESs.  You can simply use
GDALDataset::GetMetadata() or command line as Brad demonstrated - no
special build settings required.

Hope that helps-

Matt

On Tue, Apr 27, 2021 at 9:02 PM jovajova24  wrote:

> Brad, sorry for pushing but I'm going in circles here. It looks like you
> and
> Even had this discussion i.e.,
>
> http://osgeo-org.1560.x6.nabble.com/gdal-dev-Accessing-DES-in-NITF-through-GDAL-td5434141.html
>
> You gave me the example of how to output the DES's  from the command line,
> but the builds I'm pulling can't actually get access to the DES data on
> Windows.
>
> Was your build that you showed the output from above complied with the
> ESRI_NITF flagged as Even suggested?
>
> If yes, I can't figure out how to set the ESRI_NITF build flagged, any
> thoughts?
>
> Thanks again.
>
>
>
>
>
> --
> 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
>

-- 
Matthew S. Baran
matthewsba...@gmail.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] PROJ context and threads

2021-04-27 Thread Andrew Bell

Hi,

I have a process with a large thread pool. The threads occasionally make a
GDAL call that in turn calls a PROJ function. From what I can tell, this
causes the opening of a PROJ context that holds a handle/descriptor to the
PROJ database. I believe that this file descriptor is held open in TLS
until the thread is destroyed. This ends up keeping enough files open for
my application that I run out of file descriptors.

Am I properly understanding the PROJ context behavior? Is there any way to
force the deallocation of the PROJ context so that the file descriptor for
the database can be closed?

Thanks,

-- 
Andrew Bell
andrew.bell...@gmail.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Nitf Metadata parsing

2021-04-27 Thread jovajova24

Brad, sorry for pushing but I'm going in circles here. It looks like you and
Even had this discussion i.e., 
http://osgeo-org.1560.x6.nabble.com/gdal-dev-Accessing-DES-in-NITF-through-GDAL-td5434141.html

You gave me the example of how to output the DES's  from the command line,
but the builds I'm pulling can't actually get access to the DES data on
Windows. 

Was your build that you showed the output from above complied with the
ESRI_NITF flagged as Even suggested? 

If yes, I can't figure out how to set the ESRI_NITF build flagged, any
thoughts?

Thanks again.





--
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] Test Failures

2021-04-27 Thread Even Rouault



Le 27/04/2021 à 20:49, Andrew Bell a écrit :



On Tue, Apr 27, 2021 at 2:27 PM Even Rouault 
mailto:even.roua...@spatialys.com>> wrote:


Andrew,

This could be due to the PROJ version, but as I'm running with 8.0
too (and one of the CI config runs PROJ master), I suspect you
just need to install the "conus" grid for NAD27 to WGS84
transformations into {proj_prefix}/share/proj . Unpack
http://download.osgeo.org/proj/proj-datumgrid-1.8.tar.gz


I have PROJ_NETWORK set to ON. I was under the impression that this 
would cause PROJ to find whatever grids shift files it needed at 
runtime. Is there more configuration that's necessary to get this to 
happen or do I misunderstand the PROJ_NETWORK setting?


That should be fine. Actually I was wrong. This test case doesn't 
involve any datum shift / grids as it is EPSG:4326 to EPSG:3857 
reprojection.


That might then just be a subtle different rounding issue in 
computations in GDAL and/or PROJ, or more likely, due to using a 
different JPEG library as this test case involves JPEG compression. If 
that was the case, you might add your checksums as an alternative 
expected output. We do that in a number of places.


Looking a few lines before the failure, I actually see that the CI got 
that issue and we worked around it with:


    if sys.platform == 'darwin' and gdal.GetConfigOption('TRAVIS', 
None) is not None:

    assert got_cs != [0, 0, 0]
    else:

Could you run

gdal_translate ../autotest/gdrivers/data/small_world.tif out.tif -of COG 
co TILING_SCHEME=GoogleMapsCompatible -co COMPRESS=JPEG


and attach the resulting file ?



Thanks,
--
Andrew Bell
andrew.bell...@gmail.com 


--
http://www.spatialys.com
My software is free, but my time generally not.

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

Re: [gdal-dev] Test Failures

2021-04-27 Thread Andrew Bell

On Tue, Apr 27, 2021 at 2:27 PM Even Rouault 
wrote:

> Andrew,
>
> This could be due to the PROJ version, but as I'm running with 8.0 too
> (and one of the CI config runs PROJ master), I suspect you just need to
> install the "conus" grid for NAD27 to WGS84 transformations into
> {proj_prefix}/share/proj . Unpack
> http://download.osgeo.org/proj/proj-datumgrid-1.8.tar.gz
>
I have PROJ_NETWORK set to ON. I was under the impression that this would
cause PROJ to find whatever grids shift files it needed at runtime. Is
there more configuration that's necessary to get this to happen or do I
misunderstand the PROJ_NETWORK setting?

Thanks,

-- 
Andrew Bell
andrew.bell...@gmail.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] very slow sql ogr2ogr conversion

2021-04-27 Thread Neil Walker

Hello,

First time user, I hope this is the right mailing list :)



I have a fairly small (37mb - 160,000 linestrings) shp file and it loads
into QGIS in a couple of seconds. I want to import this into sql server, so
used the following ogr2ogr command:



ogr2ogr -f "MSSQLSpatial"
"MSSQL:server=myserver;database=mydatabase;Trusted_Connection=True;"
"NZ_RoadLink.shp" -a_srs "EPSG:27700" -nln "neilshape" -progress -lco
UPLOAD_GEOM_FORMAT=wkt



It's UK Ordnance Survey open roads data if anyone is interested. After 40
minutes it got to 3% complete then I gave up.


So I instead saved it as a CSV and it took about 1 minute, I then imported
this CSV into sql server and that took 1 minute too.



I then ran the following command and it worked ok too after a few seconds,
I don't know if it's right or not but looks ok...



alter table add geom GEOMETRY

update table set geom=replace(wkt,'Z','')



So, can anyone let me know what could be causing this massive slowdown
because my database connection is fast and there are no network issues. I
have tried using all the available sql server drivers (SQL Server, default
ODBC) but it's still this slow. I actually also have 'sql server native
11.0' but ogr2ogr refused to use this.


If nobody has a clue can you confirm if my removal of 'Z' in this command
is ok or what a better way is?


Also, I don't know if it's just the way it is but I kept getting 'invalid
database object mydatabase' until I entered the UPLOAD_GEOM_FORMAT=wkt
parameter. Clearly 'mydatabase' has nothing to do with the error...


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

Re: [gdal-dev] Test Failures

2021-04-27 Thread Even Rouault


Andrew,

This could be due to the PROJ version, but as I'm running with 8.0 too 
(and one of the CI config runs PROJ master), I suspect you just need to 
install the "conus" grid for NAD27 to WGS84 transformations into 
{proj_prefix}/share/proj . Unpack 
http://download.osgeo.org/proj/proj-datumgrid-1.8.tar.gz


Even

Le 27/04/2021 à 20:17, Andrew Bell a écrit :

Hi,

I'm having a few test failures with gdal master on OSX. They seem 
related to transformations. I notice that the CI build is using PROJ 
7.1. I'm linking PROJ 8.0. An example failure follows. Can this be 
explained by PROJ versions or are there other issues that I might need 
to investigate?


==

>           assert got_cs == [26293, 23439, 14955]
E           assert [26228, 22085, 12992] == [26293, 23439, 14955]
E             At index 0 diff: 26228 != 26293
E             Use -v to get the full diff

/Users/acbell/gdal/autotest/gcore/cog.py:392: AssertionError
--- Captured stderr call 
---

ERROR 1: PROJ: webmerc: Invalid latitude
ERROR 1: PROJ: webmerc: Invalid latitude
ERROR 1: PROJ: webmerc: Invalid latitude

--
Andrew Bell
andrew.bell...@gmail.com 

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


--
http://www.spatialys.com
My software is free, but my time generally not.

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

[gdal-dev] Test Failures

2021-04-27 Thread Andrew Bell

Hi,

I'm having a few test failures with gdal master on OSX. They seem related
to transformations. I notice that the CI build is using PROJ 7.1. I'm
linking PROJ 8.0. An example failure follows. Can this be explained by PROJ
versions or are there other issues that I might need to investigate?

==

>   assert got_cs == [26293, 23439, 14955]
E   assert [26228, 22085, 12992] == [26293, 23439, 14955]
E At index 0 diff: 26228 != 26293
E Use -v to get the full diff

/Users/acbell/gdal/autotest/gcore/cog.py:392: AssertionError
--- Captured stderr call
---
ERROR 1: PROJ: webmerc: Invalid latitude
ERROR 1: PROJ: webmerc: Invalid latitude
ERROR 1: PROJ: webmerc: Invalid latitude

-- 
Andrew Bell
andrew.bell...@gmail.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 3.3.0 RC1 available

2021-04-27 Thread Idan Miara

I can confirm that these scripts are indeed the samples that were moved,
Plus the arg_parser.py improvements file.


On Tue, 27 Apr 2021, 20:20 Greg Troxel,  wrote:

>
> I updated from beta1 to rc1.  The transform issue appears fixed.
>
> In building python builds, I saw a large number of differences from my
> beta1 build and my rc1 build.  I think this is the "esoteric scripts"
> cleanup, but if antyhing in this diff seems off, let me know.
>
> --- PLIST.beta  2021-04-25 11:01:56.864454375 -0400
> +++ PLIST   2021-04-27 13:15:14.169682455 -0400
> @@ -2,4 +1,0 @@
> -bin/epsg_tr.py
> -bin/esri2wkt.py
> -bin/gcps2vec.py
> -bin/gcps2wld.py
> @@ -8 +3,0 @@
> -bin/gdal_auth.py
> @@ -19 +13,0 @@
> -bin/gdalchksum.py
> @@ -21,2 +14,0 @@
> -bin/gdalident.py
> -bin/gdalimport.py
> @@ -24 +15,0 @@
> -bin/mkgraticule.py
> @@ -71,0 +63,2 @@
> +${PYSITELIB}/osgeo_utils/auxiliary/gdal_argparse.py
> +${PYSITELIB}/osgeo_utils/auxiliary/gdal_argparse.pyc
> @@ -84,8 +76,0 @@
> -${PYSITELIB}/osgeo_utils/epsg_tr.py
> -${PYSITELIB}/osgeo_utils/epsg_tr.pyc
> -${PYSITELIB}/osgeo_utils/esri2wkt.py
> -${PYSITELIB}/osgeo_utils/esri2wkt.pyc
> -${PYSITELIB}/osgeo_utils/gcps2vec.py
> -${PYSITELIB}/osgeo_utils/gcps2vec.pyc
> -${PYSITELIB}/osgeo_utils/gcps2wld.py
> -${PYSITELIB}/osgeo_utils/gcps2wld.pyc
> @@ -96,2 +80,0 @@
> -${PYSITELIB}/osgeo_utils/gdal_auth.py
> -${PYSITELIB}/osgeo_utils/gdal_auth.pyc
> @@ -118,2 +100,0 @@
> -${PYSITELIB}/osgeo_utils/gdalchksum.py
> -${PYSITELIB}/osgeo_utils/gdalchksum.pyc
> @@ -122,4 +102,0 @@
> -${PYSITELIB}/osgeo_utils/gdalident.py
> -${PYSITELIB}/osgeo_utils/gdalident.pyc
> -${PYSITELIB}/osgeo_utils/gdalimport.py
> -${PYSITELIB}/osgeo_utils/gdalimport.pyc
> @@ -128,2 +104,0 @@
> -${PYSITELIB}/osgeo_utils/mkgraticule.py
> -${PYSITELIB}/osgeo_utils/mkgraticule.pyc
> @@ -149,0 +125,4 @@
> +${PYSITELIB}/osgeo_utils/samples/epsg_tr.py
> +${PYSITELIB}/osgeo_utils/samples/epsg_tr.pyc
> +${PYSITELIB}/osgeo_utils/samples/esri2wkt.py
> +${PYSITELIB}/osgeo_utils/samples/esri2wkt.pyc
> @@ -155,0 +135,4 @@
> +${PYSITELIB}/osgeo_utils/samples/gcps2vec.py
> +${PYSITELIB}/osgeo_utils/samples/gcps2vec.pyc
> +${PYSITELIB}/osgeo_utils/samples/gcps2wld.py
> +${PYSITELIB}/osgeo_utils/samples/gcps2wld.pyc
> @@ -157,0 +141,2 @@
> +${PYSITELIB}/osgeo_utils/samples/gdal_auth.py
> +${PYSITELIB}/osgeo_utils/samples/gdal_auth.pyc
> @@ -177,0 +163,2 @@
> +${PYSITELIB}/osgeo_utils/samples/gdalchksum.py
> +${PYSITELIB}/osgeo_utils/samples/gdalchksum.pyc
> @@ -181,0 +169,4 @@
> +${PYSITELIB}/osgeo_utils/samples/gdalident.py
> +${PYSITELIB}/osgeo_utils/samples/gdalident.pyc
> +${PYSITELIB}/osgeo_utils/samples/gdalimport.py
> +${PYSITELIB}/osgeo_utils/samples/gdalimport.pyc
> @@ -201,0 +193,2 @@
> +${PYSITELIB}/osgeo_utils/samples/mkgraticule.py
> +${PYSITELIB}/osgeo_utils/samples/mkgraticule.pyc
> ___
> 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] GDAL 3.3.0 RC1 available

2021-04-27 Thread Greg Troxel


I updated from beta1 to rc1.  The transform issue appears fixed.

In building python builds, I saw a large number of differences from my
beta1 build and my rc1 build.  I think this is the "esoteric scripts"
cleanup, but if antyhing in this diff seems off, let me know.

--- PLIST.beta  2021-04-25 11:01:56.864454375 -0400
+++ PLIST   2021-04-27 13:15:14.169682455 -0400
@@ -2,4 +1,0 @@
-bin/epsg_tr.py
-bin/esri2wkt.py
-bin/gcps2vec.py
-bin/gcps2wld.py
@@ -8 +3,0 @@
-bin/gdal_auth.py
@@ -19 +13,0 @@
-bin/gdalchksum.py
@@ -21,2 +14,0 @@
-bin/gdalident.py
-bin/gdalimport.py
@@ -24 +15,0 @@
-bin/mkgraticule.py
@@ -71,0 +63,2 @@
+${PYSITELIB}/osgeo_utils/auxiliary/gdal_argparse.py
+${PYSITELIB}/osgeo_utils/auxiliary/gdal_argparse.pyc
@@ -84,8 +76,0 @@
-${PYSITELIB}/osgeo_utils/epsg_tr.py
-${PYSITELIB}/osgeo_utils/epsg_tr.pyc
-${PYSITELIB}/osgeo_utils/esri2wkt.py
-${PYSITELIB}/osgeo_utils/esri2wkt.pyc
-${PYSITELIB}/osgeo_utils/gcps2vec.py
-${PYSITELIB}/osgeo_utils/gcps2vec.pyc
-${PYSITELIB}/osgeo_utils/gcps2wld.py
-${PYSITELIB}/osgeo_utils/gcps2wld.pyc
@@ -96,2 +80,0 @@
-${PYSITELIB}/osgeo_utils/gdal_auth.py
-${PYSITELIB}/osgeo_utils/gdal_auth.pyc
@@ -118,2 +100,0 @@
-${PYSITELIB}/osgeo_utils/gdalchksum.py
-${PYSITELIB}/osgeo_utils/gdalchksum.pyc
@@ -122,4 +102,0 @@
-${PYSITELIB}/osgeo_utils/gdalident.py
-${PYSITELIB}/osgeo_utils/gdalident.pyc
-${PYSITELIB}/osgeo_utils/gdalimport.py
-${PYSITELIB}/osgeo_utils/gdalimport.pyc
@@ -128,2 +104,0 @@
-${PYSITELIB}/osgeo_utils/mkgraticule.py
-${PYSITELIB}/osgeo_utils/mkgraticule.pyc
@@ -149,0 +125,4 @@
+${PYSITELIB}/osgeo_utils/samples/epsg_tr.py
+${PYSITELIB}/osgeo_utils/samples/epsg_tr.pyc
+${PYSITELIB}/osgeo_utils/samples/esri2wkt.py
+${PYSITELIB}/osgeo_utils/samples/esri2wkt.pyc
@@ -155,0 +135,4 @@
+${PYSITELIB}/osgeo_utils/samples/gcps2vec.py
+${PYSITELIB}/osgeo_utils/samples/gcps2vec.pyc
+${PYSITELIB}/osgeo_utils/samples/gcps2wld.py
+${PYSITELIB}/osgeo_utils/samples/gcps2wld.pyc
@@ -157,0 +141,2 @@
+${PYSITELIB}/osgeo_utils/samples/gdal_auth.py
+${PYSITELIB}/osgeo_utils/samples/gdal_auth.pyc
@@ -177,0 +163,2 @@
+${PYSITELIB}/osgeo_utils/samples/gdalchksum.py
+${PYSITELIB}/osgeo_utils/samples/gdalchksum.pyc
@@ -181,0 +169,4 @@
+${PYSITELIB}/osgeo_utils/samples/gdalident.py
+${PYSITELIB}/osgeo_utils/samples/gdalident.pyc
+${PYSITELIB}/osgeo_utils/samples/gdalimport.py
+${PYSITELIB}/osgeo_utils/samples/gdalimport.pyc
@@ -201,0 +193,2 @@
+${PYSITELIB}/osgeo_utils/samples/mkgraticule.py
+${PYSITELIB}/osgeo_utils/samples/mkgraticule.pyc


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

Re: [gdal-dev] GetAxesCount returns a wrong value

2021-04-27 Thread Javier Jimenez Shaw

Thanks Even.

In the mean time (it is not easy to me patching and rebuilding now) I will
use this helper workaround function (I hope I understood correctly GetAxis
behaviour)

int getAxesCount(const OGRSpatialReference& sr)
{
int axesCount = 0;
while (nullptr != sr.GetAxis(nullptr, axesCount, nullptr))
{
axesCount++;
}
return axesCount;
}

Cheers
.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ...  ._ .__
Entre dos pensamientos racionales
hay infinitos pensamientos irracionales.



On Mon, 26 Apr 2021 at 21:09, Even Rouault 
wrote:

>
> > Is this a know bug?
> Now, yes :-)
> > Maybe fixed in PROJ 8.0.0? (I had not time to test it there yet)
>
> No, it is GDAL specific. You'll need to patch
> OGRSpatialReference::GetAxesCount() in the ( d->m_pjType ==
> PJ_TYPE_COMPOUND_CRS ) case, to test if a component of the compound CRS
> is a bound CRS, and if so, call proj_crs_get_coordinate_system() on the
> source CRS of the bound CRS ( with proj_get_source_crs() ) and not the
> bound CRS itself
>
> Even
>
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Global min/max

2021-04-27 Thread Pierre Chatelier

I have found the GetStatistics 
() 
method of GDALRasterBand(), but I did not find any GetStatistics() 
available for the whole dataset at a glance.
While it is pretty obvious that it can be achieved by calling 
GetStatictics() for all bands and gather the results, I am concerned 
about performance.
In my case, I use an ENVI driver with BIL or BIP data interleaving. 
Calling GetStatictics() on bands will induce an overhead of data 
de-interleaving to gather band raw values, but it is a pity since I will 
process all data anyway. I would expect to benefit from memory locality.


Did I miss something ?


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

Re: [gdal-dev] [EXTERNAL] Re: vsis3 worldfile support?

2021-04-27 Thread Cechini, Matthew F. (GSFC-423.0)[Science Systems & Applications, Inc.] via gdal-dev

Ah, I found the problem. Looks like it was loading the world file, but the file 
had an error in it.  Using that CPL_VSIL… parameter helped verify that the file 
was being read:


$ gdalinfo --config CPL_VSIL_CURL_ALLOWED_EXTENSIONS ".png" 
/vsis3/bucket/prefix/test_pal.png


ERROR 4: CSLLoad2("/vsis3/bucket/prefix/test_pal.pgw") failed: unable to open 
file.

ERROR 4: CSLLoad2("/vsis3/bucket/prefix/test_pal.wld") failed: unable to open 
file.

Thanks,
Matt
.
Matthew Cechini
Contractor, Science Systems and Applications, Inc.
NASA GIBS Systems/Software Engineer
410.205.6272

From: Even Rouault 
Date: Tuesday, April 27, 2021 at 10:20 AM
To: Matthew Cechini , "gdal-dev@lists.osgeo.org" 

Subject: [EXTERNAL] Re: [gdal-dev] vsis3 worldfile support?


Matt,

I've just tested and this works for me. Can't think of a reason besides a 
permission problem with the .pgw/.wld files, or if you've set the 
CPL_VSIL_CURL_ALLOWED_EXTENSIONS configuration option to "png"

Even
Le 27/04/2021 à 16:04, Cechini, Matthew F. (GSFC-423.0)[Science Systems & 
Applications, Inc.] via gdal-dev a écrit :
Using GDAL 2.4.4, I’m attempting to read a PNG file in S3 with this prefix: 
/vsis3/bucket/prefix/image.png.  Alongside that object are also image.pgw an 
image.wld objects (same content).  When I run gdalinfo on the /vsis3 path, I’m 
not seeing the geolocation information.  Am I doing something wrong? Do I need 
a new version? Is this a known limitation?

Thanks,
Matt
.
Matthew Cechini
Contractor, Science Systems and Applications, Inc.
NASA GIBS Systems/Software Engineer
410.205.6272



___

gdal-dev mailing list

gdal-dev@lists.osgeo.org

https://lists.osgeo.org/mailman/listinfo/gdal-dev

--

http://www.spatialys.com

My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] vsis3 worldfile support?

2021-04-27 Thread Even Rouault


Matt,

I've just tested and this works for me. Can't think of a reason besides 
a permission problem with the .pgw/.wld files, or if you've set the 
CPL_VSIL_CURL_ALLOWED_EXTENSIONS configuration option to "png"


Even

Le 27/04/2021 à 16:04, Cechini, Matthew F. (GSFC-423.0)[Science Systems 
& Applications, Inc.] via gdal-dev a écrit :


Using GDAL 2.4.4, I’m attempting to read a PNG file in S3 with this 
prefix: /vsis3/bucket/prefix/image.png.  Alongside that object are 
also image.pgw an image.wld objects (same content).  When I run 
gdalinfo on the /vsis3 path, I’m not seeing the geolocation 
information.  Am I doing something wrong? Do I need a new version? Is 
this a known limitation?


Thanks,

Matt

.

Matthew Cechini

Contractor, Science Systems and Applications, Inc.

NASA GIBS Systems/Software Engineer

410.205.6272


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


--
http://www.spatialys.com
My software is free, but my time generally not.

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

[gdal-dev] vsis3 worldfile support?

2021-04-27 Thread Cechini, Matthew F. (GSFC-423.0)[Science Systems & Applications, Inc.] via gdal-dev

Using GDAL 2.4.4, I’m attempting to read a PNG file in S3 with this prefix: 
/vsis3/bucket/prefix/image.png.  Alongside that object are also image.pgw an 
image.wld objects (same content).  When I run gdalinfo on the /vsis3 path, I’m 
not seeing the geolocation information.  Am I doing something wrong? Do I need 
a new version? Is this a known limitation?

Thanks,
Matt
.
Matthew Cechini
Contractor, Science Systems and Applications, Inc.
NASA GIBS Systems/Software Engineer
410.205.6272
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] GDAL 3.2.3 RC1 available

2021-04-27 Thread Even Rouault


Hi,

I have prepared a GDAL/OGR 3.2.3 release candidate. This will be the 
last release in the 3.2 series


Pick up an archive among the following ones (by ascending size):

  https://download.osgeo.org/gdal/3.2.3/gdal-3.2.3rc1.tar.xz
  https://download.osgeo.org/gdal/3.2.3/gdal-3.2.3rc1.tar.gz
  https://download.osgeo.org/gdal/3.2.3/gdal323rc1.zip

A snapshot of the gdalautotest suite is also available :

https://download.osgeo.org/gdal/3.2.3/gdalautotest-3.2.3rc1.tar.gz
  https://download.osgeo.org/gdal/3.2.3/gdalautotest-3.2.3rc1.zip

GDAL-GRASS plugin:

  https://download.osgeo.org/gdal/3.2.3/gdal-grass-3.2.3.tar.gz

The NEWS file is here :

  https://github.com/OSGeo/gdal/blob/v3.2.3RC1/gdal/NEWS

I'll call for a vote promoting it to final later this week if no
serious problems are reported before.

Best regards,

Even

--
http://www.spatialys.com
My software is free, but my time generally not.

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

Re: [gdal-dev] PROJ context and threads

Re: [gdal-dev] PROJ context and threads

Re: [gdal-dev] GDAL 3.3.0 RC1 available

Re: [gdal-dev] Nitf Metadata parsing

[gdal-dev] PROJ context and threads

Re: [gdal-dev] Nitf Metadata parsing

Re: [gdal-dev] Test Failures

Re: [gdal-dev] Test Failures

[gdal-dev] very slow sql ogr2ogr conversion

Re: [gdal-dev] Test Failures

[gdal-dev] Test Failures

Re: [gdal-dev] GDAL 3.3.0 RC1 available

Re: [gdal-dev] GDAL 3.3.0 RC1 available

Re: [gdal-dev] GetAxesCount returns a wrong value

[gdal-dev] Global min/max

Re: [gdal-dev] [EXTERNAL] Re: vsis3 worldfile support?

Re: [gdal-dev] vsis3 worldfile support?

[gdal-dev] vsis3 worldfile support?

[gdal-dev] GDAL 3.2.3 RC1 available

19 matches

Site Navigation

Mail list logo

Footer information