Friday, 25 October 2013

Madness? This. Is. My. 300th post!

Now that the 300 joke is out of the way ...

This post marks my 300th post on this blog. My 70th post for this year, making 2013 my most productive blogging year thus far.

And this blog also just passed 200k visiting pairs of eyeballs!

Like my 200 post retrospective, here's my hand-picked highlight reel from my journey to 300 posts:

And we ain't even done yet! How many more records will be broken?

Going to Autodesk University?

Well I'm not going unfortunately. But one of our major clients is.

Recep Alakus from Hume City Council will be at Autodesk University 2013 to present about using AIMS and AutoCAD Map3D to manage assets and facilities.

Most of our MapGuide-related handiwork is in use at Hume City Council. So this presentation may be of interest to any of you that are going to AU.

Wednesday, 16 October 2013

Yo Adrian! I did it!

 Thank you all for lending your eyeballs to this blog. All 200k pairs of them.


Tuesday, 15 October 2013

Eureka!

How do you know this screenshot below is OpenLayers 3

Rotation! Can't do that stuff client-side in OpenLayers 2!

Tuesday, 8 October 2013

MapGuide 2.6 feature showcase: Fusion

Since the 2.6 preview release bundles a trunk build of Fusion, I might as well cover what's new in Fusion in addition to a whole bunch of bug fixes and minor improvements.

OpenLayers upgraded to 2.12

OpenLayers has been upgraded to the 2.12 release. This gives Fusion plenty of new toys to play with.
  • Client-zoom. If you have a Map Definition with an OpenStreetMap backdrop, the OpenStreetMap tiles will stretch appropriately if you zoom to an unsupported OSM scale

  • Improved touch support for mobile devices. Try viewing your Fusion layout on an iOS or Android device. Not that we're going to officially support Fusion for mobile devices (my recommendation is to still build a dedicated viewer or use an existing mobile-optimized viewer for mobile devices), but you might be surprised to find that the Fusion is quite serviceable on tablets/phones due to the improvements provided by OpenLayers 2.12.
  • Cleaner custom build experience. As a result of the OpenLayers upgrade, we've also took the opportunity to restructure how we keep OpenLayers under version control. Now we also keep any customizations to OpenLayers under a separate directory so that creating your own custom build of OpenLayers for Fusion is a case of extracting the 2.12 release to a temp directory, overlaying our modified files on top and then building a new OpenLayers.js which can then be incorporated into the Fusion installation
Time/resources permitting, we may look to bump this to the latest stable (2.13.1)

New Geolocation widget

The Geolocation widget taps into the new HTML5 geolocation API allowing you to pan (and optionally zoom) to your current position on the map.



Of course, the utility of this widget is somewhat diminished if you (the user) are nowhere physically within the area of the map you're looking at (like myself, based in Melbourne, Australia looking at a map of Sheboygan, Wisconsin, USA). The widget will warn you if your physical location is outside the bounds of the map.



New Coordinate Tracker widget

The Coordinate Tracker widget allows you to view your current mouse coordinates in various different coordinate systems.



Unlike MapGuide, we're leveraging Proj4js to do these transformations (because CS-Map is not available for us to use in JavaScript), and we also keep a pretty big list of coordinate systems that are convertible between CS-Map and proj4 to ensure maximum compatibility of most coordinate systems.

Improved Load/Selection performance

If you're working with a version of MapGuide that supports the new CREATERUNTIMEMAP and QUERYMAPFEATURES operations (ie. The 2.6 Preview Release), you should see improvements in map loading and selection. For large maps, you should see significant loading improvements.

Otherwise we stick to the existing set of PHP web tier glue for doing map loading/selection.

Redline Enhancements

The Redline widget also sees continued improvements

Firstly, the redline widget now supports Advanced Stylization. In terms of what you see on the map, it shouldn't be much different visually from Basic Stylization except that labels you include with drawn redline objects will always be visible regardless of scale. Previously, under Basic Stylization feature labels were subjected to "MapGuide knows best" label placement which is not a good thing to have when you've made some notes on the map and you can't see the actual notes!



The lines actually have labels too, but "MapGuide knows best" label placement has determined that it can't find a suitable place to draw a label. Point styles under basic stylization had an option to override this behaviour, to always draw the label regardless. Unfortunately, line or area styles do not have an equivalent setting.

Moving to Advanced Stylization gives us this capability for all geometry style types.


As you can see, all the labels are now visible even if not packed nicely. But at least this way, you know for certain visually whether a redline feature has labels or not.

But this is not to say we've removed basic stylization support. You can choose what type of stylization to use through the new StylizationType widget extension property.

Secondly, we've continued to improve the user workflow and continue to reduce the amount of setup steps a user needs to take. You can now specify the desired redline data store format and geometry types upfront as widget extension properties. Having these properties set turns the main redline from this


To this


No need for the user to have to choose (he/she probably has no clue). Just click the big button to start.

Thirdly, we've improved the redline editing process. The redline list box is now multi-selectable, meaning you can now select/delete/edit text of multiple redline objects at once instead of doing it one-by-one


QuickPlot Enhancements

The QuickPlot widget now supports legends. The legend is produced through the existing GETMAPLEGENDIMAGE operation.



Also the QuickPlot UI lets you configure which elements you want to show in the final PDF plot.


Try it now

If you can't install the MapGuide 2.6 preview release, we've made available a trunk snapshot of Fusion for you to download and try out.

Just extract the zip or tarball to the www directory of your MapGuide web tier installation. If you want a side-by-side install without replacing the current Fusion, just rename one of the fusion directories and change the "fusion" in your viewer URL to this renamed directory as well.

