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?
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. Jody ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
