[Geoserver-devel] WMS GetFeatureInfo GML output

Hi,

I am currently working on making WMS compatible with app-schema (complex features).
I noticed that GetFeatureInfo can only output GML 2 (when choosing gml as output format). However complex features can’t be encoded in GML2, only GML3.

Somehow GML3 will have to be supported in GetFeatureInfo to be able to support complex features. But how would be configured which version to use ? (without changing request specifications!)

Ben Caradoc-Davies has suggested that it shouldn’t really be the user who specifies which version of GML to use. He has suggested that depending on which feature type is being returned, an appropriate (default?) version should be chosen or suggested by the data provider. Also considering that different versions of geosciml run on different versions of gml. This would hit the core of geotools, though. But Ben can probably explain this part better.

AnY thoughts?

···


Niels Charlier

Software Engineer
CSIRO Earth Science and Resource Engineering
Phone: +61 8 6436 8914

Australian Resources Research Centre
26 Dick Perry Avenue, Kensington WA 6151

Yeah, the mime type for gml output for GetFeatureInfo was not really though out with regard to gml versions. “application/vnd.ogc.gml” is ambiguous.

Ideally choosing the output format would follow the way other output formats do it and just use a different mime type. “text/xml; subtype=gml/2.1.2” vs “text/xml; subtype=gml/3.1.1”, etc… Choosing output format based on backend data source could work… albeit a bit tricky. And I think it is nicer to be explicit.

I could also see a configuration option that allowed the admin to control whether gml2 or gml3 is used for the “application/vnd.ogc.gml” mime type.

2c.

-Justin

On Wed, Nov 17, 2010 at 2:17 AM, Niels niels.charlier@anonymised.com wrote:

Hi,

I am currently working on making WMS compatible with app-schema (complex features).
I noticed that GetFeatureInfo can only output GML 2 (when choosing gml as output format). However complex features can’t be encoded in GML2, only GML3.

Somehow GML3 will have to be supported in GetFeatureInfo to be able to support complex features. But how would be configured which version to use ? (without changing request specifications!)

Ben Caradoc-Davies has suggested that it shouldn’t really be the user who specifies which version of GML to use. He has suggested that depending on which feature type is being returned, an appropriate (default?) version should be chosen or suggested by the data provider. Also considering that different versions of geosciml run on different versions of gml. This would hit the core of geotools, though. But Ben can probably explain this part better.

AnY thoughts?


Niels Charlier

Software Engineer
CSIRO Earth Science and Resource Engineering
Phone: +61 8 6436 8914

Australian Resources Research Centre
26 Dick Perry Avenue, Kensington WA 6151


Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev


Geotools-devel mailing list
Geotools-devel@anonymised.coms.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel


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

On Wed, Nov 17, 2010 at 4:25 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Yeah, the mime type for gml output for GetFeatureInfo was not really though
out with regard to gml versions. "application/vnd.ogc.gml" is ambiguous.
Ideally choosing the output format would follow the way other output formats
do it and just use a different mime type. "text/xml; subtype=gml/2.1.2" vs
"text/xml; subtype=gml/3.1.1", etc... Choosing output format based on
backend data source could work... albeit a bit tricky. And I think it is
nicer to be explicit.
I could also see a configuration option that allowed the admin to control
whether gml2 or gml3 is used for the "application/vnd.ogc.gml" mime type.

Sigh, tricky issue, sounds like we're going to get screwed some way or the
other.

WMS 1.1 was created when only GML2 was around, I guess that's the
reason why they did not bother to specify the version (did GML1 ever
see the light of day?).

Wondering what's the practice in the wild? Afaik given than mime type
everybody is going to expect GML2, never seen it done differently.

WMS 1.3 does not even provide a mime type guidance for feature type
info afaik (and even for WMS 1.1 it was a set of suggestions, but they
did stick with implemetations), you are just free to do whatever you
want.

Whoever is using complex features today is breaking new grounds anyways,
meaning it's dealing with custom written clients, the out of the box
ones more often than not cannot deal with them.

The configuration idea might work, but what I've seen in practice
is that servers providing complex features are either working
in an academic or niche setup, or they have to provide both
complex features and then flat views of the former that provide
a simple feature interface to the same data (the first to abide to
a standard, the latter to actually be usable by the most common
OGC clients).
Going out with GML3 might please
the few that root for complex features but will break all
other clients. At the very least the choice should be per
layer, not per server, so that the setup that try to compromise
between complex features and common needs can still
work.

My suggestion: create an explicitly mime type for GML2 and GML3
and let the old mime type be used for what it has always been
used, that is, GML2. Don't go break established expectations,
spec may be ambigous, but industry practice does not look like
it is. At least, as far as I know. Glad to be proved wrong: what server
is returning GML3 out of a GetFeatureInfo when the request
says application/vnd.ogc.gml? What WMS clients can actually
deal with GML3 as a feature info response?

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

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

The underlying problem is that for complex features, the target GML version is determined by the target schema, which is chosen by the data provider and not the client. For example, a GeoSciML 2.0 feature type *must* be delivered in GML 3.1.1, while a GeoSciML 3.0 feature type *must* be delivered in GML 3.2.1. The client cannot request a different format.

