[Java-collab] First contents in osgeom repository

[Markus Schneider]

Hello Ugo,

Ugo Taddei wrote:

>>> Although not mentioned in your list (and I don't have the code to
>>> check at work here). I would like to comment on Point:
>>> - I want to be sure we don't have getX() and getY(). The have caused
>>> so much confusion in letting people assume x/y even when their
>>> coordinate system is radial; or happens to be in y/x order etc... I
>>> would like to remove these methods and just have get( int
>>> )/getOrdiante( int ) etc...
>>
>> You're absolutely right, I fixed that in the SVN already. I went for
>> Point#get0(), Point#get1(), Point#get2() and
>> Point#get(int) because these are methods that are used very, very
>> often and should have short names.
>>
> 
> I don't agree with the point being made here, sorry. I find getX() and
> getY() clearer (and less cumbersome), and I reckon this is what people
> expect to find *most of the time*. I haven't worked with radial CRSs,
> and never came across a CRS with "inverted" axes (though I know they
> exist and have been a source of headache for everyone), so folks working
> with those please understand and correct me.

I definitely see you're point -- working with x and y as ordinate identifiers is just what people are used to. But I
think that it is also the source of many errors and unclear code when working with georeferenced geometries.

Actually, I think that stumbled about the issue of inverted axes already in day-to-day use-cases. Just consider a
gml:Point using the common EPSG:4326:

<Point srsName="http://www.opengis.net/gml/srs/epsg.xml#4326">
  <pos>50.72 7.12</pos>
</Point>

This point is located at 50.72 degrees northern latitude and 7.12 degrees eastern longitude (Bonn). If our Point class
now offers #getX() and #getY() (and we assume that the first value in the pos element would always be interpreted as X),
consider the following code:

double x = p.getX();
double y = p.getY();

So x will be 50.72 and y 7.12. IMHO, this is counterintuitive and may also lead to wrong assumptions/code. Imagine that
the user wants to plot the point by projecting it into a window. He would end up calculating the x value of the pixel
using the y value of the point...

Of course, it would be possible to make the getX() and getY() methods CRS-aware, so they would return the values of the
expected axes. I see two problems with this approach:

- What if you want to work with a geometry that does not have any CRS information at all (or refers to an unknown one)?
We cannot offer getX() and getY() with the expected semantic then.
- x and y are usually associated with distances to the origin of a coordinate system. And for angular CRS (like
EPSG:4326), this is not really true: x and y would be angular values. If you offer getX() and getY(), this would impose
the notion that a length is returned.

For the above reasons, I would rather not make the get-ordinates methods CRS-aware and just keep the methods get0(),
get1(), etc. as they are now. It may be not what a user expects at first, but it also does not lead the user to wrong
assumptions and wrong code.

Of course, we could also add the methods #getX() and #getY() that return the easting and northing in a CRS-aware
fashion. But this will only work for geometries with CRS information and will be a bit slower than #get0() and #get1().

Best regards,
Markus

P.S.: To be fair I should add that many systems actually use switched axes when working with EPSG:4326, so you may very
well find something like:

<Point srsName="EPSG:4326">
  <pos>7.12 50.72</pos>
</Point>

AFAIK, GeoServer assumes correct axis orientation (latitude followed by longitude) when working with modern srs
specifiers like http://www.opengis.net/gml/srs/epsg.xml#4326 and falls back to a legacy mode (longitude then latitude)
when it encounters EPSG:4326. But I think this only enforces my argument that we should offer a clean way of dealing
with the ordinates and not introduce any simplifications that may introduce new problems.

"Make everything as simple as possible, but not simpler. (Albert Einstein)

-- 
Markus Schneider

l a t / l o n  GmbH
Aennchenstrasse 19           53177 Bonn, Germany
phone ++49 +228 184960       fax ++49 +228 1849629
http://www.lat-lon.de        http://www.deegree.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://lists.osgeo.org/pipermail/java-collab/attachments/20090820/18272c15/signature-0001.bin