[Geoserver-devel] srsName, urn:x-ogc vs urn:ogc (more headaches and long term decisions)

GeoServer GeoServer Developer
1

Hi,
not so short mail about a question that some people have been posing me lately,
on why GeoServer is not using the urn:ogc:... form for srsName (and
it's using the
old experimental urn:x-ogc one instead).

When WFS 1.1.0 specification came out, May 3 2005, they said (citing
from page 36):

---------------------------------------------------------------------------------------------------------------

Any valid URI value can be assigned to the srsName attribute. However,
in order to
enhance interoperability, a web feature service must be able to
process srsName attribute values with the following format models:
• EPSG:<EPSG code>
• http://www.opengis.net/gml/srs/epsg.xml#&lt;EPSG code>
• urn:EPSG:geographicCRC:<epsg code>

----------------------------------------------------------------------------------------------------------------

When it was time to create the cite tests and the reference implementation they
however made us implement the urn form following the syntax of the time:

urn:x-ogc:def:crs:EPSG:4326

where the x standard for "experimental" as IANA still did not have the
occasion to
approve its official usage. A June 2008 newsletter from OGC reports the IANA
approving the "ogc" NID as news, meaning "ogc" has been valid form for the
past 2.5 years.

The most recent document from OGC talking about the urn syntax is:
http://portal.opengeospatial.org/files/?artifact_id=30575
from January 2009 which reports the following syntax (mind the double
column), page 39:

-----------------------------------------------------------------------------------------------------------------

Specializing the above, the URN value for an anyURI that references one object
in the European Petroleum Survey Group (EPSG) database should have the form:
urn:ogc:def:objectType:EPSG::code

...

The URN value for CRS 2984 is:
urn:ogc:def:crs:EPSG::2984.

----------------------------------------------------------------------------------------------------------------

