About that grand plan of 2016 ...

Not all plans go as intended. In my case, it was my grand plan for this year.

If you thought this was the mapguide-react-layout project, then I'm afraid you were mistaken. It was actually something else entirely (I did stress in that post that the project won't be MapGuide-specific). However, due to external circumstances, this plan never and probably will not materialize because I no longer see the need for it.

So since I don't see this grand plan going ahead in the near future, I might as well talk about what it was going to be. Basically, I was wanting to make a Cesium-based replacement for the Google Earth desktop application, using the stack of:

• Electron
• Cesium (possibly in conjunction with OpenLayers)
• React
• TypeScript

Why did I want to build this application (which strangely sounds like some chemistry/physics experiment, what's with these projects co-opting their terminology?). I wanted a replacement for Google Earth. 

Google Earth was good for only one thing: Visualizing KML files referenced against good quality satellite imagery.

It was absolutely horrible in all other aspects:

• I can't mash KML together other geospatial data sources (SHP files, GeoJSON, etc)
• KML is a horrible data interchange format not helped by the fact that Google Earth can't import/export to-and-from different geospatial data formats out of the box! You need a 10+ step data transformation pipeline involving OGR, QGIS and friends to get spatial data in and out of KML. OGR having 2 KML drivers adds an extra layer of confusion to the mix with one guaranteeing to trash any semblance of intelligence by outputting dumb KML geometry.
• Creating KML files is a chore because of GE's cumbersome drawing tools
• Modifying KML files is an even greater chore because GE lacks basic GIS-y tools like buffering, split, etc.

Going all in on QGIS wasn't desirable either because while it had the kitchen sink of GIS tools and functionality and rich support for countless geospatial data formats, it lacked the rich satellite imagery that GE provided and I've had a mixed experience with the various plugins available for QGIS that allowed me to drop-in OSM/Bing/GoogleMaps for real-world context when creating/editing features.

My hypothetical application was intended to be the sweet spot in between GE and QGIS and would've addressed most of these pain points with Cesium/OpenLayers doing most of the heavy lifting (Cesium has strong KML visualization capabilities and OpenLayers is the swiss army knife supporting many vector data sources and has rich editing capabilities) and having it all housed within an Electron host for a desktop experience.

But as I said, due to external circumstances, this idea has been mostly abandoned now. Those circumstances being mainly: I've found something that already addresses most of my pain points with Google Earth.

It's called geojson.io. Despite its deceptive name^ it solved most of my grievances with Google Earth:

• I can bring in KML files and can easily visualize its geographic form
• It provides serviceable tools for easily editing these geographic features. Creating new features is similarly dead simple. As these loaded features are now GeoJSON I can also easily hand-edit the GeoJSON itself if required.
• Once done, I can export the data back out as KML
• The provided mapbox vector/satellite layers provide a decent backdrop for geographic reference when drawing new features or editing existing ones.

So here's something that did 80-90% of what I needed from Google Earth without any of the pain and hassle of using Google Earth itself. The remaining percentages can be easily filled out with QGIS for editing beyond simple tracing of polygons and using GeoJSON or SHP as the interchange format (instead of KML) when I need to sling data between geojson.io and QGIS. The only time I needed to touch KML was when I am importing it into geojson.io or exporting it out. As a result, there was no longer such a need for this hypothetical replacement for Google Earth. I had what I wanted.

Now having said that, this wasn't ultimately all for nothing. I did get some fruits from this aborted plan. The mapguide-react-layout project is one (it uses most of the same technologies that I had originally intended to use for this Google Earth replacement). Another project (which I'll reveal in due course) was also born from the initial exploration phase of this idea.

But hey, if you think we could use an Electron/Cesium-based replacement for the Google Earth desktop application, by all means feel free to take this idea and run with it.

^ Seriously, I had known about the existence of this site for ages, but because of the name of the site I always assumed it only dealt in GeoJSON and glossed over the fact that I could import in KML and export back out as KML. This was the game-changing feature for me where one of my job workflows was having to produce KML files for certain geographic areas and the discovery of this feature made me scrap this grand plan. May I suggest a different name? Like ... GeoFiddle? That's what they call all online data playgrounds.

Let's introduce the other major player

My plans for the VSCode map extension now extend beyond just OpenLayers

At this point there are some small oddities:

• The timeline button SVG has broken hrefs. You can see it from the missing play/pause/rewind graphics.
• The Cesium InfoBox doesn't work.

This is probably due to a combination of:

• Running cesium from the local file system
• The VSCode/Electron webview or Cesium itself imposing sandboxing restrictions that breaks the InfoBox

Still, for the purposes of being able to quick and easily preview CZML content, this is a very nice starting point.

My grand project of 2016

In the interest of clearing out my blogger's block, let's talk about something I plan to carry out for the majority of this year.

I have this grand idea that's been fermenting in my mind for some months now.

It won't be MapGuide-centric (though it may involve MapGuide in some way down the road).

It will be a desktop application based on the Electron editor shell.

It will involve Cesium.js and/or OpenLayers (maybe both at the same time).

It will use the current hottest thing in web frontend development: React.js

And most importantly, it will all be written in TypeScript. Seriously, once you've gone TypeScript, you'll never want to go back to JavaScript! Combine TypeScript with React.js and you have web development heaven.

But the road to realizing this idea has a few roadblocks.

