[mapserver-dev] Re: [mapserver-users] Using e00 files

[Brent Fraser]

Perhaps we could have something like

LAYER
   PROJECTION
     MAP
   END
END

when a re-projection is specifically not wanted (e.g. NAD83->WGS84).  But in 
general, I agree with the opt-in/backwards-compatible approach.

   On the other hand, to make things simple for the new user, is it necessary to 
have MAP entries of EXTENTS/UNITS/PROJECTION at all?  Could mapserver just use 
the first layer's extents?


   Hmmm, the mind boggles...  A question for the experts: What is the smallest 
map file to get a rendered image (given a shapefile)?  Why are those entries 
required?  Could mapserver generate/calculate/assume reasonable defaults?  Would 
it be possible to have just:

MAP
   LAYER
     DATA '/tmp/myshapes.shp'
   END
END


   Now to push the limits (and keep in mind this is all for new users to get 
something working quickly).  Why require anything?  Why not compile in an 
ultra-low res set of continental polygons and have mapserv (if no CGI parameters 
are given) spit out some html (so you can pan/zoom) and an image of the world?

   Or perhaps getting started with mapserver isn't that hard.  I'm amazed at how 
many people new to mapping, gis data formats, projections, or web serving will 
jump right in to editing map files.

Brent


Howard Butler wrote:
> On Feb 2, 2010, at 1:20 PM, Paul Ramsey wrote:
> 
>> On Tue, Feb 2, 2010 at 11:03 AM, Brent Fraser <bfraser at geoanalytic.com> wrote:
>>> Hmm.  I see the problem.  The current Mapserver behavior is "if the LAYER
>>> proj is not specified, assume it to be the same as the MAP proj and don't
>>> re-project the coordinates".
>> I don't see that a behavior of
>> - if PROJECTION defined use that
>> - if ! PROJECTION but source SRS is available use that
>> - if no information assume same as MAP
>> would necessarily break any map files
>> (except those where the data is actually living in a state with
>> invalid source SRS information, in which case blaming mapserver for
>> breaking backwards compat is a bit harsh)
> 
> 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.
> 
> opt-in, or opt-out.  We have to choose.  My RFC was opt-in and bends over backwards to do so.
> 
> Howard
> 
> 
>