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

Fri Aug 21 05:41:28 EDT 2009

Hi Matthias,

Matthias Basler wrote:
> Markus Schneider wrote:
> 
>> Nice idea. But what happens when a Point has no CRS information at all?
>> What does getX() return then?
> 
> I don't have this use case. But good you bring up this question. My opinion is: A geometry without CRS is *useless* in a GIS system and should not be allowed.
> I mean, without a CRS...
> - you cannot draw the features because you don't even know whether their coordinates are on perpendicular axes or are spherical coordinates
> - you don't know if two such features having similar coordinates are actually at the same place or not even near each other.
> 
> You an only *assume* some CRS (be it a "real" geographic/projected CRS or just a generic perpendicular XYZ coordinate system), and in this case you could as well attach this assumed CRS to the geometry instead of having a "null" CRS.
> 
> As a consequence, a GIS application usually has have a "default CRS". This could be handled in the factory, which could add the default CRS if non is specified in the input arguments for creating the geometry.

Right. I realize that having a default CRS is the other way to go. But you always risk that the default CRS is actually
not the intended one, so using null (or cleaner: a special CRS instance that represents 'unknown/unspecified') can have
advantages as well. E.g. if you parse a GML geometry without srsName attribute and pass it to a datastore layer to be
stored in a PostGIS DB (which may be configured with a default CRS), then it *could* be more practical to work with the
unknown CRS until the geometry actually gets stored in the backend (rather than having the geometry associated with a
default geometry that may not match this particular datastore).

> But back to getX(), getY() and getZ():
> I suggest to only return values here if the CRS actually uses perpendicular axes corresponding to
> - west/east, south/north and down/up
> - DISPLAY_LEFT/~RIGHT and DISPLAY_UP/~DOWN
> - maybe even GEOCENTRIC_X/~Y/~Z 
> or subsets thereof. I would throw an exception in any other case, e.g. for polar coordinates. This gives the caller a possibility to discover that he/she is likely about to do something stupid. ;-)
> Being too lenient with getX() and getY() will create only confusion, as the GeoTools developers know by experience.
> 
>> Interesting. However, I can imagine that this could actually become more
>> confusing than just using the original axis
>> order. Can you give an example for such an operation?
> 
> You provide it yourself: "... than just using the original axis".
> 
> If I take my preference of "X must actually mean west/east/x" as a base then creating a JTS geometry (which only knows X,Y and Z) can mean that
> (a) the coordinate axes might need swapping
> (c) it will throw an exception for polar coordinates or the like, since it isn't built for working with polar coordinates as X and Y.
> 
> You prefer the opposite, which is to assume that JTS X/Y correspond to axis 1 and 2. This can equally make sense for internal implementations of union operations and the like where the axis order of intermediate objects is often irrelevant for the result and not swapping the axes back and forth can improve the computational speed. 
> 
> So for methods like "toJTS(...)" we have two choices:
> - Give the programmer the ability to specify
>   how he wants the resulting axes OR
> - Decide on one of the choices, document it well and
>   hold on it throughout the API.
> 
> I'm for flexibility. Imho it won't make the API difficult to understand if the choice and its implications are *well documented*. A good API is not necessarily the one with the shortest method signatures, but one that is well documented and consistent!
> 
> (P.S. This is also why I think that get1(), get2() are short, but not necessarily intuitive for newbies. I came up with getOrd1(), getOrd2() as compromise. But it's not a big issue for me.)

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.).

 >>> - A coordinate reference system may be specified which is not known to
>> the {@link CRSRegistry}. However, for some operations this is not a
>> necessarily a problem, e.g. a GML document may be read and transformed into {@link
>> Feature} and {@link Geometry} objects.
> 
> Do I understand you correctly?
> Having a CRS identifier but not knowing how the CRS is defined? Difficult matter, this:
> 
> I mean, some operations like union between two such geometries should be possible, but interactions between geometries without/with a known CRS are undefined. Neither will it be possible to draw a map with them.
> 
> How should this be handled? Should the geometries throw errors in such cases? Or should they be lenient and use the "default CRS" (like above) in such cases, even if this is not the correct one?

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.

> Keeping the original "specified" CRS information seems reasonable in any case.
> 
> 
> Hmm...
> Somehow I wonder if there shouldn't be a global flag for "strict" CRS handling? I personally prefer a strict handling and I'd rather not allow any operations bases in unfounded assumptions CRS wise. Better not have a result than have one that's useless because wrong. Lenient solutions should not be handled in the geometry library but on an application level (like switching to another CRS when the application discovers that the data uses opposite axis order than specified in the CRS).

See above.

> Sorry for the long mail again.

No worries, thanks for the input :-)

Best regards,
Markus

-- 
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/20090821/715f2089/signature-0001.bin