Quantcast

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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

jratike80

Cross posting intentionally.

 

TL;DR

 

I wonder if all projects under the OSGeo umbrella, starting from GDAL and Geoserver, could make a common agreement on not to use GridFunctions in GML coverages if they are not strictly needed. The other alternative would be to make all projects to support GML gridFunctions, and do it right.

 

Long story:

 

I have been trying to understand how GML coverages are used in JPEG 2000 and in WCS services.  So far I have understood that coverages can be very complex and GMLCOV and next generation CIS specifications are complex so that even the most nasty coverage types can be modelled. What seems to be missing from the specifications is a simple and unified way to model simple coverages, like orthophotos.

Not surprisingly my pain started from latitude-longitude or Northing-Easting axis order of some coordinate systems. The GDAL source code in https://trac.osgeo.org/gdal/browser/trunk/gdal/gcore/gdaljp2metadata.cpp is prepared to handle georeferencign by looking at

-          grid origin

-          offset vectors

-          EPSG database for handling the coordinate axis order in GML

 

At least in this place GDAL does not seem to be prepared in seeing gridFunctions which are defined in GML 3.2.1. With GridFunction it is possible to slide the starting point of the coverage with “startPoint”, change the order and direction of grid axes with “axisOrder” and define weird sequences for data points "Linear"/"Boustrophedonic"/"Cantor-diagonal"/"Spiral"/"Morton"/"Hilbert"

 

With orthophoto coverages I believe that all cases could be handled with the default gridFunctions: startPoint at gml:Low, axisOrder +1 +2, sequence rule “Linear”. As far as I have understood GDAL trusts that this is also what the other partners do. However, it seems that GeoServer developers have decided to handle the latitude-longitude axis flip in WCS 2.0.1 by changing the order of grid axis with a function instead of writing the offsetVectors to suit with the default +1 +2 axis order.

 

<gml:coverageFunction>

<gml:GridFunction>

<gml:sequenceRule axisOrder="+2 +1">Linear</gml:sequenceRule>

<gml:startPoint>0 0</gml:startPoint>

</gml:GridFunction>

</gml:coverageFunction>

 

-Jukka Rahkonen-


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GML lat-lon coverages and interoperability

geowolf
On Mon, Apr 3, 2017 at 2:32 PM, Rahkonen Jukka (MML) <[hidden email]> wrote:

With orthophoto coverages I believe that all cases could be handled with the default gridFunctions: startPoint at gml:Low, axisOrder +1 +2, sequence rule “Linear”. As far as I have understood GDAL trusts that this is also what the other partners do. However, it seems that GeoServer developers have decided to handle the latitude-longitude axis flip in WCS 2.0.1 by changing the order of grid axis with a function instead of writing the offsetVectors to suit with the default +1 +2 axis order.

 

<gml:coverageFunction>

<gml:GridFunction>

<gml:sequenceRule axisOrder="+2 +1">Linear</gml:sequenceRule>

<gml:startPoint>0 0</gml:startPoint>

</gml:GridFunction>

</gml:coverageFunction>


Hi Jukka,
the decision was not arbitrary, and imho, necessary.

Rasters pixels are normally represented as east/north, but OGC forces us to describe geographic data in lat/lon order.
So how do you tell the client, "look, I'm telling you that the axis order is north/east, but really, I'm giving you back data in east/north order instead"?

Cheers
Andrea

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


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.


-------------------------------------------------------

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GML lat-lon coverages and interoperability

jratike80
In reply to this post by jratike80

Great, first hit from Andrea. I am awaiting if Even strikes back. His creation (GDAL JP2OpenJPEG driver) writes out EPSG:4326 coverage into GML JP2 this way, without having gridFunction.

 

<gml:FeatureCollection

   xmlns:gml="http://www.opengis.net/gml"

   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

   xsi:schemaLocation="http://www.opengis.net/gml http://schemas.opengis.net/gml/3.1.1/profiles/gmlJP2Profile/1.0.0/gmlJP2Profile.xsd">

  <gml:boundedBy>

    <gml:Envelope srsName="urn:ogc:def:crs:EPSG::4326">

      <gml:lowerCorner>61.7282236395245 24.7248340978191</gml:lowerCorner>

      <gml:upperCorner>61.7838827490233 24.8422668729657</gml:upperCorner>

    </gml:Envelope>

  </gml:boundedBy>

  <gml:featureMember>

    <gml:FeatureCollection>

      <gml:featureMember>

        <gml:RectifiedGridCoverage dimension="2" gml:id="RGC0001">

          <gml:rectifiedGridDomain>

            <gml:RectifiedGrid dimension="2">

              <gml:limits>

                <gml:GridEnvelope>

                  <gml:low>0 0</gml:low>

                  <gml:high>15517 7354</gml:high>

                </gml:GridEnvelope>

              </gml:limits>

              <gml:axisName>x</gml:axisName>

              <gml:axisName>y</gml:axisName>

              <gml:origin>

                <gml:Point gml:id="P0001" srsName="urn:ogc:def:crs:EPSG::4326">

                  <gml:pos>61.7838789652633 24.7248378815791</gml:pos>

                </gml:Point>

              </gml:origin>

              <gml:offsetVector srsName="urn:ogc:def:crs:EPSG::4326">0 7.56751998624388e-006</gml:offsetVector>

              <gml:offsetVector srsName="urn:ogc:def:crs:EPSG::4326">-7.56751998624388e-006 0</gml:offsetVector>

            </gml:RectifiedGrid>

          </gml:rectifiedGridDomain>

          <gml:rangeSet>

            <gml:File>

              <gml:rangeParameters/>

              <gml:fileName>gmljp2://codestream/0</gml:fileName>

              <gml:fileStructure>Record Interleaved</gml:fileStructure>

            </gml:File>

          </gml:rangeSet>

        </gml:RectifiedGridCoverage>

      </gml:featureMember>

    </gml:FeatureCollection>

  </gml:featureMember>