• Cesium and OpenLayers are JavaScript libraries, making it difficult to integrate with TypeScript code. To integrate with other JavaScript libraries, one has to write TypeScript Definition (d.ts) files for the libraries they want to use in TypeScript. This is currently a manual affair and given the API surface of both these libraries, I'm not too keen on writing these definitions by hand!
• There aren't any full featured React.js components for OpenLayers and Cesium.js

My decision to go all in with TypeScript means that these roadblocks must be cleared for my grand idea to be fully realized.

So how are we going to clear these roadblocks? That'll be the subject of future posts :)

Announcing: mapguide-rest 0.10

Nope, this isn't a 1.0 release. Not only are we not using decimal release numbers, but there's still plenty of things to explore and refine before we can put the 1.0 stamp on this thing. Here's what's new and changed in this release.

(Experimental) Cesium CZML support

We now have support for outputting feature data as CZML for consumption inside the Cesium 3D web viewer. Support for CZML is made available as a representation of a given Layer Definition.

For example, the following route will return data from the trees layer as CZML:

http://localhost/mapguide/rest/library/Samples/Sheboygan/Layers/Trees.LayerDefinition/features.czml

We've included a CZML example in this release that demonstrates the level of support that has been implemented for this release.

When selecting an object, its tooltip data will be shown in Cesium's information window if available.

Note the object itself has no selection indicator unless the object is a point. Still trying to figure out if we can apply a different style for selected lines and polygons.

If your Layer Definition has elevation settings applied, they be extruded if they're polygons

Now if the (experimental) tag didn't stand out, here's the current limitations with this implementation:

• The following properties are preserved when converted to CZML, anything not listed can be assumed lost in translation:
  • Point styles: Point color is preserved. The point size in CZML is the average of the height/width of the point as defined in the Layer Definition.
  • Line styles: Line color
  • Area/Polygon styles: Fill color. Outline color
• If a Layer Definition has multiple scale ranges defined, mapguide-rest will only consider the first scale range when outputting CZML
• If a given point/area/line style is themed, the default rule (the one without a filter) is ignored

Data publishing improvements

The restcfg.json now lets you specify a Layer Definition as the data source instead of a Feature Source and Feature Class name.

Also, when using a Layer Definition as a data source, you'll get tooltip, hyperlink and elevation FDO expression pre-evaluated, allowing you to use such computed properties within your templates.

You can find a new example that uses the building footprints from the Melbourne dataset.

File download support

Most GET routes can now prompt for downloads by appending download=1 to the query string of the URL.

XYZ tile improvements

Vector tiles can now be for a base layer group or for a layer within the base layer group.

Just to recap, this URL route fetches a vector tile for a given base layer group in a Map Definition

http://servername/mapguide/rest/library/{resourcePath}.MapDefinition/xyz/{groupName}/{z}/{x}/{y}/tile.{format}

If you want vector tiles for a specific layer within that group, you can use this new URL route

http://servername/mapguide/rest/library/{resourcePath}.MapDefinition/xyz/{groupName}/{layerName}/{z}/{x}/{y}/tile.{format}

You can find a new Leaflet example that uses the single-layer vector tiles.

Other changes

• Fixed bad download links in the resource data list HTML representation
• Fixed invalid chunked file transfer behavior under certain conditions
• Samples updated to use OpenLayers 3 final and Cesium 1.1

Download

Make that 3/3

Thanks to this thread, I was finally able to crack the missing piece of the CZML output puzzle for mapguide-rest, and we can now output point, line and polygon features as CZML to Cesium.

CZML is a representation of a Layer Definition in mapguide-rest, this means we will get pre-evaluated properties to play with such as:

• Tooltips
• Hyperlinks
• Elevation/Extrusion settings

We currently use this information as follows

Tooltips get written as the description property of each CZML packet, allowing such information to be displayed in the Cesium information window when the object is selected.

Now as the above screenshot shows, there's no real visual way to know what object you selected. I'm still figuring out if there's a way in CZML or the Cesium APIs to specify how a selected object looks so it can stand out.

If the Layer Definition has elevation/extrusion settings applied, that's when the fun stuff happens. We apply the extruded value in the CZML packet for each feature, giving us 2.5D features. This extrusion only applies for polygon features at the moment.

Oh, and did you know Cesium works pretty well on any WebGL capable mobile browser?

Pretty cool stuff. Now that we've nailed down the fundamentals, it's time to figure out how much visual fidelity we can preserve from MapGuide to CZML:

• Can we transfer thematics?
• Can we transfer labels?
• Can we transfer patterns?
• Others?

Fun times ahead!

2/3

After lots of trial and error, I am finally able to output features from MapGuide as CZML to Cesium via mapguide-rest

However, only 2 out of the 3 geometry types are working (points and polygons). I'm still trying to figure out:

• How to properly output CZML for line features
• How best to apply Z extrusion where it is defined in the Layer Definition
• What parts of a Layer Definition are transferable/translatable to CZML? Doesn't have to be 1:1. KML-level visual/information fidelity would suffice here.

If only there were more comprehensive CZML examples I could refer to that would make implementing this stuff much easier! All the examples I could find try to demonstrate every bell and whistle when all I want to know is where do I stick the lat/lon/elevation coordinates from my source geometries? Their CZML documentation could do with some improvement, a single-page document is terribly hard to navigate and without reference examples it's amazing I was even able to get this far!

But in the end, all this pain and struggle will be worth it because Cesium is just plain awesome! I truly believe that Cesium will be to 3D maps what OpenLayers is to 2D maps: A powerful web-based map viewing platform that is rich in features and support for many different vector and raster data sources.