RE: [mapserver-users] A Question of Group

[Lime, Steve D (DNR)]

Version 5.6 introduces an XML mapfile schema and stylesheet. So (in theory) one 
could manage a mapfile in XML and transform it for use. We intend to allow more 
direct use somehow although that hasn't been decided. At the code sprint an 
on-the-fly transformation was tested successfully. Other options include 
just-in-time conversion from XML to .map (via XSLT) or native XML parsing. 
We'll see...

On a side note, developers here played with using HTML legends to create output 
suitable for use with the YUI collapsible menu widgets. In the end we gave up 
and instead worked up a PHP/MapScript-based solution. The script works off a 
mapfile and a bit of embedded metadata to produce a JSON legend object. That 
object is passed in turn to a legend widget that is based on YUI. The legend is 
somewhat framework agnostic and we've hooked it up to dbox (where it started) 
and more recently OpenLayers. With an XML mapfile one could probably to the 
JSON production independent of MapScript or entirely on the client although 
that's probably sharing too much information.

Steve

From: mapserver-users-boun...@lists.osgeo.org 
[mapserver-users-boun...@lists.osgeo.org] On Behalf Of Bill Thoen 
[bth...@gisnet.com]
Sent: Wednesday, March 03, 2010 1:47 PM
To: mapserver-users@lists.osgeo.org
Subject: Re: [mapserver-users] A Question of Group

Bob Basques wrote:
>
> Bill,
>
>
> This is a shameless plug for GeoMoose functionality, it was prompted
> by your comments below however, so I don't feel too bad  :c)
>
>
Grab every opportunity that sets you up for a pitch! Although I'm
actually not unhappy with HTML Legends --I've found workarounds for
things I don't like-- but it would have been nice to have known in
advance where it runs out of steam or just doesn't go, so I'd know
whether I would reach the point of implementing kludges before or after
I reached my goal.

GeoMoose sounds pretty good and seems to solve my problems 1-2-3... But
before I go try it out now instead of later and spend a lot of time I
can't spare contemplating a software switch and testing its capabilities
for possible use in a project with a tight  deadline,  can you highlight
for me the top two or three areas where the hard, cold ground rises up
to meet it (i.e. where it falls on its face)? I'm not looking for what's
broken, but more along the lines of what it is NOT designed for, so I
don't make th e mistake of trying to use in a situation where it will
not do well.

> *  Each layer (or group of layers) is controlled via it's own mapfile,
> while this might seem cumbersome to manage, it does allow for separate
> and integrated management of data layers by many data custodians,
> which is what GeoMoose was originally designed for, many data
> custodians doing their own thing.  It's also very good for automation
> purposes in general.
>
>
One of the both strong points and weak points in the FOSS mapping
software I've seen so far is its almost universal core dependence on
mapfiles or templates as the driving mechanism. These are powerful in
that the are easily modified, human and machine readable and you can
record layer "states" and mix and match the "objects" later on as you
like to create alternate configurations. But where they're a weak point
is when you want to provide a warm 'n fuzzy front end for User B. Goode.
Templates are difficult to work with at that point. They're based on the
1950s-60s notion of batch programming in which the programmer decides
where the process starts and ends. So when you try to build an
interactive, user-driven interface on top of this, the bugs and
shortcomings you tend to run into are usually rooted in a sort of
schizophrenia between the two paradigms. Has anyone here considered
breaking down the rigidity of the mapfile architecture by writing them
in XML or JSON formats so they can be more easily manipulated by an
application?

- Bill Thoen

___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] A Question of Group

[Bob Basques]

Bill, 

Your questions are a bit open ended, but here goes . . . 



Pros: 
Much easier to list these out, but at the risk of boring you, since I've seem 
GeoMoose used now in ways and areas I never thought of originally, at least not 
in detail.  The biggest Pro that I believe is there, is the potential for the 
distribution of data maintenance tasks afforded by how GeoMoose pulls it's 
services together.  GeoData, as raster, vector and add on services are all 
planned for in the GeoMoose framework as pieces of the equation that the 
implementors will want to do. 

