[gdal-dev] [Geoserver-devel] GML lat-lon coverages and interoperability

Rahkonen Jukka (MML) jukka.rahkonen at maanmittauslaitos.fi
Mon Apr 10 07:56:15 PDT 2017


Hi,

Even wrote:
However I'm not sure in which way GDAL is involved in this discussion :-)


I am preparing for the future when GDAL will have a support for WCS 2.0.1 and it will try to read EPSG:4326 coverage data from GeoServers witch describe coverage like this: http://demo.geo-solutions.it/geoserver/wcs?service=WCS&version=2.0.1&request=DescribeCoverage&coverageID=nurc__Arc_Sample

I have a feeling that without a) making GDAL to interpret gridFunction or b) Geoserver changing the way to define rectified grid (if it is possible) GDAL will fail. If not before then at latest when it tries to read a subset of coverage or to put the server to do server side scaling to size.

Andrea wrote:

If there is no 1:1 correspondence between geographic and raster space axis, then I see no other way but to use Function to explicitly correlate the two.
How would you propose to proceed instead?

Perhaps with offset vectors? An example taken from “OGC GML in JPEG 2000 (GMLJP2) Encoding StandardPart 1: Core”


<gml:domainSet>
<gml:RectifiedGrid gml:id="rg0001_C0002" dimension="2"
srsName="http://www.opengis.net/def/crs/EPSG/0/4326">
<gml:limits>
<gml:GridEnvelope>
<gml:low>1 1</gml:low>
<gml:high>3 10</gml:high>
</gml:GridEnvelope>
</gml:limits>
<gml:axisLabels>Lat Long</gml:axisLabels>
<gml:origin>
<gml:Point gml:id="P0001">
<gml:pos>9.9 9.9</gml:pos>
</gml:Point>
</gml:origin>
<gml:offsetVector>0 3.71e-005</gml:offsetVector>
<gml:offsetVector>-3.71e-005 0</gml:offsetVector>
</gml:RectifiedGrid>

I hope I have understood right when I believe that this advice means “Read data from the JPEG 2000 file in sequence. Place the first data value to the origin and the second one where the first offsetVector points. It is: keep the latitude and increase the longitude by 3.71e-005 . Continue till the “high” limit of Long axis (10). Now the first row  is full. Place the 11th value where the second offsetVector points – so decrease Lat by -3.71e-005 and keep Long at the initial value. Fill the second row. Then one more step down and fill the 3rd row. You have finished”.

So even the grid axes are “column first – rows next” it is possible to fill the grid by streaming from the data source that is organized as “rows first” like JPEG 2000 or GeoTIFF. I can imagine I could demonstrate that if I had a chess board and 64 beans, even if someone rotates the board by 90 degrees.

I must admit that I am not at all sure that I have understood it right. Actually it is not even important for me. I just would like to see WCS to work fluently so that all the servers and clients would understand each other. Somehow I have hoped the OGC would support this goal by giving understandable examples and best practice documents.


By the way, Mr Baumann told that  coverages.wg-owner at lists.opengeospatial.org<mailto:coverages.wg-owner at lists.opengeospatial.org> is an open list but it does not seem to be open for everybody:


"This is an OGC member's only list. More information can be found at:

http://www.opengeospatial.org/ogc/join . If your organization is a member, please have your organization's representative create you an OGC portal account. Once you have an account, you may then request access to the desired lists. If you have questions, you may send you and your company's contact information along with an explanation to ListMaster @OpenGeospatial.org . Thank you. OGC ListMaster"



-Jukka Rahkonen-







Lähettäjä: Andrea Aime [mailto:andrea.aime at geo-solutions.it]
Lähetetty: 10. huhtikuuta 2017 16:57
Vastaanottaja: Even Rouault <even.rouault at spatialys.com>
Kopio: Geoserver-devel <geoserver-devel at lists.sourceforge.net>; 'gdal-dev at lists.osgeo.org' (gdal-dev at lists.osgeo.org) <gdal-dev at lists.osgeo.org>; Peter Baumann <p.baumann at jacobs-university.de>
Aihe: Re: [Geoserver-devel] [gdal-dev] GML lat-lon coverages and interoperability

Hi Even,
in CIS 1.1 they state:

Coverages are assumed to have a 1:1 correlation between the axis names given in axis-Labels and gridLabels, i.e.: they shall relate pairwise, given by their sequence position. For example, axisLabels=“Lat Long h date” and gridLabels={i j k l} implies a correspondence of Lat with i, Long with j, h with k, and date with l.

If there is no 1:1 correspondence between geographic and raster space axis, then I see no other way but to use Function to explicitly correlate the two.
How would you propose to proceed instead?

Cheers
Andrea


On Mon, Apr 10, 2017 at 3:31 PM, Even Rouault <even.rouault at spatialys.com<mailto:even.rouault at spatialys.com>> wrote:

On lundi 10 avril 2017 15:06:55 CEST Andrea Aime wrote:

> Hi,

> sorry I lost track of the subject. So, to close up, and approach where the

> envelope is reported as "lat lon" and the "i j" raster space

> axis would map pairwise, so i pointing north-wards and j east-wards, would

> be considered valid?

> E.g., if one rescaling says "i is going to be 200 pixels" it really means

> the output image will be 200 pixels tall?



IMHO, importing EPSG axis order mess in raster space would seem to be foolish to me and cause major annoyances. Performance-wise, processing flipped rasters with classic algorithms that process line per line would be terrible as soon as they are large enough, since reading each line would in practice require to read the whole raster each time.



Even



--

Spatialys - Geospatial professional services

http://www.spatialys.com

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel at lists.sourceforge.net<mailto:Geoserver-devel at lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geoserver-devel



--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it


AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.



The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility  for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

-------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170410/f9f48bc7/attachment-0001.html>


More information about the gdal-dev mailing list