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 <[email protected]> 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 > [email protected] > http://lists.osgeo.org/mailman/listinfo/mapguide-users _______________________________________________ mapguide-users mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/mapguide-users
