FW: RE: Apple Mac<->Intel Linux (fwd)

[Carl Anderson]

What follows are my opinions and may contain errors due to my lack of
understanding of the underlying programs.

Notes on connecting ESRI Arcview 3.x and Grass

ESRI Arcview 3.x will connect to ESRI SDE which will connect to Oracle SDO.
Which Oracle claims to be a precursor of the SQL-3 spatial data
objects specification.

Postgres implements an earlier spatialobjects idea.
        Point        (float,float)
        Line         (point,point)
        Path         array(point)       or  (point,point,...)
          Open and Closed Paths

Arcview shapefiles commonly use data types of 
(see ESRI whitepaper on shapefiles or read source code from shapelib 1.2)
        Point        (float,float)
        MultiPoint   array(array(point)) or  ((point,point,point),(...))
        Polyline     array(array(point)) or  ((point,point,..),(point,...),...)
        Polygon      array(array(point)) or  ((point,point,..),(point,...),...)

Further, in Grass 4.2.1, Postgres functions (d.site.pg, d.vect.pg, ...) 
use an ascii interface to Postgres data structures (type casting to string)
   d.site.pg reads X,Y values from the sql database
   d.vect.pg only reads the categories in the sql database
        (not the vertices)
   neither has a facility to store data into the database.

In the long term:
 - Postgres will need to implement SQL-3 spatial data types as they
    are stabilized.
 - Grass will need to have an interface written to interact with these data
    types.

In the short term:
 - File copy the shapefiles and use v.shp2gen
 - Get the source for Postgres and look in  postgres-v6.4/src/test/regress/sql
    at the files
      lseg.sql             line segment regression tests
      rect.sql             rectangle regression tests
      path.sql             path data type regression tests
      polygon.sql          polygon data type regression tests
      point.sql            point data type regression tests
    These regression tests will show you the basic use and abuse of the spatial
     operators.
 - Help rewrite the existing Postgres routines to
     use ecpg (embedded SQL C preprocessor) for Postgres and link to libpq
     use Postgres spatial data types 
        extract vertices from Postgres
        save vertices into Postgres
 - Help write a routine to pass data from Postgres to Arcview
    Arcview is limited to ODBC, RPC, or private libraries to send or recieve
    data over a network (excepting file level access).  The Postgres ODBC driver
    does not understand spatial data and casts it to string before passing it
    on.  This will be problematic for objects that have lots of vertices. 
    Arcview (avenue) can only pass SQL statements as string SQLcon.Exec(string)
    some sort of helper app is needed.
    How about a local java app that accepts RPC data from Arcview, converts the
    request to JDBC, and constructs shapefiles (using shapelib 1.2) and passes
    back the temporary filenames to Arcview.  In the other direction accepts a 
    filename, deconstructs it into JDBC calls, and passes back a success code
    to Arcview. 

I have a working d.site.pg and d.vect.pg for Grass4.2.1 and Postgres v6.3 
(works with Postgres 6.4).  The limitations above have convinced me to start a 
rewrite of the Postgres routines.  

I want to connect to spatial data from Arcview, Java, Grass, and Arc/Info
(analysis/plotting only).  Postgres JDBC drivers understand the existing
spatial data types and bring the data in as the corresponding java data types.

I strongly believe that the existing spatial data types in Postgres need to be
extended to directly support the basic form of the shapefiles
   Polyline     array(array(point))
or adding a rectangular bounding box data type
   Polyline     (rect, array(array(point))) 
The bounding box will be necessary for datasets with a large number of
elements.  Rectangular searches are much much faster than fully evaluating the
spatial objects.  Or is it already an internal in the path data type ??

These new data types will require writing new spatial selection operators for
Postgres. 

BTW  Postgres is wonderful, and I use it in addition to and Oracle v7 database.
Kudos to the Postgres team, especially for the procedural language.


--------------------------------
GIS Manager Fulton County Georgia
E-Mail: Carl Anderson <candrsn at mindspring.com>
Date: Sun, 07-Nov-98 12:00:00 +0000 (GMT)
Time: 20:29:40

This message was sent by XFMail
----------------------------------