[postgis] To Do List

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

[postgis] To Do List

Paul Ramsey-2
- Testing (DONE)
  Results of bounding box query on indexed table of 1million records:
returned so fast we cannot stopwatch it.
- Fix to VACUUM ANALYZE (DONE)
- gml() function and associated support type
- wkb() function and associated support type
  - testing of wkb() and binary cursors with libpq
- documentation
  - started moving structure over to docbook
- type() functions to return polygon/polyline/point, etc
- interface into the Minnesota mapserver

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] To Do List

Frank Warmerdam

Paul Ramsey wrote:

> - Testing (DONE)
>   Results of bounding box query on indexed table of 1million records:
> returned so fast we cannot stopwatch it.
> - Fix to VACUUM ANALYZE (DONE)
> - gml() function and associated support type
> - wkb() function and associated support type
>   - testing of wkb() and binary cursors with libpq
> - documentation
>   - started moving structure over to docbook
> - type() functions to return polygon/polyline/point, etc
> - interface into the Minnesota mapserver

Paul,

I haven't built postgis yet, but I would like to comment on a few of the
TODO items.

I have WKB parsing/building code in my OGR library (same code used to
implement WKT and WKB functions in FME).  I don't know that it would make
sense to add the OGR code to postgis, or just to reimplement.  Handling WKB
isn't particularly hard.

I think the gml() idea is good, though I don't have much to add.

MapServer already can use "OGR datasources", which currently includes a
quick hack on libpq for simple features style vectors in postgres.  I would
like to "catch up" the postgres driver in OGR to match the schema maintained
by postgis, so that MapServer can use this link to utilize postgis.  

It may make sense to use OGR as a basis for some postgis related utilities,
and as a data loader/unloader for some applications.

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


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] To Do List

Paul Ramsey-2
Hi Frank,
We're very much interested in seeing postgis hooked into Mapserver, as
it would provide an instant interface to our datastore. And when
conversing with the PHBs, an interface is important! (For some reason,
people just don't get all excited about the SQL commandline, I have no
idea why.) Is hooking into the maplayer.c abstraction difficult?

Frank Warmerdam wrote:

>
> Paul Ramsey wrote:
>
> > - Testing (DONE)
> >   Results of bounding box query on indexed table of 1million records:
> > returned so fast we cannot stopwatch it.
> > - Fix to VACUUM ANALYZE (DONE)
> > - gml() function and associated support type
> > - wkb() function and associated support type
> >   - testing of wkb() and binary cursors with libpq
> > - documentation
> >   - started moving structure over to docbook
> > - type() functions to return polygon/polyline/point, etc
> > - interface into the Minnesota mapserver
>
> Paul,
>
> I haven't built postgis yet, but I would like to comment on a few of the
> TODO items.
>
> I have WKB parsing/building code in my OGR library (same code used to
> implement WKT and WKB functions in FME).  I don't know that it would make
> sense to add the OGR code to postgis, or just to reimplement.  Handling WKB
> isn't particularly hard.
>
> I think the gml() idea is good, though I don't have much to add.
>
> MapServer already can use "OGR datasources", which currently includes a
> quick hack on libpq for simple features style vectors in postgres.  I would
> like to "catch up" the postgres driver in OGR to match the schema maintained
> by postgis, so that MapServer can use this link to utilize postgis.
>
> It may make sense to use OGR as a basis for some postgis related utilities,
> and as a data loader/unloader for some applications.
>
> 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
>
> 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/

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] To Do List

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

> MapServer already can use "OGR datasources", which currently includes a
> quick hack on libpq for simple features style vectors in postgres.  I would
> like to "catch up" the postgres driver in OGR to match the schema maintained
> by postgis, so that MapServer can use this link to utilize postgis.

When do you think this'll get started? Dave is going to be adding some
support functions around wkb() and using binary cursors which should
make the data transfer faster, rather than parsing well-known text. Also
hopefully an 'extent()' function.
 
> It may make sense to use OGR as a basis for some postgis related utilities,
> and as a data loader/unloader for some applications.

Jeff is writing a loader/dumper (using shapelib, tee hee) so we're kind
of using OGR already. Once OGR supports PostGIS, a simple wrapper to OGR
will make more sense.

Paul
 

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

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] To Do List

Daniel Morissette-3
In reply to this post by Paul Ramsey-2
Paul Ramsey wrote:
>
> Hi Frank,
> We're very much interested in seeing postgis hooked into Mapserver, as
> it would provide an instant interface to our datastore. And when
> conversing with the PHBs, an interface is important! (For some reason,
> people just don't get all excited about the SQL commandline, I have no
> idea why.) Is hooking into the maplayer.c abstraction difficult?
>

No, hooking into the maplayer.c abstraction is not very difficult.
There's about half a dozen functions you need to implement, and there's
already 3 implementations to learn from: the native Shapelib, SDE, and
the OGR one that I added.

However as you wrote...

Paul Ramsey wrote:
>
> Jeff is writing a loader/dumper (using shapelib, tee hee) so we're kind
> of using OGR already. Once OGR supports PostGIS, a simple wrapper to OGR
> will make more sense.
>

... I think adding support for PostGIS in OGR as Frank suggested
(instead of native PostGIS support in MapServer via the maplayer.c
interface) would be a better option for the short term at least.  This
will give PostGIS more exposure since MapServer, OpenEV, and all other
apps that support OGR will automatically have access to PostGIS.

It will also be simpler for you since you will have only one interface
to maintain (the OGR one), i.e. if something changes in MapServer's
maplayer.c you don't need to do anything.. only the OGR link has to be
updated (by me :) and all the OGR drivers continue to work.

On the other hand, we have to admit that OGR's object structure adds
some overhead, so if down the road you find that OGR adds too much
overhead then you can always go ahead and implement the native PostGIS
link in MapServer and tweak it to be as fast as can be.

My 0.02$ !
--
------------------------------------------------------------
 Daniel Morissette               [hidden email]
 DM Solutions Group              http://www.dmsolutions.ca/
------------------------------------------------------------
  Don't put for tomorrow what you can do today, because if
      you enjoy it today you can do it again tomorrow.


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/