Re: [gdal-dev] OSGeo.OGR.Geometry: Union the mutiple geometries at a time

[MRRAJESH]

I am referring to the below image -

 





--
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] SUMMARY RE: What is lost when converting 12 bit imagery to 8 bit?

[Matt.Wilkie]

The summary also posted to the GIS Stack Exchange thread 
https://gis.stackexchange.com/questions/390315/what-is-lost-when-converting-12-bit-imagery-to-8-bit/.

Also in the credits I neglected to include @nils-erik-jørgensen.

-Matt

From: Matt.Wilkie
Sent: March 23, 2021 4:27 PM
To: 'gdal dev' 
Subject: SUMMARY RE: [gdal-dev] What is lost when converting 12 bit imagery to 
8 bit?


The position I've moved to after reading through and thinking about all the 
responses here and gdal-dev 
(here)
 is we need to ask for both 8 & 12 bit from the vendors.

8 bit is for visual use. It can be viewed on all displays and most programs 
without modification. Since this is 90%+ of usage scenarios having them ready 
to go is definitely beneficial to us. Additionally having the processing done 
in advance by a skilled supplier will save a lot of work -- and might even be a 
better visualization than we could produce ourselves. Producing good visuals 
across scenes systematically is not trivial.

The main drawback to automated 12 to 8 bit RGB products is that they tend to be 
very suboptimal in dark or bright areas (shadows, water, snow). This is because 
the fixed white and black point anchors needed to span the scene sets can not 
account for individual scene variation.

We should also ask imagery suppliers to describe their bit-reduction process. 
This will allow us to determine how it affects our application.

In audio terms, its a bit like cutting either the bass or the treble - what is 
best for you depends on what you want to do with the music afterwards.

  *   8 bits allows numbers from 0 to 255 (2 to the power of 8 values)
  *   12 bits allows numbers from 0 to 4095 (2 to the power of 12 values)

The simplest way conversion from 12 to 8 bits is setting the last four to zero, 
and the remaining bits shifted right four places. Its like rounding decimals to 
the nearest 100 or 1000.

What's lost is fine detail. For example the ability to discriminate between 
values of 9 and 12 - if rounded to the nearest 10 they'll both be 10 in the 
data. The same happens with binary data truncated from 12 to 8 bits.

There are other methods that could be used that preserve detail in certain 
regions of the intensity - perhaps the highest and lowest parts of the image 
can be encoded with less dynamic range, taking fewer bits, by a non-linear 
scaling of the raw data. That leaves more bits to encode the data in the middle 
of the intensity region, which might be the most important part.

12 bit is for analytic use. When using imagery for analytically (e.g. 
converting pixel values to reflectance) you probably do not want the 8 bit 
product. With the 12 bit values of 0-4095 compared to 8 bit's 0-255 there is 
opportunity to do careful scene dependent conversion in a way that best brings 
out the details available in the source data. There are a lot of methods, and 
they generally require time and patience. The challenge is sometimes called 
tone 
mapping.

Planet has a blog post describing how to manually convert single scene imagery 
to 8bit RGB at A Hands-On Guide to Color 
Correction. It's a good article 
as it explains the theory for how certain things are done instead of merely 
giving a recipe of steps.

To get GDAL in the mix: 
gdal-translate 
can do simple tone mapping for you with the 
-scale
 parameter.

A special note regarding SPOT6/7: 12 bit orthorectified (level 2 processing) 
does not appear to available as a standard product, so to get 8 & 12 it might 
be necessary to purchase both Standard and Primary products. See SPOT image 
user 
guide,
 particularly the descriptions of different processing levels in section 2.3.



This answer summarized from the contributions of @rs_burner, @spacedman, 
@Vince, Frank Warmerdam, and Patrick Young. Thank you!


Matt Wilkie
Geomatics Analyst
Environment | Technology, Innovation and Mapping
T 867-667-8133 | Yukon.ca
Hours: 08:30-16:30, Tue-Wed: Office, Thu-Fri: Remote.


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

[gdal-dev] SUMMARY RE: What is lost when converting 12 bit imagery to 8 bit?

[Matt.Wilkie]

