Here's a list of what I'm hoping for MapGuide/FDO in 2012 (or is this my personal to-do list? :-)).
FDO
1. Raster support for the PostGIS provider
The best open source spatial extension just recently had support for raster imagery. Wouldn't it be nice, to have all your vector and raster data in one centralised database that is accessible via FDO?
2. A more FDO-capable OGR provider
Like the ODBC provider, the OGR provider is a quick and easy way to tap into the vast array of data formats out there which do not have a dedicated FDO provider (most notably, MapInfo). However the OGR provider itself could do with some improvements to better support the FDO-isms like:
- Supporting the ability to create data stores (ie. Mapping FdoICreateDataStore to OGR's CreateDataSource)
- Ability to sort. The OGR SQL dialect supports ORDER BY clauses, so this should be possible. Sortability greatly improves Feature Join performance
- FDO Join support. The OGR SQL dialect supports JOIN statements as well (only LEFT JOIN, but still a FDO supported join type)
3. FDO Join support for other FDO RDBMS providers
For the best Feature Join performance scenarios, all RDBMS-based providers should support this new API. Given the SQL Server provider (which supports FDO joins) is derived from a common base that all other FDO RDBMS providers come from, I'd gather that adding support for would be a case of flipping a few bits here and there.
MapGuide
1. Improve MapGuide's standing as a geospatial services platform
Or to put it in one word: Interoperability. Currently, MapGuide has excellent data interoperability (due to FDO) but has weak service interoperability. It only does WFS/WMS and not much else. Talking to a MapGuide Server and tapping into the services available still requires specialized and dedicated client code or software and not something that can work via one or more OGC standards.
OGC standards is the glue by which geospatial software and services (Closed or Open Source) can talk to each other. So we should support as many of them as we can! Here's a few worth supporting:
2. Native support for PDF output
Let's face it, nobody really plots to DWF. Everybody wants PDF, and it's easier to tell users to download/install a 5MB PDF reader application instead of Autodesk Design Review. The current solutions that are out there only embed an rendered map image to the PDF instead of rendering directly to the PDF. The easiest way to implement such support would be to implement a new MapGuide renderer with a Cairo backend. The upside of using Cairo is that it supports SVG output as well, so we can support an additional output format for free!
So there you have it, a much shorter list this time round because from an internal perspective, MapGuide has reached a point where it is a solid web mapping platform on most fronts. However if you take an outsider's perspective, there's still room for improvement.
Happy New Year everybody. Here's to a wonderful 2012!
New Year's Edit: Inflated the list slightly.
4 comments:
Has there been any progress made towards creating support for WMTS in mapguide?
Not at the moment.
We needed better and more flexible tile access capabilities in MapGuide before we could ever implement something like WMTS on top of it.
MapGuide 3.0 gives us shareable tile sets (which I have yet to blog/talk about) which paves the way for making adding WMTS support a much easier affair.
Hi Jackie
I read on your blog a couple of place on the lack on true interoperable "FDO/MapGuide" thoughts through WFS-T.
It seems you already had some ideas and thought on it.
I was wondering how difficult it would be?
Also would you know from your FDO experience that this would be reusable in a MAP 3D fdo way or if it only would be possible via MapGuide?
Any thouhts from your end?
tx
Luc
Thoughts are the same as before.
WFS-T maps nicely to something we already have implemented (the MgFeatureService.UpdateFeatures() API)
The problem has, and still is:
* Getting MapGuide to understand the WFS-T request formats
* Getting full compliance on this WFS-T implementation
When the codebase is C++, the above two tasks are not so simple.
Post a Comment