If you plan at some point to distribute the upkeep of data across many admins, 
then GeoMoose if for you.  Any single layer breaking does not affect the rest 
of the interface, and the user has the option of just leaving it turned off. 

Other than the mapping data feeds, there are no server requirements for 
GeoMoose, it can read WMS services alone if needed for example. 

Mapping display built on OpenLayers. 

Very portable. 

Cons: 
If you plan on having a single system administrator, then GeoMoose may be 
overkill.  Although others would argue that the demo's are set up fairly nicely 
with regard to plug and play, so even the overhead is not as overbearing. 

It would be much easier to react to your past misgivings about a application 
coming up short, than to feed the pile from scratch.  Makes me think way too 
far outside of the box if you know what I mean. 

Doesn't do WFS (cleanly) [YET], although, while the geomoose project expends 
most of their effort buildig against MapServer, GeoMoose is not tied to it, and 
could talk to just about any geodata feed. 

As far as what it's not, It's not a Desktop analysis tool.  Although it's got a 
lot of analysis capabilities, with the latest version having a bunch of new 
functions added on. 

Doesn't depend on a web service in particular, why is this in the Cons, because 
it doesn't have a distinct server component.  It's very standalone-ish 
actually. 

Doesn't have your described GUI management tools (yet), although, there are 
ideas about how to pursue this, just no project yet to subsidize the work.  And 
the basic framework is very conducive to adding this.   

bobb 


>>> Bill Thoen  wrote:

Bob Basques wrote:
>
> Bill,
>
>
> This is a shameless plug for GeoMoose functionality, it was prompted
> by your comments below however, so I don't feel too bad  :c)
>
>
Grab every opportunity that sets you up for a pitch! Although I'm
actually not unhappy with HTML Legends --I've found workarounds for
things I don't like-- but it would have been nice to have known in
advance where it runs out of steam or just doesn't go, so I'd know
whether I would reach the point of implementing kludges before or after
I reached my goal.

GeoMoose sounds pretty good and seems to solve my problems 1-2-3... But
before I go try it out now instead of later and spend a lot of time I
can't spare contemplating a software switch and testing its capabilities
for possible use in a project with a tight  deadline,  can you highlight
for me the top two or three areas where the hard, cold ground rises up
to meet it (i.e. where it falls on its face)? I'm not looking for what's
broken, but more along the lines of what it is NOT designed for, so I
don't make th e mistake of trying to use in a situation where it will
not do well.

> *  Each layer (or group of layers) is controlled via it's own mapfile,
> while this might seem cumbersome to manage, it does allow for separate
> and integrated management of data layers by many data custodians,
> which is what GeoMoose was originally designed for, many data
> custodians doing their own thing.  It's also very good for automation
> purposes in general.
>
>
One of the both strong points and weak points in the FOSS mapping
software I've seen so far is its almost universal core dependence on
mapfiles or templates as the driving mechanism. These are powerful in
that the are easily modified, human and machine readable and you can
record layer "states" and mix and match the "objects" later on as you
like to create alternate configurations. But where they're a weak point
is when you want to provide a warm 'n fuzzy front end for User B. Goode.
Templates are difficult to work with at that point. They're based on the
1950s-60s notion of batch programming in which the programmer decides
where the process starts and ends. So when you try to build an
interactive, user-driven interface on top of this, the bugs and
shortcomings you tend to run into are usually rooted in a sort of
schizophrenia between the two paradigms. Has anyone here considered
breaking down the rigidity of the mapfile architecture by writing them
in XML or JSON formats so they can be more easily manipulated by an
application?

- Bill Thoen

___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

___

Re: [mapserver-users] A Question of Group

[Bill Thoen]

Bob Basques wrote:


Bill,


This is a shameless plug for GeoMoose functionality, it was prompted 
by your comments below however, so I don't feel too bad  :c)



Grab every opportunity that sets you up for a pitch! Although I'm 
actually not unhappy with HTML Legends --I've found workarounds for 
things I don't like-- but it would have been nice to have known in 
advance where it runs out of steam or just doesn't go, so I'd know 
whether I would reach the point of implementing kludges before or after 
I reached my goal.