The position I've moved to after reading through and thinking about all the 
responses here and gdal-dev 
(here)
 is we need to ask for both 8 & 12 bit from the vendors.

8 bit is for visual use. It can be viewed on all displays and most programs 
without modification. Since this is 90%+ of usage scenarios having them ready 
to go is definitely beneficial to us. Additionally having the processing done 
in advance by a skilled supplier will save a lot of work -- and might even be a 
better visualization than we could produce ourselves. Producing good visuals 
across scenes systematically is not trivial.

The main drawback to automated 12 to 8 bit RGB products is that they tend to be 
very suboptimal in dark or bright areas (shadows, water, snow). This is because 
the fixed white and black point anchors needed to span the scene sets can not 
account for individual scene variation.

We should also ask imagery suppliers to describe their bit-reduction process. 
This will allow us to determine how it affects our application.

In audio terms, its a bit like cutting either the bass or the treble - what is 
best for you depends on what you want to do with the music afterwards.

  *   8 bits allows numbers from 0 to 255 (2 to the power of 8 values)
  *   12 bits allows numbers from 0 to 4095 (2 to the power of 12 values)

The simplest way conversion from 12 to 8 bits is setting the last four to zero, 
and the remaining bits shifted right four places. Its like rounding decimals to 
the nearest 100 or 1000.

What's lost is fine detail. For example the ability to discriminate between 
values of 9 and 12 - if rounded to the nearest 10 they'll both be 10 in the 
data. The same happens with binary data truncated from 12 to 8 bits.

There are other methods that could be used that preserve detail in certain 
regions of the intensity - perhaps the highest and lowest parts of the image 
can be encoded with less dynamic range, taking fewer bits, by a non-linear 
scaling of the raw data. That leaves more bits to encode the data in the middle 
of the intensity region, which might be the most important part.

12 bit is for analytic use. When using imagery for analytically (e.g. 
converting pixel values to reflectance) you probably do not want the 8 bit 
product. With the 12 bit values of 0-4095 compared to 8 bit's 0-255 there is 
opportunity to do careful scene dependent conversion in a way that best brings 
out the details available in the source data. There are a lot of methods, and 
they generally require time and patience. The challenge is sometimes called 
tone 
mapping.

Planet has a blog post describing how to manually convert single scene imagery 
to 8bit RGB at A Hands-On Guide to Color 
Correction. It's a good article 
as it explains the theory for how certain things are done instead of merely 
giving a recipe of steps.

To get GDAL in the mix: 
gdal-translate 
can do simple tone mapping for you with the 
-scale
 parameter.

A special note regarding SPOT6/7: 12 bit orthorectified (level 2 processing) 
does not appear to available as a standard product, so to get 8 & 12 it might 
be necessary to purchase both Standard and Primary products. See SPOT image 
user 
guide,
 particularly the descriptions of different processing levels in section 2.3.



This answer summarized from the contributions of @rs_burner, @spacedman, 
@Vince, Frank Warmerdam, and Patrick Young. Thank you!


Matt Wilkie
Geomatics Analyst
Environment | Technology, Innovation and Mapping
T 867-667-8133 | Yukon.ca
Hours: 08:30-16:30, Tue-Wed: Office, Thu-Fri: Remote.


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

Re: [gdal-dev] BAG Driver - dimension size being written in the wrong order

[Even Rouault]

Hi,

For posterity: just to note that the below fix turned out to be incorrect

See https://github.com/OSGeo/gdal/issues/3605 for more details and the 
appropriate fix


Even

Le 19/03/2021 à 18:22, Even Rouault a écrit :


Eric,

I believe you're right. I've just fixed the issue by changing the 
template resource XML file used by the GDAL driver in


https://github.com/OSGeo/gdal/commit/1d2e7bc8fcde059de853335fee390479d457be06

So you can easily workaround the issue by updating this file in your 
existing installation.


For a next time, better file an issue at 
https://github.com/OSGeo/gdal/issues however. This will minimize the 
risk that your report is lost because nobody was able to address it at 
the very moment where they read it.


Even

Le 19/03/2021 à 17:51, Eric Younkin - NOAA Federal via gdal-dev a écrit :

Hello,

