Andrea Antonello wrote:
For today's IRC meeting I added an image to the following page:
http://udig.refractions.net/confluence/display/JGRASS/consoleenginedesign
In the last days me and another developer discussed a bit the issues
rerlated to the creation of a console engine that should deal with
analysis commands execution. We tried to decouple the whole console
block from UDig in order to be able to use the analysis engine also from
geoserver.
We can shortly (hopefully :)) discuss it in today's meeting.
An important issue to discuss will be the fact that we couldn't find a
way to not use the JGrass workspace definition for the analyses. The
catalog is related to virtually every datatype, projection and even
graphics... for analyses we need a container of consistent data to refer to.
I would like to know more about the JGrass workspace definition - is
their javadocs I can review?
The catalog is more used to manage known resources (the local catalog is
used to manage
connections to resources).
Individual GIS activities are free to provide their own grouping of
*data* (rather then connections):
- MapEditor - works with the concept of projects, maps and pages
- Analysis - apparently works with a "workspace" as defined by JGrass
That sounds good to me ... am I missing something?
If it goes like we see it, for analyses a GRASS workspace will have to
be defined and external data will have to be imported into it in order
to work on them. Grassers are used to it, but udiggers, living in a
world with less rules in this sense probably will experience problems.
So please think about it and express your opinion about that.
I really am not understanding something here in terms of workflow - if
it helps you could define
a "scratch" workspace to use is when analysis is performed in an ad hoc
fashion?
Jody
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
