[Mapserver-dev] Re: time support

[Steve Lime]

Any comments out there? I kinda need to move swiftly...

>>> "Steve Lime" <steve.lime at dnr.state.mn.us> 01/12/04 11:27 PM >>>
I've no problem with DB sources. They are efficient enough not to need
tiling. The issue standing in my way is whether to create a new
TILEINDEX object or to add additional parameters to deal with filters. 

The positive with a TILEINDEX object is that essentially no new keywords
would be necessary. We'd simply re-use a bunch that are already defined.
Plus there's lots of room for flexiblity in the future- say for
projections, non-shapefle index or even options to "view" the tile
index.

The negative is that this would break existing mapfiles using tiles.
That's not exactly uncommon.

Personally I favor the new object. Thoughts?

Steve

>>> "David W. Graham" <dgraham at i3.com> 01/12/04 5:11 PM >>>
Steve:

Your suggestion for a TILEINDEX object would be very useful to anyone
with

really large archives.  I am quite aware that using a shapefile with
index
will aways be faster than a database.  But some projects do lend
themselves
to database management.  We already have several archive projects where
we
are managing thousands of raster images that are getting updates
regularly.
As it is now, we only stream contiguous data sets.  They are a small
fraction of what is available from the archives.  

What do others think of such a change?

Dave

________________________________________________ 
David W. Graham 

Director of Application Development
dgraham at i3.com 
Voice: +1-970-482-4400
Fax: +1-970-482-4499
Web: www.i3.com 

i-cubed    	
201 Linden, Third Floor    	
Fort Collins, CO 80524    	

-----Original Message-----
From: mapserver-dev-admin at lists.gis.umn.edu
[mailto:mapserver-dev-admin at lists.gis.umn.edu] On Behalf Of Steve Lime
Sent: Tuesday, January 06, 2004 11:01 AM
To: dgraham at i3.com
Cc: mapserver-dev at lists.gis.umn.edu
Subject: RE: [Mapserver-dev] Re: time support

My plan is to allow arbitrary fields to be added to the tileindex, and
then
filter against whatever you need- startdate-enddate, sensor name or
whatever.
Sounds
like to meet your needs we'd need to generalize tiles futher by allowing
non-shapefile tile indexes. I could see moving TILEINDEX into it's own
object, almost a mini-layer.
So you could do something like:
  
TILEINDEX
  DATA ...
  CONNECTION ...
  FILTER ...
  FILTERITEM ...
  TILEITEM ...
END

Other ideas?

Steve

Stephen Lime
Data & Applications Manager

Minnesota DNR
500 Lafayette Road
St. Paul, MN 55155
651-297-2937

>>> "David W. Graham" <dgraham at i3.com> 1/5/2004 5:18:26 PM >>>
Steve:

Just catching up on the conversation.  It is very timely for us at
i-cubed.
:) I am trying to find a way to stream (WMS) a series of tiles that will
be
updated quite often (atleast every 2 weeks) with new versions.  All
versions
must be available for streaming.  

We are looking at a Postgres (Postgis) solution.  But as I look at this
converstion, it seems that a solution similarly to the one we are
looking at
would probably be quite useful to the temporal discussion.

My solution is simply to add a date field to the tileindex (.i.e there
will
be overlapping polygons with differing date and location attributes). 
Then
move the tile index into PostGIS so I can keep the massive flood of data
we
are potentially looking at under control.

It will likely be a mapscript hack.

Dave


________________________________________________
David W. Graham 

Director of Application Development
dgraham at i3.com
Voice: +1-970-482-4400
Fax: +1-970-482-4499
Web: www.i3.com 

i-cubed    	
201 Linden, Third Floor    	
Fort Collins, CO 80524    	

-----Original Message-----
From: mapserver-dev-admin at lists.gis.umn.edu
[mailto:mapserver-dev-admin at lists.gis.umn.edu] On Behalf Of Steve Lime
Sent: Wednesday, December 17, 2003 9:11 AM
To: morissette at dmsolutions.ca
Cc: mapserver-dev at lists.gis.umn.edu
Subject: Re: [Mapserver-dev] Re: time support

I not convinced I'm right though. The more I've thought about it the
more I
like extending TILEINDEX. Franks here today, I'll bounce it off him.

Steve

>>> Daniel Morissette <morissette at dmsolutions.ca> 12/17/2003 9:49:38
AM
>>>
Steve Lime wrote:
> A timeindex would not be a shapefile, rather simply a temporal
lookup
> table. An xbase file would do nicely. 

You're right. I didn't realize that.


> That
> way date expressions could be used with any data source if a column 
> contained ISO8601 formated date/time strings. In that case using a 
> timeindex for anything but raster data may not be necessary. Raster
data
> is certainly the task at hand for me.
> 

Actually, some people might have one shapefile per time range (or time

value), so I can see why this TIMEINDEX would be useful to shapefiles as
  well. Imagine an organization with 100 years of daily weather data: 
that's too much information to store in a single shapefile if you want

reasonable performance. I guess they would be better using a RDBMS than

shapefiles for this anyway, but that's an example where TIMEINDEX on
shapefiles could be used.

Daniel
--
------------------------------------------------------------
  Daniel Morissette               morissette at dmsolutions.ca 
  DM Solutions Group              http://www.dmsolutions.ca/ 
------------------------------------------------------------

_______________________________________________
Mapserver-dev mailing list
Mapserver-dev at lists.gis.umn.edu
http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev 

_______________________________________________
Mapserver-dev mailing list
Mapserver-dev at lists.gis.umn.edu
http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev


_______________________________________________
Mapserver-dev mailing list
Mapserver-dev at lists.gis.umn.edu
http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev