[postgis] The Next Level

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

[postgis] The Next Level

Paul Ramsey-2
Gentlepeople:

We here at Refractions have been discussing how to take PostGIS to the
"next level" as a spatial database, and the general consensus is that a
few things are needed:

  a) add most/all of the OGC Simple Features Spec (union,
     intersection, xor, etc)
  b) bundling of binaries (RPM, WIN32 Setup) for easy install
  c) full install / tutorial documentation to go with
     bundled software
  d) client access by some kind of viewer/editor tool
     commercial or otherwise

The other consensus we have reached is that we cannot afford to do all
that stuff and still stay in business. Fortunately, we are in Canada,
and there is a program called 'GeoInnovations' which will fund up to 50%
of certain kinds of geomatics R&D projects. Unfortunately, even with 50%
funding we cannot afford to procede with the kind of PostGIS project
outlined above. So, we are looking for a partner (or partners) to join
in a proposal to GeoInnovations willing to take on 30% of the project
cost, or about $35,000CA. A company or agency which wants to see an
open-source SFSQL database. If anyone on the list knows of (or is) such
a company or agency, your help in putting us together with them would be
most appreciated.

Let me close by saying that PostGIS will remain an open GPL project, and
will continue to be developed (albeit a good deal more slowly)
regardless.

Sorry to polute the list with non-technical stuff, but I figured it was
better to turn every stone than find out later of a missed opportunity.

--
      __
     /
     | Paul Ramsey
     | Refractions Research
     | Email: [hidden email]
     | Phone: (250) 885-0632
     \_

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Small business owners...
Tell us what you think!
http://us.click.yahoo.com/vO1FAB/txzCAA/ySSFAA/PhFolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
[hidden email]

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 



Reply | Threaded
Open this post in threaded view
|

Re: [postgis] The Next Level

Timothy H. Keitt-2
A couple of comments:

I definitely hope to see postgis proceed to the next level.

All the items you  listed would be great to have.  High on my list would
be native support for geodetic coordinates.  Also, packaging for Debian
would be great (I might help  out here).  I've been experimenting with
generating some test data sets for postgis, which would be nice to
include in the distribution.  I've converted Paul Wessel's global
coastline data to postgis format (go to
http://keittlab.bio.sunysb.edu/download/ for psql dumps).  I work a lot
with R (http://www.r-project.org/) and have written a postgresql query
interface.  I was experimenting yesterday with querying postgis geometry
types from the database and plotting the polygons in R.  This could be a
quick and simple front end for visualizing postgis data (plus includes
extensive statistical functions for data analysis).

In terms of funding, have you approached Great Bridge and Red Hat?  They
have commercial postgresql distributions.  They might be willing to
support postgis development, especially if users request the features.
 Perhaps we could canvas them a bit.  Having cvs access via sourceforge
or equivalent might also attract additional volunteer developers.

Cheers,
Tim

Paul Ramsey wrote:

>Gentlepeople:
>
>We here at Refractions have been discussing how to take PostGIS to the
>"next level" as a spatial database, and the general consensus is that a
>few things are needed:
>
>  a) add most/all of the OGC Simple Features Spec (union,
>     intersection, xor, etc)
>  b) bundling of binaries (RPM, WIN32 Setup) for easy install
>  c) full install / tutorial documentation to go with
>     bundled software
>  d) client access by some kind of viewer/editor tool
>     commercial or otherwise
>
>The other consensus we have reached is that we cannot afford to do all
>that stuff and still stay in business. Fortunately, we are in Canada,
>and there is a program called 'GeoInnovations' which will fund up to 50%
>of certain kinds of geomatics R&D projects. Unfortunately, even with 50%
>funding we cannot afford to procede with the kind of PostGIS project
>outlined above. So, we are looking for a partner (or partners) to join
>in a proposal to GeoInnovations willing to take on 30% of the project
>cost, or about $35,000CA. A company or agency which wants to see an
>open-source SFSQL database. If anyone on the list knows of (or is) such
>a company or agency, your help in putting us together with them would be
>most appreciated.
>
>Let me close by saying that PostGIS will remain an open GPL project, and
>will continue to be developed (albeit a good deal more slowly)
>regardless.
>
>Sorry to polute the list with non-technical stuff, but I figured it was
>better to turn every stone than find out later of a missed opportunity.
>

