Paul says Hi!

Projecting from WGS84 to SphericalMercator

noreply@blogger.com (Paul den Dulk) — Sat, 23 Apr 2011 07:52:00 +0000

Projecting from one coordinate system to another is a big topic in the geo bizz. Most apps use comprehensive libraries to deal with all possible projections. These days 90% of the projections that I see are from WGS84 to SphericalMercator. Mostly this is GPS coordinates projected to a Google, Bing or OpenStreetMap tile background. If you would like to keep it simple the code below would suffice (Thanks to Steven Fruijtier for sharing the code).


using System;
using SharpMap.Geometries;

namespace Projection
{
    public static class SphericalMercator
    {
        private readonly static double radius = 6378137;
        private static double D2R = Math.PI / 180;
        private static double HALF_PI = Math.PI / 2;

        public static Point FromLonLat(double lon, double lat)
        {
            double lonRadians = (D2R * lon);
            double latRadians = (D2R * lat);

            double x = radius * lonRadians;
            double y = radius * Math.Log(Math.Tan(Math.PI * 0.25 + latRadians * 0.5));

            return new Point((float)x, (float)y);
        }

        public static Point ToLonLat(double x, double y)
        {
            double ts;
            ts = Math.Exp(-y / (radius));
            double latRadians = HALF_PI - 2 * Math.Atan(ts);

            double lonRadians = x / (radius);

            double lon = (lonRadians / D2R);
            double lat = (latRadians / D2R);

            return new Point((float)lon, (float)lat);
        }
    }
}

Tile schema compatibility

noreply@blogger.com (Paul den Dulk) — Wed, 28 Apr 2010 21:12:00 +0000

How easy is it to combine different tile services in one map? For instance, how easy is it to combine Google Maps aerial photos with a roads overlay from a TMS. Well this depends on two things, 1) how smart is the client, and 2) how compatible are the tile schemas. Here we look at several levels of compatibility taking the TMS specification as an example.

In TMS a tile schema is described in a TileMap. The main parameters involved are:

Origin: the coordinate where the first tile starts. It is the bottom left corner of tile (0, 0).
BoundingBox: the extent in which tiles are available. The BoudingBox's bottom left coordinate is often identical to the origin but doesn't have to be.
TileSets (levels): a list of the available tile levels and their resolutions.

1) The same

Okay, lets keep this short, sometimes the schema's are just the same.

2) In the same tile system

When the BoundingBox's are different but the Origin and TileSets are the same a tile in one schema will have the same x ,y and level as it's corresponding tile in the other schema. The only difference between the schema's is that some tiles can be available in one scheme but not in the other.

The two schemas can be said to be in the same tile system. If the TileSets are perceives as a Z-axis it forms a kind of three dimensional coordinate system for tiles. The origin of that space is defined by Origin.X, Origin.Y and the resolution of the first TileSet. The steps are defined by the tile width, tile height, the step size between resolutions (which can be irregular to complicate things).

3) Project to another tile system

When the tile system differs it is sometimes possible to transform a tile in one tile system to the other tile system. For instance when in one schema the Y-Axis is inverted with respect to the other it is easy to see how tile (0, 0) can be mapped to tile (0, count - 1). Such a trick is sometimes used in simple cases. I have not seen it done for more complicated relations.

4) Project to the map

When all parameters are different it is still possible to simply project the tiles to the map canvas not one tile onto another. The price is that you have to do this for every tile layer separately. This can hit performance and might consume more memory because more tile layers and possibly image containers will be needed (depending on your client).

Porting SharpMap to Silverlight - first attempts

noreply@blogger.com (Paul den Dulk) — Wed, 07 Apr 2010 11:34:00 +0000

Over the last week I spend some time porting open source GIS library SharpMap V1 to Silverlight. My intent was to go straight towards a working version in the easiest and quickest way and try to suppress my urge to redesign. Below is how I worked through it. It might be relevant for those who have to do a similar port.

