[gdal-dev] Idea: GeoTIFF box in JPEG to add georeferencing

[Rahkonen Jukka (Tike)]

Hi,

This is just a small detail and I may be wrong, but I fear that axisLabels element does not universally remove the need to go to the database because there are systems which use "X" and "Y" as axis names, but the meaning of X and Y can be different. For example for EPSG:3857 X means Easting but for the old Finnish KKJ is means Northing. I can also be wrong in saying the "X" is an axis name because in the following EPSG reports the names seem to be "Easting" and "Northing" and "X" and "Y" are abbreviations. However, by looking at the EPSG:3857 example from the package https://portal.opengeospatial.org/files/?artifact_id=50118 just the ambiguous abbreviations are used as axisLabels.
<gml:axisLabels>x y</gml:axisLabels>

Am I right or am I wrong?

http://epsg-registry.org/report.htm?type=selection&entity=urn:ogc:def:crs:EPSG::2393&reportDetail=short&style=urn:uuid:report-style:default-with-code&style_name=OGP%20Default%20With%20Code&title=Finnish%20KKJ

http://epsg-registry.org/report.htm?type=selection&entity=urn:ogc:def:crs:EPSG::3857&reportDetail=short&style=urn:uuid:report-style:default-with-code&style_name=OGP%20Default%20With%20Code&title=EPSG:3857

Regards,

-Jukka Rahkonen-

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 at 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.baumann at jacobs-university.de
>     tel: +49-421-200-3178, fax: +49-421-200-493178
>   - Executive Director, rasdaman GmbH Bremen (HRB 26793)
>     www.rasdaman.com, mail: baumann at 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)
>