GeoServer currently assumes that output format is orthogonal to data source. This does not hold for complex features.

It seems to me that it would be rather useful if a DataAccess could notify the catalog (FeatureTypeInfo) of the preferred/supported/required output format. I know WFS 1.1.1 is required to default to GML 3.1.1, but WFS 2.0 lists this restriction and opens the door to better communication between the DataAccess and the dispatcher in selecting an OutputFormat. A similar approach may be useful for WMS GetFeatureInfo.

On 17/11/10 23:25, Justin Deoliveira wrote:

Ideally choosing the output format would follow the way other output formats do it and just use a different mime type. "text/xml; subtype=gml/2.1.2" vs "text/xml; subtype=gml/3.1.1", etc... Choosing output format based on backend data source could work... albeit a bit tricky. And I think it is nicer to be explicit.

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

On 18/11/10 04:12, Andrea Aime wrote:

Going out with GML3 might please
the few that root for complex features but will break all
other clients. At the very least the choice should be per
layer, not per server, so that the setup that try to compromise
between complex features and common needs can still
work.

+1 for per-layer/featuretype configuration. Complex features will need different GML versions if a WFS provides types from different application schemas.

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

App-schema allows clients to use style sheets to deal with responses.
(Because its a known schema, a stylesheet can be published and used to
render it. I have build clients with catalogues of stylesheets for
each feature type - and no way would it be worth bother with ad-hoc
flat schemas). We build an entire enterprise content magement,
project tracking and time-sheeting system using WFS, and also Local
government facilities booking systems based on this,
off-theshelf-desktop GIS is the niche market here, compared to
business Web applications.

general purpose GIS clients arent particulary useful getFeatureInfo
endpoints anyway - enableing actual applications to be built with the
services is a higher priority.

if the describeFeaturetype response delivers a gml 3 schema,
getFeatureInfo should respect that for the same feature types -
otherwise how will a client ever know what to trust?

IMHO we should use the sub-typing mechanism to override these
defaults, and support both text/xml or application/vnd.ogc.gml mime
types to be forgiving.

Rob

On Thu, Nov 18, 2010 at 7:12 AM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

On Wed, Nov 17, 2010 at 4:25 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Yeah, the mime type for gml output for GetFeatureInfo was not really though
out with regard to gml versions. "application/vnd.ogc.gml" is ambiguous.
Ideally choosing the output format would follow the way other output formats
do it and just use a different mime type. "text/xml; subtype=gml/2.1.2" vs
"text/xml; subtype=gml/3.1.1", etc... Choosing output format based on
backend data source could work... albeit a bit tricky. And I think it is
nicer to be explicit.
I could also see a configuration option that allowed the admin to control
whether gml2 or gml3 is used for the "application/vnd.ogc.gml" mime type.

Sigh, tricky issue, sounds like we're going to get screwed some way or the
other.

WMS 1.1 was created when only GML2 was around, I guess that's the
reason why they did not bother to specify the version (did GML1 ever
see the light of day?).

Wondering what's the practice in the wild? Afaik given than mime type
everybody is going to expect GML2, never seen it done differently.

WMS 1.3 does not even provide a mime type guidance for feature type
info afaik (and even for WMS 1.1 it was a set of suggestions, but they
did stick with implemetations), you are just free to do whatever you
want.

Whoever is using complex features today is breaking new grounds anyways,
meaning it's dealing with custom written clients, the out of the box
ones more often than not cannot deal with them.

The configuration idea might work, but what I've seen in practice
is that servers providing complex features are either working
in an academic or niche setup, or they have to provide both
complex features and then flat views of the former that provide
a simple feature interface to the same data (the first to abide to
a standard, the latter to actually be usable by the most common
OGC clients).
Going out with GML3 might please
the few that root for complex features but will break all
other clients. At the very least the choice should be per
layer, not per server, so that the setup that try to compromise
between complex features and common needs can still
work.

My suggestion: create an explicitly mime type for GML2 and GML3
and let the old mime type be used for what it has always been
used, that is, GML2. Don't go break established expectations,
spec may be ambigous, but industry practice does not look like
it is. At least, as far as I know. Glad to be proved wrong: what server
is returning GML3 out of a GetFeatureInfo when the request
says application/vnd.ogc.gml? What WMS clients can actually
deal with GML3 as a feature info response?

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

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

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

On Thu, Nov 18, 2010 at 7:00 AM, Rob Atkinson <robatkinson101@anonymised.com> wrote:

App-schema allows clients to use style sheets to deal with responses.
(Because its a known schema, a stylesheet can be published and used to
render it. I have build clients with catalogues of stylesheets for
each feature type - and no way would it be worth bother with ad-hoc
flat schemas). We build an entire enterprise content magement,
project tracking and time-sheeting system using WFS, and also Local
government facilities booking systems based on this,
off-theshelf-desktop GIS is the niche market here, compared to
business Web applications.

general purpose GIS clients arent particulary useful getFeatureInfo
endpoints anyway - enableing actual applications to be built with the
services is a higher priority.

