Bryce L Nordgren ha scritto: > An observation: > > A reprojection service should not be implemented in a renderer, but should > be provided by the Geometry implementation. In fact, any operation which > could significantly impact performance should be offered as an optimized > service by the implementation. There should also be a collection of > "generic" services which operate only on the GeoAPI interfaces (to > accomodate foreign GeoAPI implementations, if slowly). The renderer (or > any other client code) should know enough to prefer optimized services over > generic ones unless specifically instructed otherwise by the human > operator. > > A Geometry implementation is likely to be partitioned as a package/module. > This package/module should be empowered to advertise not only what level of > service is offered by the geometry implementation, but what optimized > services are offered.
I agree with you in principle, only the geometry implementation knows how to best implement decimation and reprojection. Yet, at the same time asking the geometry implementation to offer this services raises the bar for geometries, makes them harder to implement. I can live with a geometry package that does not do decimation (that's just a performance issue) but what do with do with one that does not allow for reprojection? Fail? Cheers Andrea ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
