Hey all,
I'm going to have to leave this one till monday, but I'm having a problem rendering a geotiff coverage via the 1.4.x_merge_wcs branch off of trunk.
Everything sets up just fine, the GeoTiffReader is wrapped up in a FeatureCollection with two attributes ("geom" and "grid") and that FeatureCollection is wrapped up in a CollectionDataStore.
However, when AbstractDataStore goes to create a reader for the collection (via AbstractDataStore.getFeatureReader(Query, typename)) somehowe the internal reader's version of the type is different than the AbstractDataStores 'remembered' type.
getSchema() in the abstractdatastore claims it's {'grid','geom'}
reader.getFeatureType() in abstractdatastore.getFeatureReader() claims it's {'geom','grid'}
This causes a "ReTypeFeatureReader" to be created, and since the ReTypeFeatureReader can't deep-copy the "grid" object (nor should it!) the rendering fails.
I'm still ramping up on the internal gt feature model, so my keeping track of all the threads is a bit of slow going. AbstractDataStore vs AbstractFeatureStore vs AbstractFeatureSource takes me about the times to go though and get right, etc.
Can anyone tell me where the featureType would be getting re-created? One possibility is in DefaultFeatureResults, where depending on the query, DefaultFeatureResults might subType the featureType...
Any ideas?
--saul
I figured out a bit more, but now I'm definitely leaving!
The problem is much much simpler than I would think.
I'm probably just using a bogus SLD for my coverage, but in the portion of StreamingRenderer that figures out which attributes to request, it's mis-calculating the attributes to query. It figures that my style requires the "grid" attribute, then automatically appends the "geom" attribute to the end (since it's the geometry attribute for the feature). This "inverts" the featureType in the query, which causes the createSubType call.
What's the right SLD to put in for a coverage?
--saul
Saul Farber wrote:
Hey all,
I'm going to have to leave this one till monday, but I'm having a problem rendering a geotiff coverage via the 1.4.x_merge_wcs branch off of trunk.
Everything sets up just fine, the GeoTiffReader is wrapped up in a FeatureCollection with two attributes ("geom" and "grid") and that FeatureCollection is wrapped up in a CollectionDataStore.
However, when AbstractDataStore goes to create a reader for the collection (via AbstractDataStore.getFeatureReader(Query, typename)) somehowe the internal reader's version of the type is different than the AbstractDataStores 'remembered' type.
getSchema() in the abstractdatastore claims it's {'grid','geom'}
reader.getFeatureType() in abstractdatastore.getFeatureReader() claims it's {'geom','grid'}
This causes a "ReTypeFeatureReader" to be created, and since the ReTypeFeatureReader can't deep-copy the "grid" object (nor should it!) the rendering fails.
I'm still ramping up on the internal gt feature model, so my keeping track of all the threads is a bit of slow going. AbstractDataStore vs AbstractFeatureStore vs AbstractFeatureSource takes me about the times to go though and get right, etc.
Can anyone tell me where the featureType would be getting re-created? One possibility is in DefaultFeatureResults, where depending on the query, DefaultFeatureResults might subType the featureType...
Any ideas?
--saul
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Saul Farber wrote:
This causes a "ReTypeFeatureReader" to be created, and since the ReTypeFeatureReader can't deep-copy the "grid" object (nor should it!) the rendering fails.
That sounds tough, we can relax ReTypeFeatureReader to just copy the reference when all else fails (not fun, but it will work).
I'm still ramping up on the internal gt feature model, so my keeping track of all the threads is a bit of slow going. AbstractDataStore vs AbstractFeatureStore vs AbstractFeatureSource takes me about the times to go though and get right, etc.
Can anyone tell me where the featureType would be getting re-created? One possibility is in DefaultFeatureResults, where depending on the query, DefaultFeatureResults might subType the featureType...
Any ideas?
GeoServer: it has the ability to re define the order of attributes, aka map from what attributes are in the data to what attributes (and in what order
they are made available in via WFS).
Query: a user can query attirbutes in a different order
Rendering: if the rendering system (especially after its change to looks at the SLD to query only needed attributes) can create a query with the attributes
in the order they were mentioned in the SLD (aka different from how they were defined in by the data store)
And finally, the use of FeatureType in GeoTools 2.0 to directly describe the population of the features being returned was done to allow the GML writing
code to be happy. For the next Feature Model the FeatureType will not be changed, each feature will contain a list of attributes (ie AttributeType -> Value pairs)
in a similar manner to how Map.Entry works with java.util.Map.
Cheers,
Jody