Back from foss4g now so I can focus on this one. Thanks for the
http://jira.codehaus.org/browse/UDIG-1818 bug report.
Sorry for the earlier confused response BasicFeatureRenderer is our code and we
should be able to fix this. Both the old and the new code snippet are using the
retired DefaultMapLayer. I would like to make sure we use FeatureLayer and
avoid a round of indirection.
Here is my problem with the old code - ForceCoordinateSystemFeatureResults is
basically us not trusting the FeatureCollection provided by the datastore; and
wrapping it up in something we know will know will copy all the values; and
package them up into a new feature with the "Correct" CRS.
The problem is we lose the ability of make fast queries as we pan and zoom
around! Resulting in a much much slower application.
So could we try the following:
a) update the code to use FeatureLayer
b) sort out what DataStore implementations are giving us problems (it sounds
like Shapefile?).
c) For each datastore that is not working we can fix the GeoTools code.
Example: Internally to shapefile we can have it wrap the returned (smaller)
result with ForceCoordinateSystemFeatureResults as it pans around the screen.
It also looks like the second code has a trouble; there are two methods we can
use when defining a Query
(http://docs.geotools.org/latest/userguide/library/api/datastore.html#simplefeaturesource):
Override this value in the event the datasource is incorrect and your user
knows the correct CoordianteReferenceSystem.
Query.getCoordinateSystem()
Query.setCoordinateSystem(CoordinateReferenceSystem)
Used to transform the information to requested CoordinateReferenceSystem.
Query.getCoordinateSystemReproject()
Query.setCoordinateSystemReproject(CoordinateReferenceSystem)
With that in mind the second code example looks correct; it uses
setCoordianteReferenceSystem correctly. It is just the implementation of the
datastore that is wrong?
--
Jody Garnett
On Friday, 16 September 2011 at 9:26 AM, Emily Gouge wrote:
> I did some digging and found in the BasicFeatureRenderer these lines
> (from the prepareDraw) function were commented out:
>
> FeatureCollection<SimpleFeatureType, SimpleFeature> reprojectingFc = new
> ForceCoordinateSystemFeatureResults(featureSource.getFeatures(),
> layer.getCRS());
> layers[0] = new DefaultMapLayer(reprojectingFc, style, "Test");
>
> and replaced with this:
>
> layers[0] = new DefaultMapLayer(featureSource, style, "Test");
> DefaultQuery query = new DefaultQuery(Query.ALL);
> query.setTypeName(featureSource.getSchema().getTypeName());
> query.setCoordinateSystem(layerCRS);
> layers[0].setQuery(query);
>
> If I un-do this change then the layer renders fine.
>
> I think there are multiple issues with this "new" code:
> 1) The layers[0].setQuery is called here, however it is also called
> later in the execution process in the setQueries() function. So first
> query which is supposed to set the CRS is over-written and not used when
> rendering.
>
> 2) Geotools ignores the CoordinateSystem of the layer passed in the
> layer. Even when I fixed the problem outlined in (1), the issues was
> not resolved. I looked a bit into the geotools StreamingRenderer and it
> didn't look to me like it used the CRS of the query, however I am not
> familiar enough with this code to pinpoint the issue (if there even is one).
>
>
> I'm wondering if anyone knows what prompted this change in the rendering
> process and if it can be reverted back or made to work so projections
> can be set on layers.
>
> Thanks,
> Emily
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
