Hi Justin,
before you go away for vacation I'd like to hear your opinion
on the group of issues I've opened against the axis order stuff.
About http://jira.codehaus.org/browse/GEOS-1440, it seems to me
the actual GML3 type bindings do not have the same CRS inheritance stuff
we added in AbstractGeometryTypeBinding. Which makes me wonder a little... AbstractGeometryTypeBinding is in GML3, but nothing inherits
from it, MultiSurfaceTypeBinding for example does not have the CRS
inheritance and extends AbstractComplexBinding... isn't this strange?
Where is the missing link?
In issues like GEOS-1439, GEOS-1435 and GEOS-1437 we have the problem of jumping between srs names and CoordinateReferneceSystem objects because the Envelope binding parses the srs into a CoordinateReferenceSystem object, but in order to build a bbox filter we need the srs back.
I guess we should use GML3EncodingUtils.crs(CRS), but modify it
so that it returns "urn:xxx" or "epsg:xxxx" depending on the actual
axis order. What do you think?
Issues like GEOS-1441 and GEOS-1436
raise the point of knowing what is the
declared CRS. In WFS 1.0 we do declare EPSG:4326, in 1.1
urn:x-ogc:def:crs:EPSG:6.11.2:4326 so the axis order is swapped.
What is needed is an utility allowing to know how a particular
internal crs has been declared to the outside world.
Where do we place such an utility method?
I was thinking the WFS class, but it's mostly configuration.
Anyways, GEOS-1441 is about encoding, so that method should
be visible on the GetFeature class, whilst 1436 is about parsing,
and there I guess we should grab the declared crs as soon as
we know the feature type and inject it in the parsing context,
so utility should be visible from QueryTypeBinding (the only
binding that gets to see the typeName).
Cheers
Andrea