Hi Saul you have run into the limitations of our Feature Model (again!). Here is the conflict: - FeatureType describes a Feature - We want to run Features through the system with only the requested attributes - We cannot represent invalid features (ie all attributes must be present)
The "solution" was to "retype" the Feature (because "subtype already means something). One of the acceptance tests of the new feature model is to allow for invalid features, ie ones that do not have all the attributes the schema tells them they must have. Cheers, Jody > Hey all, > > I'm trying to fix InlineFeature support in Geoserver, and I tracked the > problem down to a lack of CRS info on the created DataStore. > > Basically, the StreamingRenderer didn't know which CRS to use to render > the inline-supplied data, so it didn't get rendered at all. > > Fixing up a few things to get the CRS to appear in the MemoryDataStore > got everything working ok for those folks who declare the SRS on their > inline features GML, but some folks don't do that. I figured it would > be a nice default to assume that they mean their features to be in the > SRS of the WMS bbox (i.e. the "target" SRS for rendering). So I set > about trying to figure out how to take a MemoryDataStore that has a > featuretype.DefaultGeometry.CRS == null, and re-make it into a > MemoryDataStore that has a featuretype.DefaultGeometry.CRS == bboxcrs. > > Re-creating the featuretype was fairly easy (using the > FeatureTypeBuilder), the problem was moving the features from the old > store to the new. Here was my attempt: > > //Step 1 -- create a query to fetch all the features from the > // old store > Query q = new DefaultQuery(build.getName(), Filter.NONE); > > //Step 2 -- get a featurereader from the old store > FeatureReader ilReader = > ul.getInlineFeatureDatastore().getFeatureReader(q,Transaction.AUTO_COMMIT); > > //Step 3 -- fill the new store up with re-typed features? > MemoryDataStore reTypedDS = new MemoryDataStore(new > ReTypeFeatureReader(ilReader,newFeatureType)); > > > Problem is that this fails in the ReTypeFeatureReader. It seems that > the retypefeaturereader is really a "re-order" featureReader. I.e., it > fails if, for example, the attributetype of "SHAPE" in the original > featureType is different from the attributetype of "SHAPE" in the target > featuretype. See line 104 in ReTypeFeatureReader. > > Is this by design? Is ReTypeFeatureReader really just meant to re-order > elements in the featuretype? I just want to re-type from one compatible > featureType (with a getDefaultGeometry() == null) to another (with a > getDefaultGeometry() == something). > > --saul > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
