[postgis] JTS 0.9 has been released

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[postgis] JTS 0.9 has been released

Martin Davis-2
I'm happy to announce that a pre-release version of the Java Topology Suite
is now available for download at
http://www.vividsolutions.com/jts/jtshome.htm

This version is functionally complete (apart from isSimple and isValid,
which will be release shortly).  

The spatial predicates are robust under both Fixed and Floating precision
models.  The spatial overlay and buffer functions are unfortunately not
fully robust.  The overlay functions should perform similarly to most other
spatial APIs, however.  The buffer function is robust and precise for many
inputs, but does have known failure cases.

We invite comments, and especially suggestions on robust, precise
algorithms.

Martin Davis, Senior Technical Specialist
Vivid Solutions Inc.
Suite #1A-2328 Government Street   Victoria, B.C.   V8T 5G5
Phone: (250) 385 6040    Fax: (250) 385 6046
EMail: [hidden email]  Web: www.vividsolutions.com


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Unlimited calling with 3-way conferencing. Only $1/Mo.
with CrystalVoice! FREE trial. Click Here.
http://us.click.yahoo.com/Hb1xVB/HxbDAA/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] Re: JTS 0.9 has been released

Hisaji ONO-3
Thank you very much for your great work, Mr. Davis.

 I've tried to create some programs by using JTS's jars.

 If possible, could you  show any simple sample java programs using JTS?

 Regards.



> I'm happy to announce that a pre-release version of the Java Topology
Suite
> is now available for download at
> http://www.vividsolutions.com/jts/jtshome.htm
>
> This version is functionally complete (apart from isSimple and isValid,
> which will be release shortly).
>
> The spatial predicates are robust under both Fixed and Floating precision
> models.  The spatial overlay and buffer functions are unfortunately not
> fully robust.  The overlay functions should perform similarly to most
other
> spatial APIs, however.  The buffer function is robust and precise for many
> inputs, but does have known failure cases.
>
> We invite comments, and especially suggestions on robust, precise
> algorithms.



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] JTS 0.9 has been released

Paul Ramsey-2
In reply to this post by Martin Davis-2
Congratulations Martin, that was a long slog! The OSS GIS community is
definitately going to be far richer in the future because of your work.

P.

[hidden email] wrote:

>
> I'm happy to announce that a pre-release version of the Java Topology Suite
> is now available for download at
> http://www.vividsolutions.com/jts/jtshome.htm
>
> This version is functionally complete (apart from isSimple and isValid,
> which will be release shortly).
>
> The spatial predicates are robust under both Fixed and Floating precision
> models.  The spatial overlay and buffer functions are unfortunately not
> fully robust.  The overlay functions should perform similarly to most other
> spatial APIs, however.  The buffer function is robust and precise for many
> inputs, but does have known failure cases.
>
> We invite comments, and especially suggestions on robust, precise
> algorithms.
>
> Martin Davis, Senior Technical Specialist
> Vivid Solutions Inc.
> Suite #1A-2328 Government Street   Victoria, B.C.   V8T 5G5
> Phone: (250) 385 6040    Fax: (250) 385 6046
> EMail: [hidden email]  Web: www.vividsolutions.com
>
>
> 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/

--
      __
     /
     | 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/ 



Reply | Threaded
Open this post in threaded view
|

[postgis] ST_TRANSFORM: proposal for postgis projection tranformation

David Blasby-3

I've been doing a little bit of thinking about adding projection
tranformation support in postgis.  
OGC SF SQL doesnt have function for doing transforms, but SQL/MM (based
on SF SQL) does.

ST_TRANSFORM( shape, newSRID)

PROPOSAL
--------

Add optional function  "transform(GEOMETRY,INTEGER)" which takes a
geometry and returns a new geometry
in the spatial referencing system given by the SRID.

1. If transform support not compiled in, tranform() will return the
original geometry (unchanged)
2. If the geometry has SRID -1, then an error is thrown

method
------

We're going to be using proj4 to do the tranformation, and steal the
wkt->proj4 parser from Frank's OGR.

1. Add column (proj4text text) to spatial_ref_sys table.  
2. Add function wkt_to_proj4(text) to convert wkt to proj4 strings
3. Add function tranform(GEOMETRY,INTEGER)
        a. extracts SRID from geometry
        b. get proj4text string from spatial_ref_sys table
                i. if proj4text string is empty, call the wkt_to_proj4() function to