Now, in my opinion even today someone should be able to read the WFS spec
and implement it as is (standards should not morph over time, shouldn't they),
however I don't think any server implements WFS 1.1.0 as originally mandated.
Most use the urn:x-ogc form. Some use urn:ogc.

What about us, what shall we do? Eventually we'll have to switch to the urn:ogc
form as we implement newer versions of the standards which, hopefully, are going
to be a tad more explicit about it, and even more hopefully, a tad more stable.
In fact WFS 2.0 says (page 33):

-------------------------------------------------------------------------------------------------------------

Servers that implement this International Standard shall be able to process
srsName attribute values using the following format model:
• urn:ogc:def:crs:EPSG::<EPSG code> [(see OGC OGC 07-092r1)]
In this format model, the value <EPSG code> is a placeholders for actual
EPSG code values. EXAMPLE srsName="urn:ogc:def:crs:EPSG::26986”

--------------------------------------------------------------------------------------------------------------

Finally a bit of clarity. So, for WFS 2.0, when and if we implement it,
we're going to use the form suggested by the latest urn best practice.
Cool.
What are we going to do with WFS 1.1 then?

Make it a special case so that we continue to use urn:x-ogc, to avoid
changing our syntax below the client feet, or should we follow suit,
use urn:ogc:def:crs:EPSG::<EPSG code> also in WFS 1.1, get simpler code,
and redirect complaints about the change to OGC?

Cheers
Andrea

-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-----------------------------------------------------

2

Welcome to my nightmare :slight_smile:

I have been working with the cite group about this issue because the new versions of the cite tests require the urn:ogc syntax. But of courze geoserver uses the version that was originally mandated by the tests (urn:x-ogc).

At some point someone decided to file an issue in the cite bug tracker (non public) to change it. And they did. No other notification.

So I have been trying to argue that the both syntaxes should be supported. And the maintainers of the tests agree but it is a nightmare to modify those tests cases (xslt based) so it does not look promising.

They took a vote to the cite committee and it seems they will go on releasing the tests as is. With no regard for implementations like geoserver who worked to support the original version of the cite tests.

My objection that I made to the cite group was that geoserver cannot simply just change such things, no matter how small because people write code against gml output… and it leads to clients breaking. In the least we would need a major release of some sort of major release or something.

Anywise, all in all the cite situation seems grim. I don’t expect us to be able to upgrade to a newer version fo the tests for some time. There are other issues which seem to be falling on deaf ears.

All in all in my opinion for wfs 2.0 we should adopt the “approved” urn syntax. Well that is of course until it gets changed again without any notice. For wfs 1.1 as you say i think we should stick with what we have and possibly make it optional which srs style to use. We already have the config object for it. So we could add a second URN value easily, but then it becomes an issue of hooking it up the GML encoder.

-Justin

On Fri, Nov 12, 2010 at 1:30 AM, Andrea Aime <andrea.aime@anonymised.com68…> wrote:

Hi,
not so short mail about a question that some people have been posing me lately,
on why GeoServer is not using the urn:ogc:… form for srsName (and
it’s using the
old experimental urn:x-ogc one instead).

When WFS 1.1.0 specification came out, May 3 2005, they said (citing
from page 36):

Any valid URI value can be assigned to the srsName attribute. However,
in order to
enhance interoperability, a web feature service must be able to
process srsName attribute values with the following format models:
• EPSG:
• http://www.opengis.net/gml/srs/epsg.xml#
• urn:EPSG:geographicCRC:

When it was time to create the cite tests and the reference implementation they
however made us implement the urn form following the syntax of the time:

urn:x-ogc:def:crs:EPSG:4326

where the x standard for “experimental” as IANA still did not have the
occasion to
approve its official usage. A June 2008 newsletter from OGC reports the IANA
approving the “ogc” NID as news, meaning “ogc” has been valid form for the
past 2.5 years.

The most recent document from OGC talking about the urn syntax is:
http://portal.opengeospatial.org/files/?artifact_id=30575
from January 2009 which reports the following syntax (mind the double
column), page 39:

Specializing the above, the URN value for an anyURI that references one object
in the European Petroleum Survey Group (EPSG) database should have the form:
urn:ogc:def:objectType:EPSG::code

…

The URN value for CRS 2984 is:
urn:ogc:def:crs:EPSG::2984.

Now, in my opinion even today someone should be able to read the WFS spec
and implement it as is (standards should not morph over time, shouldn’t they),
however I don’t think any server implements WFS 1.1.0 as originally mandated.
Most use the urn:x-ogc form. Some use urn:ogc.

What about us, what shall we do? Eventually we’ll have to switch to the urn:ogc
form as we implement newer versions of the standards which, hopefully, are going
to be a tad more explicit about it, and even more hopefully, a tad more stable.
In fact WFS 2.0 says (page 33):

Servers that implement this International Standard shall be able to process
srsName attribute values using the following format model:
• urn:ogc:def:crs:EPSG:: [(see OGC OGC 07-092r1)]
In this format model, the value is a placeholders for actual
EPSG code values. EXAMPLE srsName="urn:ogc:def:crs:EPSG::26986”

Finally a bit of clarity. So, for WFS 2.0, when and if we implement it,
we’re going to use the form suggested by the latest urn best practice.
Cool.
What are we going to do with WFS 1.1 then?

Make it a special case so that we continue to use urn:x-ogc, to avoid
changing our syntax below the client feet, or should we follow suit,
use urn:ogc:def:crs:EPSG:: also in WFS 1.1, get simpler code,
and redirect complaints about the change to OGC?

Cheers
Andrea

Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

3

On Fri, Nov 12, 2010 at 4:29 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Welcome to my nightmare :slight_smile:
I have been working with the cite group about this issue because the new
versions of the cite tests require the urn:ogc syntax. But of courze
geoserver uses the version that was originally mandated by the tests
(urn:x-ogc).
At some point someone decided to file an issue in the cite bug tracker (non
public) to change it. And they did. No other notification.
So I have been trying to argue that the both syntaxes should be supported.
And the maintainers of the tests agree but it is a nightmare to modify those
tests cases (xslt based) so it does not look promising.
They took a vote to the cite committee and it seems they will go on
releasing the tests as is. With no regard for implementations like geoserver
who worked to support the original version of the cite tests.
My objection that I made to the cite group was that geoserver cannot simply
just change such things, no matter how small because people write code
against gml output... and it leads to clients breaking. In the least we
would need a major release of some sort of major release or something.
Anywise, all in all the cite situation seems grim. I don't expect us to be
able to upgrade to a newer version fo the tests for some time. There are
other issues which seem to be falling on deaf ears.

Holy cow...

All in all in my opinion for wfs 2.0 we should adopt the "approved" urn
syntax. Well that is of course until it gets changed again without any
notice.

Ha! Hopefully they will get some sense and stop changing the spec after
publishing them :wink:

For wfs 1.1 as you say i think we should stick with what we have
and possibly make it optional which srs style to use. We already have the
config object for it. So we could add a second URN value easily, but then it
becomes an issue of hooking it up the GML encoder.

I guess we can pass down a hint and have it flow down to the gml2 utility
class via the pico context (or the map, not sure what we have today).
Or (brace yourself) setup a thread local that contains that info and
that's picked
up by the gml2 utility part dealing with encoding the srs encoding.

Parsing wise we're good, referencing already supports the new notation

To be honest, I'm not sure how many clients we're going to break by just
going with the new syntax. I mean, a reusable client already has to deal
with the two syntaxes, and if I were to implement a parser I would simply
check if it starts with urn:, skip all the crap until the last column, get
the number and move on.
We'd break only the clients that check for urn:x-ogc explicitly, which hopefully
are a minority. In fact some of the complaints I got come from people that
are implementing clients and would like us to see use only urn:ogc:...

Just saying. I agree the right thing to do as a server is not to break
compatibility
or at least put the admin in control of that.

Cheers
Andrea

-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-----------------------------------------------------

4

On Fri, Nov 12, 2010 at 9:03 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Fri, Nov 12, 2010 at 4:29 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Welcome to my nightmare :slight_smile:
I have been working with the cite group about this issue because the new
versions of the cite tests require the urn:ogc syntax. But of courze
geoserver uses the version that was originally mandated by the tests
(urn:x-ogc).
At some point someone decided to file an issue in the cite bug tracker (non
public) to change it. And they did. No other notification.
So I have been trying to argue that the both syntaxes should be supported.
And the maintainers of the tests agree but it is a nightmare to modify those
tests cases (xslt based) so it does not look promising.
They took a vote to the cite committee and it seems they will go on
releasing the tests as is. With no regard for implementations like geoserver
who worked to support the original version of the cite tests.
My objection that I made to the cite group was that geoserver cannot simply
just change such things, no matter how small because people write code
against gml output… and it leads to clients breaking. In the least we
would need a major release of some sort of major release or something.
Anywise, all in all the cite situation seems grim. I don’t expect us to be
able to upgrade to a newer version fo the tests for some time. There are
other issues which seem to be falling on deaf ears.

Holy cow…

All in all in my opinion for wfs 2.0 we should adopt the “approved” urn
syntax. Well that is of course until it gets changed again without any
notice.

Ha! Hopefully they will get some sense and stop changing the spec after
publishing them :wink:

Don’t count on it :wink:

For wfs 1.1 as you say i think we should stick with what we have
and possibly make it optional which srs style to use. We already have the
config object for it. So we could add a second URN value easily, but then it
becomes an issue of hooking it up the GML encoder.

I guess we can pass down a hint and have it flow down to the gml2 utility
class via the pico context (or the map, not sure what we have today).
Or (brace yourself) setup a thread local that contains that info and
that’s picked
up by the gml2 utility part dealing with encoding the srs encoding.

Yeah… i actually thought about the thread local approach as well. Although I guess since we already pass down some other parameters like whether to encode bounding boxes and the like, this could follow the same pattern.

Parsing wise we’re good, referencing already supports the new notation

To be honest, I’m not sure how many clients we’re going to break by just
going with the new syntax. I mean, a reusable client already has to deal
with the two syntaxes, and if I were to implement a parser I would simply
check if it starts with urn:, skip all the crap until the last column, get
the number and move on.
We’d break only the clients that check for urn:x-ogc explicitly, which hopefully
are a minority. In fact some of the complaints I got come from people that
are implementing clients and would like us to see use only urn:ogc:…

Just saying. I agree the right thing to do as a server is not to break
compatibility
or at least put the admin in control of that.

Yeah, I totally agree. It probably would not turn out to be a huge deal but the real bother is that the compliance testing and cite committee feels they can just change such things mid stream with no consequences. And it worries me about what they will change next. So maybe it is silly to make such a stink over it but I feel is geoserver (the original reference implementation of wfs 1.0 and wfs 1.1) stands up and says enough is enough maybe someone will listen… probably just a pipe dream though. Here is hoping a simpler feature service gets some good following :slight_smile:

Cheers
Andrea

Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

5

Welcome to _my_ nightmare :-)!