First, I removed all the files that I didn't need. I included only those that I needed to retrieve data (shapefiles) and render a map.

System.Drawing
Silverlight has no System.Drawing (GDI), so my next goal was to move this into a separate dll while maintaining all functionality. I created an IRenderer interface in SharpMap and used the existing GDI rendering for the implementation. I put this in a separate assembly called GdiRendering.dll.

The IStyle class in SharpMap also depended on System.Drawing. I replaced all the System.Drawing classes in IStyle with implementation independent classes. These were converted to System.Drawing classes in the GdiRenderer.

For raster renderers there was no separation between data retrieval and rendering at all. So I introduced an IRasterProvider and an IRaster class. In the GdiRenderer this IRaster type was treated in the same way as the geometry types.

At that point all GDI was contained in the GdiRenderer.dll and I could remove the System.Drawing dll from SharpMap. Everything worked like at the start. There was no WPF or Silverlight yet.

System.Data
Next was System.Data. There is none in Silverlight, so no DataTable or DataRow, yet the IProvider interface heavily depends on it. I spend some time looking for a good solution here. I was expecting to find some simple grid-like data structure, but I ended up using a List of FeatureDataRow for the table and derived FeatureDataRow from Dictionary. The downside here is there is no restriction on adding columns, you could add anything you like to it. I am open for better (and simple) solutions.

System.Xml
With that settled I was about to set up a Silverlight data provider so I could start on my SilverlightRendering.dll. But which provider? It turns out that the current SharpMap data providers fall in into three categories:

Raster. This would work just fine but my purpose was to implement vector rendering to SL, I had raster already working in BruTile.
Vectors read from db or file. This is not allowed from the SL sandbox.
Vectors retrieved from web. That's what I need but it turns out they all depend on XmlDocument which is not part of Silverlight.

I worked around this problem by using WPF rendering and a file based data provider. I created two project files for my SilverlightRendering.dll, one SL, one WPF, that share the same files. I developed my renderer using the WPF version. So far I have only compiled my SL version, I have yet to find out if it actually works.

Finally Rendering
With the WPF version of the SilverlightRendering.dll I managed to render Points, MultiPoints, LineStrings, MultiLineStrings, Polygons and MultiPolygons. I was happy to see that it is also possible to render Polygons with holes, this could have been a been a show stopper for a proper gis lib. The renderer currently ignores projections but there is a Silverlight version of proj.net on http://projnet.codeplex.com.

So far it seems there are not many complications. I am currently investigating how I could use System.Data for the file and db data providers, while having a System.Data free Silverlight version. I believe it is possible to also support WPF and WinForms without too much maintenance. Support for Windows Phone 7 should be easy.

BruTile's async tile fetcher

noreply@blogger.com (Paul den Dulk) — Sun, 07 Feb 2010 20:24:00 +0000

This morning I had some time to play around with powerpoint. Below is a diagram depicting how BruTile's tile fetcher works. The tile fetcher runs on a worker thread and fetches tiles from the web or the disk. The idea behind its setup was that the direct communication between the UI thread and the fetcher thread would be minimized. The only direct communication is a ViewChanged call to the fetcher, telling it the user is panning or zooming and a DataChanged callback telling the UI it should render. The fetcher dumps incoming tiles into the MemoryCache, which is just a big bag of tiles. The UI renderer retrieves whichever tiles it needs.

Both the fetcher and the renderer can use all kinds of smart tricks. The fetcher can pre-fetch tiles based on its current view, or on the way the view changes over time. The renderer could search for alternative tiles (higher or lower levels) when the optimal tiles are not available. Those strategies should be tuned to support each other. For instance, in the current implementation the renderer uses higher level tiles when the optimal tiles are not available, and the fetcher pre-fetches higher level tiles to assist the renderer. But the way they play together is not specified in the interface. This loose coupling keeps things simple and flexible and the renderer never has to wait for the fetcher which results in a smooth (perceived) performance.