This snapshot includes the 5 MapGuide templates and is newer than the Fusion that is bundled with the MapGuide 2.6 preview release.

MapGuide Open Source 2.4.1 and newer are the versions of MapGuide that will work with this release. Versions older than 2.4.1 are un-tested and aren't guaranteed to work.

Thursday, 3 October 2013

Announcing: MapGuide Maestro 5.0.1

So ... with that problem out of the way, here's the release of MapGuide Maestro 5.0.1

This release contains 2 new features. The first one is adding in missing support for editing properties of symbol instances in a composite rule. The symbol instances dialog now has a button to edit the properties of the selected symbol instance.


This brings up a new dialog to edit the properties of the symbol instance in question


The second feature is a small enhancement to the Generic XML editor to let you re-read XML content from the originating resource. A useful feature when you need to "refresh" the XML of your current edited resource if it has changed underneath since the moment you opened it for editing.


And being a point release, it includes bug fixes from 5.0 including a fix for the annoying cursor problem in the Generic XML editor that many of you have probably encountered.

Download

Wednesday, 2 October 2013

MSBuild gotcha in .net Framework 4.5

So I was originally going to put out the first point release of MapGuide Maestro 5.0 earlier this week, but I hit a snag in the build system that completely baffled me.

Since Google failed to reveal anything of substance on this particular issue, I figured I'd do the right and responsible thing and tell you what this problem is and how I fixed it so it can be indexed by Google so anyone else having this problem can just find this post :)

The problem

To illustrate, this is the set of build artifacts for Maestro 5.0



And here's the set of build artifacts of Maestro trunk


How on earth did the release zip file balloon out by 120MB? Well if we look at the build output directory that we then make our installer/zip files from, we see how it got to this size.



The FDO and CS-Map dictionaries for our Local Connection mode addin have been copied to the root of the output directory in addition to the addin's output directory. Our Maestro VS solution file has 48 projects. Some of these projects have unmanaged dlls and content/data files that we need to also copy across into the correct subdirectories of our main output directory.

Our build system wipes out the Local Connection mode addin directory before zipping (the zip release is our multi-platform release, where Local Connection mode is windows-only so we delete this directory), but because the FDO and CS-Map dictionary directories have been duplicated somewhere they're not supposed to be due to this particular issue, they've been inadvertently included in the zip file as a result

So that's the problem, but why did this happen?

The cause

In a nutshell, something changed with the MSBuild that is installed by .net Framework 4.5.

If you built the Maestro solution in the Visual Studio IDE (2010 or 2012) or with the MSBuild that comes with .net Framework 4.0. We got the expected file/directory structure that our build system then makes the installer/zip files from. But when we build Maestro with MSBuild 4.5, we get this strange file/directory structure.

A full verbose file-logged build with MSBuild 4.0 and MSBuild 4.5 and comparing the log files revealed the culprit.

It was these settings I had in my solution file.



I don't remember why the highlighted projects were ticked, but the highlighted items were indirect dependencies of Maestro.exe that I ticked some time in the past on the belief that building Maestro will then "pull in" these indirect project dependencies and cause them to be built as well. I did this because when I want to debug Maestro from Visual Studio for the first time, I want to make sure the addin projects were being built as well but because Maestro.exe does not reference these projects directly (it loads these addins at runtime), I had to use the project dependency mechanism in the solution settings to make sure these projects were being built when I hit F5 in Visual Studio.

It turns out with MSBuild 4.5, that these settings produced an undesirable (or is it desirable?) side-effect of any files marked Copy to output directory = Always from these projects also being copied over to the output directory of Maestro.exe in addition to their project's respective output directory.

The solution (for me)

The solution for me was to simply un-tick these dependent projects. I've conditioned myself to do a full solution build in Visual Studio anyway before I start debugging so when I hit F5, the addins will have already been built and ready to be loaded by the Maestro.exe I'm debugging, so having these projects ticked was not necessary.

Now if this is not an option. There were other options I explored that also worked for me with varying levels of feasibility

  • Use post-build events to copy the relevant content/data files instead of using the Copy to output directory item property. Even if triggered as an indirect dependency project by MSBuild, the post-build events will ensure any content/data files will be copied to their intended location. If you have lots of projects with extra files that need to be copied this may be a painstaking process.
  • Replace the Microsoft.Common.tasks file under %SystemRoot%\Microsoft.NET\Framework\v4.0.30319 with the .net Framework 4.0 copy. Because .net Framework 4.5 is an in-place upgrade over 4.0, the 4.0 copy of Microsoft.Common.tasks is replaced. This is not recommended as a viable solution. I just noted this because this worked for me. I guess the proper way to do this would be to use whatever APIs provided by MSBuild to override the various v4.5 MSBuild tasks/targets with their v4.0 equivalents to get the old behaviour. I'm not an MSBuild expert, so I can't really further elaborate on this or confirm what I just said about using MSBuild APIs is actually possible.

As for whether this behaviour in MSBuild 4.5 a bug or a feature, the jury's still out on that one. At first glance I thought it was a bug (because it sure didn't behave like this in MSBuild 3.5 and 4.0), but on second thought it does seem like a feature. If project A has manually marked dependencies B and C in the solution then logically speaking you would expect any files in projects B or C marked Copy to output directory = Always to be copied to project A's output directory in addition to their project's respective output directory.

I guess this depends on what your definition of "output directory" is. Whether it's the output directory of the referenced project or the output directory of the project doing the referencing. Either way for me, my main release roadblock was removed.

Something to keep in mind should you be moving to VS2012/.net Framework 4.5.