Re: [gdal-dev] WCS: Unable to export GeoTIFF files with zero bands

2021-10-25 Thread Even Rouault 

Jukka,

The source code was useful to figure out why BandCount was reset to 0 in 
the cache :-) So it is related to the fact that there is an extra time 
dimension, and such extra dimensions must be specified according to 
https://gdal.org/drivers/raster/wcs.html#range-and-dimension-subsetting


Adding   -oo Subset="time(1985-12-31T00:00:00.000Z)" for example solves 
the issue


It would be nice to have some warning message though. Might be worth a 
ticket


Even

Le 25/10/2021 à 22:51, Rahkonen Jukka (MML) a écrit :


Hi,

I do not understand what could be wrong with this WCS. With direct WCS 
2.0.1 requests everything works fine.


GetCapabilities:

https://beta-karttakuva.maanmittauslaitos.fi/wcs/service/ows?service=WCS=2.0.1=GetCapabilities 



DescribeCoverage:

https://beta-karttakuva.maanmittauslaitos.fi/wcs/service/ows?service=WCS=2.0.1=DescribeCoverage=ortokuva__ortokuva 



This is listing DataRecord with three fields: red band, green band, 
and blue band.


GetCoverage:

https://beta-karttakuva.maanmittauslaitos.fi/wcs/service/ows?service=WCS=2.0.1=GetCoverage=ortokuva__ortokuva=E(393450,393650)=N(7495450,7495650)=image/tiff 



This sends a tiff file.

With GDAL:

gdalinfo -oo CLEAR_CACHE 
"WCS:https://beta-karttakuva.maanmittauslaitos.fi/wcs/service/ows?;


I get the subdatasets.

gdalinfo 
"WCS:https://beta-karttakuva.maanmittauslaitos.fi/wcs/service/ows?version=2.0.1=ortokuva__ortokuva;


Looks good but I am not sure what I should expect to see.

gdal_translate -projwin 393450 7495650 393650 7495450 
 "WCS:https://beta-karttakuva.maanmittauslaitos.fi/wcs/service/ows?version=2.0.1=ortokuva__ortokuva; 
wcs.tif


This gives an error:

Input file size is 1348357, 2316500

ERROR 1: wcs.tif: Unable to export GeoTIFF files with zero bands.

I can indeed see at the end of the automatically generated XML file 
that the band count is interpreted to be zero:


…

E,N

61254.6580619824,6623749.72946716

735433.573091962,7782000.0

i,j

,,

0

image/tiff

…

I tried to edit the band count into 3 by hand, but GDAL is changing it 
back to zero.


The example from the WCS driver page 
https://gdal.org/drivers/raster/wcs.html 
 that  is using the very 
same server and coverage does save an image even there is no 
fundamental difference in the command.


gdal_translate -oo CACHE=wcs_cache -oo CLEAR_CACHE -oo 
INTERLEAVE=PIXEL -projwin 377418 6683393.87938218 377717.879386966 
6683094 -oo Subset="time(1985-01-01T00:00:00.000Z)" -outsize 60 0 
"WCS:https://beta-karttakuva.maanmittauslaitos.fi/wcs/service/ows?version=2.0.1=ortokuva__ortokuva; 
scaled.tiff


I am using GDAL version is 3.4.0dev from yesterday.

-Jukka Rahkonen-


___
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] WCS: Unable to export GeoTIFF files with zero bands

2021-10-25 Thread Rahkonen Jukka (MML) 
Hi,

I do not understand what could be wrong with this WCS. With direct WCS 2.0.1 
requests everything works fine.

GetCapabilities:
https://beta-karttakuva.maanmittauslaitos.fi/wcs/service/ows?service=WCS=2.0.1=GetCapabilities
DescribeCoverage:
https://beta-karttakuva.maanmittauslaitos.fi/wcs/service/ows?service=WCS=2.0.1=DescribeCoverage=ortokuva__ortokuva
This is listing DataRecord with three fields: red band, green band, and blue 
band.
GetCoverage:
https://beta-karttakuva.maanmittauslaitos.fi/wcs/service/ows?service=WCS=2.0.1=GetCoverage=ortokuva__ortokuva=E(393450,393650)=N(7495450,7495650)=image/tiff
This sends a tiff file.


With GDAL:
gdalinfo -oo CLEAR_CACHE 
"WCS:https://beta-karttakuva.maanmittauslaitos.fi/wcs/service/ows?;
I get the subdatasets.

gdalinfo 
"WCS:https://beta-karttakuva.maanmittauslaitos.fi/wcs/service/ows?version=2.0.1=ortokuva__ortokuva;
Looks good but I am not sure what I should expect to see.