BruTile demo updated

noreply@blogger.com (Paul den Dulk) — Sun, 07 Feb 2010 17:55:00 +0000

A new version of Tim Ebben's Silverlight demo is up.

New features:

Fullscreen mode
Auto resize of map window
Bounding box zoom by using ctrl or 'bbox zoom' button.
Address finder using Tiny Geocoder

go have a look.

ArcBruTile released

noreply@blogger.com (Paul den Dulk) — Sun, 31 Jan 2010 13:35:00 +0000

Last week Bert Temme released ArcBruTile 0.1.6. This is a plugin for ArcGIS which uses BruTile to show tile layers in ArcGIS. This allows for an easy way to show openstreetmap data in ArcGIS which became very relevant due to it use in the Haiti crisis.

What I like so much about ArcBruTile is that it is connecting OSS to the ESRI/Microsoft world. That was one of the purposes we had in mind when creating BruTile and this is the perfect example. An added bonus is that we can now use the projection capabilities in ArcGIS on our tile layers, something that won't be possible with our C# OSS tools soon.

new BruTile Silverlight demo

noreply@blogger.com (Paul den Dulk) — Sat, 26 Dec 2009 11:09:00 +0000

This month Tim Ebben created a very nce new Silverlight demo. We have put a live demo here

BruTile Silverlight

noreply@blogger.com (Paul den Dulk) — Sat, 22 Aug 2009 12:02:00 +0000

I added a POC of BruTile in Silverlight, and now I need a site to host the demo in, and why not do it right here:

Update: I added animated zoom.

Update2: The hosting site, http://silverlight.live.com/ has ended its services. We have looked at Azure for an alternative, but unfortunately they offer only paid hosting. Our most recent demo is hosted at google app engine instead.

BruTile on Surface progress

noreply@blogger.com (Paul den Dulk) — Sat, 13 Jun 2009 21:40:00 +0000

Great to see the Microsoft Surface blog mentioning the BruTile library. It refers to my previous blog about our very first experience with the Surface back in februari. I am happy to say that since then the Surface team at Geodan has made a lot of progress building an application for disaster management as part of our Eagle suite.

The movie below demonstrates some of its capabilities. Apart from BruTile it uses the ERSI WPF controls and Bing Maps 3D as a secondary perspective.

BruTile on the Microsoft Surface

noreply@blogger.com (Paul den Dulk) — Wed, 18 Feb 2009 09:12:00 +0000

Last month I had the fortune to work on one of the first Surfaces shipped to Europe. To test the Surface SDK we wrote a basic map application with pan an zoom through touch.

Using the Surface SDK's ScatterView control it was very easy to get some touch controlled objects on the app, like a layer control. For panning and zooming we had to do a little bit more work, since we are not moving the map control itself but need to redraw the content instead. For this purpose the SDK provides the ManipulationProcessor. It is a little bit more coding but the documentation explains nicely how to do it. To top it off we added a little throw effect using the InertiaProcessor.

Our first meeting with the Surface was very enjoyable. The SDK met all our needs so far. Here is a little movie colleagues Steven and Martijn made of our first app.

BruTile tiling library

noreply@blogger.com (Paul den Dulk) — Wed, 18 Feb 2009 08:53:00 +0000

Tiling is a way to store raster data as image tiles on a server so that they can be quickly retrieved by a client application. Examples of GIS clients that use tiling are Google Maps, Virtual Earth and OpenLayers. The tiles themselves are really just images sitting on a server, like this one.

A while back I added tiling functionality to SharpMapV1. Last month I extracted the tiling code to put it into a separate library, BruTile (LGPL), so it can be reused in other projects, like SharpMapV2.

