torsdag 21 juni 2018

Azure Maps and Turf - a perfect match

Azure Maps is a new mapping platform from Microsoft, the geometries and features following GeoJSON format and expect coordinates in WGS84. Turf is an open source library for geometry analasis and manipulation. Turf expect GeoJSON.

So I took a few minutes to play with the combination of Bing Maps and Turf and I found it as a perfect match. With just six lines of code I:

  • created a random linestring with turf (perfect for testing)
  • buffered the linestring. 
  • calculated the map extent
  • added some styling
  • added the buffer
  • focus the map to the extent and added some padding.
In fact it is a one to one line translation of the algorithm above to code! Namespace in Azure Maps is still Atlas, I don't know if that is expected to change because I believe Atlas was the project name for Azure Maps.

const lineString = turf.randomLineString(1, {bbox: [15, 61, 18, 63],
   num_vertices: 10, max_length: 0.5});

let lineBuffer = turf.buffer(lineString, 0.8);

const bbox = turf.bbox(lineBuffer);

lineBuffer.features[0].properties = {color: "rgba(0, 255, 255, 0.7)",
   outlineColor: "blue"};


map.setCameraBounds({bounds: bbox, padding: 100});

That's it! This could have been an difficult operation. It is not - thanks to standard formats, people and organisations adapting it.

One thing I like with Turf and Bing Maps is the ability to generate test data. In Turf it's a bit hidden in the Random section, for example randomLineString.

The industry is starting to gather around GeoJSON. At least leading players such as Micrsoft and MapBox who is also backing Turf.

When will there be a binary standard format with the same adaption as GeoJSON ? Maybe GeoBuf?

måndag 23 april 2018

Snakeline module - bringing life to the map

Animations are great in many situations. For example helping the user solving a task, today animations is a natural part in applications. So therefor I thought it was time to have a Polyline animation module - or a snakemodule. There is a good article about animations in Bing Maps here The principles should be about the same but the v7 control is outdated.

Except adding life to the application animating a polyline makes sense in some use cases. For example when in comes to routing and directions. Animate the route from A->B also emphasize the direction for the user.

Moreover I added possibility to have several poly line styles for one polyline, I don't know if I missed anything from the documentation but I added ability to add mulitple styles. But wouldn't it be cool to declare style the same way CSS is declared? Being able to adding a shadow to geometry is a nice way enhancing the information. 

The module

The snakemodule is structured in two, three pieces. The first piece densifies if needed the polyline, as shown in the image below. The spatial math library is a big help for this task. The second part plots the chunks with a "frame duration" of 15 ms. The animation duration is configurable when calling the draw function.

The code is published on Github, feel free to try it. But I would have loved to see a repository with various modules, libraries etc on GitHub coordinated by Microsoft. 

tisdag 10 april 2018

How long is my route?

How long is my route actually? When it comes to routing there is one thing that is for sure - there are no rights and wrongs. Routing is indeed an interesting subject.

What length of the route does Bings Direction service provide? I suspect the length is in 2d, not the actual driving distance. So lets find out.

Calculating 3d distance on a sphere is hard. So first I need to narrow it down to something that is understandable for me. So I route between my home town and a ski resort in the mountains.

First lets inspect what Bing Maps returns in route summary. Is says the route is 283.758 km. Using the method Microsoft.Maps.SpatialMath.getLengthOfPath(path) and passing path gives 283.981 which is about 220 meters different. It is a different that is such small that is just academia. It is impressing that the client returns such accurate result considering it is JavaScript.

So lets examine what happens when transforming the coordinates to UTM. Fortunately the route is within the same UTM zone. So for each segment I simple used Pythagoras formula to calculate the length of each segment. It gives me 284.491 km. It gives a difference of 0.25%. Still within what is acceptable for this experiment.

In order to measure in 3d I use the elevations service for each location received from the direction service. After that all I need to do is add the elevation to the location.

Since it is now a planar coordinate system it is now possible to calculate 3d length with Pythagoras formula, according to this: The result surprised me though. Given planar conditions it says 284.538. Which is a different of 47 meters.That is a big surprise! I thought it would be more significant.

And comparing my 3d route length with the length from spatial math library it just about 0.01%.

My conclusion is that for driving it is not really worth calculating if it is not in extreme terrain. But for walking and bicycling it makes sense to take elevation into account.

The code is here for scrutiny:

måndag 22 januari 2018

Spatial Server Tools?

Over time Microsoft has a history of developing mapping services and applications. It spans from Encarta, with map tours, to lately announced Location based services on Azure. MSFT took the path through various online services such as MapPoint, Virtual Earth and Bing Maps.

I believe over time Microsoft have developed suite tools for handling GIS and spatial information (otherwise they would not deliver the services they have). One thing I found a bit odd is the current Bing Maps client is really powerful with the Spatial Math library in combination with services and the new routing API. But there are not so many tools on the server. Of course there is SQL Server and the library Microsoft.SqlServer.Types. Developing server side GIS with .Net you will probably end up with ESRI or NetTopology Suite (NTS), a powerful open source library).

But I believe there is room and a need for yet another library. For example:
  • Test geometry generator, create test geometries
  • IO, various formats.
  • Spatial Math
  • Geometry compression
