[postgis] Next Level Redux

John Reid jgreid at uow.edu.au
Fri Aug 17 00:43:02 PDT 2001


  Hi,

There are some other open source efforts that may help provide some of 
what you appear to be looking for that I haven't seen any mention of yet 
on the list.  I don't know if they might be interested in collaboration. 
 Some details, ideas and a healthy dose of questions below:

Paul Ramsey wrote:

>Frank Warmerdam wrote:
>
>>It would depend on your language of implementation.  Because so much is
>>separated out into the database which has it's own concept a long running
>>process for maintaining some state and caching I would hope a light cgi-bin
>>impelementation would be fine.  Of course, I don't know too much about
>>how Java stuff is done in a web environment.  You certainly don't want to
>>start a JVM for each call.
>>
>
>Laugh if you will, but I was actually thinking about perl... one can
>prototype with a CGI and go long-running with mod_perl when performance
>is a problem. The thing about transactional stuff is that you run up
>against one of the interesting and silly quirks that doing GIS
>operations over HTTP gives you:
>
>1-  Client to WFS: Lock feature X!
>1-  WFS to Client: Locked.
>2-  Client to WFS: Here's an update to feature X!
>2-  WFS to Client: OK, thanks.
>
>HTTP session 1 actually *ends* and session 2 is a completely new
>connection. If you have a simple CGI, it will shut down and lose all its
>state between connection 1 and 2
>
Some open source development is currently occuring associated with 
resource data directory projects in Australia.  I know they have been 
working on distributed retrieval of info with wrappers to desktop data. 
 AFAIK mostly read only at this stage.

>For database purposes, this means you
>lose your connection to the database, and hence also your transaction,
>*oof*! So for simple CGI, you have to do the locking *yourself*, fun!
>However, with a long-running process, you can maintain your database
>connection between HTTP requests, and therefore can delegate the
>maintenance of the lock to the database. The trick then is matching up
>clients to their locks: I have to go back to the spec, I am assuming a
>lock request generates a lock key for the client.
>
Could the GoF's connection pool pattern be relevant here?

>>Well, there are a few WFS clients in existance now - including GeoMedia
>>(or at
>>least an upcoming GeoMedia) but you are right that there wouldn't be too
>>much.
>>
Some stuff along these lines must have been done by these projects aimed 
at combining and delivering spatial data from different sources:

    * canri/nrdd/social change online (see
      http://www.canri.nsw.gov.au/tech/index.html) - mapserver
      extensions using java, perl for access to distributed data sources.
    * imroc/csiro ( http://imp.cmis.csiro.au/imroc/csiro/about.htm, also
      http://www.cmis.csiro.au/sis/) also svg java toolkit for vector
      graphics.

HTH,

John



------------------------ Yahoo! Groups Sponsor ---------------------~-->
Do you need to encrypt all your online transactions? Secure corporate intranets? Authenticate your Web sites? Whatever
security your site needs, you'll find the perfect solution here!
http://us.click.yahoo.com/Bre3tC/Q56CAA/yigFAA/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