[Geoserver-devel] GetFeature and DescribeFeatureType: inconsistent behavior for unprefixed type names

GeoServer GeoServer Developer
1

Hi,
I'm looking into what appears to be a 2.0.x regression vs GetFeature
and DescribeFeatureType behavior.

Basically it seems GetFeature can deal with names without a namespace
without issues, but DFT cannot
do the same:

This one works:
http://demo.opengeo.org/geoserver/wfs?request=GetFeature&typeName=states&version=1.0.0&service=wfs

This one breaks:
http://demo.opengeo.org/geoserver/wfs?request=DescribeFeatureType&typeName=states&version=1.0.0&service=wfs

Whilst using topp:states they both work.

Now, typeName is parsed by a QNameKvpParser, which used to have a bit
of code around line 80
to inject the default namespace into the qname that was commented out
in this commit:

r11502 | jdeolive | 2009-03-01 03:12:58 +0100 (dom, 01 mar 2009) | 1 line
GEOS-2662, ported wfs to new catalog + config

Now, uncommenting that bit of code would fix my issue but would
probably create others, as the catalog
behavior is to look in the default namespace first, but then fall back
into whatever first layer is named
"states" in case the default namespace does not contain it, right?

So what about having TypeNameKVPParser override QNameKvpParser parsing
and make it use
the catalog itself to lookup a non qualified feature type name?

I guess that would make DFT and GetFeature behaviour consistent and
backwards compatible at the
same time?

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

Hi Andrea,

On Tue, Oct 26, 2010 at 9:05 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
I’m looking into what appears to be a 2.0.x regression vs GetFeature
and DescribeFeatureType behavior.

Basically it seems GetFeature can deal with names without a namespace
without issues, but DFT cannot
do the same:

This one works:
http://demo.opengeo.org/geoserver/wfs?request=GetFeature&typeName=states&version=1.0.0&service=wfs

This one breaks:
http://demo.opengeo.org/geoserver/wfs?request=DescribeFeatureType&typeName=states&version=1.0.0&service=wfs

Whilst using topp:states they both work.

Now, typeName is parsed by a QNameKvpParser, which used to have a bit
of code around line 80
to inject the default namespace into the qname that was commented out
in this commit:

r11502 | jdeolive | 2009-03-01 03:12:58 +0100 (dom, 01 mar 2009) | 1 line
GEOS-2662, ported wfs to new catalog + config

Hmmm… perhaps I was a bit sloppy when doing this. I can’t quite remember the reason. But i think you are right and it was probably to rely on the catalogs lookup heuristic.

Now, uncommenting that bit of code would fix my issue but would
probably create others, as the catalog
behavior is to look in the default namespace first, but then fall back
into whatever first layer is named
“states” in case the default namespace does not contain it, right?

So what about having TypeNameKVPParser override QNameKvpParser parsing
and make it use
the catalog itself to lookup a non qualified feature type name?

Sounds like a good idea. And should ensure that operations always get a qualified name and prevent us relying on the operation to applying the correct behaviour. I would run it through cite just to be sure… maybe you can do a cite test run directly after the commit. Or just wait until they run later tonight.

I guess that would make DFT and GetFeature behaviour consistent and
backwards compatible at the
same time?

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

Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-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.