[mapguide-users] Re-thinking Fusion redlining efficiency

[Johan Van de Wauw]

I like the ideas, but rather than focusing on the fusion viewer I
think the first focus should be on how to serve the data so it can be
used in any viewer/client. Integrating georest may be an option.
Improving wfs support could be another one. Serving vector tiles is a
third one.

In fact with html 5 it seems more logical to do all vector rendering
on the client, as was done in .... the (autodesk) mapguide activeX.

Having vector layers in open layers also has other advantages: eg you
can enable snapping when digitizing. I've done this with a mapguide
wfs before.

Johan

On Wed, Jul 10, 2013 at 4:34 AM, Jackie Ng <jumpinjackie at gmail.com> wrote:
> Hi All,
>
> I've been thinking about the efficiency of drawing redlines in Fusion. While
> we've eliminated most of the workflow slowness in the data store and layer
> setup before you even get to start drawing your lines and squiggles, the
> actual drawing process still seems woefully inefficient where each geometry
> drawn triggers a map refresh. For really heavy maps, redlining against them
> seems to be very inefficient
>
> I'm starting to float the idea of a client-side "staging area" for newly
> drawn redlines.
>
> The idea is that when you draw your redlines they don't immediately get
> saved to your redline SDF/SHP/SQLite feature source server-side, instead
> they are stored client-side in a OpenLayers.Layer.Vector. This would then
> allow the user to draw multiple objects rapidly in succession without
> interruptions from map refreshes. When they're done, the user can then
> commit and save the whole lot of client-side redlines into the redline
> SDF/SHP/SQLite feature source in one go and then the widget can trigger a
> map refresh.
>
> So the process for drawing 5 redlines is currently:
>
>  * Invoke Redline widget
>  * Choose redline data store type (in Fusion trunk, this option can be
> shortcutted thus skipping this step)
>  * Draw redline #1 -> Triggers map refresh
>  * Draw redline #2 -> Triggers map refresh
>  * Draw redline #3 -> Triggers map refresh
>  * Draw redline #4 -> Triggers map refresh
>  * Draw redline #5 -> Triggers map refresh
>
> The process of drawing 5 redlines under this theoretical revised widget
> would look like this.
>
>  * Invoke Redline widget
>  * Choose redline data store type (in Fusion trunk, this option can be
> shortcutted thus skipping this step)
>  * Draw redline #1
>  * Draw redline #2
>  * Draw redline #3
>  * Draw redline #4
>  * Draw redline #5
>  * Review what you've drawn.
>    * If everything's ok, commit and save the lot and trigger map refresh.
>    * If something's wrong, discard/edit the client-side vector objects and
> commit.
>
> The revised widget would cut down the amount of map refreshes, with the
> small caveat that redlines in the "staging area" won't have your configured
> redline styles (they'll be using whatever OpenLayers provides) and they
> won't show up in any plots of the map until they've been committed by the
> user.
>
> Thoughts?
>
> - Jackie
>
>
>
> --
> View this message in context: http://osgeo-org.1560.x6.nabble.com/Re-thinking-Fusion-redlining-efficiency-tp5065272.html
> Sent from the MapGuide Users mailing list archive at Nabble.com.
> _______________________________________________
> mapguide-users mailing list
> mapguide-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-users