<html>
<head>
<style type="text/css">
<!--
body { margin-top: 4px; margin-right: 4px; margin-left: 4px; font-variant: normal; margin-bottom: 1px; line-height: normal }
p { margin-top: 0; margin-bottom: 0 }
-->
</style>
</head>
<body style="margin-top: 4px; margin-right: 4px; margin-left: 4px; margin-bottom: 1px">
<p style="margin-bottom: 0; margin-top: 0">
<font face="Comic Sans MS" size="3">Brent,</font> </p>
<br>
<p style="margin-bottom: 0; margin-top: 0">
<font face="Comic Sans MS" size="3">I think those type of things are best left to packaging of demos.</font> </p>
<br>
<p style="margin-bottom: 0; margin-top: 0">
<font face="Comic Sans MS" size="3">While the minimum settings required for a SHP file may be lower than some other format, the reality is, that to accommodate all those other file types, there are settings that will need to be required, whether or not they are needed.</font> </p>
<p style="margin-bottom: 0; margin-top: 0">
<font face="Comic Sans MS" size="3">Now, to address the newbie perspective, I would suggest going in a bit different direction, probably needs a bit of discussion though.</font> </p>
<br>
<p style="margin-bottom: 0; margin-top: 0">
<font face="Comic Sans MS" size="3">What about a MapServer "Lite" (less filling . . . blah, blah) and focused primarily on the newbie and pre-packaging in mind. They use the LITE version to learn on. May possibly be a way to jump start the new XML format as well (which is supposed to be automateable and less likely to need user (human) wangling, especially if a configuration GUI were added to the mix, could start with something like QGIS for example. In general, the idea would be to put a LITE suite of things together so all the pieces are configured and work, but with minimal configuration requirements.</font> </p>
<br>
<p style="margin-bottom: 0; margin-top: 0">
<font face="Comic Sans MS" size="3">A USB based distribution may be a fit here as well.</font> </p>
<br>
<p style="margin-bottom: 0; margin-top: 0">
<font face="Comic Sans MS" size="3">Just rambling, my own fault for reading the lists, I guess.</font> </p>
<br>
<p style="margin-bottom: 0; margin-top: 0">
<font face="Comic Sans MS" size="3">bobb</font><br><br>>>> Brent Fraser <bfraser@geoanalytic.com> wrote:<br> </p>
<div style="background-color: #f3f3f3; border-left: solid 1px #050505; margin-top: 0; padding-left: 7px; margin-left: 15px; margin-right: 0; margin-bottom: 0">
<p style="margin-bottom: 0; margin-top: 0">
Perhaps we could have something like<br><br>LAYER<br>   PROJECTION<br>     MAP<br>   END<br>END<br><br>when a re-projection is specifically not wanted (e.g. NAD83->WGS84).  But in<br>general, I agree with the opt-in/backwards-compatible approach.<br><br>   On the other hand, to make things simple for the new user, is it necessary to<br>have MAP entries of EXTENTS/UNITS/PROJECTION at all?  Could mapserver just use<br>the first layer's extents?<br><br><br>   Hmmm, the mind boggles...  A question for the experts: What is the smallest<br>map file to get a rendered image (given a shapefile)?  Why are those entries<br>required?  Could mapserver generate/calculate/assume reasonable defaults?  Would<br>it be possible to have just:<br><br>MAP<br>   LAYER<br>     DATA '/tmp/myshapes.shp'<br>   END<br>END<br><br><br>   Now to push the limits (and keep in mind this is all for new users to get<br>something working quickly).  Why require anything?  Why not compile in an<br>ultra-low res set of continental polygons and have mapserv (if no CGI parameters<br>are given) spit out some html (so you can pan/zoom) and an image of the world?<br><br>   Or perhaps getting started with mapserver isn't that hard.  I'm amazed at how<br>many people new to mapping, gis data formats, projections, or web serving will<br>jump right in to editing map files.<br><br>Brent<br><br><br>Howard Butler wrote:<br>> On Feb 2, 2010, at 1:20 PM, Paul Ramsey wrote:<br>><br>>> On Tue, Feb 2, 2010 at 11:03 AM, Brent Fraser <bfraser@geoanalytic.com> wrote:<br>>>> Hmm.  I see the problem.  The current Mapserver behavior is "if the LAYER<br>>>> proj is not specified, assume it to be the same as the MAP proj and don't<br>>>> re-project the coordinates".<br>>> I don't see that a behavior of<br>>> - if PROJECTION defined use that<br>>> - if ! PROJECTION but source SRS is available use that<br>>> - if no information assume same as MAP<br>>> would necessarily break any map files<br>>> (except those where the data is actually living in a state with<br>>> invalid source SRS information, in which case blaming mapserver for<br>>> breaking backwards compat is a bit harsh)<br>><br>> The problem with case #2 is we use the source SRS and it's negligibly different, we trigger unnecessary reprojection.  The only test we have is to compare proj.4 strings, which in many cases can have functionally equivalent but not identical proj.4 representations.<br>><br>> opt-in, or opt-out.  We have to choose.  My RFC was opt-in and bends over backwards to do so.<br>><br>> Howard<br>><br>><br>><br>_______________________________________________<br>mapserver-dev mailing list<br>mapserver-dev@lists.osgeo.org<br><a href="http://lists.osgeo.org/mailman/listinfo/mapserver">http://lists.osgeo.org/mailman/listinfo/mapserver</a>-dev<br>
</p>
</div>
</body>
</html>