Oh are we going to have another client-side vector viewer discussion? :) Since our last discussion on this subject:
* Silverlight has been EOLed by Microsoft * Java applets are security swiss cheese under Oracle's stewardship * Flash is in terminal decline. * HTML5 capabilities has been growing in leaps in bounds with near unanimous support from all modern browsers for the subset of HTML5 features that we would want to utilise for building a client-side vector map viwer. So yes, HTML5 is indeed the logical choice. But past discussions on this have failed to add some real meat that would allow someone to start playing around with the discussed ideas. If we just want a client-side vector viewer with basic styling options, then I'd just let OpenLayers 3.0/Leaflet/etc solve the problem for us and re-focus our efforts on how we can deliver this data to them in the most efficient manner. * I wouldn't suggest WFS in its current form as the current WFS implementation in MapGuide leaves a lot to be desired in terms of memory efficiency. It has the same problem as SELECTFEATURES and friends have pre-RFC130, the responses are not truly streamed out but fully buffered internally. Not very efficient if you want to scale out to multiple users. * GeoRest integration is a bit difficult as its configuration aspect falls outside of the MapGuide resource service. The repository is after all where all our configuration stuff is stored, so we should be leveraging this and not have this information lying out in the external filesystem. This would involve lots of discussions and thoughts about introducing new resource types and matching XML schemas to go with it. * You talk about vector tiles, could you possibly elaborate on this? Is this stuff cacheable server-side like its image-based counterparts? I would prefer something that allows us to re-use our existing Layer Definitions for client-side vector rendering. I'm not sure whether ol3/leaflet support customizable rendering pipelines where we can take over certain aspects of the rendering process and plug our own method of rendering features in. I toyed around with a truly "out there" idea of adding a SDL-based SE_Renderer and then using emscripten to "transpile" the rendering/stylization core with the SDL renderer to javascript, where the SDL API calls get translated to HTML5 canvas calls. This "transpiled" core could then theoretically be enough to build a client-side rendering service around with an actual viewer on top. But this idea was scuppered when I found out that the stylization library had a tight dependency on FDO and its expression engine. I might revisit this idea when I can find out how to refactor out this FDO dependency. I too would like a client-side vector viewer. All our viewer technologies thus far are nothing more than glorified LiteView clients, we do need the modern contemporary to the ActiveX viewer. But like I said we really need some discussions with meat in them. All previous discussions have been somewhat fruitless. - Jackie -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Re-thinking-Fusion-redlining-efficiency-tp5065272p5065968.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