There is a lot, a LOT, of debate at the moment about optimal form of
identifiers - see the UK Location Strategy for example. EPSG as an
entity no longer exists - making things fun...

I think we can only cope by addressing the reality - the concept we
are identifying has a canonical local representation we can do
something with (i.e. Geoserver chooses an internal form) - and we just
have to accept that there will be multiple, and changing, external
flavours. Any URI with an organisation name it is is inherently
fragile.

my concern would be if we're too tightly bound to something that we
have no legitimate reason to have a stable contract with, and on a
certain timescale thats URIs - since the architecture of the Web is
still evolving, and these are fundamental.

All we can do IMHO is to take opportunities to make controlled
vocabularies more configurable. I guess the challenge is to make the
parsing more configurable - but maybe we should forget it and just
make it a lookup? Then give Geoserver the tools to import a new
vocabulary and a cross walk to one of its known (already loaded)
vocabularies?

Rob

On Mon, Nov 15, 2010 at 7:54 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

On Fri, Nov 12, 2010 at 9:03 AM, Andrea Aime <andrea.aime@anonymised.com>
wrote:

On Fri, Nov 12, 2010 at 4:29 PM, Justin Deoliveira <jdeolive@anonymised.com>
wrote:
> Welcome to my nightmare :slight_smile:
> I have been working with the cite group about this issue because the new
> versions of the cite tests require the urn:ogc syntax. But of courze
> geoserver uses the version that was originally mandated by the tests
> (urn:x-ogc).
> At some point someone decided to file an issue in the cite bug tracker
> (non
> public) to change it. And they did. No other notification.
> So I have been trying to argue that the both syntaxes should be
> supported.
> And the maintainers of the tests agree but it is a nightmare to modify
> those
> tests cases (xslt based) so it does not look promising.
> They took a vote to the cite committee and it seems they will go on
> releasing the tests as is. With no regard for implementations like
> geoserver
> who worked to support the original version of the cite tests.
> My objection that I made to the cite group was that geoserver cannot
> simply
> just change such things, no matter how small because people write code
> against gml output... and it leads to clients breaking. In the least we
> would need a major release of some sort of major release or something.
> Anywise, all in all the cite situation seems grim. I don't expect us to
> be
> able to upgrade to a newer version fo the tests for some time. There are
> other issues which seem to be falling on deaf ears.

