Saturday, 9 March 2013

Fusion redlining revisited.

For the next MapGuide Open Source 2.5 release (not sure if it will be another beta or straight to RC atm), we're giving the Fusion (in particular the Redline widget) a bit more spit and polish.


As explained previously, in this author's opinion, the original Redline widget for Fusion was completely useless functionality wise:

  • Can't plot a view of your map with your redlines
  • Can't control the styling of your redlines
  • GML is your only import/export format. Who on earth consumes GML? Certainly not Autodesk's geospatial products!
So we threw it out and rebuilt it based on the original Generic Tasks sample for the AJAX viewer.

Now admittedly, the v1 re-implementation (which was in AIMS 2013) was nothing more than a carbon copy of the Generic Tasks sample, meaning not much real thought was put into usability and user efficiency. The redlining process was a cumbersome multi-step process that didn't really scream productivity.

So for the MGOS 2.4 iteration of this widget, we patched up the usability problems, shortcutting most of the previously mandatory setup steps (with options to revisit these steps if required). We also took advantage of some previously-unknown fusion components (to me anyway) to improve the digitizing process with informative prompts.

This iteration while usable and powerful, had one remaining limitation. SDF was the only import/export format. While round-tripping between Autodesk's geospatial products is not a problem, round-tripping to other geospatial software is a problem because SDF is not exactly a well supported format outside of Autodesk's range of geospatial products.

The widget improvements

So for the MGOS 2.5 iteration of this widget, the Redline widget now supports the following formats:
  • Import: SDF, SQLite and SHP (as a zip file)
  • Export: SDF, SQLite, SHP (as a zip file), KML and KMZ
That's 2 extra import formats and 4 extra export formats!

Here's how the revised management UI looks

Most of the UI functions as it did before, so we'll just cover the bits that have changed.

What was previously the "New" button has now been separated into its own section 

This may look a bit complex, but it's not really. You pick the types of geometries you want to be able to digitize and hit the button to create the redline data store of the desired format. 

Why did we have to do this? Simple. If we want to support the ever-ubiquitous ESRI SHP file as a redline import/export format, we have to cater to its extremely cumbersome file storage limitations. While SDF/SQLite files can happily store all 3 geometry types for redline data, SHP can only support one geometry type per SHP file

So if we want the user to be able to record redlines in SHP files, we have to know what type of SHP file the user wants to create. As you can see from the screenshot, as all 3 geometry types are selected so SHP is not available as an option. But if you only checked one of those types, the ability to create a SHP file for redlines is then made available.

The second difference, is in the actual redline digitizing UI. Geometry types that cannot be digitized will be disabled. So the digitizing UI for a point-only SHP file looks like this (notice how only "Point" is enabled):

The final difference, is the expanded list of download options.

"Download Data" will serve out the redline data store as before. KML and KMZ download options take advantage of MapGuide's built-in KML service APIs to export the selected redline layer out as KML/KMZ files. Unlike the normal usage scenario, this a full KML/KMZ dump of the layer (ie. a GetFeaturesKml call) and not the map (ie. GetMapKml), which is actually a KML skeleton of NetworkLinks back into the mapagent to get the actual layer KML data.

So how does this KML look? Here's some redlines I've prepared earlier

Clicking "Download KML" or "Download KMZ" gives you the download prompt.

Which looks like this when we look at it from Google Earth

As you can see, we lose a bit of visual fidelity because MapGuide styles don't cleanly translate 1:1 to KML styles, but the core geometric shapes and text information are there.

A general note about Importing/Exporting

I guess we failed to document this when re-implementing this widget so it's better now than never.

There are some caveats to take note of when importing/exporting redlines.
  • Your export format is the format that you specified when you created/imported the redline data store. If you created a SQLite redline data store, that is what you will get prompted to download (a SQLite file) when exporting. Previously the only supported data store format was SDF, so this wasn't much of an issue.
  • If exporting redlines as SHP, you will be prompted to download a zip file. Once again, the shapefile format is not one file, but a set of inter-related files. Since we can't prompt you to download multiple files at once, the widget zips up the files in question and serves that file out for download.
  • Similarly for importing redline files. If you want to import a SHP redline, it has to be a zip file of the SHP file and its related DBF, IDX, SHX, etc files.
  • On the general subject of importing, the file you choose to upload must meet certain structural requirements in order to be accepted as a redline feature source. Generally speaking, we assume you are uploading redline files created orignally by this widget.
  • Exporting only exports the data and not its visual representation (ie. the Layer Definition)
  • Similarly, importing will set up a default Layer Definition for your uploaded data.


Steve Golden said...

I've had users wanting to create their own "layers" and then use for some other purpose, so I think this is a huge step forward (also a feature that some other web map apps have integrated). I noticed that your example redlining had two geometries (polygons and lines). You exported to KML, but it looked like just the polygons showed up. Is that correct or should it have exported all geometry types? Also, I think that some non-technical users are going to be a bit stumped when having to choose a file format type for new redlines. And is there a way to better identify "Download Data" (i.e. Download in native format)? It's a bit mysterious that the other two identify a format, but that one does not. Just some suggestions, you've definitely enriched the application.

Jackie Ng said...

I think you've exposed a possible bug in the KML serving from MapGuide. The lines are actually there, they just had 0 width when I took the screenshot.

The button labels are all localization ready, so if there's friendlier terminology to use, I'm all ears.

Steve Golden said...

I would exchange:

Download Data -> Native Format
Download Data -> Original Format

Download KML -> KML Format
Download KMZ -> KMZ Format

The button is already in the Download section, so perhaps it's a bit redundant to have "Download" on the button.

I think with the right workflow, if you combine MGOS, Avenza PDF Maps, and a desktop GIS (like QGIS or ArcGIS) you can create a pretty good offline mobile mapping system that could use the same geospatial PDFs as your online "basemaps" and potentially take your offline field surveys and sync back into the "online" system. And your non-GIS users could create overlays using MGOS, push out a KML and use in the field. I guess two of the missing links that would allow a better workflow are allowing KMLs as redline widget imports and being able to export MGOS maps as geospatial PDFs.

Jacqueline said...

Know of any public webpages using MGOS 2.5? I would love to try out the new redlining tools.