I disagree. GeoServer is for today production systems, R&D is important
for the future but should never be allowed to break production readiness
in common situations (app schema and complex features are good,
but they should not break our existing simple feature user base).
Before going on with such changes I suggest, as I already did in my
previous mail, to do a reality check and see what other server do
and what clients can accept, and come out with a solution that
does not make GeoServer an oddball existing systems cannot talk to.

if the describeFeaturetype response delivers a gml 3 schema,
getFeatureInfo should respect that for the same feature types -
otherwise how will a client ever know what to trust?

I think there is confusion here. GetFeatureInfo is for WMS, which
is a different service than WFS: one cannot simply go and assume
what is published by WFS has any influence over the WMS outputs.
The only link between the two, spec wise, is provided by the SLD
spec, which has the DescribeLayer call which in turn links
back to DescribeFeatureType (a WFS 1.0 one, btw).
However that is meant for clients
that need to build their own SLD, I don't recall ever seeing any
indication of a link between that and the GetFeatureInfo output.

Moreover, if you look at the WMS 1.3 spec you'll see that there
is no mention anymore of the output format that GetFeatureInfo
is supposed to support.

It would be easier, imho, to have some conventional name that
returns the gml in the app-schema form, and leave the WMS 1.1
suggested mime type be, possibly by returning some flattened
form of the complex feature, or nothing at all.

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

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

I think I've missed how this will break backward compatibility with
existing deployments, making the server respect the feature type
definition and canonical schema as defaults would leave things alone,
but allow new implementations to be richer. If old clients cant parse
new features, it still doesnt break old deployments, and client will
catch up.

but I do agree that it is a hole in the OGC architecture - its reather
weak on interoperability contracts between service operations -
capabilities docs are very ad-hoc.

Rob

On Thu, Nov 18, 2010 at 7:37 PM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

On Thu, Nov 18, 2010 at 7:00 AM, Rob Atkinson <robatkinson101@anonymised.com> wrote:

App-schema allows clients to use style sheets to deal with responses.
(Because its a known schema, a stylesheet can be published and used to
render it. I have build clients with catalogues of stylesheets for
each feature type - and no way would it be worth bother with ad-hoc
flat schemas). We build an entire enterprise content magement,
project tracking and time-sheeting system using WFS, and also Local
government facilities booking systems based on this,
off-theshelf-desktop GIS is the niche market here, compared to
business Web applications.

general purpose GIS clients arent particulary useful getFeatureInfo
endpoints anyway - enableing actual applications to be built with the
services is a higher priority.

I disagree. GeoServer is for today production systems, R&D is important
for the future but should never be allowed to break production readiness
in common situations (app schema and complex features are good,
but they should not break our existing simple feature user base).
Before going on with such changes I suggest, as I already did in my
previous mail, to do a reality check and see what other server do
and what clients can accept, and come out with a solution that
does not make GeoServer an oddball existing systems cannot talk to.

if the describeFeaturetype response delivers a gml 3 schema,
getFeatureInfo should respect that for the same feature types -
otherwise how will a client ever know what to trust?

I think there is confusion here. GetFeatureInfo is for WMS, which
is a different service than WFS: one cannot simply go and assume
what is published by WFS has any influence over the WMS outputs.
The only link between the two, spec wise, is provided by the SLD
spec, which has the DescribeLayer call which in turn links
back to DescribeFeatureType (a WFS 1.0 one, btw).
However that is meant for clients
that need to build their own SLD, I don't recall ever seeing any
indication of a link between that and the GetFeatureInfo output.

Moreover, if you look at the WMS 1.3 spec you'll see that there
is no mention anymore of the output format that GetFeatureInfo
is supposed to support.

It would be easier, imho, to have some conventional name that
returns the gml in the app-schema form, and leave the WMS 1.1
suggested mime type be, possibly by returning some flattened
form of the complex feature, or nothing at all.

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

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

On Thu, Nov 18, 2010 at 11:23 AM, Rob Atkinson <robatkinson101@anonymised.com> wrote:

I think I've missed how this will break backward compatibility with
existing deployments, making the server respect the feature type
definition and canonical schema as defaults would leave things alone,
but allow new implementations to be richer. If old clients cant parse
new features, it still doesnt break old deployments, and client will
catch up.

Please go back and read again the description of the mixed complex + simple
feature servers that I'm forced to setup today to ensure we can work
at the same time we the few ad hoc newer clients developed to support
complex features and app schema,
and the common simple feature oriented clients that are available in
the wild today.
I'm simply asking that we make sure that kind of compromise can keep
on working, since it's the only way to get some data interoperability
_today_ (with the practical definition of interoperabilty, that is, take a
client and check it works against the server, the more you can do that
with different clients, the higher the practical interoperability of your
service is).

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

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

So I guess what I will do for now is create a special mime type for GML3, which would then support app-schema. The old mime type would still return GML2, and produce an error if it is run against app-schema data.

Cheers
Niels

···


Niels Charlier

Software Engineer
CSIRO Earth Science and Resource Engineering
Phone: +61 8 6436 8914

Australian Resources Research Centre
26 Dick Perry Avenue, Kensington WA 6151