<html>
<head>
<style type="text/css">
<!--
body { margin-right: 4px; margin-top: 4px; font-variant: normal; margin-left: 4px; margin-bottom: 1px; line-height: normal }
p { margin-top: 0; margin-bottom: 0 }
-->
</style>
</head>
<body style="margin-right: 4px; margin-top: 4px; margin-bottom: 1px; margin-left: 4px">
<p style="margin-top: 0; margin-bottom: 0">
<font size="3" face="Comic Sans MS">Bill,</font> </p>
<br>
<p style="margin-top: 0; margin-bottom: 0">
<font size="3" face="Comic Sans MS">Your questions are a bit open ended, but here goes . . .</font> </p>
<br> <br><br>
<p style="margin-top: 0; margin-bottom: 0">
<font size="5" face="Comic Sans MS">Pros:</font><font size="3" face="Comic Sans MS"></font> </p>
<p style="margin-top: 0; margin-bottom: 0">
<font size="3" face="Comic Sans MS">Much easier to list these out, but at the risk of boring you, since I've seem GeoMoose used now in ways and areas I never thought of originally, at least not in detail. The biggest Pro that I believe is there, is the potential for the distribution of data maintenance tasks afforded by how GeoMoose pulls it's services together. GeoData, as raster, vector and add on services are all planned for in the GeoMoose framework as pieces of the equation that the implementors will want to do.</font> </p>
<br>
<p style="margin-top: 0; margin-bottom: 0">
<font size="3" face="Comic Sans MS">If you plan at some point to distribute the upkeep of data across many admins, then GeoMoose if for you. Any single layer breaking does not affect the rest of the interface, and the user has the option of just leaving it turned off.</font> </p>
<br>
<p style="margin-top: 0; margin-bottom: 0">
<font size="3" face="Comic Sans MS">Other than the mapping data feeds, there are no server requirements for GeoMoose, it can read WMS services alone if needed for example.</font> </p>
<br>
<p style="margin-top: 0; margin-bottom: 0">
<font size="3" face="Comic Sans MS">Mapping display built on OpenLayers.</font> </p>
<br>
<p style="margin-top: 0; margin-bottom: 0">
<font size="3" face="Comic Sans MS">Very portable.</font> </p>
<br>
<p style="margin-top: 0; margin-bottom: 0">
<font size="5" face="Comic Sans MS">Cons:</font> </p>
<p style="margin-top: 0; margin-bottom: 0">
<font size="3" face="Comic Sans MS">If you plan on having a single system administrator, then GeoMoose may be overkill. Although others would argue that the demo's are set up fairly nicely with regard to plug and play, so even the overhead is not as overbearing.</font><font size="5" face="Comic Sans MS"></font> </p>
<br>
<p style="margin-top: 0; margin-bottom: 0">
<font size="3" face="Comic Sans MS">It would be much easier to react to your past misgivings about a application coming up short, than to feed the pile from scratch. Makes me think way too far outside of the box if you know what I mean.</font> </p>
<br>
<p style="margin-top: 0; margin-bottom: 0">
<font size="3" face="Comic Sans MS">Doesn't do WFS (cleanly) [YET], although, while the geomoose project expends most of their effort buildig against MapServer, GeoMoose is not tied to it, and could talk to just about any geodata feed.</font> </p>
<br>
<p style="margin-top: 0; margin-bottom: 0">
<font size="3" face="Comic Sans MS">As far as what it's not, It's not a Desktop analysis tool. Although it's got a lot of analysis capabilities, with the latest version having a bunch of new functions added on.</font> </p>
<br>
<p style="margin-top: 0; margin-bottom: 0">
<font size="3" face="Comic Sans MS">Doesn't depend on a web service in particular, why is this in the Cons, because it doesn't have a distinct server component. It's very standalone-ish actually.</font> </p>
<br>
<p style="margin-top: 0; margin-bottom: 0">
<font size="3" face="Comic Sans MS">Doesn't have your described GUI management tools (yet), although, there are ideas about how to pursue this, just no project yet to subsidize the work. And the basic framework is very conducive to adding this. </font> </p>
<br>
<p style="margin-top: 0; margin-bottom: 0">
<font size="3" face="Comic Sans MS">bobb</font> </p>
<p style="margin-top: 0; margin-bottom: 0">
<br>
<br>
>>> Bill Thoen <bthoen@gisnet.com> wrote:<br> </p>
<div style="background-color: #f3f3f3; margin-right: 0; margin-top: 0; margin-left: 15px; margin-bottom: 0; border-left: solid 1px #050505; padding-left: 7px">
<p style="margin-top: 0; margin-bottom: 0">
Bob Basques wrote:<br>><br>> Bill,<br>><br>><br>> This is a shameless plug for GeoMoose functionality, it was prompted<br>> by your comments below however, so I don't feel too bad  :c)<br>><br>><br>Grab every opportunity that sets you up for a pitch! Although I'm<br>actually not unhappy with HTML Legends --I've found workarounds for<br>things I don't like-- but it would have been nice to have known in<br>advance where it runs out of steam or just doesn't go, so I'd know<br>whether I would reach the point of implementing kludges before or after<br>I reached my goal.<br><br>GeoMoose sounds pretty good and seems to solve my problems 1-2-3... But<br>before I go try it out now instead of later and spend a lot of time I<br>can't spare contemplating a software switch and testing its capabilities<br>for possible use in a project with a tight  deadline,  can you highlight<br>for me the top two or three areas where the hard, cold ground rises up<br>to meet it (i.e. where it falls on its face)? I'm not looking for what's<br>broken, but more along the lines of what it is NOT designed for, so I<br>don't make th e mistake of trying to use in a situation where it will<br>not do well.<br><br>> *  Each layer (or group of layers) is controlled via it's own mapfile,<br>> while this might seem cumbersome to manage, it does allow for separate<br>> and integrated management of data layers by many data custodians,<br>> which is what GeoMoose was originally designed for, many data<br>> custodians doing their own thing.  It's also very good for automation<br>> purposes in general.<br>><br>><br>One of the both strong points and weak points in the FOSS mapping<br>software I've seen so far is its almost universal core dependence on<br>mapfiles or templates as the driving mechanism. These are powerful in<br>that the are easily modified, human and machine readable and you can<br>record layer "states" and mix and match the "objects" later on as you<br>like to create alternate configurations. But where they're a weak point<br>is when you want to provide a warm 'n fuzzy front end for User B. Goode.<br>Templates are difficult to work with at that point. They're based on the<br>1950s-60s notion of batch programming in which the programmer decides<br>where the process starts and ends. So when you try to build an<br>interactive, user-driven interface on top of this, the bugs and<br>shortcomings you tend to run into are usually rooted in a sort of<br>schizophrenia between the two paradigms. Has anyone here considered<br>breaking down the rigidity of the mapfile architecture by writing them<br>in XML or JSON formats so they can be more easily manipulated by an<br>application?<br><br>- Bill Thoen<br><br>_______________________________________________<br>mapserver-users mailing list<br>mapserver-users@lists.osgeo.org<br><a href="http://lists.osgeo.org/mailman/listinfo/mapserver">http://lists.osgeo.org/mailman/listinfo/mapserver</a>-users<br>
</p>
</div>
</body>
</html>