--
Timothy H. Keitt
Department of Ecology and Evolution
State University of New York at Stony Brook
Stony Brook, New York 11794 USA
Phone: 631-632-1101, FAX: 631-632-7626
http://life.bio.sunysb.edu/ee/keitt/




------------------------ Yahoo! Groups Sponsor ---------------------~-->
Small business owners...
Tell us what you think!
http://us.click.yahoo.com/vO1FAB/txzCAA/ySSFAA/PhFolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
[hidden email]

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 



Reply | Threaded
Open this post in threaded view
|

Re: [postgis] The Next Level

Frank Warmerdam
In reply to this post by Paul Ramsey-2
Paul Ramsey wrote:
>
> Gentlepeople:
>
> We here at Refractions have been discussing how to take PostGIS to the
> "next level" as a spatial database, and the general consensus is that a
> few things are needed:
>
>   a) add most/all of the OGC Simple Features Spec (union,
>      intersection, xor, etc)

Paul,

In this area, there is a broad set of work on supporting tables for spatial
data referencing spatial tables, spatial columns within those tables, and
coordinates systems associated with those columns that hasn't been done in
PostGIS.  In fact I am not quite sure how we would do it.  I see this as
more important to building an interoperable SFSQL solution than adding support
for exotic spatial operators (though they would be nice).

>   b) bundling of binaries (RPM, WIN32 Setup) for easy install

What are the chances of us getting postgis available from the normal PostgreSQL
sources as an option for the standard install of PostgreSQL?  Have you been
in contact with the postgresql developers about such a thing?  If not, I happen
to know Marc 'Scrappy' Fournier (core maintainer) who used to get a UUCP feed
through me.  I could approach him.  

Basically, I think PostGIS is a credible spatial extension to PostgreSQL and
we should be looking at having it conveniently available with PostgreSQL rather
than as a separate installed option from downloaded from somewhere completely
different.  Companies like Oracle put alot of effort into providing spatial
extenders to their database as an easily added feature because there is lots
of spatial data out there in regular enterprises.  I would like to see postgresql
also address this.

What I am not so convinced we want to do is get deeply buried in figuring out
the correct way of installing extensions to PostgreSQL on many platforms.  

This might also relate to possibilities of geoinnovations cofunding.  Great
Bridge and Red Hat are both pushing PostgreSQL now for "enterprise" solutions.
Perhaps one of them could be convinced to provide a little seed funding to
a geoinnovations project.

There might also be government agencies in Canada of the type that would
like to buy something like CubeSTOR but find it too expensive that we might
be able to talk into providing some seed funding.

>   c) full install / tutorial documentation to go with
>      bundled software
>   d) client access by some kind of viewer/editor tool
>      commercial or otherwise

Any thoughts on what client you would target?  A few options:

 o OpenEV: really, it already supports reading from PostGIS due to it's use
   of OGR.  It would be nice to add write support as well - currently OpenEV
   can only save to shapefiles.

 o Geotools: It would seem like it should be easy to add PostGIS support using  
   the JDBC link.  I am not all that Geotools savvy, but it seems like a strong
   multi-platform client application for vector editing and visualization.

 o ArcGIS: I have been doing a bunch of work making OGR data sources accessable
   as spatial data sources in ArcGIS via OLEDB.  However, using this mechanism
   to access PostGIS would be kind of clumsy due to the layers of translation
   that would be going on.  Also, access to OLEDB datasources in ArcGIS is a bit
   clumsy.

 o Geomedia: Geomedia is releasing an OGDI reader.  If we wrote an OGDI driver
   for PostGIS we could get read access in Geomedia.

 o FME: What would we need to do to have clean read and write support for
   PostGIS in FME?  I know you guys have been using some sort of customized
   stuff with FME to load PostGIS but could we build a proper reader and writer
   for FME?  If we contributed it for free, I think there is a decent chance that
   Safe would distribute it.  I have lots of experience doing readers (and one
   writer) for FME, and could do a chunk of this work.

