Thanks Martin, I agree with both proposals, so I started from customizing the NADCONTransform and exploring the epsgs. By indexing I meant the tree structure algorithms and I agree with what you have suggested.
Regarding your question about algorithm package - if I remember well it is used just by builders and I think that It was as private as possible. I'll look into it. I'm currently away - I'll do more when I'll come back home (tomorrow). Bests, Jan. ______________________________________________________________ > Od: [EMAIL PROTECTED] > Komu: Jan Jezek <[EMAIL PROTECTED]> > CC: Jesse Eichar <[EMAIL PROTECTED]>, geotools-devel > <[email protected]> > Datum: 05.06.2007 16:16 > Předmět: Re: GSoC report&questions > >Hello Jan > >I didn't looked deeply at the NADCONTransform code. It is something I wanted to >do for a while, but didn't had the time yet. But there is some notes: > >If you go on the path of something similar to NADCONTransform, it would be nice >if NADCONTransform could be refactored into something generic (not specific to >NADCON), maybe with a NADCONTransform subclass if needed - but ideally the >parent should should be generic enough that we don't need. > >About the way to specify the mapped positions (WKT, Parameter or URL), maybe we >need to provides both. Maybe we could begin with URL for the following reason? > >* May be easier to implement (no special ParameterDescriptor). >* Allow to retrofit NADCONTransform in your framework. >* Needed anyway for usage with the EPSG database. > >The later point seems of special interest to me. The EPSG database defines >transforms based on some definition files (mostly gridded data I guess), with >filenames declared in the "Coordinate_Operation_Parameter Values" table. This >apply to EPSG operation methods 9613, 9614, 9615, 9620, 9634, 9658, 9662, 9663, >9664, 9665. It would be nice if you could take a look at what EPSG said about >those operation methods and design your framework (including the way to specify >mapped points) in a compatible manner, if possible. > >About the indexing mechanism, I'm not sure what you means. Do you means a R-tree >or something similar? If so, is it envisageable to take the implementation in >the shapefile plugin, document it if needed, and move the implementation to the >referencing module? We can not introduce a dependency to the shapefile plugin >since it would be a circular dependency (shapefile already depends on >referencing), but shapefile could use the implementation in referencing if we >move it there. > > Martin > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