GeoMoose sounds pretty good and seems to solve my problems 1-2-3... But 
before I go try it out now instead of later and spend a lot of time I 
can't spare contemplating a software switch and testing its capabilities 
for possible use in a project with a tight  deadline,  can you highlight 
for me the top two or three areas where the hard, cold ground rises up 
to meet it (i.e. where it falls on its face)? I'm not looking for what's 
broken, but more along the lines of what it is NOT designed for, so I 
don't make th e mistake of trying to use in a situation where it will 
not do well.


*  Each layer (or group of layers) is controlled via it's own mapfile, 
while this might seem cumbersome to manage, it does allow for separate 
and integrated management of data layers by many data custodians, 
which is what GeoMoose was originally designed for, many data 
custodians doing their own thing.  It's also very good for automation 
purposes in general.



One of the both strong points and weak points in the FOSS mapping 
software I've seen so far is its almost universal core dependence on 
mapfiles or templates as the driving mechanism. These are powerful in 
that the are easily modified, human and machine readable and you can 
record layer "states" and mix and match the "objects" later on as you 
like to create alternate configurations. But where they're a weak point 
is when you want to provide a warm 'n fuzzy front end for User B. Goode. 
Templates are difficult to work with at that point. They're based on the 
1950s-60s notion of batch programming in which the programmer decides 
where the process starts and ends. So when you try to build an 
interactive, user-driven interface on top of this, the bugs and 
shortcomings you tend to run into are usually rooted in a sort of 
schizophrenia between the two paradigms. Has anyone here considered 
breaking down the rigidity of the mapfile architecture by writing them 
in XML or JSON formats so they can be more easily manipulated by an 
application?


- Bill Thoen

___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] A Question of Group

[Bob Basques]

Bill, 

This is a shameless plug for GeoMoose functionality, it was prompted by your 
comments below however, so I don't feel too bad  :c) 

*  GeoMoose can handle almost an unlimited number of layers (Browser memory 
being the limit for the most part), we have just over 170 layers in our 
internal installation (and growing) 
*  It has had a expand/collapse feature since day one. 
*  It has had grouping available via MapFiles from day one, and the last couple 
of versions have had grouping with control in the client, while still 
maintaining individual layer control at the user end.  You can group layers in 
a single mapfile for a single image return, and still be able to control the 
separate layer on/off visibility in the client. 
*  Most (if not all) of the layer specific controls are icon based. (you can 
also add layer specific user extensions as well, that's another post though) 
*  Each layer (or group of layers) is controlled via it's own mapfile, while 
this might seem cumbersome to manage, it does allow for separate and integrated 
management of data layers by many data custodians, which is what GeoMoose was 
originally designed for, many data custodians doing their own thing.  It's also 
very good for automation purposes in general. 

Check it out, the new GeoMoose site ( www.geomoose.org) ( 
http://www.geomoose.org) ) has some live demos of the interface running, which 
demonstrate many of it's capabilities in online working versions. 

bobb 



>>> Bill Thoen  wrote:



In my case I was happily building a pretty good tool in Open Layers, and
the first thing a new client wanted was support for up to 100 layers,
which is not do-able in OL because the layer switcher doesn't have a
scrollbar and it maxes out when the list of layer reaches the bottom of
the map window. It also has no grouping ability to treat a group of
layers as a single layer, nor does it provide a expand/collapse feature,
or show layer icons. Other than the grouping issue (which I think is not
going to be as useful as the client thinks, even if I get it to work the
way they want) HTML Legends cover a lot of ground with not a lot of code
needed. Still, I think I should look at this GeoMoose some time. It
sounds pretty good.










___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] A Question of Group

[Bill Thoen]

Bob Basques wrote:


As a matter of discussion, I went into using HTML legends early on, 
and ran into similar problems as these, and after a few months I ended 
up abandoning the use of them.  Also, I now use GeoMoose as my 
preferred client side interface, which deals with each layer 
separately, which is very conducive to building out layer specific 
legends.  The PROs of using HTML legends were canceled out 
essentially, by the organizational structure of how GeoMoose requests 
it's resources.


I went to Plan B, which was to manually truncate the data structures to 
just a gid and then tile the layers with ogrtindex. I think the main 
problem with HTML Legend is that there's just not enough interest in it. 
By the time a MapServer developer discovers things like this that are on 
the edge of MapServer's development horizon, they're already moving into 
tools like Open Layers, GeoMoose and things like that with more user 
interface support. When I first asked about HTML Legends here last week 
it took three tries and an edgy subject line to get a response.


In my case I was happily building a pretty good tool in Open Layers, and 
the first thing a new client wanted was support for up to 100 layers, 
which is not do-able in OL because the layer switcher doesn't have a 
scrollbar and it maxes out when the list of layer reaches the bottom of 
the map window. It also has no grouping ability to treat a group of 
layers as a single layer, nor does it provide a expand/collapse feature, 
or show layer icons. Other than the grouping issue (which I think is not 
going to be as useful as the client thinks, even if I get it to work the 
way they want) HTML Legends cover a lot of ground with not a lot of code 
needed. Still, I think I should look at this GeoMoose some time. It 
sounds pretty good.










___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] A Question of Group

