On 15/06/2010, at 11:39 PM, Andrea Aime wrote:
> Hi,
> looking into the build failures caused by Jody's MapContext
> refactor I found that there is a discrepancy in how we handle
> the reprojeciton policy in GeoServerFeatureSource.
>
> Basically, getSchema() and getFeatures() do apply the reprojection
> policies, but getBounds() returns the native bounds always,
> forgetting about crs forcing and reprojecting.
>
> Unfortunately the fix is not easy as there is code using the
> getBounds() method to compute a layer _native_ bounds, for
> example, see CatalogBuilder().getNativeBounds().
>
> I would like to fix the above, but how?
> Ideas:
> - have the CatalogBuilder() dodge the
> FeatureTypeInfo().getFeatureSource() method and
> call onto the data store directly to get the feature
> source (uses internal knowledge that the store is
> not being wrapped)
> - expose in GeoServerFeatureSource() getNativeBounds()/
> getNativeBounds(query) methods and have the builder
> perform a cast? However that will break when using
> read only security wrappers
>
> Bummer... I guess option a) is the only feasible one?
c) Can you somehow mark your with an interface; and have a method to return the
"native" FeatureSource? Less api if nothing else.
if( featureSource instanceof WrappedFeatureSource){
WrappedFeatureSource wrapped = (WrappedFeatureSource) featureSource;
return wrapped.getBounds(); // returns the native bounds
}
Jody
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
