| | 1 | [[PageOutline]] |
| | 2 | |
| | 3 | This page is part of the [wiki:Future MapGuide Future] section, where ideas are proposed and refined |
| | 4 | before being turned into RFCs (or discarded). Visit the [wiki:Future] page to view more! |
| | 5 | |
| | 6 | = Overview = |
| | 7 | |
| | 8 | This page is a living proposal for implementing a client-side vector map viewer. |
| | 9 | |
| | 10 | = Motivation = |
| | 11 | |
| | 12 | All of our client-side viewing technologies (AJAX/Fusion/AIMS Mobile Viewer/Pure OpenLayers) are cut from the same cloth: |
| | 13 | |
| | 14 | * Rendering is done server-side |
| | 15 | * Map state is managed server-side |
| | 16 | * Session state is managed server-side |
| | 17 | * They are all inherently connected. If we lose connectivity with the MapGuide Server, all our viewers break down. |
| | 18 | |
| | 19 | If we want to use a MapGuide 6.5 analogy, these are all glorified LiteView clients. We lack the modern contemporary to the MapGuide 6.5 ActiveX viewer where rendering is done client-side and limited offline capabilities can be achieved through the use of static MWF layers. |
| | 20 | |
| | 21 | Having a client-side vector map viewer will significantly reduce the processing burden on a MapGuide Server as its role under a client-side vector viewer would now be reduced to being simply an efficient vector/raster/tile delivery platform. Under a client-side viewer all rendering and map state management can be offloaded from the MapGuide Server onto the client machine |
| | 22 | |
| | 23 | = Choosing the technological base for our client-side vector viewer = |
| | 24 | |
| | 25 | [http://osgeo-org.1560.x6.nabble.com/OpenLayers-SVG-MapGuide-Vector-Viewer-td4210812.html Previous discussions] on the [http://osgeo-org.1560.x6.nabble.com/Future-Development-Options-for-Web-Server-Extensions-and-new-High-Performance-Viewer-td4212021.html#a4212022 matter] has put forth the following possible contenders: |
| | 26 | |
| | 27 | * Silverlight |
| | 28 | * SVG |
| | 29 | * Flash |
| | 30 | * HTML5 |
| | 31 | |
| | 32 | Silverlight's future was sealed due to Microsoft's move towards WinRT/Metro. It is effectively an EOL'ed technology. |
| | 33 | |
| | 34 | SVG is a mature technology but is hindered by Internet Explorer and potential drawing complexity (Even if not desirable, we must allow for scenarios of a map with 10000-100000 features on screen) |
| | 35 | |
| | 36 | Flash is in a state of terminal decline slowly being supplanted by HTML5 |
| | 37 | |
| | 38 | Which leaves HTML5 as the clear winner. Assuming IE8 as a legacy browser, HTML5 is unanimously supported [http://caniuse.com/#search=canvas for the browsers we intend to target] and the subset of HTML5 features we intend to mainly use. HTML5 support is continually improving and more and more complex applications are being built on top of HTML5. Even Autodesk's AutoCAD 360 web is built on HTML5 technologies. If this isn't a clear sign that HTML5 is ready for prime time, then nothing is. |
| | 39 | |
| | 40 | = The key problems to solve with HTML5 = |
| | 41 | |
| | 42 | == Rendering/Stylization == |
| | 43 | |
| | 44 | This is the most important problem to solve. The easiest thing to do would be to just leverage OpenLayers/Leaflet/etc and just serve vector data to it from MapGuide. |
| | 45 | |
| | 46 | While this is indeed the simplest approach. The problem with this is that you are putting rendering/stylization concerns into the client library which may either have a different or simplified opinion on how your features are to be rendered. In other words, there is a major loss of visual fidelity offloading rendering/stylization concerns to a thirdparty JS mapping library. We ideally want to able to leverage our existing Layer Definitions and have the settings defined within be respected by our client-side viewer. |
| | 47 | |
| | 48 | This means of course that we'll need to somehow re-use our existing Rendering/Stylization code. [http://mg-desktop.googlecode.com mg-desktop] and [http://au.autodesk.com/?nd=class&session_id=5241 a particular AU presentation in 2009] have proven this Rendering/Stylization core is pretty self-contained and re-usable outside of the MapGuide Server context with zero dependencies on ACE and other thirdparty libraries. But that code is in C++, and our target platform is HTML/JavaScript. Is there a way to easily leverage our existing C++ code in JavaScript instead of having to re-implement all this from scratch? |
| | 49 | |
| | 50 | It just so happens there is a way. Using a tool called [https://github.com/kripken/emscripten emscripten], we can "transpile" C++ code to JavaScript. The pedigree and readiness of emscripten can be verified with the fact that monstrously complex C++ codebases like the [http://www.unrealengine.com/html5/ Unreal Engine 3] and [http://vps2.etotheipiplusone.com:30176/redmine/projects/emscripten-qt/wiki/Demos Qt] was able to be transpiled via emscripten and run within a web browser. |
| | 51 | |
| | 52 | Advancements in improving JavaScript performance such as asm.js from Mozilla means this emscripten approach has a lot of viability for reusing C++ code in a web browser. Our client-side viewer is not a 3D game engine or a windowing/application framework, so the bar for us to reach isn't exactly high, but also isn't exactly low either. |
| | 53 | |
| | 54 | === Preparing the rendering/stylization code === |
| | 55 | |
| | 56 | '''NOTE: This section was based on light reading of emscripten documentation and blogs. The feasibility of this approach is not proven yet and is purely theoretical''' |
| | 57 | |
| | 58 | A straight run of emscripten on the Rendering/Stylization code is not going to magically give us our magical HTML5 canvas rendering/stylization library. We need to do some preparation/modifications on the code: |
| | 59 | |
| | 60 | * We have to use [http://www.libsdl.org/ SDL] as this is how we automagically get HTML5 canvas support. Emscripten converts SDL calls to HTML5 canvas calls. We need to implement a SE_Renderer that uses the SDL library |
| | 61 | * We need to reduce the dependency set. This means our emscripten build profile should not have: |
| | 62 | * DWFRenderer, EPlotRenderer, EMapRenderer (dependency on DWF Toolkit) |
| | 63 | * GDRenderer (dependency on GD) |
| | 64 | * AGGRenderer (dependency on AGG) |
| | 65 | * KMLRenderer (dependency on parts of the C++ standard library that probably have no emscripten equivalent) |
| | 66 | * We basically only want one concrete SE_Renderer implementation: The one using SDL |
| | 67 | * Replace FreeType calls with SDL (is this even possible?) |
| | 68 | * We also need to eliminate dependency on FDO. This means stubbing out or replacing references to the FDO Expression Engine and replacing any FDO enums/types with our own internally defined ones. |
| | 69 | * We need an implementation of RS_FeatureReader that can callback into JavaScript via emscripten |
| | 70 | * We need a way to marshal byte arrays in JS (however emscripten suggests we should represent them) to FGF byte arrays. LineBuffer objects have support for direct initialization from FGF byte arrays, so FDO does not have to play a part. We'll need some support libraries in JS to support conversion to FGF from common formats like GeoJSON. |
| | 71 | |
| | 72 | The final set of libraries that will be transpiled to JS are: |
| | 73 | |
| | 74 | * MdfModel |
| | 75 | * Renderers |
| | 76 | * Stylization |
| | 77 | |
| | 78 | It is envisioned the final transpiled core can render features off of a HTML5 canvas element and a JS-proxied RS_FeatureReader instance which wraps a collection of GeoJSON features or OpenLayers vectors, with a library like Proj4js taking over the role of CS-Map for client-side coordinate transformation needs. |
| | 79 | |
| | 80 | == Building a new client-side API around this core == |
| | 81 | |
| | 82 | TBD |
| | 83 | |
| | 84 | == Offline storage == |
| | 85 | |
| | 86 | TBD |
| | 87 | |
| | 88 | == MapGuide Server delivery of content/rasters/vectors/tiles == |
| | 89 | |
| | 90 | TBD |
