[GRASS5] Re: Vector format proposal

[David D Gray]

Andrea Aime wrote:
> 
> Well, I can't say that I fully agree with you, Radim and David,
> because I like a more simple approach, like teachers :-)
> Anyway, freedom of choice is important and your points are
> relevant, althoght in my applications they're not (I'm using
> GRASS as a backend for analysis and let the user view and
> manipulate data thru commercial applications, and I need vector
> capabilities because I would like to perform all calculation on
> server side, now vector overlays are performed client side
> by Autocad Map :-( ...)

Andrea,

Server side processing can be slow - an idea is to have the server
repond by serving a section of requested map data (perhaps selected on
spatial query), and then have a client side plug-in of some kind render
it (possibly as a shapefile if you are happy with that format). Or the
server can generate these forms and then serve the result - but then as
i said above you have the serious time-lag of two-way traffic, if any
interactive processing is to be done on the results.




> So, if I want to stick to my poor's man data representation
> (the shapefile model) I should follow some convention,
> such as putting only one type
> of data in each vector map and using the following string to
> associate geometry to attributes:
> 
> * 1 $MAP id $GISDBASE/$LOCATION/$MAPSET/dbf dbf
> 
> If I undestand correctly this means that every map is linked
> to its own db file, that this file is named as the map and the
> link it done thru an integer index. That's good for me.
> If I link data thru an hypotetical PosgreSQL driver
> the thing would look something like:
> 
> * 1 $MAPSET_$MAP id geodb_$LOCATION pgsql
> 
> so that a map named geology in mapset Andrea in location Modena
> would be stored in the database geodb_Modena, in a table named
> Andrea_geology... will it be possible?
> 

Converting GRASS linework to polygons (like shapefile `shapes') is fast
and clean - in fact we have functions that do this already, as used in
v.out.shape for example. Because we want to move as much functionality
from shell level commands to libraries, we can easily create functions
that reduce the data to a simpler format. Someone developing a module or
plug-in that needs this could call functions that would automatically
generate such data without having to be concerned about how it's done.
So it could generate a shapefile of a given name, or something
structurally analogous to it, and also create a pg table (say) with the
simple connection you suggest. That can then be used for displaying or
querying a client-side display.



> And what about table creation? It shold be made by hand or there
> are some tools that let you specify the table structure?
> And what happens when I perform a g.remove? There should be an
> option to delete the table along with the data (an option, so that
> I can decide to leave the table in place, too)
> 

It depends on the database. If we use SQL databases, you could use a
generic SQL database table creation tool like gASQL if that's available.
If we have a dedicated native interface, then we would have to develop
the tools as well.

You touch on the point of transaction handling here. When a map is
removed, usually you want it to be removed cleanly, or if it is edited,
you want everything in sync. This is going to be very difficult to
create unless we go for the option of using a database, like pg, that
has this facility already in place.

> Let's consider a particular case of overlay: it starts from
> two polygon layers and ends into a new polygon layer representing
> intersection. Each polygon in the result should have attributes
> from both maps (so, it is a spatial join), and I expect the result
> to be linked to a new table that has columns from both of the
> input tables... but what happens if the input data is linked to more
> than one table? Should I cross every table with each other? Don't do
> it at all and have the resulting data linked to each of the input
> tables (sigh, this would be that I would have to do some kind of
> post-processing to return back to the shapefile model...)
> Any idea?

The different category numbers (if present) are just different ways of
projecting the same spatial partition onto different datasets. In
practice you would choose for a given input layer a particular table -
you are right in that normally there will only be one - and then all the
fields from that table would go into the result table along with those
from the other input layer from the other input map. But notice that we
can get more powerful results than are normally available with what I
think would be relatively little extra code when we employ multi-cat
capabilities: if we combine Map 1 and 2 to produce Map 3, if map 1 has
two categories, and we select both, and Map2 has 1 category, we can
create Map3 with two categories with joins on the two originals from Map
1.

Post-processing to get a shapefile system out of this is actually fairly
trivial - I've done this even with the existing GRASS
attribute/categories system. Just alter the table to contain a field
that contains the entity index explicitly. Export one table as the
primary dbf for that shapefile system, and the others as secondary dbf
files, with whatever naming convention you choose. This can be done with
a function call or script, though it can only be done manually now. In
ArcView, if that is your target platform, import the shapefile, and
import the other dbf's as extra tables which you can then join through
the common entity-id index.

Regards

David


> Regards
> Andrea Aime
> 
> ----------------------------------------
> If you want to unsubscribe from GRASS Development Team mailing list write to:
> minordomo at geog.uni-hannover.de with
> subject 'unsubscribe grass5'



---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'