[fusion-users] Speed of Fusion vs MapFish (OpenLayers)

[Andrew Parker]

Paul D:

 From your post, it is my understanding that Fusion does not have the 
capability to use tiles.  Is this true?  If needed, I have a programmer 
that can dedicate his time to add tile functionality.  

I set the SingleTile tag to "true" then "false" in the MapSet (file 
ApplicationDefinition.xml) to see if there was any change on the way 
Fusion rendered the map.  I did not notice any difference.  I also 
played around with the map size in the *.map file from "800 640" to "200 
100" to "2000 1000" to see if it made any difference (curiosity, what 
else can I say).  I did not notice any difference with respect to speed; 
I am sure Fusion is overwriting this setting.  I set the final size to 
"300 300" for no reason at all.

At this time, I am most concerned with fast rendering of the USGS topo 
maps and the Geologic Map.  Google is not that important.  But, if need 
be, I can have the programmer start working on the 
OpenLayers.Layers.Google class; I will need a little help to point him 
in the right direction.

~andrew


Paul Deschamps wrote:
> Hi Andrew,
>
> hehe yes or no answer ;)
>
> What you are doing here is not a "true" comparison of the three 
> different technologies.
>
> Your mapfish and your openlayers application are using tiles where 
> your fusion app is not. You see in a tiled mapwindow tiles outside of 
> the mapwindow can be cached so that they display when they are dragged 
> into position. Another consideration about tiled mapviewers is the 
> size of each tile.
>
> If the size of the tile requested from the server is requested at the 
> same native size of the tile on the server then the server does not 
> need to stitch tiles together.
>
> All three of these examples are using Openlayers. So from a strictly 
> fetching of the map image and presenting it on the screen the 
> performance would be identical as long as the requested image is the 
> same size across all three.
>
> And lastly, Your Openlayers app is using Google's Server Farm directly 
> for it's imagery where the mapfish and fusion are  requesting it.  so 
> it's an extra step for every map draw.
>
> Fusion is a toolkit that provides common set of map "widgets" and UI 
> controls that enable rapid application development (RAD) there's a 
> buzz wo from the past. :)
>
> If you really want fusion to preform in the same fashion that your 
> openlayers app is. You can:
>
> Add the OpenLayers.Layers.Google class to your openlayers.js and get 
> fusion to work with it. ( may or may not be an easy task)
> Or wait for it to be added eventually ;)
>
> Cheers
>
> Paul D.
>
> On Wed, Oct 29, 2008 at 5:47 PM, Andrew Parker <andrew at source3.com 
> <mailto:andrew at source3.com>> wrote:
>
>     I am not sure if there is a way to make Fusion render maps as fast
>     as OpenLayers.  At this time, I just need a yes or no answer.
>
>     For example, it would be great if I could make my current Fusion
>     application (http://216.93.173.156/testing/) draw the map as fast
>     as my current OpenLayers application (http//:webgis.source3.com
>     <http://webgis.source3.com>) and my MapFish test at
>     (http://http://216.93.173.156/MFtest/).
>
>     What I am using for a comparison is the Topo Map Layer with the
>     USGS wells (the data is limited to New Mexico, USA) at a scale of
>     about 1:100,000.  When I zoom and pan, I like how fast
>     OpenLayers/MapFish redraws.
>     I went ahead and turned on the two layers that I am using for a
>     comparison in MapFish test and my Fusion test.
>
>     The topo is from TerraServer.  The USGS data is in PostGIS.
>
>     thanks,
>
>     ~andrew
>     _______________________________________________
>     fusion-users mailing list
>     fusion-users at lists.osgeo.org <mailto:fusion-users at lists.osgeo.org>
>     http://lists.osgeo.org/mailman/listinfo/fusion-users
>
>
>
>
> -- 
>    Paul Deschamps
>    Applications Specialist
>    DM Solutions Group Inc.
>
>    Office: (613) 565-5056 x28
>    pdeschamps at dmsolutions.ca <mailto:pdeschamps at dmsolutions.ca>
>    http://www.dmsolutions.ca
>    http://research.dmsolutions.ca
>    
>