[Bob Basques]

  
  

  Bill,
  

  Well, first off, I have no idea how the Legend entry for grp_BLM_WSAa_2009 is being created with nothing whatsoever in the Mapfile (other than comments) having that as a value.  Could you be experiencing a Caching problem somewhere?  Another possibility, is that the HTML legend parser is not recognizing the Comments in the Mapfile, you could test this easily enough by removing the lines entirely.
  

  I think a (more) failsafe way of approaching this is to build a complete set of dummy layer definitions for the Legends.  One thing that seems to be a problem, is the separation of WMS and normal legend HTML/Chip generation, maybe you need two separate mapfiles, one for the HTML legends and one for the mapping, seems cumbersome to go this route though.
  

  As a matter of discussion, I went into using HTML legends early on, and ran into similar problems as these, and after a few months I ended up abandoning the use of them.  Also, I now use GeoMoose as my preferred client side interface, which deals with each layer separately, which is very conducive to building out layer specific legends.  The PROs of using HTML legends were canceled out essentially, by the organizational structure of how GeoMoose requests it's resources.
  

  bobb
  

  
  
  >>> Bill Thoen  wrote:

  
thomas bonfort wrote:  
  

as the code is right now, classes don't show up in the legend if they
  
have no NAME *nor* TITLE

  



  Seeing Bob's comment, I should add that I'm using HTML legends and I'm trying to combine *layers* as opposed to classes. Combining CLASSes from a LAYER is comparatively easy  (just select everything.)Taking out the LAYER name doesn't seem to work, and if I remove the wms_title and the entire CLASS definition I still get  a row in the legend for that layer, no icon, and '[metadata name="wms_title"]' in place of the layer title (see red arrow pointing to what I get instead.Here's the piece of my mapfile showing what I commented out and what I have in there (The extra baggage is there to support retreiving feature attribute data):   LAYER  GROUP "BLM Lands"# NAME "grp_BLM_ACECs_2009"  METADATA "legend_order" "2"#'wms_title' "grp_BLM_ACECs_2009"#'wms_group_title' "all_blm_land1" 'wms_srs' "epsg:2163" 'gml_include_items' "All"  END  TYPE POLYGON  STATUS ON  TEMPLATE "foo"  DUMP TRUE  DATA "Agencies/DOI/BLM/BLM_ACEC/BLM_ACECs_2009_2163"# CLASS#NAME "Areas of Critical Env. Concern"#STYLE#   COLOR 255 247 181#   COLOR 255 000 000#END# END  PROJECTION "init=epsg:2163"  END   ENDI thought of trying different settings in the opt_flag bit field, but there doesn't appear to be a setting for "just do what I want." So I'm still looking for ideas, but Plan B is to script a conversion of all these various tables into a common structure and then use ogrtindex to paste them together. If anyone has an idea that would work and take less time I'd sure like to hear from you!


On Tue, Mar 2, 2010 at 14:02, Bob Basques  wrote:

  



James,


the Legend entries are keyed off of the NAME paramater in the mapfile, if

you don't want a entry in the Legend, comment out the NAME parameter that is

displaying the stuff you don't want.


bobb


On 3/2/2010 6:42 AM, Bill Thoen wrote:





James Card wrote:

  



On Mon, 01 Mar 2010 20:48:59 -0800, Bill Thoen  wrote:






I've got about about 30 layers that I'd like to display as a single

layer, all in the same style, with only one entry in the legend for the

group. I've tried using the 'GROUP' command in the mapfile, and while that

does put them all under the same heading, each layer still shows as a

separate entry in the legend.

  



Perhaps a tileindex would work? See "ogrtindex" at

.






Thanks! That was so close, but that doesn't work unless the data sets have

the same structure. Can you think of anything else short of manually merging

these one by one?


  



___

mapserver-users mailing list

mapserver-users@lists.osgeo.org

http://lists.osgeo.org/mailman/listinfo/mapserver-users







___

mapserver-users mailing list

mapserver-users@lists.osgeo.org

http://lists.osgeo.org/mailman/listinfo/mapserver-users


  








___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] A Question of Group