In my opinion OpenEV could be a decent option for folks willing to install a big
application, and Geotools is great because it runs anywhere (that Java runs).  
Of course, both are also open source and easily modified.

Best regards,

---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Small business owners...
Tell us what you think!
http://us.click.yahoo.com/vO1FAB/txzCAA/ySSFAA/PhFolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
[hidden email]

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 



Reply | Threaded
Open this post in threaded view
|

RE: [postgis] The Next Level

Norman Vine
Frank Warmerdam writes:

>
>Paul Ramsey wrote:
>>
>> We here at Refractions have been discussing how to take PostGIS to the
>> "next level" as a spatial database, and the general consensus is that a
>> few things are needed:
>
>>   b) bundling of binaries (RPM, WIN32 Setup) for easy install
>
>What are the chances of us getting postgis available from the normal
PostgreSQL
>sources as an option for the standard install of PostgreSQL?
>
>Basically, I think PostGIS is a credible spatial extension to PostgreSQL
and
>we should be looking at having it conveniently available with PostgreSQL

I agree wholeheartily !!

Aside from the packaging issue, which should become a mute point if accepted
as an 'offical' contributed module,  this should also insure that PostGIS
remains
compatable with future improvements in PostgreSQL as the core PostgreSQL
team would hopefully help with this as necessary.

IMHO this is the 'compelling reason' to pursue this approach.

Cheers

Norman Vine


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Secure your servers with 128-bit SSL encryption! Grab your copy of VeriSign's FREE Guide: "Securing Your Web Site for Business." Get it Now!
http://www.verisign.com/cgi-bin/go.cgi?a=n094442340008000
http://us.click.yahoo.com/n7RbFC/zhwCAA/yigFAA/PhFolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
[hidden email]

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 



Reply | Threaded
Open this post in threaded view
|

Re: [postgis] The Next Level

David Blasby-3
In reply to this post by Frank Warmerdam
> In this area, there is a broad set of work on supporting tables for spatial
> data referencing spatial tables, spatial columns within those tables, and
> coordinates systems associated with those columns that hasn't been done in
> PostGIS.  In fact I am not quite sure how we would do it.  I see this as
> more important to building an interoperable SFSQL solution than adding support
> for exotic spatial operators (though they would be nice).

Frank,

        I've spent the last few days reading the OpenGIS Simple Features
Specification for SQL, with special regard to the metadata tables.  I
dont think it would be all the difficult to actually implement it.  It
would, unfortunately, complicate using PostGIS.  But, it could be much
easier to maintain more complex installations.  I'm using section 3.2 of
the spec, "Components - SQL92 with Geometry Type Implementation of
Feature Tables".

The hard part is figuring out (1) what the spec is really saying and (2)
how that translates into postgresql.  The spec isnt externally
consistent between the various possible implementations.

(1) For example, you used to do a
"create table geom_table (gid integer, desc varchar(100), mygeom
geometry);"

Now, you'll have to do (according to the spec):
"create table geom_table (gid integer, desc varchar(100));
AddGeometryColumn(<database name>,'','geom_table','mygeom',<SRID>) ;"

AddGeometryColumn( <catalog>, <schema>, <table>, <geom column>, <SRID>)
is defined in section 2.3.8.

Unfortunately, the spec indicates that the metatable should contain
COORD_DIMENSION, even though the AddGeometryColumn() doesnt specify it.
The AddGeometryColumn() function also doesnt specify what geometry
sub-type (ie. POINT or LINESTRING) the column should be.  Its all a bit
confusing.

