Ok, this might seem like a far out request, but . . .

[Stephen Woodbridge]

Hey Bob, this is a good idea. I had simpler ideas along this line. If
you take the ArcExplorer model, the first thing you do is load the layer
and zoom to its extents. It would be easy to create an application that
you pointed at a shapefile and it reads the attribute columns and asks
you what which id any you want to use as a label, what color you want
the object displayed in maybe 1-2 more options, it could also give you
some additional information, like extents, object type, number of
objects, a preview map, with the objects in black, or gray and black
outline so you can preview it. After you make your selection it would
generate a mapfile for that one shapefile.

It gets a lot harder to create a multiple layer mapfile and for that you
should move to something like DM Solutions MapLab.

Also, if all you data is tagged as being in one of a group of areas,
then you could have a standard base map layer like the US States as
under the data layer you are making to give is more context.

Just some more ideas for the brew :)
-Steve W.

Bob Basques wrote:

> . . . .here goes. (get cup/glass of your favorite beverage)
>
> Has anyone experimented with trying to build a basic mapfile simply by
> reading a SHP datasource.
>
> ----------------
>
> My situation:
>
> I have just about everything automated for a data custodian to publish
> their respective dataset (SHP) through a MAPSERVER install except for
> the MAPFILE creation.   The thought was to start with a template of some
> sort (similar to a HTML template) and using some REGEX operation to
> substitute the source data  piece to come up with a way to initiate a
> cursory Mapfile.
>
> The end product to be a basic discorvy mechamism for the MapServer to
> use in generating it's own data them configuration files.
>
> Is this out there to far left to think about?
>
> These initial config files would be used by whomever the data custodian
> is or the MapServer admin to start up a publishing process.   We have a
> couple of different Client built that can be handed the discory
> information of a new data theme fairly easily.  The MapServer piece
> seems like it might be a bit tricky.
>
> Eventually, we want to move to a WMS distribution process so that this
> type of operation make much more sense, but for now it would be intended
> as a way to jumpstart a data theme publishing action.
>
> some items that might mitigate something like this would be :
>
>    * The type of theme, POINT, LINE, POLYGON, TEXT, RASTER,etc.  Maybe
>      the solution to this is a different template.
>    * The source data folder, how to tell MapServer that there is
>      something someplace.  We use a Flatfile control that does this
>      now.  A HTML interface added on to it would help out I think,
>      where a validated theme owner could add in their data theme, even
>      uploading of the file could be enabled.  This is for an INTRANET
>      at first.
>    * How to describe in a discovery process that there is new data to
>      distribute.  A getcapabilities request for example.  I suppose a
>      Master Mapfile would be needed for this.  We use seperate MapFiles
>      for each theme at the moment.  The MapFiles are right alongside of
>      the data themes themseleves along with any dependant config file,
>      TEMPLATES, SYMBOLS,etc.
>
> I'm sure I'll come up with more stuff as I think about the task some more.
>
> In the end I would like to move as much of the config process as
> possible back to the data owners/custodians, and just run the system as
> an administrative function.  I can see down the road the notion of
> building a simple online MAPFILE editor.
>
> Thanks
>
> bobb
>