[Bill Thoen]

thomas bonfort wrote:

  as the code is right now, classes don't show up in the legend if they
have no NAME *nor* TITLE
  

Seeing Bob's comment, I should add that I'm using HTML legends and I'm
trying to combine *layers* as opposed to classes. Combining CLASSes
from a LAYER is comparatively easy  (just select everything.) 

Taking out the LAYER name doesn't seem to work, and if I remove the
wms_title and the entire CLASS definition I still get  a row in the
legend for that layer, no icon, and '[metadata name="wms_title"]' in
place of the layer title (see red arrow pointing to what I get instead.


Here's the piece of my mapfile showing what I commented out and what I
have in there (The extra baggage is there to support retreiving feature
attribute data):
   LAYER
  GROUP "BLM Lands"
# NAME "grp_BLM_ACECs_2009"
  METADATA
 "legend_order" "2"
#    'wms_title' "grp_BLM_ACECs_2009"
#    'wms_group_title' "all_blm_land1"
 'wms_srs' "epsg:2163"
 'gml_include_items' "All"
  END
  TYPE POLYGON
  STATUS ON
  TEMPLATE "foo"
  DUMP TRUE
  DATA "Agencies/DOI/BLM/BLM_ACEC/BLM_ACECs_2009_2163"
# CLASS
#    NAME "Areas of Critical Env. Concern"
#    STYLE
#   COLOR 255 247 181
#   COLOR 255 000 000
#    END
# END
  PROJECTION
 "init=epsg:2163"
  END
   END
I thought of trying different settings in the opt_flag bit field,
but there doesn't appear to be a setting for "just do what I want." So
I'm still looking for ideas, but Plan B is to script a conversion of
all these various tables into a common structure and then use ogrtindex
to paste them together. If anyone has an idea that would work and take
less time I'd sure like to hear from you!


  On Tue, Mar 2, 2010 at 14:02, Bob Basques  wrote:
  
  
James,

the Legend entries are keyed off of the NAME paramater in the mapfile, if
you don't want a entry in the Legend, comment out the NAME parameter that is
displaying the stuff you don't want.

bobb



On 3/2/2010 6:42 AM, Bill Thoen wrote:


  James Card wrote:
  
  
On Mon, 01 Mar 2010 20:48:59 -0800, Bill Thoen  wrote:



  I've got about about 30 layers that I'd like to display as a single
layer, all in the same style, with only one entry in the legend for the
group. I've tried using the 'GROUP' command in the mapfile, and while that
does put them all under the same heading, each layer still shows as a
separate entry in the legend.
  

Perhaps a tileindex would work? See "ogrtindex" at
.


  
  Thanks! That was so close, but that doesn't work unless the data sets have
the same structure. Can you think of anything else short of manually merging
these one by one?

  

___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users


  
  ___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

  




___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] A Question of Group

[thomas bonfort]

as the code is right now, classes don't show up in the legend if they
have no NAME *nor* TITLE

