Saturday, 31 December 2011

My MapGuide/FDO wishlist for 2012

Might as well get this in before the last day of the year ticks over

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:

Jacqueline said...

Has there been any progress made towards creating support for WMTS in mapguide?

Jackie Ng said...

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.

Unknown said...

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

Jackie Ng said...

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.