[Java-collab] Re: CRS axis issues (Was: Introduction and a few suggestions on recent topics)

[Matthias Basler]

> BTW, is it just me who thinks that getOrd0()/get0() should return the
> first ordinate (and not getOrd1()/get1())? I
> guess, we should also have a corresponding getOrd(int) method, and I
> personally think that counting here should start at
> 0 (as in arrays, collections, etc.).

Agreed.
It should be zero-based as usual in the strange world of computers. ;-)

> Actually, I was just thinking of one of the most simple use case:
> 
> 1. Parse GML 2 into geometry objects
> 2. Write out GML 3.2.1
> 
> I don't see why this should fail just because the srsName attributes in
> the input could contain a custom-made SRS. We
> currently do this by attaching the CRS wrapper with the geometry
> (and not the CRS object itself). Only when operations
> are performed that require CRS-awareness, the actual CRS object is
> resolved. If however, the user wants to be informed
> on CRS problems right away, the parser or the geometry factory
> could well be configured to operate strict (as you
> suggest below) and resolve all CRS objects in the wrappers right away.

Agreed, again.

Actually I think this could be handled by having two (Runtime?)Exceptions:
- NoSuchAxisException and
- MissingCRSException
(maybe derived from a common super class)

The former could be thrown in a case where (f.e.) getX() is called by the CRS does not define such axis because it is f.e. using polar coordinates.

The latter could be thrown when the geometry has no CRS attached at all, as you suggest it should be possible.

In your above use case a GMX3.2.1 writer could read out the CRS, could catch the MissingCRSException and write a <null> SRS.

(Or by using a CRS wrapper like the CRSInfo class I suggest to add a "hasCRS()" method, which would probably more efficient than creating thousands of exceptions.
-- 
Matthias Basler
matthiasbasler at earthflight.org