get a proj4 string
        c. get proj4text string for new SRID from spatial_ref_sys table
                i.  if proj4text string is empty, call the wkt_to_proj4() function to
get a proj4 string
        d. call a C function convert_geom(geometry,proj4string, proj4string,
newsrid)
                        i. allocate 2 new proj4 projection objects
                        ii. rip apart all the objects inside the geometry and run them
through
                                proj4 to convert them to the new projection
                        iii. rebuild the geometry with the new points.

NOTE:
        I want to add the proj4text column instead of always using the
wkt_to_proj4() function because
           there will be cases when a better proj4 string can be supplied (ie.
including datum transformation info)


ie. select transform(the_geom,4512) from mygeom;

>From the above discussion, it would appear this query would cause 2 (or
4) subselects for each row in mygeom.  But steps 3b and 3c are cachable
functions, so they should only be called once.

This version of transform() could be very inefficient because it builds
the 2 proj4 objects for *each* row in the query.  I'm not sure if the
proj4 objs can be easily serialized.

what think?
dave

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Unlimited PC-PC calling at Crystal Voice! - Only $1/Mo.
Download your free 30 day trial. Click here.
http://us.click.yahoo.com/Gb1xVB/GxbDAA/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] ST_TRANSFORM: proposal for postgis projection tranformation

Roderick A. Anderson-3
On Tue, 18 Dec 2001, Dave Blasby wrote:

>
> I've been doing a little bit of thinking about adding projection
> tranformation support in postgis.  

I'm all for it.  A week or so ago I mentioned trying the same thing.  A
very selfish need provoked me.  I have quite a bit of data from several
different sources and in different 'projections' that I'd like to use
with MapServer.  By importing it and then transforming all the bits and
pieces to the same system I'd have what I want and need.

I like all your thoughts and plans.



Rod
--
                      Let Accuracy Triumph Over Victory

                                                       Zetetic Institute
                                                        "David's Sling"
                                                         Marc Stiegler


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Unlimited PC-PC calling at Crystal Voice! - Only $1/Mo.
Download your free 30 day trial. Click here.
http://us.click.yahoo.com/Gb1xVB/GxbDAA/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] ST_TRANSFORM: proposal for postgis projectiontranformation

David Blasby-3
I looked at Frank's (?) code for converting WKT to PROJ4.  Its complex.

Since we have already existing lists of WKT and PROJ4 for all the EPSG
projections, I'm not going to write the WKT->PROJ4 function.  

Perhaps someone can make a big list of all the EPSG projections in WKT
and PROJ4 and make a (big) example spatial_ref_sys table with both the
srtext (WKT) and proj4text?

At some point in the future, we can add the WKT->PROJ4 converter, but it
seems like a lot of work with very little actual gain.

dave

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Need new boots for winter? Looking for a perfect gift for your shoe loving friends?
Zappos.com is the perfect fit for all your shoe needs!
http://us.click.yahoo.com/ltdUpD/QrSDAA/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] ST_TRANSFORM: proposal for postgis projectiontranformation

Frank Warmerdam
Dave Blasby wrote:

> I looked at Frank's (?) code for converting WKT to PROJ4.  Its complex.
>
> Since we have already existing lists of WKT and PROJ4 for all the EPSG
> projections, I'm not going to write the WKT->PROJ4 function.  
>
> Perhaps someone can make a big list of all the EPSG projections in WKT
> and PROJ4 and make a (big) example spatial_ref_sys table with both the
> srtext (WKT) and proj4text?
>
> At some point in the future, we can add the WKT->PROJ4 converter, but it
> seems like a lot of work with very little actual gain.


Dave,

First, I would like to suggest calling GDAL/OGR functions for doing the
WKT->Proj.4 translation as an option.  This would avoid the need to have
the proj4text column populated in advance at the cost of loading a
substantially larger shared library (libgdal.1.1.so) in addition to the
PROJ.4 one.  I am not sure how big an issue that is.  Note, there are
C linkage entry points for OGRSpatialReference, and OGRCoordinateTransform.
Once benefit of "buying into" OGR is that we can also piggyback on it's
knowledge of how to translate between other coordinate system representations
like EPSG codes,OGC XML, ESRI .prj format and so forth.  Of course, it might
just be better to use an OGR based tool to help populate the SRID table
and keep the direct dependencies of PostGIS minimal.

