[Web Comm] Q&A to choose a software stack

[Jason Birch]

Frank,
 
I think I had a different sense of "entire stack".  I was thinking of Jody's "Postgres/PostGIS/Mapserver/GeoServer/uDig" example; database, mid-tier and end user all in one.  My sense is that this kind of bare-earth deployment is pretty rare.  Although I have a real desire to use PostGIS, this would be a separate project from publishing a web map, or deploying uDig to my users.  I'd probably want to know up front that the potential was there, but a short blurb in the project profile would be enough.  Also, though I really respect and value enabling tools like GDAL/OGR, PROJ, GEOS/JTS, etc, I don't want to have to think about these (or even see them) as part of my package selection.
 
If we provide project profiles, sucess stories (case studies), live demos, and installers, then that should be enough :)  Presenting the info in a consistent template and providing case studies will really help users.  The more up-front work we can do to help folks find their right tool, the better.  We just have to ensure that the content is organised in such a way that users can quickly and easily find what they are looking for.
 
We also have to make sure the content is current and accurate.  Hmm.  Perhaps we could set up some kind of page review database on the wiki to ensure that each page gets visited and checked be one of us or a designated individual... quarterly?
 
Jason

 
________________________________

From: Frank Warmerdam on behalf of Frank Warmerdam
Sent: Sun 2006-04-02 10:13 PM
To: dev at webcommittee.osgeo.org
Subject: Re: [Web Comm] Q&A to choose a software stack



Jason Birch wrote:
>
> I guess for web mapping, what stack you use would depend a lot on what your
> existing preferred development/deployment environment is.  Also, people
> aren't usually looking for an entire stack, just what they need to get the
> job done.

Jason,

I'm not sure I agree with this.  If you have a task, ie. "publish
maps on the web from my counties airphotos in GeoTIFF and roads
infrastructure in a shapefile" there is still a need for a stack
of software.  Perhaps GDAL + PROJ + MapServer + Mapbender for instance.

It is a rather trivial need that can be completely met by just one
piece of software.  On the other hand, you have a point a that a
"bells and whistles" software package may be overkill for some
purposes.

> I certainly see some problems coming trying to distinguish between the
> various web mapping components, and show how they work together.  Also,
> differentiating between the use cases for some of the smaller agile
> packages, and the larger ones like MapGuide.  We have a real wealth of
> packages to choose from, but in some ways this is a hinderance.

I agree.  At some point, to help users coming in we are going to have
to explain the roles of the different packages, and their strengths
and weaknesses.  This is going to be difficult technically and politically.
Technically there is a great deal of overlap in web mapping for instance
(between GeoServer, MapServer and MapGuide) and it is not too clear yet
from a technical point of view which is best for what cases.  But it is
also politically very dangerous for us to "judge" the packages in a
public facing way.  This could easily infuriate some of the projects.

I think it might be best to explain strengths and weaknesses of each
without trying to say anything definitive about which is best for cases
where any of several packages would be a reasonable choice.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGF, http://osgeo.org


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 7242 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/webcom/attachments/20060402/b73ad39e/attachment.bin