Thanks for your comments.
first, on the admin part, please try to avoid any attachement in your e-mails to the list as it
consume large chunk of bandwidth and e-mail space. I'm leaving in the Pacific where Internet can
cost up to 50c a kB, so I'm sensible to these things. Use a link to the document or announce
that you have the doc so I can receive it and place it on the fmaps ftp site if needed... I hope
however that I'm not impeding your future participation.
It seems that we will have to take bets on the future:
PostgreSQL fast enough to handle the data.
PostgreSQL quickly toasted to allow large records (>9kB).
PostgreSQL able to do data replication.
As for the windows port and the relation on a local database. I would prefer to avoid totally a
loacl database as in GIS it brings more data consistency trouble than it solves. In my day time
job, I'm working on GIS metadata and a MS-SQL system/MapInfo to store and metadata all usefull
MapInfo tables so they can be retreived via queries (I want the roads of Niue rather than where
is this file?).
I have implemented a database using MS-SQL on NT server and remote locations using MS-SQL server
on win95 with replication enabled, and it is working great. Doing the same with access would
have been a coding hassle.
On the windows port, I think we have to separate the client from the server, which means how
much do we put in the server and how much in the client. PG works on many platforms, so
extending it should go on any platform. My undestanding of the problem is that PG server on
Windows needs cygwin which is not really free. However I suspect that from windows you can call
a PG server running on another platform (linux for instance). If you are serious in GIS you can
spend a little bit on hardware to install Linux on a separate machine, and have windows/Linux
clients. I would rather take this approach rather than go local database.
I think Eric has sorted out most of the new types to define, and we should leave the engine
broad enough to allow the adding of any object type.
1)Let say we have a data table called mytable, then we have the tables called f_points_mytable,
f_polylines_mytable,... It is easy then to add a new type to the engine...But there are many
tables to manage.
2)The other way is to have a single object type wihich is a union of all types. The object type
is the only type available to the user. It then creates a single table with extra colums for
geoobject. But we can hit quicly here the 8kB limit...
I would like to know which option is prefered. I was going in the way of 1) as it allows to add
columns for time, line width, pattern,...
For Indexing we can leave it for the moment, as I know now that everything is possible with PG
(cf http://gist.cs.berkely.edu/), when the display egine will work then we will be able to
request part of the objects for display, so we will need a suitable index...
There is also a question of projections. Should it be PG to handle or the client? I think it
will be easier if it is the client that handles the projection convertion, however it will
create problems when you try to intersect to objects from 2 different projections. Part of the
query work will have to be done in the client... It will allow also the client to request
projection transformation for many reasons...
I will now read the PDF...
And try to do some coding this WE, prepare the port to windows by removing any gnome
Adrian Vance Custer wrote:
> Hello everyone,
> Been following your list for a little while and am impressed by your
> enthusiasm and intensity. If you keep it up, you'll be running in no
> time. :)
> I'll spit back your own words at you:
> Data Model: Where is it?
> Before any developer can do too much, it's necessary to have a
> well defined data model. I realize such a thing is in the
> works. It's probably a good idea to think about how
> abstractions can be used here. Of course, there is the low
> level data format, but the presentation to other parts of the
> software and the user should be somewhat higher level.
> Then you all started learning and coding and ...well, there is an
> active discussion going on as well. I'm not quite sure who is going in
> what direction as far as the search structure/indexing is concerned.
> I've attached a pdf file taking things from the top down rather than
> from the implementation direction. I've been trying to define data
> objects which could be used effectively for ecological analysis. I'm
> working to define the objects, understand how they can be stored in
> various search structures and figure out how a modular system could be
> assembled. My vision has not been the tight integration with a
> database but I'm really interested to see you all going after that.
> I gather from Nicholas (windows port) that the database integration is
> a crucial issue for his work. The temptation is really strong to have
> an intergrated database---it's the route Arcinfo8 has taken (on MS
> Access) and it is great for searching for data objects by their
> attributes. Since PostgreSQL's types are all 2-D you're going to have
> to create all the 3D (and time?) search functions yourselves. If
> PostgreSQL is fast enough then it's great and your work is useful to
> other projects as well. It sounds like you are saying you need to
> create index structures. Since you are allready building an object
> structure (reactive tree?) in memory for display purposes, it makes me
> wonder how much the database is bringing you.
> My kick is along these lines. Essentially my question is "What search
> structures are needed to get analytical output from a GIS?" Also, I echo
> Nicholas' sentiments. I've thought of gnuGIS as a three component
> program, a viewer and query piece, an analytical piece and a a core
> data manipulation piece. The idea is you could get a view up and
> running pretty quickly, (cheap thrills). Then you start building the
> backend. If you add an API layer between your viewer and the backend
> storage, you leave yourself free to completely re-tool the backend
> anytime you want.
> So this attachment is my preliminary take. I'm hoping to give it more
> detail over time. I'm not sure how relevant it is to what you are
> doing but I would be interested to read your responses.
> adrian custer
> Name: gnugis_white-paper_version1.pdf
> Type: Portable Document Format (application/pdf)
> gnugis_white-paper_version1.pdf Encoding: base64
> Description: PDF document, version 1.2
> Download Status: Not downloaded with message