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). > 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; or the ReprojectingFeatureCollection in the work justin and I were working on. > 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). >> Can we get a list of offenders and make sure bug reports exist? > There is no bug report, all data stores are offenders. Too much > work for me given my time frames, that's why I'm looking for a > Geoserver side solution, where I can fix at least CRS forcing > in a single place. Gak. > To do things quick, I could do this only for the read only case using > getView(xxx). > Too bad the datastore API is designed is such a way that I cannot > distinguish read > only access from read/write one. The ability to distinguish was one of the suggestions put into the DataAccess proposal. > 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. Jody > 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
