Re: [Geotools-devel] FIDMapper issues

[Jody G. <jga...@re...>]

Andrea Aime wrote:
>> 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?
Well it sounds like you are sure on this new definition of feature id; I 
would start by documenting the FeatureId interface so the intention is 
clear. I would then start with a well known datastore; say shapefile and 
see what you can do to make this happen; an obvious one is respecting 
the "namespace" and "typename" provided as part of the query. The fix 
may be in the datastore; or it may be in the ReTypeFeatureCollection I 
am not sure ... If you like the results recommend the practice to others 
... and then go on to JDBCDataStore (renegotiate your contract with your 
subclasses), and AbstractDataStore (same deal).

Cheers,
Jody