Thursday, 18 September 2014

350 posts

This train ain't stopping yet!


Tuesday, 16 September 2014

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

Saturday, 13 September 2014

300,000 views!

In the race between 300,000 page views and 350 blog posts, the page views crossed the finish line first. For the record, this is my 348th post.

Thank you all for your continued viewership!



Wednesday, 10 September 2014

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:

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!

Friday, 5 September 2014

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.

Saturday, 30 August 2014

Bootstrap map viewer templates

So this past week, I attended another hackathon and our hack was yet-another-twitter-bootstrap-with-openlayers concoction. The problem it seems, every time I go down this path, I lose several critical hours re-creating my desired responsive layout of a map viewer with sidebar with bootstrap CSS every time. You'd think that having done this many times now, I'd have memorised the necessary HTML markup and CSS to do this by now.

But that is just not the case, so after the event (and a good long post-hackathon sleep), I fired up Sublime Text and set out to solve this problem once and for all: A set of starter bootstrap templates that should serve a useful foundation to build a bootstrap-based map viewer web application on top of. Several hours later, there's two templates available.

A 2-column template. A full-screen map viewer with a sidebar to the left:


And a 3-column template, which has sidebars to the left and right which is reminiscent of the classic MapGuide AJAX viewer.


A key feature of both templates is that the floating sidebars are both collapsible.


On small displays, sidebars start off initially collapsed, but can be brought out through their respective toggle buttons.


You can check out the templates below:


Do you have ideas for improving my initial design and have some web design skills? Send me some pull requests.

Tuesday, 26 August 2014

I have a dream

I have a dream

Where MapGuide and FDO source code are hosted and/or mirrored on GitHub.

Where by the virtue of being hosted on GitHub, these repositories are set up to take advantage of every free service available to improve our code quality and developer workflow:
  • TravisCI for Continuous Integration of Linux builds
  • AppVeyor for Continuous Integration of Windows builds
  • CoverityScan for static code analysis
  • Coveralls for code coverage analysis
  • What other awesome services can we hook on here? Please enlighten me. I'd really want to know.
Where a single commit (from svn or git) can start an avalanche of cloud-based services that will immediately tell me in several hours time (because C++ code builds so fast doesn't it?):
  1. If the build is OK (thanks to Travis and AppVeyor)
  2. Where we should look to improve our test coverage (thanks to coveralls)
  3. Areas in our codebase where we should look to change/tweak/refactor (thanks to coverity scan)
  4. Other useful reports and side-effects.
Now the difference between dream and reality is that there are clear obstacles preventing our dream from being realised. Here's some that I've identified.

1. Git presents a radically different workflow than Subversion

Yes, we're still using subversion for MapGuide and FDO (har! har! Welcome to two-thousand-and-late!). Moving to GitHub means not only a change of tools, but a change of developer workflows and mindset.

So in this respect, rather than a full migration, an automated process of mirroring svn trunk/branches (and any commits made to them) to GitHub would be a more practical solution. Any pointers on how to make this an idiot-proof process?

2. Coverage/support is not universal

MapGuide/FDO are multi-platform codebases. Although TravisCI can cover the Ubuntu side and AppVeyor can cover the Windows side, it does leave out CentOS. I've known enough from experience (or plain ignorance) that CentOS and Ubuntu builds need their own separate build/test/validate cycles.

And actually, Travis VMs being 64-bit Ubuntu Linux doesn't help us either. Our ability to leverage Travis would hinge on whether we can either get 64-bit builds working on Linux or am able to cross-compile and run 32-bit MapGuide on 64-bit Ubuntu, something that has not been tried before.

Also most service hooks (like coveralls and CoverityScan) target Travis and not AppVeyor, meaning whatever reports we get back about code quality and test coverage may have a Linux-biased point of view attached to them.

3. The MapGuide and FDO repositories are HUGE!

The repositories of MapGuide and FDO not only contain the source code of MapGuide and FDO respectively, but the source code of every external thirdparty library and component that MapGuide/FDO depends on, and there's a lot of third-party libraries we depend on.

If we transfer/mirror the current svn repositories to GitHub as-is, I'm guessing we'd probably be getting some nice friendly emails from GitHub about why our repos are so big in no time.

Also would Travis and AppVeyor let us get away with such giant clones/checkouts happening every time a build is triggered in response to a commit? I probably don't think so. Then again, I do live in a country where bandwidth doesn't grow on trees and our current government has destroyed our dreams of faster internet. What do I know?



So what do you think? Is this dream something worth pursuing?