Add option to encode srsName as urn:ogc in WFS responses

I guess that we should use this new format by default for WFS 2.0, and have an option for WFS 1.1?
The rationale is that while OGC is in the business of chaning the specs after releasing them, we're not and follow what is specified in the original spec instead (but an admin that wants to break clients and follow OGC should be probably allowed to do that).

I think GeoServer already does the right thing in accepting both forms in queries. The old rule of interoperability is to be permissive in what you receive and strict in what you send. Adding a new format for responses would be the next step, and I agree that it would be best to allow the administrator to control this.

Simon C is advocating HTTP URIs of the form http://www.opengis.net/def/crs/EPSG/0/4283 and this is likely to be adopted as the new standard by the OGC-NA (hopefully not retrospectively this time!) [Incorrect and out of date. See Simon's email below.]. We could configure srsName style for each service version. So an admin might want urn:x-ogc for WFS 1.1, urn:ogc for WFS 2.0, and the HTTP URI for WFS 2.1.

Ugly. I'll have to think about it.

There was already a http form in WFS 1.0 that we still consider forcing in east/north order, I really do hope they are not getting it back with the same syntax and make it follow the same rules as the urn one instead!

Happily enough the WFS 1.0 one it's different: http://www.opengis.net/gml/srs/epsg.xml#xxxx

I think the new HTTP URI form is meant to be a structured controlled vocabulary. It should not be mistaken for the old WFS 1.0 form. As far as I know, it will respect the official axis order.

Simon would like to correct my remark above:

On 26/04/12 10:57, Cox, Simon (CESRE, Kensington) wrote:
>Ben wrote:
>> Simon C is advocating HTTP URIs of the form http://www.opengis.net/def/crs/EPSG/0/4283 and this is likely to be adopted as the new standard by the OGC-NA
>
> Actually this is out of date and incorrect.
>
> - OGC officially adopted http URIs for persistent identification of resources governed by OGC in June 2010.
> - This was a recommendation of the OGC-NA, but was a decision of the TC as a whole (the OGC-NA is formally a sub-committee of the TC so has an open membership and no independent decision making power).
> - This applies going forward. You can never kill a URI (e.g. a URN) that has already been used, but the intention is that only http URIs will be coined for new resources.

See also this WFS change request "Allow use of http URIs to identify CRS" (OGC 11-152, Simon Cox):
https://portal.opengeospatial.org/files/?artifact_id=46445

-------- Original Message --------
Subject: Re: [Geoserver-devel] wfs 1.1 cite update
Date: Thu, 24 May 2012 13:54:15 +0800
From: Ben Caradoc-Davies
To: Justin Deoliveira
CC: geoserver-devel@lists.sourceforge.net

On 24/05/12 12:39, Justin Deoliveira wrote:
> * New srs format
> Currently for wfs 1.1 we use the original srs urn syntax as specified in
> the original version of the wfs 1.1 spec. Which looks like:
> urn:x-ogc:def:crs:EPSG:4326
> The mandated format has been changed "mid-spec" and now the tests
> mandate that the format look like:
> urn:ogc:def:crs:EPSG::4326
> Note the "double colon" between the authority and code, that is not a typo.

Correct. This element is for the version of the EPSG database. In
general, urn:ogc versions are optional (hence the double colon), but OGC
insist on their inclusion in the case of EPSG: "The “version” part shall
be included in this case, since the EPSG sometimes deprecates and
replaces existing definitions." From: "URNs of definitions in ogc
namespace" (OGC 05-010):
https://portal.opengeospatial.org/files/?artifact_id=8814

I don't like this as it is yet another point of variation to confuse
clients. I am more than happy to have the version left blank, but this
might cause cite compliance problems later.

> So... what to do. As I see it we have a few options.
> (1) Update this across the board and just output the new form by default.
> (2) Only use this form when cite compliance is turned on.
> (3) Add this new form as a new possibility for GMLInfo.getSrsNameStyle()
> making it configurable to use the new style, updating the wfs 1.1 cite
> configuration to use the newest version and possibly keeping the default
> configuration using the existing style
> All in all I think (3) is probably the most ideal, but represents the
> most work. (1) is the easiest. Curious to here what people think about
> this one.

(1) may break existing clients.

(2) makes we worry that some users will be stuck with all
cite-compliance options when they only want one.

I like (3), which is also extensible to support the new HTTP URI form
(e.g. http://www.opengis.net/def/crs/EPSG/0/4326). You could also add
support for an OGC URN with EPSG version (e.g.
urn:ogc:def:crs:EPSG:6.3:4326). I suspect that (3) will put us in a
position to add new formats almost as fast as OGC can invent them.

Here are two current Jira issues:
https://jira.codehaus.org/browse/GEOT-3581
https://jira.codehaus.org/browse/GEOS-4545

Support in WFS for HTTP URIs like:

http://www.opengis.net/def/crs/EPSG/0/4326

is before the WFS/FES SWG and will likely be included in WFS 2.1. See:
"Allow use of http URIs to identify CRS" (WFS/FES change request 11-152):
https://portal.opengeospatial.org/files/?artifact_id=46445

Whitepaper:
"OGC Identifiers – the case for http URIs" (OGC 10-124r1):
https://portal.opengeospatial.org/files/?artifact_id=39467

HTTP URIs are current OGC policy:
"In June 2010 OGC revised the naming policy to use http URIs to identify
persistent OGC resources instead of URNs."
http://www.opengeospatial.org/projects/groups/ogcnasc

Youse might also be interested in Simon's recent seminar on controlled
vocabularies (slides and audio):
https://wiki.csiro.au/display/ARRCSeminars/Delivering+controlled+vocabularies+on+the+web+-+persistent+identifiers+and+the+web+of+things

Simon explains why HTTP URIs are useful because they allow the
implementation of Tim Berners-Lee's Linked (Open) Data rules, and
describes some successful patterns for using them.

Kind regards,

–
Ben Caradoc-Davies
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

Ok guys, here is the first cut of this patch, turned out to be bigger than I thought.

Justin, that patch is contains no changes; it looks like the output of diff used with --name-only.

Doh... sorry guys. This one should be good.

Do we expect to support HTTP URI style in requests? Is this done in a referencing plugin?

My understanding is that it's not part of this patch, as it's not required to get CITE tests work. Those that need such new schema should weight in with their own work time to implement it imho

It is just an SRS format. If I dared to venture into the referencing module ...

I noticed that urn:ogc format already works in requests. I should have a look and see where this is done, and how easy it would be to add HTTP URIs like:
http://www.opengis.net/def/crs/EPSG/0/4326

urn:ogc support in requests is provided by gt-referencing URN_AuthorityFactory. To support HTTP URIs we need an HTTP_URI_AuthorityFactory (not to be confused with HTTP_AuthorityFactory). We would also need SPI entries in:
modules/library/referencing/src/main/resources/META-INF/services/org.opengis.referencing.crs.CRSAuthorityFactory
modules/library/referencing/src/main/resources/META-INF/services/org.opengis.referencing.cs.CSAuthorityFactory

Yep, that sounds about right (and tests for the new factory, too). That is needed for parsing URIs, but then you'll also have to also support encoding them, which happens in XML land.

Yes; the encoding part is the thing that Justin has just implemented.

Committed the change for now. @Ben, can you open a separate issue for handling the syntax of the new "ogc http uri" structure.

Done: GEOT-4160: Support parsing srsName in OGC HTTP URI format.

Switching all issues that have been in "resolved" state for more than one month without further comments to "closed" status