</gml:FeatureCollection>

 

-Jukka-

 

Lähettäjä: [hidden email] [mailto:[hidden email]] Puolesta Andrea Aime
Lähetetty: 3. huhtikuuta 2017 15:58
Vastaanottaja: Rahkonen Jukka (MML) <[hidden email]>
Kopio: '[hidden email]' ([hidden email]) <[hidden email]>; [hidden email]
Aihe: Re: [gdal-dev] GML lat-lon coverages and interoperability

 

On Mon, Apr 3, 2017 at 2:32 PM, Rahkonen Jukka (MML) <[hidden email]> wrote:

With orthophoto coverages I believe that all cases could be handled with the default gridFunctions: startPoint at gml:Low, axisOrder +1 +2, sequence rule “Linear”. As far as I have understood GDAL trusts that this is also what the other partners do. However, it seems that GeoServer developers have decided to handle the latitude-longitude axis flip in WCS 2.0.1 by changing the order of grid axis with a function instead of writing the offsetVectors to suit with the default +1 +2 axis order.

 

<gml:coverageFunction>

<gml:GridFunction>

<gml:sequenceRule axisOrder="+2 +1">Linear</gml:sequenceRule>

<gml:startPoint>0 0</gml:startPoint>

</gml:GridFunction>

</gml:coverageFunction>

 

Hi Jukka,

the decision was not arbitrary, and imho, necessary.

 

Rasters pixels are normally represented as east/north, but OGC forces us to describe geographic data in lat/lon order.

So how do you tell the client, "look, I'm telling you that the axis order is north/east, but really, I'm giving you back data in east/north order instead"?

 

Cheers

Andrea

 

--

==

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

 

 

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.

 

-------------------------------------------------------


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GML lat-lon coverages and interoperability

geowolf
On Mon, Apr 3, 2017 at 3:19 PM, Rahkonen Jukka (MML) <[hidden email]> wrote:

    <gml:Envelope srsName="urn:ogc:def:crs:EPSG::4326">

      <gml:lowerCorner>61.7282236395245 24.7248340978191</gml:lowerCorner>

      <gml:upperCorner>61.7838827490233 24.8422668729657</gml:upperCorner>


Can you clarify which one is longitude and which one is latitude? :-)

It's one thing that really gets me about CITE tests too, if they wanted to make order obvious without further specs, the
coordinates of test data could have had some values greater than 90 ;-)

Cheers
Andrea

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


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.


-------------------------------------------------------

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GML lat-lon coverages and interoperability

jratike80
In reply to this post by jratike80

Hi,

 

Gdalinfo about my test image “4326.jp2”:

 

Size is 15518, 7355

Coordinate System is:

GEOGCS["WGS 84",

    DATUM["WGS_1984",

        SPHEROID["WGS 84",6378137,298.257223563,

            AUTHORITY["EPSG","7030"]],

        AUTHORITY["EPSG","6326"]],

    PRIMEM["Greenwich",0],

    UNIT["degree",0.0174532925199433],

    AUTHORITY["EPSG","4326"]]

Origin = (24.724834097819130,61.783882749023277)

Pixel Size = (0.000007567519986,-0.000007567519986)

Image Structure Metadata:

  INTERLEAVE=PIXEL

Corner Coordinates:

