|
From: Andrea A. <aa...@op...> - 2008-05-08 20:33:58
|
Jody Garnett ha scritto: > Andrea Aime wrote: ... >> The thing is, primary keys and raw feature identifiers of any kind >> are prefixed by the feature type name. I don't know exactly when >> this happened, but it has something to do with the request >> that on a WFS using a feature id you should be able to figure out >> the feature without any specification of the type name (like >> "give me states.1" out of the blue, without telling you from which >> feature type is should be extracted). >> > Nope it is just supposed to be a stable identifier of the form > "[A-Z,a-z]+[A-Z,a-z,0-9]*" and prepending the type name was a common > convention to get an identifier that started with a letter. Then it has been a happy conincidence, since by WFS spec you have to be able and answer a request such as: http://host:port/server?service=WFS&request=GetFeature&featureId=states.1 e.g.: http://sigma.openplans.org:8080/geoserver/wfs?service=WFS&request=GetFeature&featureId=states.1 >> Now, when we go back from the published fid to the raw one, the >> code that does the prefixes just wipes out everything before the >> dot... leading to this issue. >> > Yeah going from a published fid to a raw one was never the intention; I > understand that thing may of changed for the GMLObjectId method; so we > probably need to look again - and possibly revisit our FeatureId policy. Sorry Jody, but it was intention all the way, how do you encode a FID filter otherwise? >> What about adding a method like "canDecode(String FID)" >> and then have the code in getPKAttribute throw an exception >> if the decode is not possible? >> > I think that may be needed; in order to support a true GMLObjectId > method that did not assume anything about the internal structure of the > FeatureID.... As I said, this is implied already by the base WFS spec (and we're failing to support it fully if you have two feature types with the same name in different namespaces, at least in GeoServer). Cheers Andrea |