[Geoserver-devel] datastore implementation impact question re feature ids

GeoServer GeoServer Developer
1

Hey, just a question.

What would be the impact to geoserver if a datastore does not respect the convention of providing feature ids as .

I’m betting the only compromised feature for geoserver would be the WFS GetFeature request with featureId= parameter?

Also, am I right this is one of those kind of mandatory conventions, like the one for datastore factories to support a “namespace” parameter, but that are not set in stone anywhere?

The feature id issue bothers me since a while now and would like to gather opinions on whether it shouldn’t be mandatory for geotools datastores to prefix the feature ids that way. It looks to me like a WFS think leaking down to the data access layer, in order for GeoServer to be able of supplying unique ids at the service instance level, which in an ideal world should be GeoServer’s responsibility (like in GeoServer being in charge of prefixing the workspace + type name to the geotools provided feature id).

–
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

2

On 04/04/13 22:57, Gabriel Roldan wrote:

What would be the impact to geoserver if a datastore does not respect
the convention of providing feature ids as <simple type name>.<backend
identifier>

Gabriel, I don't think this is any sort of convention, just the current implementation.

I'm betting the only compromised feature for geoserver would be the WFS
GetFeature request with featureId= parameter?

app-schema DataAccess supports any valid gml:id (xs:NCNAME) and works correctly with featureid.

You wrote the ancestor of this plugin, back in 2006 or so. :slight_smile:

Also, am I right this is one of those kind of mandatory conventions,
like the one for datastore factories to support a "namespace" parameter,
but that are not set in stone anywhere?
The feature id issue bothers me since a while now and would like to
gather opinions on whether it shouldn't be mandatory for geotools
datastores to prefix the feature ids that way.

It is not. We already have one (app-schema) that does not.

It looks to me like a WFS
think leaking down to the data access layer, in order for GeoServer to
be able of supplying unique ids at the service instance level, which in
an ideal world should be GeoServer's responsibility (like in GeoServer
being in charge of prefixing the workspace + type name to the geotools
provided feature id).

+1.

In my view, anything that attempts to parse a featureid is relying on implementation behaviour, not a published interface.

A datastore should be free to use any (xs:NCNAME) feature id, as long as it is able to parse them from Query objects that it is given. WFS GetGmlObject is implemented by querying every data store that is a GmlObjectStore. This does raise the possibility of a feature id collision if two stores both provide features with the same id; this violates the WFS spec.

Kind regards,

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

3

Hey Ben thanks for the reply.

On Fri, Apr 5, 2013 at 2:09 AM, Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com254…> wrote:

On 04/04/13 22:57, Gabriel Roldan wrote:

What would be the impact to geoserver if a datastore does not respect
the convention of providing feature ids as .

Gabriel, I don’t think this is any sort of convention, just the current implementation.

I’m betting the only compromised feature for geoserver would be the WFS
GetFeature request with featureId= parameter?

app-schema DataAccess supports any valid gml:id (xs:NCNAME) and works correctly with featureid.

But does it even if typeName is not given to GetFeature? (I seem to remember typeName is optional for a featureId request?)

In any case, thanks for your insights, just what I needed to know.

Cheers,
Gabriel

You wrote the ancestor of this plugin, back in 2006 or so. :slight_smile:

Also, am I right this is one of those kind of mandatory conventions,
like the one for datastore factories to support a “namespace” parameter,
but that are not set in stone anywhere?
The feature id issue bothers me since a while now and would like to
gather opinions on whether it shouldn’t be mandatory for geotools
datastores to prefix the feature ids that way.

It is not. We already have one (app-schema) that does not.

It looks to me like a WFS
think leaking down to the data access layer, in order for GeoServer to
be able of supplying unique ids at the service instance level, which in
an ideal world should be GeoServer’s responsibility (like in GeoServer
being in charge of prefixing the workspace + type name to the geotools
provided feature id).

+1.

In my view, anything that attempts to parse a featureid is relying on implementation behaviour, not a published interface.

A datastore should be free to use any (xs:NCNAME) feature id, as long as it is able to parse them from Query objects that it is given. WFS GetGmlObject is implemented by querying every data store that is a GmlObjectStore. This does raise the possibility of a feature id collision if two stores both provide features with the same id; this violates the WFS spec.

Kind regards,

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

–
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

4

On Thu, Apr 4, 2013 at 4:57 PM, Gabriel Roldan <groldan@anonymised.com> wrote:

Hey, just a question.

What would be the impact to geoserver if a datastore does not respect the
convention of providing feature ids as <simple type name>.<backend
identifier>

The issue would just be that featureid in WFS GET has a lower chance to
work, since it becomes higher the probability to have a conflict, same id,
different store.
That said, even with the current setup it's not really impossible to have a
conflict, if you have two stores in different workspaces producing the same
ids.

The feature id issue bothers me since a while now and would like to gather
opinions on whether it shouldn't be mandatory for geotools datastores to
prefix the feature ids that way. It looks to me like a WFS think leaking
down to the data access layer, in order for GeoServer to be able of
supplying unique ids at the service instance level, which in an ideal world
should be GeoServer's responsibility (like in GeoServer being in charge of
prefixing the workspace + type name to the geotools provided feature id).

In a perfect world, yes, the GeoServerFeatureSource/Store should wrap the
feature ids generated by the source so that we generate something like
<ws>.<publishedName>.<nativeId>, and rewrite the incoming filters
accordingly

Cheers
Andrea

--

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

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

5

right, thanks for confirming.

cool, at least we’re on the same page re what the proper way of doing so would be in that perfect world. We might even have the motivation to chase it in this regard one day. And yes, the gotcha would be having to rewrite all incoming fid filters.

Thanks for the insights Andrea.
Gabriel

···

On Thu, Apr 4, 2013 at 4:57 PM, Gabriel Roldan <groldan@anonymised.com> wrote:

Hey, just a question.

What would be the impact to geoserver if a datastore does not respect the convention of providing feature ids as .

The issue would just be that featureid in WFS GET has a lower chance to work, since it becomes higher the probability to have a conflict, same id, different store.
That said, even with the current setup it’s not really impossible to have a conflict, if you have two stores in different workspaces producing the same ids.

The feature id issue bothers me since a while now and would like to gather opinions on whether it shouldn’t be mandatory for geotools datastores to prefix the feature ids that way. It looks to me like a WFS think leaking down to the data access layer, in order for GeoServer to be able of supplying unique ids at the service instance level, which in an ideal world should be GeoServer’s responsibility (like in GeoServer being in charge of prefixing the workspace + type name to the geotools provided feature id).

In a perfect world, yes, the GeoServerFeatureSource/Store should wrap the feature ids generated by the source so that we generate something like .., and rewrite the incoming filters accordingly

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

6

Gabriel, you are absolutely right. If typename is not specified for a featureid WFS GetFeature, TypeNameExtractingVisitor is used to add every type guessed from <typename>.<something> found in the catalog to the typename list. If featureid is not of the form <typename>.<something>, the request will fail. :-/

On 05/04/13 21:49, Gabriel Roldan wrote:

But does it even if typeName is not given to GetFeature? (I seem to
remember typeName is optional for a featureId request?)

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