[postgis] JTS vs Java2D

Adrian Custer acuster at nature.berkeley.edu
Wed Aug 1 13:26:00 PDT 2001


Thanks for the explanation about JTS; it looks like something worth
exploring.


I think there is some confusion in this discussion so this is an attempt
to clarify the issues. The core issue is where the gis application's
query is performed and goes to the core of whether the application is
designed with a database as the core analytical component or with the
database as one (of many) sources of data.

Consider the situation where a user wants to access data in a shapefile
and data stored in a PostGIS database. The application could be designed
in two ways:

1)

application -> [query engine] -> Data Base query engine -> data table
                    |------------------------------------> Shapefile

In this case the application calculates the final result. The shapefile
objects are read into RAM, a database query made for the set of objects
that are not evidently excluded from the final query and the final query
is made by the application's query engine on the two sets of objects.

2)

application --------> PostGIS query engine  ----------> data table
                                            |---------> shapefile table

In this case the shapefile has to be read into the database before the
query and then the application does no analysis of it's own. (Changes to
the shapefile table would have to be returned carefully to the original
shapefile since in the meantime that file could have been modified
through another program.)


>From what I can tell JTS makes the best sense for the first setup, where
it is used by the native query engine of the application. If the
application is written in Java, it can create spatial objects from the
shapefile into memory, call the database for objects relevant to the
query, put them in memory and then use JTS to do the final analysis. The
object set coming from the database would obviously be large since it is
not the subset that conforms to the final query.

In the second case, PostGIS would be responsible for implementing the
full suite of queries. It might choose to use JTS but I don't quite see
how. (my ignorance of how PostgreSQL works shines through.) Is a call of
"PostGIS->JTS->operation on table" fast? Is coding the "JTS-> operation
on table" less work than coding "PostGIS->operation on table"? It seems
that the advantage of keeping the link direct is to optomize the
"operartion on table" and that adding the dependency on Java a bad idea.
I really don't get how JTS helps but would be interested to learn more.


All this being said, it seems to me the perferred form of operation is
as follows:

application -> query api -> app query engine ------> data files
                                             |-> PostGIS query engine
                   |---------------------------> PostGIS query engine

The API allows the application to issue queries stably and the back end
to evolve. Over time, the application can rely more and more on PostGIS
as PostGIS functionality develops. The presence of an application query
engine allows the applicaiton to funcition when PostGIS isn't around
and/or the creation of queries that are so esoteric that PostGIS would
never be interested in them. Again the API abstraction give coders the
flexibility to duplicate work (2 query engines) or not as they find
important.

Hope this helps,

cheers,
adrian



------------------------ 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:
postgis-unsubscribe at yahoogroups.com

 

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





More information about the postgis-users mailing list