[mapserver-dev] Re: [mapserver-users] Using e00 files
Bob Basques
Bob.Basques at ci.stpaul.mn.us
Wed Feb 3 10:34:12 EST 2010
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20100203/53fa088e/attachment-0001.html
More information about the mapserver-dev
mailing list