Upper Left  (  24.7248341,  61.7838827) ( 24d43'29.40"E, 61d47' 1.98"N)

Lower Left  (  24.7248341,  61.7282236) ( 24d43'29.40"E, 61d43'41.61"N)

Upper Right (  24.8422669,  61.7838827) ( 24d50'32.16"E, 61d47' 1.98"N)

Lower Right (  24.8422669,  61.7282236) ( 24d50'32.16"E, 61d43'41.61"N)

 

-Jukka-

 

Lähettäjä: [hidden email] [mailto:[hidden email]] Puolesta Andrea Aime
Lähetetty: 3. huhtikuuta 2017 16:31
Vastaanottaja: Rahkonen Jukka (MML) <[hidden email]>
Kopio: '[hidden email]' ([hidden email]) <[hidden email]>; [hidden email]
Aihe: Re: [gdal-dev] GML lat-lon coverages and interoperability

 

On Mon, Apr 3, 2017 at 3:19 PM, Rahkonen Jukka (MML) <[hidden email]> wrote:

    <gml:Envelope srsName="urn:ogc:def:crs:EPSG::4326">

      <gml:lowerCorner>61.7282236395245 24.7248340978191</gml:lowerCorner>

      <gml:upperCorner>61.7838827490233 24.8422668729657</gml:upperCorner>

 

Can you clarify which one is longitude and which one is latitude? :-)

 

It's one thing that really gets me about CITE tests too, if they wanted to make order obvious without further specs, the

coordinates of test data could have had some values greater than 90 ;-)

 

Cheers

Andrea

 

--

==

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

 

 

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.

 

-------------------------------------------------------


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GML lat-lon coverages and interoperability

Even Rouault-2
In reply to this post by jratike80

On lundi 3 avril 2017 13:19:18 CEST Rahkonen Jukka (MML) wrote:

> Great, first hit from Andrea. I am awaiting if Even strikes back.

 

I don't really have an opinion on this. I haven't read the relevant part of the GML or GMLCOV spec and I'm afraid I wouldn't understand it well. The GDAL GMLJP2 code just follows what the GMLJP2 spec and examples suggest, as well as data productions. Perhaps it is not "correct"...

 

> His

> creation (GDAL JP2OpenJPEG driver) writes out EPSG:4326 coverage into GML

> JP2 this way, without having gridFunction.

> <gml:FeatureCollection

> xmlns:gml="http://www.opengis.net/gml"

> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

> xsi:schemaLocation="http://www.opengis.net/gml

> http://schemas.opengis.net/gml/3.1.1/profiles/gmlJP2Profile/1.0.0/gmlJP2Pro

> file.xsd">

<gml:boundedBy>

> <gml:Envelope srsName="urn:ogc:def:crs:EPSG::4326">

> <gml:lowerCorner>61.7282236395245 24.7248340978191</gml:lowerCorner>

> <gml:upperCorner>61.7838827490233 24.8422668729657</gml:upperCorner>

> </gml:Envelope>

> </gml:boundedBy>

> <gml:featureMember>

> <gml:FeatureCollection>

> <gml:featureMember>

> <gml:RectifiedGridCoverage dimension="2" gml:id="RGC0001">

> <gml:rectifiedGridDomain>

> <gml:RectifiedGrid dimension="2">

> <gml:limits>

> <gml:GridEnvelope>

> <gml:low>0 0</gml:low>

> <gml:high>15517 7354</gml:high>

> </gml:GridEnvelope>

> </gml:limits>

> <gml:axisName>x</gml:axisName>

> <gml:axisName>y</gml:axisName>

> <gml:origin>

> <gml:Point gml:id="P0001"

> srsName="urn:ogc:def:crs:EPSG::4326">

<gml:pos>61.7838789652633

> 24.7248378815791</gml:pos> </gml:Point>

> </gml:origin>

> <gml:offsetVector srsName="urn:ogc:def:crs:EPSG::4326">0

> 7.56751998624388e-006</gml:offsetVector>

<gml:offsetVector

> srsName="urn:ogc:def:crs:EPSG::4326">-7.56751998624388e-006

> 0</gml:offsetVector> </gml:RectifiedGrid>

> </gml:rectifiedGridDomain>

> <gml:rangeSet>

> <gml:File>

> <gml:rangeParameters/>

> <gml:fileName>gmljp2://codestream/0</gml:fileName>

> <gml:fileStructure>Record Interleaved</gml:fileStructure>

> </gml:File>

> </gml:rangeSet>

> </gml:RectifiedGridCoverage>

> </gml:featureMember>

> </gml:FeatureCollection>

> </gml:featureMember>

> </gml:FeatureCollection>

>

> -Jukka-

>

> Lähettäjä: [hidden email] [mailto:[hidden email]] Puolesta

> Andrea Aime

Lähetetty: 3. huhtikuuta 2017 15:58

> Vastaanottaja: Rahkonen Jukka (MML) <[hidden email]>

> Kopio: '[hidden email]' ([hidden email])

> <[hidden email]>; [hidden email]

Aihe:

> Re: [gdal-dev] GML lat-lon coverages and interoperability

>

> On Mon, Apr 3, 2017 at 2:32 PM, Rahkonen Jukka (MML)

> <[hidden email]<mailto:jukka.rahkonen@maanmittauslaito

> s.fi>> wrote:

With orthophoto coverages I believe that all cases could be

> handled with the default gridFunctions: startPoint at gml:Low, axisOrder +1

> +2, sequence rule “Linear”. As far as I have understood GDAL trusts that

> this is also what the other partners do. However, it seems that GeoServer

> developers have decided to handle the latitude-longitude axis flip in WCS

> 2.0.1 by changing the order of grid axis with a function instead of writing

> the offsetVectors to suit with the default +1 +2 axis order.

> <gml:coverageFunction>

> <gml:GridFunction>

> <gml:sequenceRule axisOrder="+2 +1">Linear</gml:sequenceRule>

> <gml:startPoint>0 0</gml:startPoint>

> </gml:GridFunction>

> </gml:coverageFunction>

>

> Hi Jukka,

> the decision was not arbitrary, and imho, necessary.

>

> Rasters pixels are normally represented as east/north, but OGC forces us to

> describe geographic data in lat/lon order.

So how do you tell the client,

> "look, I'm telling you that the axis order is north/east, but really, I'm

> giving you back data in east/north order instead"?

> Cheers

> Andrea

>

> --

> ==

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

> -------------------------------------------------------

 

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GML lat-lon coverages and interoperability

jratike80

Hi,


Adding mapserver-dev to recipients in hope that Stephan Meissl notices and could share his opinion.  Mapserver WCS 2.0.1 does not generate axisOrder.


-Jukka Rahkonen-


Lähettäjä: Even Rouault <[hidden email]>
Lähetetty: 3. huhtikuuta 2017 23:03
Vastaanottaja: [hidden email]
Kopio: Rahkonen Jukka (MML); Andrea Aime; [hidden email]
Aihe: Re: [gdal-dev] GML lat-lon coverages and interoperability
 

On lundi 3 avril 2017 13:19:18 CEST Rahkonen Jukka (MML) wrote:

> Great, first hit from Andrea. I am awaiting if Even strikes back.

 

I don't really have an opinion on this. I haven't read the relevant part of the GML or GMLCOV spec and I'm afraid I wouldn't understand it well. The GDAL GMLJP2 code just follows what the GMLJP2 spec and examples suggest, as well as data productions. Perhaps it is not "correct"...

 

> His

> creation (GDAL JP2OpenJPEG driver) writes out EPSG:4326 coverage into GML

> JP2 this way, without having gridFunction.

> <gml:FeatureCollection

> xmlns:gml="http://www.opengis.net/gml"

> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

> xsi:schemaLocation="http://www.opengis.net/gml

> http://schemas.opengis.net/gml/3.1.1/profiles/gmlJP2Profile/1.0.0/gmlJP2Pro

> file.xsd">

<gml:boundedBy>

> <gml:Envelope srsName="urn:ogc:def:crs:EPSG::4326">

> <gml:lowerCorner>61.7282236395245 24.7248340978191</gml:lowerCorner>

> <gml:upperCorner>61.7838827490233 24.8422668729657</gml:upperCorner>

> </gml:Envelope>

> </gml:boundedBy>

> <gml:featureMember>

> <gml:FeatureCollection>

> <gml:featureMember>

> <gml:RectifiedGridCoverage dimension="2" gml:id="RGC0001">

> <gml:rectifiedGridDomain>

> <gml:RectifiedGrid dimension="2">

> <gml:limits>

> <gml:GridEnvelope>

> <gml:low>0 0</gml:low>

> <gml:high>15517 7354</gml:high>

> </gml:GridEnvelope>

> </gml:limits>

> <gml:axisName>x</gml:axisName>

> <gml:axisName>y</gml:axisName>

> <gml:origin>

> <gml:Point gml:id="P0001"

> srsName="urn:ogc:def:crs:EPSG::4326">

<gml:pos>61.7838789652633

> 24.7248378815791</gml:pos> </gml:Point>

> </gml:origin>

> <gml:offsetVector srsName="urn:ogc:def:crs:EPSG::4326">0

> 7.56751998624388e-006</gml:offsetVector>

<gml:offsetVector

> srsName="urn:ogc:def:crs:EPSG::4326">-7.56751998624388e-006

> 0</gml:offsetVector> </gml:RectifiedGrid>

> </gml:rectifiedGridDomain>

> <gml:rangeSet>

> <gml:File>

> <gml:rangeParameters/>

> <gml:fileName>gmljp2://codestream/0</gml:fileName>

> <gml:fileStructure>Record Interleaved</gml:fileStructure>

> </gml:File>

> </gml:rangeSet>

> </gml:RectifiedGridCoverage>

> </gml:featureMember>

> </gml:FeatureCollection>

> </gml:featureMember>

> </gml:FeatureCollection>

>

> -Jukka-

>

> Lähettäjä: [hidden email] [mailto:[hidden email]] Puolesta

> Andrea Aime

Lähetetty: 3. huhtikuuta 2017 15:58

> Vastaanottaja: Rahkonen Jukka (MML) <[hidden email]>

> Kopio: '[hidden email]' ([hidden email])

> <[hidden email]>; [hidden email]

Aihe:

> Re: [gdal-dev] GML lat-lon coverages and interoperability

>

> On Mon, Apr 3, 2017 at 2:32 PM, Rahkonen Jukka (MML)

> <[hidden email]<mailto:jukka.rahkonen@maanmittauslaito

> s.fi>> wrote:

With orthophoto coverages I believe that all cases could be

> handled with the default gridFunctions: startPoint at gml:Low, axisOrder +1

> +2, sequence rule “Linear”. As far as I have understood GDAL trusts that

> this is also what the other partners do. However, it seems that GeoServer

> developers have decided to handle the latitude-longitude axis flip in WCS

> 2.0.1 by changing the order of grid axis with a function instead of writing

> the offsetVectors to suit with the default +1 +2 axis order.

> <gml:coverageFunction>

> <gml:GridFunction>

> <gml:sequenceRule axisOrder="+2 +1">Linear</gml:sequenceRule>

> <gml:startPoint>0 0</gml:startPoint>

> </gml:GridFunction>

> </gml:coverageFunction>

>

> Hi Jukka,

> the decision was not arbitrary, and imho, necessary.

>

> Rasters pixels are normally represented as east/north, but OGC forces us to

> describe geographic data in lat/lon order.

So how do you tell the client,

> "look, I'm telling you that the axis order is north/east, but really, I'm

> giving you back data in east/north order instead"?

> Cheers

> Andrea

>

> --

> ==

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

> -------------------------------------------------------

 

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GML lat-lon coverages and interoperability

Peter Baumann
In reply to this post by jratike80

Hi all,

introducing (outing) myself as the coverage standard / WCS editor.

To avoid the problems that other standards have with axis order, coverages contain the axis order explicitly, in the axisLabels attribute. Here an example:

        <gml:Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/4326" axisLabels="Lat Long" uomLabels="deg deg" srsDimension="2">
            <gml:lowerCorner>1 1</gml:lowerCorner>
            <gml:upperCorner>3 10</gml:upperCorner>
        </gml:Envelope>

The sequence in axisLabels is indicative. So it is not necessary to use GridFunctions for this purpose. My personal opinion is that such mechanisms are not optimal for fiddling with coordinate positions as they make it unnecessarily difficult to determine the final pixel position. This seems to be the case here as well.

On a side note, GMLCOV (aka CIS) 1.0 carries along some burden from GML, the price for backwards compatibility. CIS 1.1 (just adopted) introduces a more orthogonal coverage model in addition [1]. Among others, it allows a very explicit modelling of the coordinate axes - see the examples.

You may want to take notice of the public Coverages.DWG OGC Wiki [2], we try to provide useful information, and feedback / questions are possible, too.

HTH,
Peter

PS: I wonder why nobody just asked earlier by contacting me, or some list like the (open) coverages.dwg list [3].

[1] http://external.opengeospatial.org/twiki_public/pub/CoveragesDWG/CoveragesBigPicture/cis_1-1.zip
[2] http://external.opengeospatial.org/twiki_public/CoveragesDWG/WebHome
[3] https://lists.opengeospatial.org/mailman/listinfo/coverages.wg



On 04/03/2017 02:32 PM, Rahkonen Jukka (MML) wrote:

Cross posting intentionally.

 

TL;DR

 

I wonder if all projects under the OSGeo umbrella, starting from GDAL and Geoserver, could make a common agreement on not to use GridFunctions in GML coverages if they are not strictly needed. The other alternative would be to make all projects to support GML gridFunctions, and do it right.

 

Long story:

 

I have been trying to understand how GML coverages are used in JPEG 2000 and in WCS services.  So far I have understood that coverages can be very complex and GMLCOV and next generation CIS specifications are complex so that even the most nasty coverage types can be modelled. What seems to be missing from the specifications is a simple and unified way to model simple coverages, like orthophotos.

Not surprisingly my pain started from latitude-longitude or Northing-Easting axis order of some coordinate systems. The GDAL source code in https://trac.osgeo.org/gdal/browser/trunk/gdal/gcore/gdaljp2metadata.cpp is prepared to handle georeferencign by looking at

-          grid origin

-          offset vectors

-          EPSG database for handling the coordinate axis order in GML

 

At least in this place GDAL does not seem to be prepared in seeing gridFunctions which are defined in GML 3.2.1. With GridFunction it is possible to slide the starting point of the coverage with “startPoint”, change the order and direction of grid axes with “axisOrder” and define weird sequences for data points "Linear"/"Boustrophedonic"/"Cantor-diagonal"/"Spiral"/"Morton"/"Hilbert"

 

With orthophoto coverages I believe that all cases could be handled with the default gridFunctions: startPoint at gml:Low, axisOrder +1 +2, sequence rule “Linear”. As far as I have understood GDAL trusts that this is also what the other partners do. However, it seems that GeoServer developers have decided to handle the latitude-longitude axis flip in WCS 2.0.1 by changing the order of grid axis with a function instead of writing the offsetVectors to suit with the default +1 +2 axis order.

 

<gml:coverageFunction>

<gml:GridFunction>

<gml:sequenceRule axisOrder="+2 +1">Linear</gml:sequenceRule>

<gml:startPoint>0 0</gml:startPoint>

</gml:GridFunction>

</gml:coverageFunction>

 

-Jukka Rahkonen-



_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Dr. Peter Baumann
 - Professor of Computer Science, Jacobs University Bremen
   www.faculty.jacobs-university.de/pbaumann
   mail: [hidden email]
   tel: +49-421-200-3178, fax: +49-421-200-493178
 - Executive Director, rasdaman GmbH Bremen (HRB 26793)
   www.rasdaman.com, mail: [hidden email]
   tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
"Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)



_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GML lat-lon coverages and interoperability

geowolf
On Tue, Apr 4, 2017 at 12:24 PM, Peter Baumann <[hidden email]> wrote:

To avoid the problems that other standards have with axis order, coverages contain the axis order explicitly, in the axisLabels attribute. Here an example:


        <gml:Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/4326" axisLabels="Lat Long" uomLabels="deg deg" srsDimension="2">
            <gml:lowerCorner>1 1</gml:lowerCorner>
            <gml:upperCorner>3 10</gml:upperCorner>
        </gml:Envelope>

The sequence in axisLabels is indicative.

I'm looking at the WCS 2.0.1 core spec, all it says about the labels is:

"The attribute axisLabels is an ordered list of labels for all the axes of this CRS". Label is a generic term, I don't see any dictionary giving meaning to the labels.
So the following should all be equivalent to the client, or not?
<gml:Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/4326" axisLabels="Lat Long" uomLabels="deg deg" srsDimension="2">
<gml:Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/4326" axisLabels="a b" uomLabels="deg deg" srsDimension="2">
<gml:Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/4326" axisLabels="foo bar" uomLabels="deg deg" srsDimension="2">
<gml:Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/4326" axisLabels="Long Lat" uomLabels="deg deg" srsDimension="2">

I added the last on purpose, since they are just labels, they really carry no meaning, and the axis order is still determined by the srsName instead (thus, lat long).
Or not?
 
So it is not necessary to use GridFunctions for this purpose. My personal opinion is that such mechanisms are not optimal for fiddling with coordinate positions as they make it unnecessarily difficult to determine the final pixel position. This seems to be the case here as well.

The function is there because we could not stomach the idea that "i j" in raster space would be associated to up and right (in this order), geographic coordinates systems have their own madness (or at least OGC wants us to believe that) but we hoped the raster space wouldn't be touched. If we remove the function, keep the lat/lon orientation for the envelope, and assume pairwise matching like Jukka suggests, then this is our raster (aka pixel) space:

Inline image 2 
It can work of course.

Then, since you are here, a question about the axis order of the returned coverages (let's assume geotiff for simplificity's sake). I am presuming some uniformity across OGC standards, so if vector data in WGS84 is to be returned in lat/lon order, does it makes sense to return also coverages in the same order? 
Projection unaware software displays vector data flipped when returned by a compliant WFS 1.1 server... shouldn't it happen the same for WCS 2.0? Or should rasters be considered somehow blessed and outside of this issue?

Cheers
Andrea

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


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.


-------------------------------------------------------

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GML lat-lon coverages and interoperability

Peter Baumann



On 04/05/2017 02:16 PM, Andrea Aime wrote:
On Tue, Apr 4, 2017 at 12:24 PM, Peter Baumann <[hidden email]> wrote:

To avoid the problems that other standards have with axis order, coverages contain the axis order explicitly, in the axisLabels attribute. Here an example:


        <gml:Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/4326" axisLabels="Lat Long" uomLabels="deg deg" srsDimension="2">
            <gml:lowerCorner>1 1</gml:lowerCorner>
            <gml:upperCorner>3 10</gml:upperCorner>
        </gml:Envelope>

The sequence in axisLabels is indicative.

I'm looking at the WCS 2.0.1 core spec, all it says about the labels is:

"The attribute axisLabels is an ordered list of labels for all the axes of this CRS". Label is a generic term, I don't see any dictionary giving meaning to the labels.

srsName and axisLabels are inherited from GML 3.2.1 which says (cf comment in geometryBasic0d1d.xsd):
"The attribute axisLabels is an ordered list of labels for all the axes of this CRS. The gml:axisAbbrev value should be used for these axis labels, after spaces and forbidden characters are removed. When the srsName attribute is included, this attribute is optional. When the srsName attribute is omitted, this attribute shall also be omitted."
In GMLCOV/CIS axisLabels is mandatory.

Purpose is to associate the EPSG CRS axes with the axes as used in the XML document in a machine readable manner, without the ambiguities of other standards.
In CIS 1.0 this is via axisAbbrev, so quite rigid. Following long and winding discussions with EPSG this has been changed in CIS 1.1 so that your examples 3 and 4 are allowed as well (identification by position, not by name).

So the following should all be equivalent to the client, or not?
<gml:Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/4326" axisLabels="Lat Long" uomLabels="deg deg" srsDimension="2">

correct as per EPSG:4326

<gml:Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/4326" axisLabels="a b" uomLabels="deg deg" srsDimension="2">
<gml:Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/4326" axisLabels="foo bar" uomLabels="deg deg" srsDimension="2">
<gml:Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/4326" axisLabels="Long Lat" uomLabels="deg deg" srsDimension="2">

all these are wrong in CIS 1.0, you _must_ use the axisAbbrev element. In CIS 1.1 ok, although the last one is misleading.


I added the last on purpose, since they are just labels, they really carry no meaning, and the axis order is still determined by the srsName instead (thus, lat long).
Or not?

srsName and axisLabels are inherited from GML 3.2.1 which says (cf comment in geometryBasic0d1d.xsd):
"The attribute axisLabels is an ordered list of labels for all the axes of this CRS. The gml:axisAbbrev value should be used for these axis labels, after spaces and forbidden characters are removed. When the srsName attribute is included, this attribute is optional. When the srsName attribute is omitted, this attribute shall also be omitted."
In GMLCOV/CIS axisLabels is mandatory.



 
So it is not necessary to use GridFunctions for this purpose. My personal opinion is that such mechanisms are not optimal for fiddling with coordinate positions as they make it unnecessarily difficult to determine the final pixel position. This seems to be the case here as well.

The function is there because we could not stomach the idea that "i j" in raster space would be associated to up and right (in this order), geographic coordinates systems have their own madness (or at least OGC wants us to believe that) but we hoped the raster space wouldn't be touched. If we remove the function, keep the lat/lon orientation for the envelope, and assume pairwise matching like Jukka suggests, then this is our raster (aka pixel) space:

Inline image 2 
It can work of course.

Then, since you are here, a question about the axis order of the returned coverages (let's assume geotiff for simplificity's sake). I am presuming some uniformity across OGC standards,

that is the Holy Grail. In practice, groups work individually (which is somehow understandable - it's all voluntary effort, although not desirable - I have brought it to the doors of OGC many times that a centralized point of coordination on the basics would be advantageous; that point could be OWS Common which is under revision since some time - not sure what this will mean in practice).

so if vector data in WGS84 is to be returned in lat/lon order, does it makes sense to return also coverages in the same order?

as we seem to have EPSG as common ground, yes.

Projection unaware software displays vector data flipped when returned by a compliant WFS 1.1 server... shouldn't it happen the same for WCS 2.0? Or should rasters be considered somehow blessed and outside of this issue?

I am always for harmonization (principle of least surprise in Software Engineering), but you will find wildly varying opinions on this :)

HTH,
Peter



Cheers
Andrea

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


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.


-------------------------------------------------------

-- 
Dr. Peter Baumann
 - Professor of Computer Science, Jacobs University Bremen
   www.faculty.jacobs-university.de/pbaumann
   mail: [hidden email]
   tel: +49-421-200-3178, fax: +49-421-200-493178
 - Executive Director, rasdaman GmbH Bremen (HRB 26793)
   www.rasdaman.com, mail: [hidden email]
   tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
"Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)



_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GML lat-lon coverages and interoperability

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

Cheers
Andrea


On Wed, Apr 5, 2017 at 8:17 PM, Peter Baumann <[hidden email]> wrote:



On 04/05/2017 02:16 PM, Andrea Aime wrote:
On Tue, Apr 4, 2017 at 12:24 PM, Peter Baumann <[hidden email]> wrote:

To avoid the problems that other standards have with axis order, coverages contain the axis order explicitly, in the axisLabels attribute. Here an example:


        <gml:Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/4326" axisLabels="Lat Long" uomLabels="deg deg" srsDimension="2">
            <gml:lowerCorner>1 1</gml:lowerCorner>
            <gml:upperCorner>3 10</gml:upperCorner>
        </gml:Envelope>

The sequence in axisLabels is indicative.

I'm looking at the WCS 2.0.1 core spec, all it says about the labels is:

"The attribute axisLabels is an ordered list of labels for all the axes of this CRS". Label is a generic term, I don't see any dictionary giving meaning to the labels.

srsName and axisLabels are inherited from GML 3.2.1 which says (cf comment in geometryBasic0d1d.xsd):
"The attribute axisLabels is an ordered list of labels for all the axes of this CRS. The gml:axisAbbrev value should be used for these axis labels, after spaces and forbidden characters are removed. When the srsName attribute is included, this attribute is optional. When the srsName attribute is omitted, this attribute shall also be omitted."
In GMLCOV/CIS axisLabels is mandatory.

Purpose is to associate the EPSG CRS axes with the axes as used in the XML document in a machine readable manner, without the ambiguities of other standards.
In CIS 1.0 this is via axisAbbrev, so quite rigid. Following long and winding discussions with EPSG this has been changed in CIS 1.1 so that your examples 3 and 4 are allowed as well (identification by position, not by name).

So the following should all be equivalent to the client, or not?
<gml:Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/4326" axisLabels="Lat Long" uomLabels="deg deg" srsDimension="2">

correct as per EPSG:4326

<gml:Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/4326" axisLabels="a b" uomLabels="deg deg" srsDimension="2">
<gml:Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/4326" axisLabels="foo bar" uomLabels="deg deg" srsDimension="2">
<gml:Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/4326" axisLabels="Long Lat" uomLabels="deg deg" srsDimension="2">

all these are wrong in CIS 1.0, you _must_ use the axisAbbrev element. In CIS 1.1 ok, although the last one is misleading.


I added the last on purpose, since they are just labels, they really carry no meaning, and the axis order is still determined by the srsName instead (thus, lat long).
Or not?

srsName and axisLabels are inherited from GML 3.2.1 which says (cf comment in geometryBasic0d1d.xsd):
"The attribute axisLabels is an ordered list of labels for all the axes of this CRS. The gml:axisAbbrev value should be used for these axis labels, after spaces and forbidden characters are removed. When the srsName attribute is included, this attribute is optional. When the srsName attribute is omitted, this attribute shall also be omitted."
In GMLCOV/CIS axisLabels is mandatory.



 
So it is not necessary to use GridFunctions for this purpose. My personal opinion is that such mechanisms are not optimal for fiddling with coordinate positions as they make it unnecessarily difficult to determine the final pixel position. This seems to be the case here as well.

The function is there because we could not stomach the idea that "i j" in raster space would be associated to up and right (in this order), geographic coordinates systems have their own madness (or at least OGC wants us to believe that) but we hoped the raster space wouldn't be touched. If we remove the function, keep the lat/lon orientation for the envelope, and assume pairwise matching like Jukka suggests, then this is our raster (aka pixel) space:

Inline image 2 
It can work of course.

Then, since you are here, a question about the axis order of the returned coverages (let's assume geotiff for simplificity's sake). I am presuming some uniformity across OGC standards,

that is the Holy Grail. In practice, groups work individually (which is somehow understandable - it's all voluntary effort, although not desirable - I have brought it to the doors of OGC many times that a centralized point of coordination on the basics would be advantageous; that point could be OWS Common which is under revision since some time - not sure what this will mean in practice).

so if vector data in WGS84 is to be returned in lat/lon order, does it makes sense to return also coverages in the same order?

as we seem to have EPSG as common ground, yes.

Projection unaware software displays vector data flipped when returned by a compliant WFS 1.1 server... shouldn't it happen the same for WCS 2.0? Or should rasters be considered somehow blessed and outside of this issue?

I am always for harmonization (principle of least surprise in Software Engineering), but you will find wildly varying opinions on this :)

HTH,
Peter



Cheers
Andrea

--
==
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: <a href="tel:+39%200584%20962313" value="+390584962313" target="_blank">+39 0584 962313
fax: <a href="tel:+39%200584%20166%200272" value="+3905841660272" target="_blank">+39 0584 1660272
mob: <a href="tel:+39%20339%20884%204549" value="+393398844549" target="_blank">+39  339 8844549


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.


-------------------------------------------------------

-- 
Dr. Peter Baumann
 - Professor of Computer Science, Jacobs University Bremen
   www.faculty.jacobs-university.de/pbaumann
   mail: [hidden email]
   tel: <a href="tel:+49%20421%202003178" value="+494212003178" target="_blank">+49-421-200-3178, fax: <a href="tel:+49%20421%20200493178" value="+49421200493178" target="_blank">+49-421-200-493178
 - Executive Director, rasdaman GmbH Bremen (HRB 26793)
   www.rasdaman.com, mail: [hidden email]
   tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: <a href="tel:+49%20173%205837882" value="+491735837882" target="_blank">+49-173-5837882
"Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)





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


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.


-------------------------------------------------------

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Geoserver-devel] GML lat-lon coverages and interoperability

Even Rouault-2

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


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Geoserver-devel] GML lat-lon coverages and interoperability

geowolf
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 <[hidden email]> 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
[hidden email]
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


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.


-------------------------------------------------------

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Geoserver-devel] GML lat-lon coverages and interoperability

Even Rouault-2

On lundi 10 avril 2017 15:57:03 CEST Andrea Aime wrote:

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

 

Well, Function might be helpful then (and happily ignored by code that assumes that usual raster order will be used). However I'm not sure in which way GDAL is involved in this discussion :-) Regarding GMLJP2, GDAL will ignore Function on reading it, and not write it. So I think that on the read side, that should be OK in practice. So, there could potentially be issues on the write side for rasters generated by GDAL and read by other software that would assume that a georeferencing with Lat Long order would imply the raster first axis to be Lat ? Or perhaps issues in the GDAL WCS client ? Perhaps Jukka could give more precisions if there are actual interoperability problems.

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Geoserver-devel] GML lat-lon coverages and interoperability

Peter Baumann

Hi all,

why not simply check against the compliance tests of WCS 2 and maybe a reference implementation? Might be the easiest for answering all such questions.

cheers,

Peter


On 04/10/2017 04:23 PM, Even Rouault wrote:

On lundi 10 avril 2017 15:57:03 CEST Andrea Aime wrote:

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

 

Well, Function might be helpful then (and happily ignored by code that assumes that usual raster order will be used). However I'm not sure in which way GDAL is involved in this discussion :-) Regarding GMLJP2, GDAL will ignore Function on reading it, and not write it. So I think that on the read side, that should be OK in practice. So, there could potentially be issues on the write side for rasters generated by GDAL and read by other software that would assume that a georeferencing with Lat Long order would imply the raster first axis to be Lat ? Or perhaps issues in the GDAL WCS client ? Perhaps Jukka could give more precisions if there are actual interoperability problems.

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


