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

[Brent Fraser]

Bob,

   I think those are good ideas, and I see a great future in XML map files (when 
combined with a GUI tool), and in the QGIS mapserver plugin.

   I think good demos are mandatory too, but they're not the only answer.  After 
getting the demo to work, the next step is usually to integrate your own data. 
And going from memory, the top reasons users don't see their data are:

   1. STATUS DEFAULT
   2. MAP and LAYER projection not the same
   3. MAP EXTENTS (or UNITS!) not appropriate for your data
   4. DATA path problems

   Personally, I think the first three are solvable with programming.

Best Regards,
Brent

Bob Basques wrote:
> 
> 
> Brent,
> 
> 
> I think those type of things are best left to packaging of demos.
> 
> 
> 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.
> 
> Now, to address the newbie perspective, I would suggest going in a bit 
> different direction, probably needs a bit of discussion though.
> 
> 
> 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.
> 
> 
> A USB  based distribution may be a fit here as well.
> 
> 
> Just rambling, my own fault for reading the lists, I guess.
> 
> 
> bobb
> 
>> >> Brent Fraser <bfraser at geoanalytic.com> wrote:
> 
> 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
>>
>>
>>
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>