gdal_translate -projwin 393450 7495650 393650 7495450   
"WCS:https://beta-karttakuva.maanmittauslaitos.fi/wcs/service/ows?version=2.0.1=ortokuva__ortokuva;
 wcs.tif
This gives an error:
Input file size is 1348357, 2316500
ERROR 1: wcs.tif: Unable to export GeoTIFF files with zero bands.

I can indeed see at the end of the automatically generated XML file that the 
band count is interpreted to be zero:
...
E,N
  61254.6580619824,6623749.72946716
  735433.573091962,7782000.0
  i,j
  ,,
  0
  image/tiff
...
I tried to edit the band count into 3 by hand, but GDAL is changing it back to 
zero.

The example from the WCS driver page https://gdal.org/drivers/raster/wcs.html 
that  is using the very same server and coverage does save an image even there 
is no fundamental difference in the command.
gdal_translate -oo CACHE=wcs_cache -oo CLEAR_CACHE -oo INTERLEAVE=PIXEL 
-projwin 377418 6683393.87938218 377717.879386966 6683094  -oo 
Subset="time(1985-01-01T00:00:00.000Z)" -outsize 60 0 
"WCS:https://beta-karttakuva.maanmittauslaitos.fi/wcs/service/ows?version=2.0.1=ortokuva__ortokuva;
 scaled.tiff

I am using GDAL version is 3.4.0dev from yesterday.

-Jukka Rahkonen-

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

Re: [gdal-dev] gdallocationinfo + WCS question...

2021-10-25 Thread Rahkonen Jukka (MML) 
Hi,

Thanks for testing and sending the results back for the community.

-Jukka Rahkonen-

Lähettäjä: gdal-dev  Puolesta Carl Godkin
Lähetetty: maanantai 25. lokakuuta 2021 18.37
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: Re: [gdal-dev] gdallocationinfo + WCS question...

Hi,

I just built GDAL 3.3.3 RC1 here on Windows with VS2019 and  PROJ 8.1.1 and it 
built easily.

I retried the gdallocationinfo queries that I was having trouble with 
beforehand (with 3.3.1) and both the USGS National Map and my local WCS server 
queries now return the expected values.  I know others had tested the fix Even 
mentioned but I wanted to try it myself.

Thanks again for the explanation and the fix,
carl

On Thu, Oct 21, 2021 at 2:00 PM Carl Godkin 
mailto:cgod...@gmail.com>> wrote:
Thanks, Even.

That makes sense.  (Finally!)  I can wait a little bit to come back to this so 
I'll either build 3.3 HEAD on my own or await the next release.

It's great that this isn't a random server load thing or something!

The weird result on my own WCS server also seemed to be caused by a bad "xmin" 
value which is how I started down this road.

Thanks again,

carl




On Thu, Oct 21, 2021 at 1:49 PM Even Rouault 
mailto:even.roua...@spatialys.com>> wrote:


Le 21/10/2021 à 22:32, Rahkonen Jukka (MML) a écrit :
Hi Even,

You are right, re-running the request -oo clear_cache gives me the same error 
about 3 bands. Obviously our server was configured right when I used it with 
GDAL last time. Now gdallocationinfo does not work even for me because I wiped 
the working configuration from my cache. We will fix the service metadata when 
we go from beta to official soon.

The nationalmap.gov service does not still work for me. 
I cleared the cache but I still get a 404 error from the server. Subsets in the 
reques are these
SUBSET=x(-20037507.067213,-13590403.131594259)=y(5303978.1067894027,5304490.1067842878)

The xmin value in the request you get is obviously wrong. The subset I get with 
GDAL master and head of 3.3 branch is:

SUBSET=x%(-13591427.131584032,-13590403.131594259)=y(5303978.1067894027,5304490.1067842878)

I suspect you might use a GDAL release version, that hasn't yet received the 
following recent fix that is likely related to that issue and will be in 3.3.3 
and 3.4.0:

https://github.com/OSGeo/gdal/commit/8af67b64371c275a3770e75da1bd0d4bb7329295

(I get the same error as you with the 3.2 branch, so I strongly suspect the 
above is indeed the fix for that)

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] gdallocationinfo + WCS question...

2021-10-25 Thread Carl Godkin 
Hi,

I just built GDAL 3.3.3 RC1 here on Windows with VS2019 and  PROJ 8.1.1 and
it built easily.

I retried the gdallocationinfo queries that I was having trouble with
beforehand (with 3.3.1) and both the USGS National Map and my local WCS
server queries now return the expected values.  I know others had tested
the fix Even mentioned but I wanted to try it myself.

Thanks again for the explanation and the fix,
carl

On Thu, Oct 21, 2021 at 2:00 PM Carl Godkin  wrote:

