[Mapserver-dev] Re: time support

[Steve Lime]

Hi Dave: I'm not sure what you mean by "But the problem still remains
that nature of the query on the TILELAYER in order to find the locations
for the actual image tiles.". Can you ellaborate?

Steve

>>> "David W. Graham" <dgraham at i3.com> 1/15/2004 11:40:27 AM >>>
Brent,

Your solution actually makes a lot of sense.  Often times I have the
"TILEINDEX" shapefile in the MAP object as a layer unto itself called
the
"coverage" of the raster data.  This allows user to turn on a layer and
see
the tile lines and names of the tiles (used in data management and
ordering
apps).  But the problem still remains that nature of the query on the
TILELAYER in order to find the locations for the actual image tiles.

Any suggestions?

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 Brent
Fraser
Sent: Wednesday, January 14, 2004 11:44 AM
To: Steve Lime
Cc: mapserver-dev at lists.gis.umn.edu 
Subject: Re: [Mapserver-dev] Re: time support

Steve,

  Here's an idea from left field.  The basic problem is we're on the
road to
creating a layer-within-a-layer, adding new keywords and possibly
changing
the syntax of existing keywords.

How about pointing to another layer (a tileindex layer) from the layer
of
interest?

LAYER
  NAME 'landsat images'
  TYPE raster
  STATUS on
  TILEITEM "Location"
  TILELAYER "landsat_tiles"  # new keyword; points to tile layer END

LAYER
  NAME 'landsat tile outlines'
  TYPE polygon                     # or have a new type of  "tile" ?
  STATUS off
  DATA "index/landsat.shp"
END

That way we could leverage existing filtering, connection, etc
structure for
the tile layer.  Might be too weird though....

Brent


----- Original Message -----
From: "Steve Lime" <steve.lime at dnr.state.mn.us>
To: <morissette at dmsolutions.ca>
Cc: <mapserver-dev at lists.gis.umn.edu>
Sent: Wednesday, January 14, 2004 10:16 AM
Subject: Re: [Mapserver-dev] Re: time support


> I could create a single new keyword (e.g. TILES) and use the older 
> keywords to populate members of the new object. That's how styles
work 
> so that older map files don't break. In effect:
>
> TILEINDEX 'foo'
>
> would be the same as
>
> TILES
>   DATA 'foo'
> END
>
> To take advantage of filtering you'd have to move to the TILES
object.
> The only
> side effect would be that mapscript would break since 
> $layer->{tileindex} isn't real anymore. That was the same case with 
> styles.
>
> This seems a reasonable compromise to me anyway.
>
> Steve
>
> >>> Daniel Morissette <morissette at dmsolutions.ca> 1/14/2004 7:55:30
AM
> >>>
> Steve Lime wrote:
> > Any comments out there? I kinda need to move swiftly...
> >
> >
>
> I am concerned by the fact that the new tileindex object would break

> existing mapfiles.  Could we stick to shapefile tileindexes for this

> release for now, since we don't have much time anyway, and perhaps in

> a
>
> later release we could move a tileindex object and support tile 
> indexes
>
> in any format?
>
> I suppose the main drawback of this approach would be that we would 
> have to create TILEFILTER/TILEFILTERITEM which would have to be 
> deprecated later when we create the tileindex object.
>
> I dunno.... I think we should try to avoid breaking older mapfiles 
> unless we really have to... that's always a pain for users to upgrade

> when we break the mapfile format.
>
> 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