Hi Emmanuel,
my fault, the curse of shorthand...expanding a little:
- GMLCOV gives a format-independent coverage model, with an increasing number of
mappings from/to concrete formats getting available. As there is a formal
dependency of GMLJP2 on GMLCOV both best should be adopted in sync.
Characterizing GMLCOV as a 19123 implementation standard makes a lot of sense -
19123 is abstract, and many non-interoperable implementations can be (and have
been) done. GMLCOV is based on the 19123 concepts and refines them to an
interoperable data model which is conformance-testable down to single pixel level.
- WCS indeed is a separate issue (GMLCOV is built in a way that many services
can be used, while WCS just happens to be the one with the most
coverage-specific functionality). Makeing WCS an ISO standard actually has been
suggested to me independently from this thread & earlier, by several people.
As WCS likewise is based on 19123 (here the functional part comes in) IMHO it
would indeed make sense to have both data and service model standardized in the
realm of TC211.
Although having been pushed I have not undertaken any steps in this direction
until now, partly due to resource issues and partly as I am not familiar with
TC211 procedures. I will try to join TC211 telcos so that we jointly can clarify
issues.
cheers,
Peter
On 05/20/2014 12:00 PM, Emmanuel Devys wrote:
Peter, Carl et al
For the sake of clarification, I'd like to know in the " this includes GMLCOV and WCS."
What does the "this" relates to ? (GMLJP2 ?, OGC/ISO discussion ? both ?
Moreover, I believe WCS is not directly related (or included) ... IMHO, the
relationship between WCS (Web coverage Service) and these encodings (JPEG2000,
JPEG, PNG) is only via the WCS encoding extensions (presently the GeoTIFF one,
and the emergent JP2K one).
The version 2 of the OGC GML in JP2000 (GMLJP2) candidate is based on the
GMLCOV schema.
My understanding of the OGC/ISO TC211 discussion is that it is related to the
"Geo-enabled JP2K standard(s)", for which GMLJP2 is a candidate, being aware
that there are others (such as the GeoTIFF box in JPEG2000 - also called GeoJ2(TM)).
Would there be additional discussion to bring GMLCOV to ISO TC211 (as an
implementation standard for 19123) ?
Cheers
Emmanuel Devys
-----Message d'origine-----
De : gdal-dev-boun...@lists.osgeo.org [mailto:gdal-dev-boun...@lists.osgeo.org]
De la part de Peter Baumann
Envoyé : mardi 20 mai 2014 09:27
À : Carl Reed; Even Rouault; gdal-dev@lists.osgeo.org
Cc : Jukka Rahkonen; standa...@lists.osgeo.org
Objet : Re: [gdal-dev] [OSGeo-Standards] Idea: GeoTIFF box in JPEG to
addgeoreferencing
On 05/19/2014 10:50 PM, Carl Reed wrote:
Thanks, Peter.
Also, FYI, version 2 of the OGC GML in JP2000 (GMLJP2) candidate
standard is in an OGC adoption vote until June 29. There is also an
OGC/ISO discussion this week as to whether this OGC standards should also
become an ISO standard.
Just for clarification: this includes GMLCOV and WCS.
cheers,
Peter
Cheers
Carl
-----Original Message----- From: Peter Baumann
Sent: Monday, May 12, 2014 3:39 PM
To: Even Rouault ; gdal-dev@lists.osgeo.org
Cc: Jukka Rahkonen ; standa...@lists.osgeo.org
Subject: Re: [OSGeo-Standards] [gdal-dev] Idea: GeoTIFF box in JPEG to
addgeoreferencing
PS: not sure all on this list are aware of this overview page:
http://external.opengeospatial.org/twiki_public/CoveragesDWG/Coverages
BigPicture
-Peter
On 05/12/2014 11:38 PM, Peter Baumann wrote:
Hi all,
just saw this, thought I'd chime in being the editor of GMLCOV :) Any
questions, I'll gladly try to answer, I'm just on the road currently,
so expect a delay of a day or so.
Trying to respond to what has been raised below:
On 05/12/2014 11:18 PM, Even Rouault wrote:
Le lundi 12 mai 2014 23:05:21, Jukka Rahkonen a écrit :
Even Rouault <even.rouault <at> mines-paris.org> writes:
...
In light of this, it may be better to use an xml or textual
representation and embed it inside an XMP block, which is
supported for many formats[1]. Also it would allow for easier human-reading.
Yes, that's one possibility. Which comes back to GMLJP2 unless
there are
other
standards...
I'd want to build on something that is a "real" standard or a
de-facto standard, but not reinvent everything from scratch.
What GMLJP2 gives as a bonus is the axis order trouble
actually, no. GMLJP2 relies on GMLCOV which defines axis order. Each
coverage has a Native CRS which is defined via an OGC URI (which, in
the case of EPSG, refers to the OGP maintained database). In the CRS
definition the axis is given unambiguously.
If you don't want to go to that database, use the axisLabels
attribute in the Envelope, it lists axes in their proper sequence.
and not totally
clear interpretation if origin is in the centre (probably it is) or
in the corner of a pixel,
naively, GMLCOV follows the pixel-in center interpretation. However,
encodings may override this, such as GeoTIFF (see the pertaining
adopted spec [1]).
[1] https://portal.opengeospatial.org/files/?artifact_id=50118
and rectified grid does not support ground control points.
yes, because it is rectified. If you want more degree of freedom do
not use RectifiedGridCoverage but ReferenceableGridCoverage. In
conjunction with GML
3.3 ( a compatible enhancement of GML 3.2.1) this gives you irregular
and warped grids. We're not completely done, though, and would be
glad about your support in some advanced issues. Note that this work
is all voluntary and relies on some project financing to be done. Up
to now, EC and ESA have been generous, and so we are going ahead step by step.
Thus GMLJP2 is at least not better in everything, it has also
drawbacks.
Hi Jukka,
Yes, for all your above reasons, I would prefer to avoid it.
so which ones are remaining, following the clarification you mention below?
cheers,
Peter
Although the axis order trouble (the one of EPSG) and interpretation
of origin (pixel center) should be mostly clarified with the revised version.
As far as ground countrol points are concerned, I've not really
looked at the capabilities of GMLCov, so perhaps there's something in it for
that.
Otherwise, that would be indeed a drawback.
-Jukka Rahkonen-
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Dr. Peter Baumann
- Professor of Computer Science, Jacobs University Bremen
www.faculty.jacobs-university.de/pbaumann
mail: p.baum...@jacobs-university.de
tel: +49-421-200-3178, fax: +49-421-200-493178
- Executive Director, rasdaman GmbH Bremen (HRB 26793)
www.rasdaman.com, mail: baum...@rasdaman.com
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
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Dr. Peter Baumann
- Professor of Computer Science, Jacobs University Bremen
www.faculty.jacobs-university.de/pbaumann
mail: p.baum...@jacobs-university.de
tel: +49-421-200-3178, fax: +49-421-200-493178
- Executive Director, rasdaman GmbH Bremen (HRB 26793)
www.rasdaman.com, mail: baum...@rasdaman.com
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
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
