[EMAIL PROTECTED] wrote on 02/14/2007 01:38:48 AM:
> Bryce L Nordgren ha scritto: > > An observation: > > [...] > > 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. > > 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? Nope. Use the default (slow) generic service. I suspect that Geometry implementations will only offer services if there is a specific and substantial performance advantage over the generic services. Using this scheme, ALL geometry implementations leverage decimation if a generic decimation service is written. If it provides its own, the process is just faster or smaller, that's all. As a matter of fact, most of the methods on the Geometry interface (buffer, distance, includes...) could probably be broken out as services written only against the GeoAPI interfaces. Even data-only geometry implementations optimized for some specific environment could be capable of having fairly complex operations performed on them. > Yet, at the same time asking the geometry implementation to offer > this services raises the bar for geometries, makes them harder to implement. Yes and no. It keeps knowledge of the implementation details of the geometry within the geometry implementation module. To put it another way, if such a service is required for performance reasons, then geometry implementations should already provide the service. The bar is already set high, and asking the geometry implementation to provide its own services just makes things simpler to manage in a multi-implementation environment. Bryce ------------------------------------------------------------------------- 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
