[Java-collab] First contents in osgeom repository

[Ugo Taddei]

Hello Markus,

you're right. I don't know why, I keep assuming only hobbits have maps
where north is along the x axis
(http://www.douglas.eckhart.btinternet.co.uk/maps-thrors-map-01.jpg).

Seems logical to me to almost always think in terms of longitude -> x,
and latitude -> y because that's the way meridians and parallels are
oriented, respectively. Anyway, this is all based on conventions and
not worth the discussion here at such length. (For me it's anyway, getX 
== getOrd1; x is always the first ordinate, y the second, z the third, 
independent of how the CRS is oriented)

Apart from that, I'll take you're not being biased by the name of the
company you work for  ;-)

Keep up the good work.

Cheers,

Ugo

Markus Schneider wrote:
> 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)
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Java-collab mailing list
> Java-collab at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/java-collab