With the BruTile library you can define the way the tiles are stored on the server (the TileSchema), request which tiles you need to fill a particular boundingbox up with tiles, and then retrieve those tiles from the server with a properly formatted request string. The rendering of the tiles is up to the client application. There are various protocols to store and retrieve tiles. The current implementation of BruTile only supports the Tms and WmsC protocol. I hope to support more protocols in the future like the OGC's Wmts and Microsoft's Virtual Earth protocol.

In the following example I describe how to draw a map onto a WinForms form using tiles.The sample uses the OpenStreetMap tile server which uses the Tms protocol. The result is the form below, no further interaction with the map is possible.

First some prerequisites. To do rendering in WinForms you need to override the OnPaint


protected override void OnPaint(PaintEventArgs e)
{
e.Graphics.DrawImage(buffer, 0, 0);
}

In it we draw a bitmap buffer onto the window. This bitmap is initialized to the window's size in the constructor.


buffer = new Bitmap(this.Width, this.Height);

Everything else is done in the Load method. First a Transform class is created. This is used to calculate from screen positions to world coordinates and back. It is initialized to a center point somewhere in the Netherlands, a resolution wide enough to show the whole of the netherlands, and the width and height of the window. The transform class is not part of BruTile itself because something similar is already part of most GIS libraries.


Transform transform = new Transform(new PointF(629816f, 6805085f), 1222.992452344f, this.Width, this.Height);

Next you need to define how the tiles on the server are stored. The tile scheme needs a lot of information. Luckily the Tms service publishes this information. In future versions of BruTile I would like to automatically parse this info so it need not be specified on the client. So here I wont go into detail about what it all means.


private ITileSchema CreateTileSchema()
{

  double[] resolutions = new double[] {     
   156543.033900000, 78271.516950000, 39135.758475000, 19567.879237500, 9783.939618750,     
   4891.969809375, 2445.984904688, 1222.992452344, 611.496226172, 305.748113086,     
   152.874056543, 76.437028271, 38.218514136, 19.109257068, 9.554628534, 4.777314267,    
   2.388657133, 1.194328567, 0.597164283};

  TileSchema schema = new TileSchema();

  schema.Name = "OpenStreetMap";
 foreach (float resolution in resolutions) schema.Resolutions.Add(resolution);
 schema.OriginX = -20037508.342789;
 schema.OriginY = 20037508.342789;
 schema.Axis = AxisDirection.InvertedY;
 schema.Extent = new Extent(-20037508.342789, -20037508.342789, 20037508.342789, 20037508.342789);
 schema.Height = 256;
 schema.Width = 256;
 schema.Format = "png";
 schema.Srs = "EPSG:900913";
 return schema;
}

Now you can request which tiles you need to fill up the entire view


ITileSchema schema = CreateTileSchema();
IList<TileInfo> tiles = Tile.GetTiles(schema, transform.Extent, transform.Resolution);

Next you need to specify the RequestBuilder to use. In this case you need the RequestTms class because of the Tms protocol. As arguments you need to pass the url of the OpenStreetMap tile service and the format in which the tiles are stored.


IRequestBuilder requestBuilder = new RequestTms(new Uri("http://a.tile.openstreetmap.org"), "png");

Finally we can request all tiles from the server and render them to our buffer Bitmap.


Graphics graphics = Graphics.FromImage(buffer);
foreach (TileInfo tile in tiles)
{
  Uri url = requestBuilder.GetUrl(tile);
  byte[] bytes = ImageRequest.GetImageFromServer(url);
  Bitmap bitmap = new Bitmap(new MemoryStream(bytes));
  graphics.DrawImage(bitmap, transform.WorldToMap(tile.Extent.MinX, tile.Extent.MinY, tile.Extent.MaxX, tile.Extent.MaxY));
}

The sample code above is part of the BruTile project on codeplex. The solution also includes a WPF project which demonstrates how to get a nice user experience with tile requests on a background thread and rendering tiles at the moment they arrive.

Crayon Phycis Deluxe Released

