[Mapserver-dev] Re: time support
Brent Fraser
bfraser at geoanalytic.com
Thu Jan 15 14:59:25 EST 2004
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