Just as I feared: option (2) causes a GeoServer request with srsName=http://www.opengis.net/def/crs/EPSG/0/4326 to return a response with srsname="http://www.opengis.net/gml/srs/epsg.xml#4326"; and longitude/latitude order.
The underlying cause (I think) is that HTTP_AuthorityFactory is configured with Hints: FORCE_LONGITUDE_FIRST_AXIS_ORDER = true FORCE_AXIS_ORDER_HONORING = http Just as described in the javadoc for Hints.FORCE_AXIS_ORDER_HONORING, this causes longitude/latitude order, even for my HTTP URI srsName. It looks like HTTP_AuthorityFactory is locked to one axis order convention. Any objection to me implementing option (1), that is, changing Citations.HTTP_OGC so I can put in another factory for HTTP URI srsName? Kind regards, Ben. On 31/07/12 17:57, Ben Caradoc-Davies wrote: > Current OGC policy is for srsName to be encoded as an HTTP URI: > http://www.opengis.net/def/crs/EPSG/0/4326 > > We currently support parsing HTTP srsNames in the GML 2 form: > http://www.opengis.net/gml/srs/epsg.xml#4326 > > This is done by HTTP_AuthorityFactory. The authority for this form, set > in Citations.HTTP_OGC, is "http://www.opengis.net";. > > The problem is that ManyAuthoritiesFactory assumes that the correct > factory for an srsName can be found by matching the start of the srsName > against the authority for the factory. This assumption prevents me from > adding a second factory for "http://www.opengis.net/def/crs/"; because > these URIs will also be matched by HTTP_AuthorityFactory. > > I can either: > (1) Change the authority of Citations.HTTP_OGC from > "http://www.opengis.net"; to "http://www.opengis.net/gml/srs/"; so that I > can add a new factory with authority "http://www.opengis.net/def/crs/";, or > (2) Hack HTTP_AuthorityFactory to support the new form. > > Option (1) appears to be the cleanest because it preserves the > one-factory-per-form pattern. However, it will break any third-party > code that depends on the authority identifier, making it a > backwards-incompatible change. > > Option (2) would be quite straightforward, but I am worried about hidden > magic axis-order behaviour. For historical reasons (we can still see the > scars), the GML 2 form is treated as having longitude/latitude axis > order by applications such as GeoServer: > http://docs.geoserver.org/latest/en/user/services/wfs/basics.html#axis-ordering > > I do not know where this conversion occurs. Does anyone know of using > HTTP_AuthorityFactory to parse the new HTTP URI form > http://www.opengis.net/def/crs/EPSG/0/4326 would cause the resulting CRS > it to have longitude/latitude axis order? (It is meant to have > latitude/longitude axis order.) There is some code in > HTTP_AuthorityFactory.defaultAxisOrderHints, but I do not understand > what it does nor how it is used. > > I will be writing unit tests to gather evidence. > > For more discussion on why we need HTTP URIs, see: > https://jira.codehaus.org/browse/GEOT-4160 > > Kind regards, > -- Ben Caradoc-Davies <ben.caradoc-dav...@csiro.au> Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