Holy cow...

> All in all in my opinion for wfs 2.0 we should adopt the "approved" urn
> syntax. Well that is of course until it gets changed again without any
> notice.

Ha! Hopefully they will get some sense and stop changing the spec after
publishing them :wink:

Don't count on it :wink:

> For wfs 1.1 as you say i think we should stick with what we have
> and possibly make it optional which srs style to use. We already have
> the
> config object for it. So we could add a second URN value easily, but
> then it
> becomes an issue of hooking it up the GML encoder.

I guess we can pass down a hint and have it flow down to the gml2 utility
class via the pico context (or the map, not sure what we have today).
Or (brace yourself) setup a thread local that contains that info and
that's picked
up by the gml2 utility part dealing with encoding the srs encoding.

Yeah... i actually thought about the thread local approach as well. Although
I guess since we already pass down some other parameters like whether to
encode bounding boxes and the like, this could follow the same pattern.

Parsing wise we're good, referencing already supports the new notation

To be honest, I'm not sure how many clients we're going to break by just
going with the new syntax. I mean, a reusable client already has to deal
with the two syntaxes, and if I were to implement a parser I would simply
check if it starts with urn:, skip all the crap until the last column, get
the number and move on.
We'd break only the clients that check for urn:x-ogc explicitly, which
hopefully
are a minority. In fact some of the complaints I got come from people that
are implementing clients and would like us to see use only urn:ogc:...