Second, an issue that isn't really adequately addressed in general by
the SF_TRANSFORM(shape,newSRID) mechanism is that there could be more than
one transformation that can take you from the source coordinate system
to the destination one.  This isn't a huge issue in the short term, but
will be an issue in the longer term with the need to match up with the
OGC Coordinate Transformations model for coordinate transforms.

Examples of coordinate system pairs with multiple transformations is stuff
like should the NTv1 or NTv2 datum shift tables be used.  What locally
optimized 3 parameter transform should be used for a mapping between two
datums.

Third, I would be willing to produce a table mapping all easily translatable
2D EPSG coordinate systems to WKT and PROJ.4 definitions.  Poke me when the
need for these becomes pressing if I haven't already produced.

Fourth, I would advise against direct serialization of projPJ structures.
The PROJ.4 definition string is pretty much the serialized form, and shouldn't
be terribly expensive to translate back into a structure.  However, for
reprojecting whole tables, it would be really desirable to be able to
cache the projPJ handles for a little while.  Is there no way to cache them
in a hash table and clean them up later when a transaction is complete?


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 ---------------------~-->
Win a Capcom Console Game of Your Choice Or Even a Capcom Arcade System. Click Here to Enter.
http://us.click.yahoo.com/tmpz8B/exbDAA/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] ST_TRANSFORM: proposal for postgis projectiontranformation

David Blasby-3
Frank Warmerdam wrote:

> First, I would like to suggest calling GDAL/OGR functions for doing the
> WKT->Proj.4 translation as an option.  This would avoid the need to have
> the proj4text column populated in advance at the cost of loading a
> substantially larger shared library (libgdal.1.1.so) in addition to the
> PROJ.4 one.  I am not sure how big an issue that is.  Note, there are
> C linkage entry points for OGRSpatialReference, and OGRCoordinateTransform.
> Once benefit of "buying into" OGR is that we can also piggyback on it's
> knowledge of how to translate between other coordinate system representations
> like EPSG codes,OGC XML, ESRI .prj format and so forth.  Of course, it might
> just be better to use an OGR based tool to help populate the SRID table
> and keep the direct dependencies of PostGIS minimal.

I hear what you're saying, and to a large extent I agree.  But, I dont
really want to stick the entire GDAL distribution into
PostGIS/PostgreSQL.
On the other hand, having GDAL/OGR support would add a lot of
functionality
and benefits to the larger Open Source GIS community.  
It would be nice to say to GDAL/OGR "Hay, I've got this projection, data
in
this location, and this new projection.  What do I do?"  Or, even
better,
"Here's some geometry and 2 srids, give me a new geometry."
I'm all for having GDAL/ORG doing working for me.  If all I have to
maintain
is the transform_geom(GEOMETRY,proj4text_source, proj4text_destination)
function, I'd be a happy boy.  Even better would be
tranform_geom(GEOMETRY,
PJ *proj_source, PJ *proj_dest).

 

> Second, an issue that isn't really adequately addressed in general by
> the SF_TRANSFORM(shape,newSRID) mechanism is that there could be more than
> one transformation that can take you from the source coordinate system
> to the destination one.  This isn't a huge issue in the short term, but
> will be an issue in the longer term with the need to match up with the
> OGC Coordinate Transformations model for coordinate transforms.
>
> Examples of coordinate system pairs with multiple transformations is stuff
> like should the NTv1 or NTv2 datum shift tables be used.  What locally
> optimized 3 parameter transform should be used for a mapping between two
> datums.

Yes, these are things I dont really want to worry about - it would be
best if I could just ask GDAL/OGR what to do.  But, one could still do
this
under the proposed system by creating 2 specific SRIDs, doing a NULL
transform from the generic projection to the specific projection, then
doing
a real transform from the specific source SRID to the specific
destination
SRID, and another NULL transform from the specific destination SRID to
generic SRID.

