how to implement catalog support for GRASS workspaces

introductive information of what we are talking

Since a workspace is something more on userlevel, I will from now on use grass database for the folder structure and workspce for what the user will interact with at application level.

Overview of a GRASS database structure:

Most important files and folders for now WIND - contains the active processing region and the resolution PROJ_INFO - contains the information about the projection PROJ_UNITS - contains the information about projection units used cell, fcell - contain the raster files vector - contain the vector data since GRASS 6 sites_list - contain the sites type data, deprecated from GRASS 6 on, but maintained in JGrass

File structure of GRASS Location A GRASS raster map consists of several files in several subdirectories in a mapset, organized as follows: cellhd/: map header including projection code, coordinates representing the spatial extent of the raster map, number of rows and columns, resolution, and information about map compression; cell/, fcell/ or grid3/: generic matrix of values in a compressed, portable format which depends on the raster data type (integer, floating point or 3D grid); hist/: history file which contains metadata such as the data source, the command that was used to generate the raster map, or other information provided by the user; cats/: optional category file which contains text or numeric labels assigned to the raster map categories; colr/: optional color table; cell_misc/: optional timestamp, range of values, quantization rules (for floating point maps) and null (no-data) files; GRASS vector maps are stored in several separate files in a single directory. While the attributes are stored in either a DBF file, a SQLite file or in an external DBMS (PostgreSQL, MySQL, ODBC), the geometric data are saved as follows: head: vector map ASCII header with information about the map creation (date and name), its scale and threshold; coor: binary geometry file which includes the coordinates of graphic elements (primitives) that define the vector feature; topo: binary topology file describes the spatial relationships between the map's graphic elements; hist: history ASCII file with complete commands that were used to create the vector map, as well as the name and date/time of the map creation; cidx: binary category index file which is used to link the vector object IDs to the attribute table rows; dbln: ASCII file which contains definition(s) of link to attribute storage in database (DBMS). Taken from the GRASS developer's manual

blueprint of the impementation (resume of the irc meeting)

Everyhting starts with saying that the service will be what JGrass calls location. service == location

From the user side that means that he would just select the location and then all the mapsets and maps are imported to catalog.
After that the user could right click on a map and select new map for rendering (this part is not topic here).

What need sto be implemented is:

• IService (Location)
• IGeoResource (MapSet)
• IGeoResource ( GMap )
• ServiceExtension (Used for saving and loading mostly)

Service extension is also used for drag and drop so that the framework can tell if the current object dropped can be used to make a service of that type.
It is suggested to implement IServiceExtension2, since it provides the framework with better feedback.

Main steps:

1. define a net.refractions.udig.catalog.ServiceExtension Extension in the plugin.xml. In the plugin.xml make sure that net.refraction.udig.catalog is a dependency and that the plugin.xml is saved.
2. switch to the extensions tab, press add and find the net.refractions.udig.catalog.ServiceExtension. You have to fill that out so that it points to your ServiceExtension.
3. create a net.refractions.udig.catalog.fileFormat extension in the plugin.xml. There is a minor issue here. fileFormat is for files and we are dealing with directories.
   

   DnD conflicts A word of warning. when you drag and drop a folder or file just the URL is passed in so all the ServiceExtensions fight over it. If you have a greedy Service extension then it could cause problems with other extensions. As a developer you have to make sure that you only accept files/directories that are "good".

4. for wizard: create a net.refractions.udig.catalog.ui.connectionFactory extension
   containing two subcomponents:
   1. factory
   2. wizardPage

actually DND may not work until you have factory extension point.