noreply@blogger.com (Paul den Dulk) — Thu, 15 Jan 2009 14:21:00 +0000

Hey look, The official version of Crayon Physics Deluxe has been released last week:

http://www.crayonphysics.com/

Downloading the demo right now.

Crayon Physics

noreply@blogger.com (Paul den Dulk) — Mon, 17 Mar 2008 20:35:00 +0000

This is just so cool! First look at the video, then think 'wow this guy makes it look so awesome', then download the prototype and find out it really is so awesome, and then start to think of all the cool stuff you yourself should do with such simple technology.

Apparently the full version, Crayon Physics Deluxe, will use the Farseer engine, which works with XNA and Silverlight. I really need to check that out because there are so many ideas I need to try out right now. Airhockey on the TouchTable being the first one.

The Target

noreply@blogger.com (Paul den Dulk) — Sat, 24 Nov 2007 14:53:00 +0000

Played location based game The Target in Utrecht last sunday. And the news is, it is a real location based game, it works and it is fun.

The Target is played with 4 nokias with gps. Each nokia is manned with a team of 2 or 3 players. One team is the target, the others are agents hunting for it. To win the target has to collect one million by stealing money at several predefined locations over town. The agents have to catch the target to prevent it.

The game designers did a nice job keeping the game very simple yet fun. The players have a shoot button with which they can kill the enemy when within a certain range. Further, they can collect several types of items (e.g. knife, lorry, ladder) which are placed on several spots over town. With those items they can robe money at other locations. But for each robbery a different combination of items is needed. When the target takes an item the agents get a message stating which item was taken. But because every item can be found at a number of different locations it leaves a number of alternatives. In practice the agents spend a lot of time guessing where the target is, what he is up too, and which items he will go for next. At some interval the agent and target also get the know the exact position of their opponents.

The good things about this game are:
- Simple user interface. The user controls the game mostly through the way they move over town. You can make choices by walking to specific location on the map, with little need for buttons.
- The playing area is a fixed square in the center of town. This is represented with a fixed map on the Nokia. Although you can zoom into each of the 16 parts of the map this is not really necessary. This keeps it simple.
- Partial information about what is going on. The concept of the items needed for a robbery is great. It leaves enough room for guessing and enough information to make a fair guess.
- You rent the game for 2 hours actual playing. The game keeps track of the time so it only measure actual playing time and you do not have to worry about when to bring it back.

Not so good:
- It is basically a running game. Real fast runners will do best. I can imagine that for some people this is too demanding. You need players with a sports mentality. We happened to have a number of those in our group but even for them it took some effort to get into sports mode on a cold day walking around in heavy clothing. I would love to play this game again on a sunny day dressed in my running outfit.
- When an agent is far removed from the target the game is not so interesting anymore. It becomes harder to motivate oneself for running. Maybe the agent should have some alternative things to do in those cases.

Code Conventions

noreply@blogger.com (Paul den Dulk) — Wed, 31 Oct 2007 00:08:00 +0000

The main reason to have code conventions within your developers group is that it can stop the discussion about code conventions. For some reason those discussions never converge on mutual agreement. In my environment the topic has not come up for a while, I like to keep it that way, but secretly I try to stick to some my own code conventions.

I have been following these rules

1) If you work on existing code adopt whatever conventions they seem to be using
2) If code conventions differ from file to file use the conventions of that file don't work toward conventions throughout the library.
3) If you start anything new, go with the flow. Do whatever the majority is doing (spaces not tabs) or what big guys do (for c# I try to stick to the Microsofts guidelines, see this too).
4) If for some (maybe good) reason you defer from the convention, do not invent a rule why you did this, just say you were lazy.

BTW, so please don't tell anyone this, because it could start the discussion again.

Welcome

noreply@blogger.com (Paul den Dulk) — Sat, 09 Dec 2006 15:44:00 +0000

Hi, Welcome to my new blog!

Paul