One of the things which crops up alot in talk about OpenGIS is the
Well-Known Binary format. We have talked about implementing it in some
manner (Dave's internal representation is not far from WKB, in alot of
ways) but have come up against an interesting pgsql quirk: almost all of
the input and output in pgsql is done via text representations.
Certainly, if you are going at pgsql via the JDBC interface, your
conversion with the server is in text, even if you don't see it, because
the JDBC driver works against a standard text cursor.
Now, Pgsql supports binary cursors, and I am pretty sure at this point
that we could set up some functions which allow input and output of WKB
via a binary cursor, but those cursors will only be available to people
writing interfaces via libpq. Once you start playing with binary cursors
there are also issues of endianness to worry about: if you access a
server running on a big-endian server (solaris on sparc, say) from a
little endian client (a linux box on intel) then there will be endian
issues. Fortunately, WKB has an endian flag so in theory everything will
still be hunky dory.
Does anyone have any interest in WKB? Is anyone using it? The only
reason I can see for pursuing it is for performance: the thought of all
the text->machine->text->machine translations that would be required to
tie postgis to some kind of client implementation is starting to give me
pause. Things could end up very slow. Thoughts?
I suppose that would end up as myGIS? :) Unfortunately (or fortunately),
postGIS is tied right into the internals of pgsql: there is no leverage
to be gained against mysql using the code (or understanding) our postgis
efforts have generated. Along the lines of my "Feature Server" message
of last night, a clean and db neutral API could frontend both postgis
and a different mygis implementation.
Our early tests of using pgsql to do opengis yielded the following
thoughts which may or may not apply to mysql:
- the "fully-relational" setup of SF had a lot of input/output overhead
putting things together and taking them apart
- using pgsql with the features in BLOBs seemed cool, but in comparison
with using the basic geometric types to store the same features was 10
TIMES slower for read access
- the built-in geometrics were good, but were limited to the 8K page
size, did not support aggregation, and did not have explicit holes for
the polygons. in the end we decided it would be better to write our own
than to try and hack around the limitations of the built-in types.
So what would a myGIS implementation look like? I have no idea, I know
too little about the strength and weeknesses of mysql. If the blob
access is fast enough, perhaps a system which stuffs the geometries into
tables as WKB would work. I assume better people than I have chewed this
Kenneth Melero wrote:
> Is there any desire to support MySQL as well as PostgreSQL?
> Great work on PostGIS already! :-)
> - Ken
> Kenneth Melero Imagelinks, Inc.
> Director of Technology 4450 W. Eau Gallie Blvd.
> Melbourne, FL 32934
> 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