[Webmap-discuss] GeoMoose vs. OpenLayers for specific project (Was Re: [mapserver-users] Advice for MapServer project)

[Lorenzo Becchi]

>
> This XML file is even something that can be automated, so that an 
> > > online method of setting up a Mapping interface could be built, and is 
> > > something that is planned for as well.
>   
>
> Sure, but you can build that without XML  :)  Lorenzo Becchi has been
> doing that with his WMS capabilities reading layer loader thingy, I
> think. It then serializes to JSON or XML context documents, 
> which can then be reloaded later on.
that's true!
:-)

need to put it in openlayers plug-in directory

Lorenzo




Christopher Schmidt wrote:
> This discussion carried over from MapServer-Users list. This is about
> the benefits GeoMoose offers over OpenLayers.
>
> On Tue, Feb 26, 2008 at 05:21:13PM -0500, Christopher Schmidt wrote:
>   
>> On Tue, Feb 26, 2008 at 04:12:58PM -0600, Bob Basques wrote:
>>     
>>> The setup of the interface as well as the data sources are all 
>>> abstracted to the point that each individual data custodian, and/or 
>>> service owner, can implement their respective dataset/service in their 
>>> own way and update it as frequently, or infrequently as they desire.
>>>       
>
> To me, this sounds like server-side layer management: is that what
> you're talking about?
>
>   
>>> Everything in GeoMoose, including the Nav tools, are considered a tool 
>>> or service of some sort, so it's very easy to add others to the mix.
>>>       
>
> These sound like OpenLayers Controls: Attribution, OverviewMap, etc. Is
> that what you mean? Is there something special in how GeoMoose does
> this?
>
>   
>>> The administration of the data maintenance is also a big difference 
>>> compared to other pacakages, because once the layer/service  is 
>>> implemented via GeoMoose, it's up the layer/service providor to keep it 
>>> maintained into the future.   Since everything is a service of some 
>>> sort, these services can all be maintained and authenticated in any 
>>> manner the custodian/owner want to use.
>>>       
>
> Is this server side code? Client side code? This sounds sort of like
> OpenLayers 'layers'; I'm not sure how it's different, other than that we
> maintain the layers in the OpenLayers code. Does this make sense? Do you
> do this differently?
>
> Is WMS a 'layer/service' in GeoMoose?
>
>   
>>> GeoMoose is aimed at datasets that change fairly often, on the order of 
>>> hours or minutes, and is intended primarily to access this type of data 
>>> set.  
>>>       
>
> Sure: how does the client accomodate for that? Automatic refreshes?
> Cache busting? Is this configured through the XML?
>
>   
>>> OpenLayers with it's Tiled interface seems to be intended for 
>>> displaying datasets that tend to be more static in nature.  
>>>       
>
> This may be true for some people. Of course, OpenLayers supports:
>  * Automatic merging of 'cache busting' parameters into the layer
>    parameters via layer.reload
>  * Untiled interface to layers as well (just turn on the singleTile
>    option for layers which support it) 
>
> And of course, in my mind, the time length for which data is valid is
> not related to the client, but to the *server* which should deliver
> appropriate caching headers: OpenStreetMap does this for its
> 'Osmarender' layer, which will automatically refresh tiles which are
> updated as you drag the map around.      
>
>   
>>> Now, either of the two packages can can be used for each others
>>> capabilities, but GeoMoose was built from the ground up based on a
>>> asset management type of business need with mapping as the visual
>>> identifier.
>>>       
>
> Hm, I'm not sure I understand this: perhaps this is a key point. Can you
> describe "asset management type of business need" more clearly? 
>
>   
>>> One last item, is that GeoMoose the interface is initiaqlized from a XML 
>>> file, a MAPBOOK, so setting up business specific interfaces is very 
>>> easy.  
>>>       
>
> I'll admit that OpenLayers eschews non-standard XML-based configuration,
> tending instead towards standards like WMC for configuration via XML.
> Mostly, howeveer, it's true that OpenLayers expects users to configure
> their application via Javascript. MapBuilder is the tool to use if
> XML-based configuration is really your thing, and you're interested in
> OpenLayers: It's all done via some XML document that is being
> standardized as they build it or something, as far as I understand it.    
>
>   
>>> This XML file is even something that can be automated, so that an 
>>> online method of setting up a Mapping interface could be built, and is 
>>> something that is planned for as well.
>>>       
>
> Sure, but you can build that without XML :) Lorenzo Becchi has been
> doing that with his WMS capabilities reading layer loader thingy, I
> think. It then serializes to JSON or XML context documents, 
> which can then be reloaded later on. 
>
> Looking forward to learning more,
>