Above are all low hanging fruit. In fact all of them are in Bing Maps client.

What if just the functions in Bing Maps client would also be available server side? That would include all four points above. Or what if just the Spatial Math library would be available as a NPM package? Or even a Nuget package and expand from that? 

torsdag 18 januari 2018

Drawing a donut in Bing Maps


Polygons with holes aka donuts have been a challange in web mapping. For not too long ago when customers asked if it is possible to have holes in polygons, I was avoiding the question. It is possible to send an array of rings to the polygon constructor. But within Spatial math library it is possible to achieve holes in polygons pretty easy. If a user draw a polygon on top of a polygon on the same layer, it might mean a hole.


  1. Create a polygon. The easiest way I know for this use case is to make a circle. 
  2. Create another smaller polygon, a polygon that I use to punch out the hole on the bigger polygon.
  3. Use the difference function in Spatial Math library to punch out the polygon.
  4. Add the donut polygon to the map. Done. 


Assuming there is an instantiated Bing Maps variable named map...
 Microsoft.Maps.loadModule('Microsoft.Maps.SpatialMath', () =>; {
    const outer = Microsoft.Maps.SpatialMath.getRegularPolygon(map.getCenter(),
                  30, 36, Microsoft.Maps.SpatialMath.DistanceUnits.Kilometers);

    const outerRing = new Microsoft.Maps.Polygon(outer);

    const  inner = Microsoft.Maps.SpatialMath.getRegularPolygon(map.getCenter(), 
                   10, 36, Microsoft.Maps.SpatialMath.DistanceUnits.Kilometers);

    const innerRing = new Microsoft.Maps.Polygon(inner);
    const donut = Microsoft.Maps.SpatialMath.Geometry.difference(outerRing, 


It is surprisingly easy to accomplish holes in polygons - and drawing circles. It is about ten lines of code depending on how you count it. Inside the module, it is in fact six lines that acctually do something.

It is powerful, easy to use and it solves reall world problems, like drawing islands on a lake. Or lakes on islands. 

fredag 20 oktober 2017

What does geometry.toString() mean?


In web development with JavaScript or similar, what is the meaning of geometry.toString()? I was developing a small application and started to think may be it is time to do something more interesting than [object] or Uncaught Not implemented. What if toString() would return the actual string representation of the object? That would make toString() useful.

Since JSON is the natural representation of the object would it  make sense to simple return a stringified GeoJson? I think so. For polygon the implementation would look something as:

Microsoft.Maps.Polygon.prototype.toString = function () {
    var _json = Microsoft.Maps.GeoJson.write(this);
    return JSON.stringify(_json);

Does it make sense? At least it does for me since I can just write geom.toString() when I need to communicate with the server.

Of course there are alternatives to GeoJSON, WKT, well known text for example. I think it would be elegant to just write geometry.toWKT(); Adding it to the module would make sense. While waiting for an update, adding it when the modules callback would look something like:

Microsoft.Maps.loadModule('Microsoft.Maps.WellKnownText', function(){
    Microsoft.Maps.Polygon.prototype.toWKT = function () {
        var wkt = Microsoft.Maps.WellKnownText.write(this);
        return wkt;

What if I could add this suggestions to GitHub issues for modules?

Friday afternoon geo dev thoughts.

Small example implementation;

fredag 8 september 2017

Cognitive routing

A bit background

The last couple of months I have checked out and tried Microsofts preview advanced routing projects. First when it comes to routing it is important to understand there is no rights or wrong. What is the best route? For some it might be:
  • The shortest route?
  • The fastest route?
Those are easy to find. For others they might be?
  • A route with minimun slope?
  • A route with rest areas with parking facilities?
  • The most beautiful route?
  • ... and so on.
So, the best route can be different depending on the purpose of the trip, vehicle and different regulations. So I always keep that in mind when it comes to routing.


So is it cognitive as the URL implies? When I am in the middle of development, it is algorithms and algorithms with predicates. Combining this new routing services with advanced client tools is for sure a powerful tool. Adding historic traffic data to predict calculate routes, isochrones and solving TSP is calculating complicated stuff in short period of time. So the rise of cognitive GIS is coming.

It is at least really powerful and can solve complex problem and will be useful for many organisations.

Down the road

In order to understand what is next I look back to be able to connect the dots ahead. Isochrones is a natural derivat of routing. Although I guess the challenge with an algorithm that is heavily heuristic (which I assume Bing Maps are) is to polish away the heuristic but still be effective to accomplish isochrones. Next in this area would be to calculate things that is n minutes/distances away, but not closer than n unites from a given point as I describes in this post. Another natural evolvement is travelling salesman problem. Natural to integrate into the service module in CRM and may be a Geo-Calendar is on its way from Bellevue/Redmond.  

What to expect?

From a technical perspective I guess this new services will be available in a C# API like the Bing Maps REST Toolkit. That feels like a safe bet. On the client side I would except modules for routing, including the new services.

Another thing I would like to see is that Microsoft truly adapts GeoJson as in every time geographical data is send as JSON - I expect GeoJson.

Moreover, I hope the new services will cover at least Europe as well. If it scales in North America, the hard job with scaling is probably already done.

Thanks to Fredrik Jonsson for illustration.