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 ------------------------------------------------------------------------- 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
