Re: [Geotools-devel] FIDMapper issues

[Andrea A. <aa...@op...>]

Jody Garnett ha scritto:
> Andrea Aime wrote:
>>> 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?
> Fid filter is sent to a specific published FeatureType right? The fact 
> that another FeatureType that is also published (perhaps a view of the 
> same data?) has the same FeatureId is not always a problem?

No, it's not sent to a specific feature type, again, look at this
request (which I pasted before):
http://sigma.openplans.org:8080/geoserver/wfs?service=WFS&request=GetFeature&featureId=states.1

this is by spec, and there is no typeName. The FID is supposed
to be so unique that it identified a feature _in the whole server_.

> But yeah it makes sense to me that everyone ignored the OGC General 
> Model and started using FeatureId in this way ...
>>>> 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).
> Cool; so we need to revisit FeatureId definition in GeoTools; the target 
> has changed since the OGC General Model and the days of WFS 1.0.

Hmmm... ok? How?
Cheers
Andrea