> Thanks, Even.
>
> That makes sense.  (Finally!)  I can wait a little bit to come back to
> this so I'll either build 3.3 HEAD on my own or await the next release.
>
> It's great that this isn't a random server load thing or something!
>
> The weird result on my own WCS server also seemed to be caused by a bad
> "xmin" value which is how I started down this road.
>
> Thanks again,
>
> carl
>
>
>
>
> On Thu, Oct 21, 2021 at 1:49 PM Even Rouault 
> wrote:
>
>>
>> Le 21/10/2021 à 22:32, Rahkonen Jukka (MML) a écrit :
>>
>> Hi Even,
>>
>>
>>
>> You are right, re-running the request -oo clear_cache gives me the same
>> error about 3 bands. Obviously our server was configured right when I used
>> it with GDAL last time. Now gdallocationinfo does not work even for me
>> because I wiped the working configuration from my cache. We will fix the
>> service metadata when we go from beta to official soon.
>>
>>
>>
>> The nationalmap.gov service does not still work for me. I cleared the
>> cache but I still get a 404 error from the server. Subsets in the reques
>> are these
>>
>> SUBSET=x(-20037507.067213,-13590403.131594259)=y(5303978.1067894027,5304490.1067842878)
>>
>> The xmin value in the request you get is obviously wrong. The subset I
>> get with GDAL master and head of 3.3 branch is:
>>
>>
>> SUBSET=x%(-13591427.131584032,-13590403.131594259)=y(5303978.1067894027,5304490.1067842878)
>>
>> I suspect you might use a GDAL release version, that hasn't yet received
>> the following recent fix that is likely related to that issue and will be
>> in 3.3.3 and 3.4.0:
>>
>>
>> https://github.com/OSGeo/gdal/commit/8af67b64371c275a3770e75da1bd0d4bb7329295
>>
>> (I get the same error as you with the 3.2 branch, so I strongly suspect
>> the above is indeed the fix for that)
>>
>> 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] GDAL 3.3.3 RC1 available, and imminent tree reorganization in master

2021-10-25 Thread Even Rouault 

Hi,

I have prepared a GDAL/OGR 3.3.3 release candidate.

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

  https://download.osgeo.org/gdal/3.3.3/gdal-3.3.3rc1.tar.xz
  https://download.osgeo.org/gdal/3.3.3/gdal-3.3.3rc1.tar.gz
  https://download.osgeo.org/gdal/3.3.3/gdal333rc1.zip

A snapshot of the gdalautotest suite is also available :

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

GDAL-GRASS plugin:

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

The NEWS file is here :

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

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



Other topic:  the release/3.4 branch (with RC1 to be created from it 
next week) has now been created and master is thus open for 3.5dev


As I mentioned last week, https://github.com/OSGeo/gdal/pull/4663 
contains the initial import of the cmake4gdal repository and follow-up 
improvements. It also contains a move of the gdal/ subdirectory to the 
top level directory. I plan to merge this very soon, so please speak up 
now if there are concerns.


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] GDAL ConfigOptions

2021-10-25 Thread Even Rouault 


Le 25/10/2021 à 14:25, azat.nurgal...@dlr.de a écrit :

Hello everyone,

I am working on optimizing a GDAL application that uses RasterIO and GeoTiff.
I am using the C++ library.

I would like to experiment with different ConfigOptions, but they have no 
effect on the application.
I specify them in an environment variable and directly in the code.

I am especially interested in GTIFF_DIRECT_IO.

I use blktrace I/O trace to check.
It traces all I/O operations, and through it I see that the application sends 
"RA" operations, which means readahead.
The readahed operations only happen when buffered I/O is enabled, and readahead 
operations should no longer happen when direct I/O is enabled.


That's not what GTIFF_DIRECT_IO does. It "just" bypasses libtiff and the 
GDAL block cache (when possible). But it uses the regular GDAL I/O, 
which means buffered I/O (fread() calls). Using unbuffered reads would 
probably have only a marginal effect (but maybe not ? this is left to 
the reader as an exercise :-))


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] GDAL ConfigOptions

2021-10-25 Thread Azat.Nurgaliev 
Hello everyone,

I am working on optimizing a GDAL application that uses RasterIO and GeoTiff.
I am using the C++ library.

I would like to experiment with different ConfigOptions, but they have no 
effect on the application.
I specify them in an environment variable and directly in the code.

I am especially interested in GTIFF_DIRECT_IO.

I use blktrace I/O trace to check.
It traces all I/O operations, and through it I see that the application sends 
"RA" operations, which means readahead.
The readahed operations only happen when buffered I/O is enabled, and readahead 
operations should no longer happen when direct I/O is enabled.

Could you please help me with the correct use of ConfigOptions?

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