Hey, You are starting to talk about real 'coverages' rather than 'grid coverages'. There is a spec to help you implement such a thing, ISO 19123, probably with antecedents in the OGC world. You are discussing an 'analytic coverage' or more specifically a time-dependent analytic coverage.
The quick hack is for you to write a module that works for you; the long term solution is not for the faint of heart. 'Coverages' are the end goal of most of this geographic work; they therefore encompass the rest of the stack, they are features, they are the real 'layers' of most GIS applications. This means that 'coverages' are the last piece of the core puzzle that will fall in place prior to having a full working base layer for a GIS. An early step on the road to 'coverages' will be to cleanup the new Feature model since 'coverages' are 'features'. This is the cleanup work of removing deprecated classes and making intelligible javadoc which I hope we can get to once we branch for 2.6. You probably want to take a look at coverages and at Bryce's excellent primer---they will give you ideas about the wider field. Other than that, you'll be on your own to make something that works for you. Unfortunately it will probably only live as an interim hack until the more general solution lands. --adrian On Mon, 2008-06-30 at 21:36 +1000, Michael Bedward wrote: > Hi all, > > A few days ago I asked about how to implement a coverage defined on a > mathematical function on the users' list. Simone and Martin replied > with info about using JAI's ImageFunction directly or indirectly - > this was a big help. > > Sometime soon I'll have a need for a leaner (in terms of overhead) > approach. I am working on a simulation where entities move within a > landscape, their movements being influenced by local resources, > hazards etc. I want to provide for resource coverages where value is > defined by a mathematical function, the inputs to which may be > position and/or time and/or spatial relationship with features (sens > lat) in other coverages. > > Frequently, resource value will only be queried over a tiny fraction > of the total extent of a coverage. In such cases I'm worried that > there is a large redundant overhead in creating a large image with JAI > to back the coverage. > > One approach to this would be a type of coverage based on a > mathematical function (passed to its constructor perhaps). It would > use lazy instantiation so that the function would only be parsed into > some efficiently runnable form (an AST perhaps) when the coverage is > first queried for a value. There would be some facility to create a > backing image for cases where it is known a priori that a large number > of locations will be queried. > > Does this sound like it would have any general use ? If so, I would > be happy to being hacking it as an unsupported module - I'll be doing > it for my own app anyway. > > I'd be very grateful for any comments, tips on related work already > happening etc. > > cheers > Michael > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