Using conda installed GDAL 3.2.1

I think I've stumbled on a bug with the BAG driver.  It seems as 
though when you use Create() to make a BAG, it writes the 
dimensionSize xml attribute in the wrong order. It sets the column 
dimension size to the row dimensionSize xml attribute, and row to 
column.  I found this on examining the xml manually, see blob below.



        
          
            codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#MD_DimensionNameTypeCode 
" 
codeListValue="row">row

          
*          
            546
          *
          
            2.0
          
        
      

This bug does not affect viewing the BAG in QGIS, as it seems like 
QGIS just computes the size using the actual array.  I found that 
GDAL created BAGs would not load in Caris, a software for viewing 
bathymetric data.  I believe that is because Caris is using the 
dimensionSize xml instead of calculating size from the data.  If I 
swap row/col dimensionSize, the BAG then works in Caris.


Seems like a relatively simple fix (assuming I am right about this), 
please let me know if I need to submit it somewhere else.


Thanks,
Eric

--
Eric Younkin
Physical Scientist
NOAA OCS, Hydrographic Systems and Technology Branch
1315 East-West Highway
N/CS11, Room 6604
Silver Spring, MD 20910
Office: 240-847-8208
Cell: 828-331-8197

___
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


--
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] Fwd: [IIIF-Discuss] IIIF Maps Community Call on Wednesday March 24

[Mateusz Loskot]

FYI, GDAL is on the agenda

ML

-- Forwarded message -
From: Eliot Jordan 
Date: Tue, 23 Mar 2021 at 20:42
Subject: [IIIF-Discuss] IIIF Maps Community Call on Wednesday March 24
To: IIIF Discuss 


Map Enthusiasts -

We have a maps community call scheduled for Wednesday March 24 at 8:00
AM PDT, 11:00 AM EDT, 15:00 UK, 16:00 CET.

Zoom Link: 
https://stanford.zoom.us/j/99449304468?pwd=UUNzMmFtV2dXSWs2MjVicnplS29LUT09

Agenda:

https://docs.google.com/document/d/1Rfl7ufHFJtLUgLdaZUjX8CPEsmy0fPW3MWY_GPDRHl4

If you have anything you’d like to talk about or any related work
you’ve done recently please add to the agenda!

See you there.

- Eliot
__
Eliot Jordan
Geospatial Infrastructure Developer
Princeton University Library
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Computing a geo-transform with gdalwarp from a set of GCPs also rectifies the input images

[Bullinger, Sebastian]

Dear gdal community,

I'm currently working with a set of satellite images that are geo-registered 
with a set of GCPs. To compute a geo-transform from the GCPs, I've been using 
gdalwarp with:

gdalwarp -of GTiff path/to/original/file path/to/warped/file

While "gdalwarp" correctly computes a transformation from the GCPs, at the same 
it also performs some kind of rectification / north-up image transformation. 
I'm not sure about the applied operation.

Presumably, the reason for this is that the original GCPs reflect a 
transformation with skew factors.
See the following transformations of the original and the warped image.

>>> import gdal
>>> dataset = gdal.Open("path/to/original/file")
>>> print(gdal.GCPsToGeoTransform(dataset.GetGCPs()))
(-58.57294039342205, -3.991598267026281e-06, 0.0, -34.451175177186684, 
-3.6492767328575985e-07, 3.1987810722132996e-06)

>>> import gdal
>>> dataset = gdal.Open("path/to/warped/file")
>>> print(dataset.GetGeoTransform())
(-58.577917916461026, 3.435846284510554e-06, 0.0, -34.44693359348493, 0.0, 
-3.435846284510554e-06)

The "rectification" result is very convenient, since it allows to use the 
images with an existing satellite image segmentation pipeline (which tiles the 
satellite images using geo-tiles)
However, in order to overlay the segmentations (performed on the "rectified" 
images) with the original images, I need some information about the 
transformation applied during "gdalwarp".

I've searched the documentation for more information - unfortunately without 
success.
For example, parameters like "-novshiftgrid" do not affect this transformation.

