GRASS compatibility

brainstorming both JGrass & UDig

JGrass: UDig has different projection handling, different workspace idea.We love to be able to work inside a workspace, which is an ordered filestructure on filesystem (apart of remote files). The different feeling is the following: you click to add a "map" to a udig layer in GRASS there is a place for rasters, vectors and whatever to work with them, you have to import them.

UDig: Indeed we have some constructs aimed towards helping a 'team" work through data processing chores. So there are a couple of structures uDig has that may be of interest.

1. Project
2. catalog
   Aside: you can capture the idea of your "workspace" directly in the udig catalog as a "Service", the resources in that service would be the different raster data. Alternatively workspace sounds like a catalog... ie a place where the data resources are "tracked".

Proper definition
It sounds like the goal for "workspace" is to manage some disk space so raster opperations have a place to play? Which is different from the goals of project (ie share a map) and catalog (organize geo resources).

UDig: We could do the following: (just an idea not necessarily the only way/right way to do).

1. add an decorator (it is an extension that can modify how the text and image in a viewer, catalog in our case is shown) the decorator could show a layer as imported or not.
2. add an import to workspace action/operation one idea.
3. Another would be to add categories to the catalog so that you can see local vs remote data really the catalog view should be an entire perspective and we've discussed making it one. But haven't had the incentive as of yet. We could make a catalog perspective which has more functionality than the single view we have now. Indeed if this disctinction matters (and it does in this case) it would be motivation for a catalog perspective.

JGrass: we want to work from your existing workspace - rather then "project" because we are sharing that workspace with a GRASS operator.

JGrass: the JGrass/GRASS database definition (very, very quickly, to get more go here):

In the root folder there are LOCATIONS as many as you like. LOCATION is the keeper of the projection information as well as the region bounds in which the choosen projection makes sense. Inside of every LOCATION we have MAPSETS, one particular, called PERMANENT that is shared by everyone and others that the user creates to work inside (the playing around Jody was talking about). This is based on a multiuser concept and there can be permissions on the mapsets.

UDig: So to do a bit of brainstorming: the idea of creating a service that represents a grass workspace is not a bad one. It would allow workspaces to be added and removed easily. It could handle permissions. Could be dynamic and have special operations for it. Services are the top level items in the catalog. Each child is normally a georesource. The members of your workspace service could be rasters and vectors. In this way they could be added to maps like any other resource. But because they are part of the special service they can be managed in certain ways. You could add resources to it by dragging and dropping files or other resources into it.

To summarize that thread

1. Service for a workspace
2. be able to create a map from the workspace
3. operate on maps so that the operations are not tied to a grass
4. Coordinate Reference System compatibility I think should not be too bad both can go to and from WKT I'm pretty sure so we at least have a method for communication.