Just saying. I agree the right thing to do as a server is not to break
compatibility
or at least put the admin in control of that.

Yeah, I totally agree. It probably would not turn out to be a huge deal but
the real bother is that the compliance testing and cite committee feels they
can just change such things mid stream with no consequences. And it worries
me about what they will change next. So maybe it is silly to make such a
stink over it but I feel is geoserver (the original reference implementation
of wfs 1.0 and wfs 1.1) stands up and says enough is enough maybe someone
will listen... probably just a pipe dream though. Here is hoping a simpler
feature service gets some good following :slight_smile:

Cheers
Andrea

-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-----------------------------------------------------

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

6

On 13/11/10 00:03, Andrea Aime wrote:

On Fri, Nov 12, 2010 at 4:29 PM, Justin Deoliveira<jdeolive@anonymised.com> wrote:

All in all in my opinion for wfs 2.0 we should adopt the "approved" urn
syntax. Well that is of course until it gets changed again without any
notice.

I have a PowerPoint from Peter Vretanos (WFS 2.0 editor) that states that in WFS 2.0:

"Mandatory supported CRS format for EPSG codes is: urn:ogc:def:crs:EPSG::<code>"

(Justin, I think I sent this to you. OGC members can see it in Pending Documents in the portal. [Doc number 10-148, file 10-148_2010_WFS_and_FES_Revision_Summary.ppt])

As an aside, it goes on to state:

"Coordinate order is defined by the payload being used not the WFS specification
- For the canonical payload (i.e. GML v3.2.1) this means that for EPSG code 4326 the coordinate order is lat / lon.
- Other payloads may define something else; for example GeoJSON defines the coordinate order as lon / lat (always)"

Kind regards,

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineering Team Leader
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

7

On Mon, Nov 15, 2010 at 3:50 AM, Ben Caradoc-Davies
<Ben.Caradoc-Davies@anonymised.com> wrote:

On 13/11/10 00:03, Andrea Aime wrote:

On Fri, Nov 12, 2010 at 4:29 PM, Justin Deoliveira<jdeolive@anonymised.com> wrote:

All in all in my opinion for wfs 2.0 we should adopt the "approved" urn
syntax. Well that is of course until it gets changed again without any
notice.

I have a PowerPoint from Peter Vretanos (WFS 2.0 editor) that states
that in WFS 2.0:

"Mandatory supported CRS format for EPSG codes is:
urn:ogc:def:crs:EPSG::<code>"

(Justin, I think I sent this to you. OGC members can see it in Pending
Documents in the portal. [Doc number 10-148, file
10-148_2010_WFS_and_FES_Revision_Summary.ppt])

As an aside, it goes on to state:

"Coordinate order is defined by the payload being used not the WFS
specification
- For the canonical payload (i.e. GML v3.2.1) this means that for EPSG
code 4326 the coordinate order is lat / lon.
- Other payloads may define something else; for example GeoJSON defines
the coordinate order as lon / lat (always)"

Ben, if you read the WFS 1.1 specification they mandated three syntaxes,
then did a U turn and started using a different one and then they changed its
syntax again.

If history taught us something is that a written, voted and published
specification
is not stopping them from changing their mind (nothing wrong with that) and
forcing implementors of published specs to follow instead of just issuing a new
spec with the amendments (bzzt, wrong!)

Cheers
Andrea

Kind regards,

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineering Team Leader
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-----------------------------------------------------