Version 3.3 wish list...

[Stephen Lime]

I'm pondering a url based spec using an object syntax common to a number of
OOP languages, JavaScript comes to mind as a good example. Each element
in the mapfile could be refered to using simple object.member notation. So,
changing a layer classes label size would be something like:

  map.covertype.forest.label.size=5

where covertype is a unique layername and forest is a class name. Anything, from
scalebar parameters to projection arguments (a bit harder, you'd need array notation)
could be controlled this way. I just need to figure out how to use to lexers in the
same package. This would have limited use with get requests, but I suspect a few
changes would all that would happen at anyone time. The whole mapfile could be
handled using a post. I've already added the concept of layer groups to the code
so unique layer names won't take away any of the neat things you can do now. I
really like this idea.

Again, Rob fill me in on the OpenGIS stuff when you can. I hope the MapServer
group will be participating in the OGIS web technology testbed at somepoint.

The XML idea has merit. The more standards based the better. Actually the format
is REAL close, it's all tag based now. just replace LAYER with <LAYER> and the 
corresponding END with </LAYER> and so on.

Steve

Stephen Lime
Internet Applications Analyst
MIS Bureau - MN DNR

(651) 297-2937
steve.lime at dnr.state.mn.us

>>> Rob Atkinson <rob at socialchange.net> 06/29 12:10 PM >>>

To do this you will need a more extensible syntax for object specification in
the URL.
You may find this useful:

http://icmiss.socialchange.net.au/support/csgi/csgihttp.doc 

The actual content is still a bit lightweight for your needs - it is more a
minimal set for interoperability, but the mechanism is extensible.

We are currently working on such issues with the OpenGIS consortium, but I'm not
at liberty to divulge details.

Also I guess it would be nice to see the map file expressed in  XML to get
instant access to parsers and validators.

Regards
Rob Atkinson


Banister Trevor wrote:

> I like this idea of more control from forms. I'm having a tough time getting
> granular control without building lots of .map files.
>
> How about an intermediate step which allows all the parameters from a .map
> file to be called from a form, or from the query string? This technique
> would help in using mapserver as a backend workhorse to serve images to
> multiple front end servers.
>
> This would also allow other front end systems (running PHP, Cold Fusion,
> ASP, etc.) access to generate layer parameters without having to write a
> temporary .map file on the mapserver, on the fly (a kludgey technique I'm
> using to change the order and projection in which layers are presented)
>
> I'm toying with the idea of letting users upload their own layers (shapes or
> images) to add value to the maps the generate. Being able to generate a map
> without a .map file would make this much easier too.
>
> Since this is my first posting, let me take a minute to say thanks for
> creating mapserv, and making it open source. I hope to be able to contribute
> some code once I get up to speed on its internals.
>
> Does anyone else have an interest in serving up MrSID images (with sid world
> files)?
> For those that don't already know, MrSID is a wavelet compression system
> developed by Lizard tech (www.lizardtech.com) which is lossy like JPEG, but
> produces much better compression (20:1) with hardly any loss.
>
> Trevor Banister
> Sr. Application Designer (and builder, deployer, maintainer, .....)
> Space Imaging
> TBanister at SpaceImaging.com 
>
> To satisfy the legal department:
> The preceding statements and opinions are my own and not those of my
> employer, Space Imaging.
>
> -----Original Message-----
> From: kenboss at dilbert.dnr.state.mn.us 
> [mailto:kenboss at dilbert.dnr.state.mn.us] 
> Sent: Monday, June 28, 1999 10:08 AM
> To: steve.lime at dnr.state.mn.us; mapserver-users at lists.gis.umn.edu 
> Subject: Re: Version 3.3 wish list...
>
> Steve--
>
> How about mapfile-based definition of classes for thematic rasters,
> following
> the model of the shapefile stuff.  It'd be really cool to be able to do
> hierarchical class collapsing this way, rather than having to maintain
> separate
> rasters for that purpose.  With the advent of MapScript, we'd then have the
> capability to let users define through html forms how they want to see the
> classes displayed.  As a side benefit, we'd also get dynamic legend creation
> for
> raster images out of the deal.  Of course we'd also want to retain the
> current
> mechanisms as a default mode, so that if no classes are defined in the
> mapfile
> for a raster, then it is displayed in accordance with the associated color
> table.  I realize that this may be a rather large pain to develop, given the
>
> varying requirements for the different raster formats supported, but as long
> as
> we're talking wish lists, I thought I'd throw that in...
>
> --Ken

--
--------------------------------------------------------------------------------

Rob Atkinson                                                rob at socialchange.net 

Director                                                        Mob 0419 202 973

Social Change Online Pty Ltd                                Ph  +61 (2)9557 6500

http://online.socialchange.net                              Fax +61 (2)9519 8940