Thom,

I found it a perfect solution to store the tileindex vectors in a PostGIS database. It makes the use of tileindexes (image catalogs) more flexible. It's possible to set SQL filters on the tileindex layers.

All updates are easily to achieve, just need to send SQL commands with whatever programming language you want to Postgis to reference a new image. Spatial indexes are updated automatically too. And you can keep additional metadata also in the database.

The only requirement is to use 2 instead of one layer definition for the image catalog.

Armin

Thom DeCarlo wrote:
Hey Ed,
(So, you and Norm are over here, too. Small world!)

This sounds good. I've been reading up on the gdaltindex and I think I
understand how to get it set up. But, what is this shptree thing you
mentioned? Also, two other issues. First, the client is going to be continually
requesting map updates and the server will be getting frequent additions to
its repository. If the tile index is held in a shapefile will the MapServer
re-read that file when a new client request comes in or is it only read when
Mapserver starts?
Second, since I've already got a PostgreSQL server managing the vector data,
can the tile index be held in it, too? I'm going to have a lot of
overlapping imagery and it seems (to the novice that I am) that SQL queries
could find the best/newest data to serve out to the client. Or, is this just
unnecessary overhead?

Reply via email to