[Mapserver-dev] Re: time support
Steve Lime
steve.lime at dnr.state.mn.us
Thu Jan 15 15:23:07 EST 2004
I'm thinkin it must be that way. *joy*
>>> "Brent Fraser" <bfraser at geoanalytic.com> 1/15/2004 1:59:25 PM >>>
Steve,
My vote is to put the location item with the tile layer.
As you point out, this would allow you to use one tile index
layer for one or more datasets :
#--- data layers: -----
LAYER
NAME 'landsat natural color images'
TYPE raster
STATUS on
TILEITEM "LocationNatural"
TILELAYER "landsat tile outlines" # points to tile layer
END
LAYER
NAME 'landsat infrared color images'
TYPE raster
STATUS on
TILEITEM "LocationInfrared"
TILELAYER "landsat tile outlines" # points to tile layer
END
#--- index layer:---
LAYER
NAME 'landsat tile outlines'
TYPE polygon
STATUS off
DATA "index/landsat.shp"
END
Brent
----- Original Message -----
From: "Steve Lime" <steve.lime at dnr.state.mn.us>
To: <dgraham at i3.com>; <mapserver-dev at lists.gis.umn.edu>
Sent: Thursday, January 15, 2004 12:30 PM
Subject: RE: [Mapserver-dev] Re: time support
> The queries against the tileindex or layer are issolated in 2 places:
1
> time for shapefiles and 1 time for rasters. No other datasources use
> tiles. The query is really straight forward and I'm already doing
it,
> find all tiles intersecting a rectangle. It's identical to what the
> layer specific code already does, that is, it results in a list of
> candidate features (or tiles). The nice thing about a tile layer is
that
> the code to manage that list, including filtering, is already
written. I
> looked at the code last night and I don't think the changes are too
bad-
> there are just a whole bunch. It sucks to have to keep the old code
> cause I think this can be really clean.
>
> One gotcha is that someplace you need to define a the location item.
> Should it be in the layer to be tiled or the tile index? If not kept
> seperate then there would be no sharing of indexes across layers.
This
> would be bad. However, keeping them seperate is tricky too because,
> well, information needed to deal with layer is in two places. I think
I
> can just treat a tile layer as a normal query layer and simply
retrieve
> all attributes (sorry thinking out loud) so it doesn't matter where
the
> location item is stored.
>
> This will be part of the 4.2 release...
>
> Steve
>
> >>> "David W. Graham" <dgraham at i3.com> 1/15/2004 12:29:24 PM >>>
> Steve:
>
> Basically what Brent has indicated below. The raster layer would
have
> to
> perform a query against the tileindex layer and be returned the
> location of
> the raster objects. Would this be some sort of standardized
internal
> query,
> or does the mapfile user have to format the query response
themselves.
> It
> is unclear how the whole interaction would work.
>
> 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: Brent Fraser [mailto:bfraser at geoanalytic.com]
> Sent: Thursday, January 15, 2004 11:22 AM
> To: David W. Graham; mapserver-dev at lists.gis.umn.edu
> Subject: Re: [Mapserver-dev] Re: time support
>
> Dave,
>
> Conceptually, the layer describing the individual tiles would be
> more
> for specifying the rendering of the elements (colors, fonts, etc for
> vectors, not very useful for raster), while the layer describing the
> tile
> index would be for filtering/querying (both spatial and attribute,
> e.g.
> time). But you could use the full power of all the layer options if
> you
> liked (more filtering on the individual elements, etc).
>
> As you point out, a query (spatial at least) would have to be
> performed
> on the tile index layer, then for each record returned from the
index,
> the
> location of the tile would be used in processing the tile layer
(this
> is
> done in the current version anyways).
>
> Steve Lime had mentioned in a previous post that it would be no
> small
> effort to add this layer-pointing-to-a-layer feature, and he is
right.
> We
> would have to look at the effect this would have on the various
objects
> and
> attributes of a layer. For example, what if the projection object
of
> the
> tile index layer was specified differently from the tile layer? (BTW
> Steve,
> I've got code (not checked-in!) for that).
>
> There are benefits though....
>
> Brent
>
>
> ----- Original Message -----
> From: "David W. Graham" <dgraham at i3.com>
> To: <mapserver-dev at lists.gis.umn.edu>
> Sent: Thursday, January 15, 2004 10:40 AM
> Subject: RE: [Mapserver-dev] Re: time support
>
>
> > 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
>
>
> _______________________________________________
> 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
More information about the mapserver-dev
mailing list