Re: [MetaCRS] question on GeoTiff axis order

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [MetaCRS] question on GeoTiff axis order

Frank Warmerdam
On 10-12-17 11:43 AM, Martin Desruisseaux wrote:

> Hello Frank
>
> Thanks for your reply. I guess that "correct way" means "what the GeoTIFF
> standard said", and that standard at
> http://www.remotesensing.org/geotiff/spec/geotiff2.5.html seems to be silent
> about the axis order. The above page basically just make a reference to a list
> a tables, and the GeoTIFF table at
> ftp://ftp.remotesensing.org/geotiff/tables/horiz_cs.csv explicitely define
> (lat,long) axis order for 4326 and some other CRS.
>
>  From this point of view, the GeoTIFF specification seems to mandate (lat,long)
> axis order. I guess that this is not the intend. Maybe a note somewhere could
> at least put a warning (something like "while the GeoTIFF tables derived from
> the EPSG database put latitude before longitude, the common usage for raster
> data is to display north up and east on the right side"). While I admit that
> this is very fuzzy, it is actually hard to provide an accurate rule applicable
> also to polar area, South Africa, Australia, etc..., and I guess that no one
> have the energy to produce an accurate specification at this time...

Martin,

My approach is to assume long/lat for geographic coordinate systems, but
(in theory at least) to honour EPSG axis order for projected coordinate
systems.  In theory, as the spec does not address axis order, you are right
that we ought to treat most GCSes as lat/long but the absolutely foolhardyness
of going against all current practice makes this unreasonable.  My emotional
response is largely due to the mayhem I saw come out of pushing EPSG axis
order for GCSes in WMS and beyond.

I agree that some clarification in the GeoTIFF FAQ would be helpful.  I
will endevour to add something there today.

I'm cc:ing the geotiff list since that is really where this discussion
should be. For those there who are interested the exchange is available
at:

   http://lists.osgeo.org/pipermail/metacrs/2010-December/thread.html

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

_______________________________________________
Geotiff mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/geotiff
Reply | Threaded
Open this post in threaded view
|

Re: [MetaCRS] question on GeoTiff axis order

Max Martinez
Frank,

Your approach does sound reasonable. The horse has long left the barn on
this one.

But I'm not sure I completely understand what Martin is getting at.
GeoTIFF doesn't address display of the image, only the definition of
raster space, model space and the relationship between the two. The way
I would interpret this is that implementers are not intending to change
the definition of the coordinate reference systems used from EPSG.
Rather, lack of specificity in the standard, some misleading examples
(e.g. , 3.2.1), and old habit has led to common usage of fixing the axis
order of geographic coordinate systems at Lon, Lat when specifying the
relationship between raster space and model space, regardless of the CRS
definition. This only affects the encoding of the tags that describe
this relationship (ModelPixelScaleTag, ModelTiepointTag,
ModelTransformationTag) and adopters would be advised to observe this
convention if they want to achieve interoperability.

Perhaps this has an impact elsewhere and I am overlooking it.

Max

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Frank Warmerdam
Sent: Friday, December 17, 2010 12:15 PM
To: [hidden email]
Cc: GeoTIFF
Subject: Re: [Geotiff] [MetaCRS] question on GeoTiff axis order

On 10-12-17 11:43 AM, Martin Desruisseaux wrote:

> Hello Frank
>
> Thanks for your reply. I guess that "correct way" means "what the
> GeoTIFF standard said", and that standard at
> http://www.remotesensing.org/geotiff/spec/geotiff2.5.html seems to be
> silent about the axis order. The above page basically just make a
> reference to a list a tables, and the GeoTIFF table at
> ftp://ftp.remotesensing.org/geotiff/tables/horiz_cs.csv explicitely
> define
> (lat,long) axis order for 4326 and some other CRS.
>
>  From this point of view, the GeoTIFF specification seems to mandate
> (lat,long) axis order. I guess that this is not the intend. Maybe a
> note somewhere could at least put a warning (something like "while the

> GeoTIFF tables derived from the EPSG database put latitude before
> longitude, the common usage for raster data is to display north up and

> east on the right side"). While I admit that this is very fuzzy, it is

> actually hard to provide an accurate rule applicable also to polar
> area, South Africa, Australia, etc..., and I guess that no one have
the energy to produce an accurate specification at this time...

Martin,

My approach is to assume long/lat for geographic coordinate systems, but
(in theory at least) to honour EPSG axis order for projected coordinate
systems.  In theory, as the spec does not address axis order, you are
right that we ought to treat most GCSes as lat/long but the absolutely
foolhardyness of going against all current practice makes this
unreasonable.  My emotional response is largely due to the mayhem I saw
come out of pushing EPSG axis order for GCSes in WMS and beyond.

I agree that some clarification in the GeoTIFF FAQ would be helpful.  I
will endevour to add something there today.

I'm cc:ing the geotiff list since that is really where this discussion
should be. For those there who are interested the exchange is available
at:

   http://lists.osgeo.org/pipermail/metacrs/2010-December/thread.html

Best regards,
--
---------------------------------------+--------------------------------
---------------------------------------+------
I set the clouds in motion - turn up   | Frank Warmerdam,
[hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

_______________________________________________
Geotiff mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/geotiff
_______________________________________________
Geotiff mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/geotiff
Reply | Threaded
Open this post in threaded view
|

Re: [MetaCRS] question on GeoTiff axis order

johann sorel-2
In reply to this post by Frank Warmerdam
Hello,

I agree that it would be a huge work to fix everything.
Still I am what we could call part of the 'new' generation of GIS
developers (only 25 years old, doing gis since 4years ago).
I first discover the problem when working on WMS, a big mess without
axis order which is not clearly define even today with the wms 2 working
group going on. Before that I was always working using the strict EPSG,
considering others as anomalies.
I don't know what happened in the past to make things the way they are
today, from what I understand, the 'change' first occured in proj4 and
because it's widely used, the 'change' has spread. Something pretty
similar to the google pseudo mercator, just another anomaly which has
spread so widely that it can't be fixed anymore.
The way I see things, is that this ambigious case of axis order, the
futur generations will have it too ... frustrating and for me unacceptable.

At least I see a way to solve the problem concerning GeoTiff, since
there is nowhere in the tiff metadata tags where 'EPSG' is written, the
only thing written in the tags is the numeric code. We could declare a
new authority (which could be named LEPSG for LongitudeFirstEPSG) and
specify that geotiff relys on this authority. Nothing to change in the
code, no files to fix and no more ambiguity.
Just saying that geotiff rely on a  EPSG but with longitude first is not
enought, how do you define which ones are flipped ? at least a rule must
be given like the one given by frank, but does this rule matches all cases ?

My proposal is a bit naive and doesn't solve the problem for other
formats, but at least the problem would be stopped in geotiff.

johann sorel







Le 17/12/2010 20:01, Norm Olsen a écrit :

> Hello All . . .
>
> I'm on board with Frank on this one.  We certainly could go and redo all this to be the "correct way"; but at the cost of many man years of effort for virtually no benefit at all.  The end result after experiencing many years of agony and pain would be pretty much what we have now as technology advancement would have to take a big hit to provide the resources to achieve "axis order correctness".
>
> Virtually every GIS/CAD/CAM system expects the first ordinate of a coordinate array to increase to the east, and the second ordinate to increase to the north, and the third ordinate (if present) to increase away from the center of the earth.
>
> While it is nice to be "correct", the price of "correcting" 30 years of software development makes this idea unthinkable.
>
> Norm Olsen
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Martin Desruisseaux
> Sent: Friday, December 17, 2010 10:33 AM
> To: [hidden email]; [hidden email]
> Subject: Re: [MetaCRS] question on GeoTiff axis order
>
> Le 17/12/10 18:15, Frank Warmerdam a écrit :
>> My approach is to assume long/lat for geographic coordinate systems, but
>> (in theory at least) to honour EPSG axis order for projected coordinate
>> systems.
> This rule sound a nice compromise to me: unambiguous while simple, and probably
> matching a majority of common practices :). Thanks for the clarification.
>
>
>> I'm cc:ing the geotiff list since that is really where this discussion
>> should be.
> The http://www.remotesensing.org/geotiff/faq.html#Status FAQ entry gave us the
> feeling that the GeoTIFF mailing list was not active anymore, but I think that
> we have misunderstood this FAQ entry.
>
> Martin
> _______________________________________________
> MetaCRS mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/metacrs
> _______________________________________________
> MetaCRS mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/metacrs
>

_______________________________________________
Geotiff mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/geotiff