-- 
Dr. Peter Baumann
 - Professor of Computer Science, Jacobs University Bremen
   www.faculty.jacobs-university.de/pbaumann
   mail: [hidden email]
   tel: +49-421-200-3178, fax: +49-421-200-493178
 - Executive Director, rasdaman GmbH Bremen (HRB 26793)
   www.rasdaman.com, mail: [hidden email]
   tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
"Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)



_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Geoserver-devel] GML lat-lon coverages and interoperability

jratike80
Peter Baumann wrote
Hi all,

why not simply check against the compliance tests of WCS 2 and maybe a reference
implementation? Might be the easiest for answering all such questions.

cheers,

Peter
Hi,

I could not find exact match for raster image (GeoTIFF) case from http://cite.opengeospatial.org/teamengine/about/wcs/2.0.1/site/ or http://schemas.opengis.net/wcs/2.0/examples/.


When it comes to reference implementation, by following the link http://standards.rasdaman.org/ to the WCS endpoint demo using service http://ows.rasdaman.org/rasdaman/ows and then to coverage BlueMarbleCov I can read that DescribeCoverage contains this:

    <coverageFunction>
      <GridFunction>
        <sequenceRule axisOrder="+2 +1">Linear</sequenceRule>
        <startPoint>0 0</startPoint>
      </GridFunction>
    </coverageFunction>
    <gmlcov:metadata/>
    <domainSet>
      <RectifiedGrid dimension="2" gml:id="BlueMarbleCov-grid">
        <limits>
          <GridEnvelope>
            <low>0 0</low>
            <high>17999 8999</high>
          </GridEnvelope>
        </limits>
        <axisLabels>Lat Long</axisLabels>
        <origin>
          <Point gml:id="BlueMarbleCov-origin" srsName="http://ows.rasdaman.org/def/crs/EPSG/0/4326">
            <pos>89.99 -179.99</pos>
          </Point>
        </origin>
        <offsetVector srsName="http://ows.rasdaman.org/def/crs/EPSG/0/4326">-0.02 0</offsetVector>
        <offsetVector srsName="http://ows.rasdaman.org/def/crs/EPSG/0/4326">0 0.02</offsetVector>
      </RectifiedGrid>

