Jody Garnett ha scritto: > Andrea Aime wrote: >> _Every_ data store ignores the forced CRS and the reprojected one when >> asked to do things in read/write mode. > I see; let me review the API and get back to you on this. I would much > rather apply a patch in one spot then force applications to apply > wrappers. Currently we have two "applications" doing this work > (GeoServer if you proceed and the renderer).
Geosever may be a good case, the renderer should reproject only after decimation. If not, it's plain stupid. Anyways, I already did the thing with Geoserver, I have a release to put out of the door. >> The only place where forced and reproject CRS are used is in the >> DataStore.getView(Query) method, that works read only. > I am going to go look at this - getView origionally was simply a way to > combine a predefined Query with with one for later; if it has also > started applying wrapping code that would be the magic *three* hacks > around one DataStore QA problem. >> Handling CRS forcing in write mode should not be that hard, and >> requires modifying all getFeatureWriter(xxx) methods, doing the same >> for reprojection is harder and requires modifying all feature writer >> classes to do back-reprojection before writing down the result. > >> Oh, I forgot one important detail: getFeatureWriter does not accept >> query, so how I tell it that I want to change CRS? > My impression is the reprojecting FeatureWriter did this sort of thing; There is no reprojecting feature writer I can see, and how could you create one if you don't pass the CRS information to getWriter(xxx)? That information is in a Query object, remember? >> Hum, this could be a real exercise for the API change handling >> procedures? It would be a way to break the DataStore API, since we >> would need new methods in it. > I am not interested in maintaining FeatureWriter as an API, I find this > better handled (and almost identically handled) in a FeatureCollection > implementation (the only difference is you can use the FeatureCollection > more then once). I tried to implement a wrapping FeatureCollection, but stopped right away. I would have had to implement 50 methods!!! This is absurd, no one will implement the custom Feature collections you envisage under these conditions, an abstract class providing boiler plate code is needed, something along the lines of AbstractCollection in the collection framework, that leaves you to implement only 2 methods. > The ability to distinguish was one of the suggestions put into the > DataAccess proposal. The DataAccess proposal is a nice view of how the API may become in a 2 years timeframe (since it breaks all code plain and does not allow for most the optimizations that do make Geotools work (think about optimized data loading in the renderer)). Give me something that we can realistically implement in 3/6 months and I'll consider it. I'm more for breaking a little the existing API in order to fix it than creating another Geotools. >> I'll be forced to do some kind of temporary hack, until the gt2 story >> gets fixed (which >> I can provide some time to help fixing, only I cannot do that under a >> release deadline). > Okay understood the difference between deadline and fix; for now can we > get a bug report > and list this as one of the things we need straight for the GeoTools 2.4 > timeframe. There's no way to fix this unless we allow getWriter(xxx) to accept a Query. After that, you "simply" have to add the method to all datastores, link to feature collections and feature results around, or else you'll end up with another half backed solution like the filters in 2.3.0. The fact you don't like writers does not match well with the reality that writers are still not deprecated in trunk, and that feature collection is not, imho, in a state that allows it be seen as a replacement. Cheers Andrea ------------------------------------------------------------------------- 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 _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
