On Mon, Jul 4, 2011 at 2:38 AM, Jody Garnett <[email protected]> wrote:
> Or drop them altogheter. The current ones are not efficient, most of them
> have a better implementation
> on the GeoServer side. All the FeatureToFeatureProcess classes are memory
> bound for example.
> There are some good ideas on both sides (the base class approach is nice
> for example), would be best to merge them
>
> Okay I will keep that in mind; as author of those things on the geoserver
> side I assume you can give me permission to copy them over.
>
I do.
> 4) gt-process-feature
> - not sure if we have many feature based processes yet; the ones in
> geoserver are specific to their catalog near as I can tell (or perform
> simple things like returning a "count")
>
> There is a good bunch which are interesting on their own, buffer, cookie
> cutter, intersection, overlap and so on.
>
> Is that the ESRI definition of cookie cutter? Suppose I will find out.
>
We have a clip process optimized for rectangles and a ESRI style polygon
overlay that keeps attributes
of both intersected featuers in the result. I'm also working to make a more
generic clip process that will
work with any shape, not just rectangles, but found issues with bbox filters
and reprojected feature collections
that prevent me from committing it, I guess I need another weekend of work
to clean that mess before
the process can be committed.
> 5) Moving the good bits into the library
> - the actual interfaces can move to gt-api
> - the core implementations to gt-main (my preference) or gt-metadata
> depending on if they are useful for raster processing?
> - this would leave plugins/process as an optional plugin that contains only
> basic "literal" processes
>
> Processes can handle whatever, they can be pure vector, pure raster, mix,
> or completely non spatial
> (reporting processes, send mail processes, and so on, the typical stuff
> found in a ETL/workflow system).
>
> Okay from that feedback I should move this into gt-metadata then.
>
I would also check what dependencies they introduce. Main would not be such
a bad place
> Q: What about sextante?
>
> My understanding is that the sextante license has changed; perhaps we could
> now have a gt-process-sextante plugin in geotools.
>
>
> Yep, if someone is interesting in maintaining it there is a set of rough
> bindings available in GeoServer community land.
> I basically gave up on integrating it because it uses a push model, it's
> too hard to make it scale to large
> quantities of data, raster processes do not use tiling for input/output,
> vector can do streaming only if not
> chained... I mean, making clever use of thread (one per process), blocking
> queues, JAI wrappers that
> call the process tile by tile it might be possible to get it going but it's
> a lot of work.
> A plain wrapping is easier but would be bound to memory... meh... not
> exciting at all.
>
> So should I take it to geotools as an unsupported module? Perhaps it can
> attract a developer.
>
Feel free to grab it. Warning, it might not be working at all, I got fed up
mid way when I realized there
was no easy/straightforward way to get it to work with reasonable
performance/scalability
> Q: What about jgrasstools?
>
> It already supports the process api; it should just need to change its
> dependencies a bit (to just depend on gt-api and/or gt-main).
>
> It supports the geotools process api? I thought it was using another
> process API. (open modelling framework or something
> like that).
>
> Yes it does; and the wrapper has been produced so it can use the OMS3
> metadata and produce the geotools data structure we need to run... it is
> actually pretty nice.
>
Cool, that's good news. Still, the license is a roadblock for GeoTools.
Cheers
Andrea
--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
-------------------------------------------------------
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