I suppose there should be an SQL function that looks more like;
AddGeometryColumn(<database name>, <table name>, <column name>, <geom
type>, <geom dim>, <SRID>)

(2) I think a 'catalog' is equivelent to a postgresql 'database', but I
cannot find an equivelent to 'schema'.


Hopefully I'll start adding the metadata and Spatial Reference
metatables to PostGIS next week.


Comments?

dave
ps. the spec I'm refering to is at
"http://www.opengis.org/techno/specs/99-049.pdf".

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Small business owners...
Tell us what you think!
http://us.click.yahoo.com/vO1FAB/txzCAA/ySSFAA/PhFolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
[hidden email]

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 



Reply | Threaded
Open this post in threaded view
|

Re: [postgis] The Next Level

Paul Ramsey-2
In reply to this post by Frank Warmerdam

Frank Warmerdam wrote:
>
> In this area, there is a broad set of work on supporting tables for
> spatial data referencing spatial tables, spatial columns within
> those tables, and coordinates systems associated with those columns
> that hasn't been done in PostGIS.  In fact I am not quite sure how
> we would do it.  I see this as more important to building an
> interoperable SFSQL solution than adding support
> for exotic spatial operators (though they would be nice).

Support for SRS is on our list (although I think I forgot it in the
email listing). The general goal is to get as close to SFSQL compliance
as possible: it's a credibility thing. Regarding the exotic operators,
if the JTS project had not already been funded to write and release the
algorithms as open source, we could not contemplate it with the
relatively small budget we are working from. With JTS, the job collapses
to porting the algorithms to C++ and revisiting the underlying database
objects of PostGIS to make interoperating with the C++ JTS libraries
simple.

> >   b) bundling of binaries (RPM, WIN32 Setup) for easy install
>
> What are the chances of us getting postgis available from the
> normal PostgreSQL sources as an option for the standard install
> of PostgreSQL?  Have you been in contact with the postgresql
> developers about such a thing?  If not, I happen to know Marc
> 'Scrappy' Fournier (core maintainer) who used to get a UUCP feed
> through me.  I could approach him.

I'm sure they'll add us to 'contrib/' without any difficulties
whatsoever. If you think we should pursue that, we can. The release in
contrib will always lag our development release though (since pgsql
releases on a more infrequent schedule, natch).

I see proper bundling as important because so many people simply cannot
Use The Source. It's not in their nature. So a bundled Win32
PostGIS/PostgreSQL or an RPM PostGIS/PostgreSQL would be a boon to a
user community which would be locked out otherwise.

> This might also relate to possibilities of geoinnovations
> cofunding.  Great Bridge and Red Hat are both pushing PostgreSQL
> now for "enterprise" solutions. Perhaps one of them could be
> convinced to provide a little seed funding to
> a geoinnovations project.

I had not initially considered going directly to Red Hat or Greatbridge,
but I am re-evaluating that now. Given the magnitude of the investment
(smallish) and the fact that geoinnovations would be magnifying that
investment substantially with its contribution, I am hoping that Red Hat
and Greatbridge might *both* contribute. The more organizations willing
to contribute a little, the less each organizations has to contribute.

> There might also be government agencies in Canada of the type that would
> like to buy something like CubeSTOR but find it too expensive that we might
> be able to talk into providing some seed funding.

If you know of any, or of people who might know of any, please forward
information to them. I have attached a short PostGIS PDF blurb which I
am sending to people.

> Any thoughts on what client you would target?  A few options:

All interesting options. The most desirable is clearly the ESRI client,
from the point of view of people being interested in accepting
PostGIS/PostgreSQL into their GIS shops. One option you do not mention
is OpenMap from BBN, which I really like alot.

--
      __
     /
     | Paul Ramsey
     | Refractions Research
     | Email: [hidden email]
     | Phone: (250) 885-0632
     \_
To unsubscribe from this group, send an email to:
[hidden email]

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 