ie.
        Create 2 new rows in the spatial_ref_sys table with the
           specific projection information (ie. what 3 or 7 parameter
           datum shift to use).
       
        setSRID(
                TRANSFORM(
                        setSRID(geometry, <SRID_specific_source>)
                        ,<SRID_specific_destination>
                        )
                ,<SRID_generic_desination>
                )

Yes, its ugly and difficult to understand, but it should work.

What are other system using to account for these multiple transformation
problems?

 
> Third, I would be willing to produce a table mapping all easily translatable
> 2D EPSG coordinate systems to WKT and PROJ.4 definitions.  Poke me when the
> need for these becomes pressing if I haven't already produced.

Okay.  Someone (maybe Paul Ramsey) has a big list of WKT projections and
their
corresponding EPSG codes.  I think proj4 ships with a big list of EPSG
codes
and proj4 strings.
 
> Fourth, I would advise against direct serialization of projPJ structures.
> The PROJ.4 definition string is pretty much the serialized form, and shouldn't
> be terribly expensive to translate back into a structure.  However, for
> reprojecting whole tables, it would be really desirable to be able to
> cache the projPJ handles for a little while.  Is there no way to cache them
> in a hash table and clean them up later when a transaction is complete?

Postgresql has a high degree of isolation between action that take place
between rows. The easiest way convey partial results is to use cacheable
functions.  I believe functions are cached only during the execution of
a single statement (its subject to change in future releases - some
people
are advocating caching over an entire transaction).

A function is cacheable if it has no side effects, and the result is
always the
same if the function's arguments are the same.

Here's an example of "cheating" around the row isolation. In the example
below, I dont want to re-parse the WKT spheroid definition for every
row.

SELECT
length_spheroid(geometry_column,'SPHEROID["GRS_1980",6378137,298.257222101]')
 from geometry_table;

This example looks like it would parse the WKT for every row.  In fact,
it doesnt.

The length_spheroid() function is defined as:

CREATE FUNCTION length_spheroid(GEOMETRY,SPHEROID)
   RETURNS FLOAT8
   AS
'/data1/Refractions/Projects/PostGIS/work_dave/postgis/libpostgis.so.0.6','length_ellipsoid'
             LANGUAGE 'c'  with (isstrict);

Notice that the 2nd argument is of type SPHEROID not "text".

So, when postgresql sees a call to the length_spheroid(geometry, text)
is looks for
a function with types length_spheroid(geometry, text), and cannot find
it.  It finds the
function length_spheroid(geometry, spheroid) and says to itself "can I
convert text to
spheroid?".  It then looks for a function SPHEROID(TEXT) - and finds
it.  

The WKT string is then converted to the datatype "SPHEROID" and that
conversion is cached.  
length_spheroid(geometry,spheroid) is called.

On the next row, it will used the cached version of SPHEROID(TEXT).

At least thats what I think it does.

In our case, transform(geometry,integer), is much more complex.
Eventually, we want to convert this to tranform(geometry, PJ*,PJ*) but
there
is no automatic way of changing the number of arguments to a function.

I'm probably going to have tranform(geometry,integer) be another
function
(language: plpsql or sql) that will do something simple like:

   transform(geometry, integer) :-
        transform($1, get_proj4_from_srid( getSRID($1) ),
get_proj4_from_srid($2) )

the getSRID(geometry) will (probably) always produce the same SRID.
That means
that the 1st get_proj4_from_srid() will only get called once since it
could cache
its results.  The 2nd get_proj4_from_srid() would, likewise, only get
called once.


This leaves us with what does get_proj4_from_srid() return.  If it
returns a
string, tranform(geom,text,text) would have to parse the proj4
definition string
for each row.
On the other hand, if we create a new type (say PROJ4_PJ) thats a
serialized form
of the PJ* structure, we can have get_proj4_from_srid() return a
PROJ4_PJ and
have tranform(geometry, PROJ4_PJ, PROJ4_PJ) de-serialize it (instead of
parsing a string).  

There maybe other fancy-pants ways of storing partial results (that dont
move around
in memory) during a single SQL statement, but they would be pretty
magical and involve
using the postgresql shared memory heap.  Not something I really want to
do.


Hope I'm making sense,

dave

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Call any Phone in the World from your PC with CrystalVoice
-LOW rates world-wide - $0.039/min in U.S.
FREE trial. Click here.
http://us.click.yahoo.com/Ib1xVB/IxbDAA/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/