So both the Rasdaman demo and Geoserver are using gridFunction axisOrder +2 +1 with EPSG:4326. However, on April 4th you wrote on this mailing list:

"So it is not necessary to use GridFunctions for this purpose. My personal opinion is that such mechanisms are not optimal for fiddling with coordinate positions as they make it unnecessarily
difficult to determine the final pixel position."

I am not yet sure what is the conclusion.

-Jukka Rahkonen-


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Geoserver-devel] GML lat-lon coverages and interoperability

Piero Campa
In reply to this post by jratike80
​Hi Jukka,​

On 10 April 2017 at 16:56, <[hidden email]> wrote:
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?


l'lI just chime​ in to confirm you that: yes, offset vectors are the right means.

There is no need for raster and CRS axis to have 1) the same dimensionality (you want to describe a 2D grid in a 3D cube) and neither 2) the same axis ordering.

Indeed raster/CRS axis pairing can make sense only when the raster is diligently aligned with the CRS space, otherwise that would makes no sense.

@see


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Geoserver-devel] GML lat-lon coverages and interoperability

Peter Baumann

Hi all,

Piero is right - what I said applies to the case that grid and CRS axes align - which addresses the vast marjotiy of cases in my experience. However, OGC coverages (to some extent CIS 1.0, more with CIS 1.1) can also address more complex cases (irregular grids, grids embedded in higher-dimensional spaces, grids given by sensor models, etc.), but naturally description of such grids gets increasingly involved.

To put it differently: parameters omitted use defaults that try to keep usage simple.

My 2 philosophical cents,

Peter


On 04/11/2017 09:13 AM, Piero Campalani wrote:
​Hi Jukka,​

On 10 April 2017 at 16:56, <[hidden email]> wrote:
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?


l'lI just chime​ in to confirm you that: yes, offset vectors are the right means.

There is no need for raster and CRS axis to have 1) the same dimensionality (you want to describe a 2D grid in a 3D cube) and neither 2) the same axis ordering.

Indeed raster/CRS axis pairing can make sense only when the raster is diligently aligned with the CRS space, otherwise that would makes no sense.

@see



_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Dr. Peter Baumann
 - Professor of Computer Science, Jacobs University Bremen
   www.faculty.jacobs-university.de/pbaumann
   mail: [hidden email]
   tel: +49-421-200-3178, fax: +49-421-200-493178
 - Executive Director, rasdaman GmbH Bremen (HRB 26793)
   www.rasdaman.com, mail: [hidden email]
   tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
"Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)



_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Loading...