On Tue, Mar 2, 2010 at 14:02, Bob Basques  wrote:
> James,
>
> the Legend entries are keyed off of the NAME paramater in the mapfile, if
> you don't want a entry in the Legend, comment out the NAME parameter that is
> displaying the stuff you don't want.
>
> bobb
>
>
>
> On 3/2/2010 6:42 AM, Bill Thoen wrote:
>>
>> James Card wrote:
>>>
>>> On Mon, 01 Mar 2010 20:48:59 -0800, Bill Thoen  wrote:
>>>
 I've got about about 30 layers that I'd like to display as a single
 layer, all in the same style, with only one entry in the legend for the
 group. I've tried using the 'GROUP' command in the mapfile, and while that
 does put them all under the same heading, each layer still shows as a
 separate entry in the legend.
>>>
>>> Perhaps a tileindex would work? See "ogrtindex" at
>>> .
>>>
>> Thanks! That was so close, but that doesn't work unless the data sets have
>> the same structure. Can you think of anything else short of manually merging
>> these one by one?
>>
>
> ___
> mapserver-users mailing list
> mapserver-users@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-users
>
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] A Question of Group

[Bob Basques]

James,

Oops, I didn't see right off that you were using HTML legends, You can 
do the same as I described eariler, but you could also try something 
with DUMMY layers too, where you set up a layer purely for legend 
display (no real DATA definition)


bobb



On 3/2/2010 6:42 AM, Bill Thoen wrote:

James Card wrote:
On Mon, 01 Mar 2010 20:48:59 -0800, Bill Thoen  
wrote:


I've got about about 30 layers that I'd like to display as a single 
layer, all in the same style, with only one entry in the legend for 
the group. I've tried using the 'GROUP' command in the mapfile, and 
while that does put them all under the same heading, each layer 
still shows as a separate entry in the legend.


Perhaps a tileindex would work? See "ogrtindex" at 
.


Thanks! That was so close, but that doesn't work unless the data sets 
have the same structure. Can you think of anything else short of 
manually merging these one by one?




___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] A Question of Group

[Bob Basques]

James,

the Legend entries are keyed off of the NAME paramater in the mapfile, 
if you don't want a entry in the Legend, comment out the NAME parameter 
that is displaying the stuff you don't want.


bobb



On 3/2/2010 6:42 AM, Bill Thoen wrote:

James Card wrote:
On Mon, 01 Mar 2010 20:48:59 -0800, Bill Thoen  
wrote:


I've got about about 30 layers that I'd like to display as a single 
layer, all in the same style, with only one entry in the legend for 
the group. I've tried using the 'GROUP' command in the mapfile, and 
while that does put them all under the same heading, each layer 
still shows as a separate entry in the legend.


Perhaps a tileindex would work? See "ogrtindex" at 
.


Thanks! That was so close, but that doesn't work unless the data sets 
have the same structure. Can you think of anything else short of 
manually merging these one by one?




___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] A Question of Group

[Bill Thoen]

James Card wrote:

On Mon, 01 Mar 2010 20:48:59 -0800, Bill Thoen  wrote:

I've got about about 30 layers that I'd like to display as a single 
layer, all in the same style, with only one entry in the legend for 
the group. I've tried using the 'GROUP' command in the mapfile, and 
while that does put them all under the same heading, each layer still 
shows as a separate entry in the legend.


Perhaps a tileindex would work? See "ogrtindex" at 
.


Thanks! That was so close, but that doesn't work unless the data sets 
have the same structure. Can you think of anything else short of 
manually merging these one by one?


--
- Bill Thoen 
 GISnet - www.gisnet.com

 303-786-9961

___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] A Question of Group

[James Card]

On Mon, 01 Mar 2010 20:48:59 -0800, Bill Thoen  wrote:

I've got about about 30 layers that I'd like to display as a single  
layer, all in the same style, with only one entry in the legend for the  
group. I've tried using the 'GROUP' command in the mapfile, and while  
that does put them all under the same heading, each layer still shows as  
a separate entry in the legend.


Perhaps a tileindex would work? See "ogrtindex" at  
.


--
James Card
California CAD Solutions, Inc.
209-578-5580 - Voice
209-521-6493 - FAX
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users