It would be very helpful, if someone could shed some light on the used 
"rectification".
What kind of operation is applied? What would be the correct term to search for?
Is it "only" a decomposition of the transform? Or does "gdalwarp" something 
else too?
Is there a possibility to access this information, while using "gdalwarp"? (Or 
can this operation also be done by hand?)
Does GDAL contain any functions to invert this "rectification" step - given the 
corresponding transformation used by "gdalwarp"?

Best regards,
Sebastian



--
Dr. Sebastian Bullinger
Department Object Recognition
Fraunhofer Institute of
Optronics, Sytem Technologies and Image Exploitation IOSB
Gutleuthausstr. 1, 76275 Ettlingen, Germany
Phone +49 7243 992-197
sebastian.bullin...@iosb.fraunhofer.de
www.iosb.fraunhofer.de
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] OAPIF with Accept-encoding: gzip

[Even Rouault]

Hi Jukka,

Accept-Encoding: gzip is actually sent by default as you can see with 
"ogrinfo 
OAPIF:"https://beta-paikkatieto.maanmittauslaitos.fi/inspire-buildings/features/v1/collections/building/; 
--debug on --config CPL_CURL_VERBOSE YES", and the server honors it:


[...]

GET 
/inspire-buildings/features/v1/collections/building/items?f=json=10 
HTTP/1.1

Host: beta-paikkatieto.maanmittauslaitos.fi
Accept-Encoding: gzip
Accept: application/geo+json, application/json

< HTTP/1.1 200 OK
[...]
< Content-Encoding: gzip
< Content-Type: application/geo+json

Curl automatically uncompress the data, so this is transparent for GDAL.

The debug trace "HTTP: These HTTP headers were set" is a bit misleading 
as it only displays the HEADERS option sent to CPLHttpFetch(), but not 
the content of what is specified with the GDAL_HTTP_HEADER_FILE config 
option. Enabling Curl traces with CPL_CURL_VERBOSE=YES is the ultimate 
way of seeing what is really sent to the server.


Even


Le 23/03/2021 à 13:21, Rahkonen Jukka (MML) a écrit :


Hi,

Is it possible to ask the OAPIF server to send response as gzipped, 
and if it succeeds, would GDAL know what to do with the response? I 
made a try by saving a line “Accept-Encoding: gzip" as a test file and 
then making this request:


ogrinfo 
OAPIF:"https://beta-paikkatieto.maanmittauslaitos.fi/inspire-buildings/features/v1/collections/building/; 
--config GDAL_HTTP_HEADER_FILE headers.txt --debug on --config 
cpl_debug on


Unfortunately it seems that Accept-Encoding header was not added:

HTTP: These HTTP headers were set: Accept: application/geo+json, 
application/json


Is there some trick to make this to work or would it require changes 
into the OAPIF driver?


-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] OAPIF with Accept-encoding: gzip

[Rahkonen Jukka (MML)]

Hi,

Is it possible to ask the OAPIF server to send response as gzipped, and if it 
succeeds, would GDAL know what to do with the response? I made a try by saving 
a line "Accept-Encoding: gzip" as a test file and then making this request:

ogrinfo 
OAPIF:"https://beta-paikkatieto.maanmittauslaitos.fi/inspire-buildings/features/v1/collections/building/;
 --config GDAL_HTTP_HEADER_FILE headers.txt --debug on --config cpl_debug on

Unfortunately it seems that Accept-Encoding header was not added:
HTTP: These HTTP headers were set: Accept: application/geo+json, 
application/json

Is there some trick to make this to work or would it require changes into the 
OAPIF driver?

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

[gdal-dev] Gdal Java

[paul.malm]

Hi list,
is there someone out there who has succeeded in installing Gdal Javabindings in 
Windows?
I've tried for some weeks now :( and I can't find very much information how to 
do it I Windows.
gdalalljni.dll is not found for starters (Gdal 3.2.0) but it is there, as 
installed by the installation process.
I've been asking around on internet, but without any luck.
If these is someone who knows how to do it in Windows with Eclipse, it would be 
much appreciated to get some info...
It would be nice to have a bullet list (for dummies), from where to get the 
correct download files, installation, setting environment, what is needed to be 
set in Eclipse etc. I don't have any experience with javabindings or C++...

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