postgis-cgdi.pdf (16K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [postgis] The Next Level

Paul Ramsey-2
In reply to this post by Timothy H. Keitt-2


"Timothy H. Keitt" wrote:

> All the items you  listed would be great to have.  High on my list would
> be native support for geodetic coordinates.  

Speaking of which, we have an open request from a client to add
calculations of area on a spheroid to PostGIS. We have been stymied to
date in that we haven't been able to find an equation/algorithm for it.
Anyone have a reference or some sample code?

--
      __
     /
     | Paul Ramsey
     | Refractions Research
     | Email: [hidden email]
     | Phone: (250) 885-0632
     \_

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Small business owners...
Tell us what you think!
http://us.click.yahoo.com/vO1FAB/txzCAA/ySSFAA/PhFolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
[hidden email]

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 



Reply | Threaded
Open this post in threaded view
|

Re: [postgis] The Next Level

Paul Ramsey-2
In reply to this post by Timothy H. Keitt-2

> Having cvs access via sourceforge
> or equivalent might also attract additional volunteer developers.

I think you're right, so I have opened up the CVS archive to anonymous
read access.

:pserver:[hidden email]:/home/cvs/postgis

password: cvs

As per usual, if particular people have loads of commits to do, we'll
give them write access, otherwise just update and diff and send us the
patch.

--
      __
     /
     | Paul Ramsey
     | Refractions Research
     | Email: [hidden email]
     | Phone: (250) 885-0632
     \_

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Secure your servers with 128-bit SSL encryption! Grab your copy of VeriSign's FREE Guide: "Securing Your Web Site for Business." Get it Now!
http://www.verisign.com/cgi-bin/go.cgi?a=n094442340008000
http://us.click.yahoo.com/n7RbFC/zhwCAA/yigFAA/PhFolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
[hidden email]

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 



Reply | Threaded
Open this post in threaded view
|

RE: [postgis] The Next Level

Norman Vine
In reply to this post by Paul Ramsey-2
Paul Ramsey writes:
>
>Speaking of which, we have an open request from a client to add
>calculations of area on a spheroid to PostGIS. We have been stymied to
>date in that we haven't been able to find an equation/algorithm for it.
>Anyone have a reference or some sample code?

I don't have any code for you but
here is an interesting take on this problem
http://www.geodyssey.com/papers/ggelare.html

Norman

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Small business owners...
Tell us what you think!
http://us.click.yahoo.com/vO1FAB/txzCAA/ySSFAA/PhFolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
[hidden email]

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 



Reply | Threaded
Open this post in threaded view
|

[postgis] SRID initial support (in CVS)

David Blasby-3
In reply to this post by Frank Warmerdam
I'm making lots of changes to support the metadata information required
by the openGIS specification.  This is currently available in the CVS
version.  

NB: I've made a change to the binary representation of a geometry, so
you'll need to dump/restore your geometry databases BEFORE installing
the CVS version.  I dont recommend using the CVS version right now - I'm
just send the changes out so folks can give me comments and know whats
going on.



1. There is now a spatial_ref_sys table created when you run the
postgis.sql initialization script.  This is defined in the OpenGIS spec
section 3.2.1.2.  This is where you will define the map projection your
data is in.

create table spatial_ref_sys ( srid integer not null primary key,
auth_name varchar(256), auth_srid integer, srtext varchar(2048) );

2. The meta-data information table is also created (section 3.2.2.2);

create table geometry_columns (
f_table_catalog varchar(256) not null,
f_table_schema  varchar(256) not null,
f_table_name    varchar(256) not null,
f_geometry_column varchar(256) not null,
coord_dimension  integer ,
srid integer,
CONSTRAINT GC_PK primary key ( f_table_catalog,f_table_schema,
f_table_name,f_geometry_column)
) ;

OpenGIS requires that this table auto-adjust itself if the
catalog/schema/table_name change.  This is difficult to support under
PostgreSQL because it doesnt normally allow triggers to be attached to
system tables.  Plus (1) there is no equivelent to 'schema' and (2) you
cannot access information in another database.  Any suggestions?

3. GEOMETRY type now has a SRID (spatial reference system id) built into
it.  Its cannonical text form now looks like; "SRID=75;<wkt>".   You
should no longer use the canonnical form - use the astext() function or
the geometryfromtext() function.

Heres an example of the new cannonical form (previously it was just the
WKT representation of the geometry);

# select * from t;
 gid |            mygeom            
-----+---------------------------
   1 | SRID=-1;POINT(1 1)
   1 | SRID=5;POINT(1 1)
   2 | SRID=7;POINT(100 100 100)
(3 rows)

You can do something like:

insert into <table> values ('SRID=73;LINESTRING(0 0, 10 10)');

If you omit the "SRID=" portion, its set to -1.
I think openGIS frowns upon inserting new geometries this way.  Instead,
you should...

4. new function (section 3.2.6.2) GeometryFromText( String, SRID).  The
string is a WKT representation of some geometry, so you are supposed to
create geometries like;

        GeometryFromText('LINESTRING(0 0, 10 10)', 73)

insert into t values (66, GeometryFromText('LINESTRING(0 0, 10 10)', 73)
);

5. new function SRID(geometry) :- returns the spatial referencing system
id used in that geometry

6. new function astext(geometry) :- returns the WKT representation of
the geometry

So, under the OpenGIS zen, you would look at a table like this;

# select gid, astext(mygeom),srid(geom) from t;
 gid |       astext       | srid
-----+--------------------+------
   1 | POINT(1 1)         |   -1
   1 | POINT(1 1)         |    5
   2 | POINT(100 100 100) |    7
(3 rows)

7. I'm writing the AddGeometryColumn() function.  According to the
OpenGIS spec, you are not allowed to make geometry columns using the sql
"create table ..." feature.  You first make a table, then use the
AddGeometryColumn() function to stick in a geometry column.  The nice
thing about this is you can easily keep track of all your geometry
columns and add constraints on the table to ensure that all the
geometries have the same spatial referencing system.  I still havent
figured out EXACTLY what AddGeometryColumn() is supposed to do (the
exact details are a bit murky).  Comments?

8.  You're also supposed to include a DropGeometryColumn() function.
Unfortunately postgresql does not allow you to use the sql "alter table
..." to drop columns.  I'm not sure what exactly to do to get around
this; the postgresql manual says you should create a new temporary table
without the offending column, then delete the original table, then
rename the temporary table.  That can cause problems with referencial
integrity with the the metadata table, plus any constraints you've put
on that table.   Not to mention its quite resource-intensive. Comments?


Any suggestions?
dave
ps. the spec I'm refering to is at
"http://www.opengis.org/techno/specs/99-049.pdf".

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Small business owners...
Tell us what you think!
http://us.click.yahoo.com/vO1FAB/txzCAA/ySSFAA/PhFolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
[hidden email]

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 



Reply | Threaded
Open this post in threaded view
|

Re: [postgis] SRID initial support (in CVS)

Paul Ramsey-2

Dave Blasby <[hidden email]> said:

>
> 3. GEOMETRY type now has a SRID (spatial reference system id) built into
> it.  Its cannonical text form now looks like; "SRID=75;<wkt>".   You
> should no longer use the canonnical form - use the astext() function or
> the geometryfromtext() function.

One minor comment: having a semi-colon in the text representation might not be the best idea (since it's the end-of-line marker for SQL). How about : instead. Or, 'FEATURE(LINESTRING(2 2 2,3 3 3),SRID=23)'

--
  Paul Ramsey
  [hidden email]
  Refractions Research Inc
  (250) 885-0632

 

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Small business owners...
Tell us what you think!
http://us.click.yahoo.com/vO1FAB/txzCAA/ySSFAA/PhFolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
[hidden email]

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/