EPSG:28992, or the Dutch double stereographic RD (RijksDriehoekstelsel) projection, is quite often incompletely or just plain badly defined.

My version of MapServer for Windows (2.2.6 from september last year) states

+proj=stere +lat_0=52.15616055555555 +lon_0=5.38763888888889 +k=0.999908 +x_0=155000 +y_0=463000 +ellps=bessel +units=m +no_defs  no_defs <>

Which yields the following result when a native 28992 dataset is projected onto a Microsoft Virtual Earth (EPSG:900913 or EPSG:3785 as it is now called):

Note that the buildings layer on top of the VE aerial photos is shifted to the north, by about 100 metres.

Spatialreference.org has a slightly different take on EPSG:28992:

+proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889 +k=0.9999079 +x_0=155000 +y_0=463000 +ellps=bessel +units=m +no_defs

which yields an almost identical result:

These projection strings are both incomplete, because they do not take into account the datum shift that is used in the RD projection and can be approximated using the ‘towgs84′ parameter in PROJ4.

The one and only right PROJ4 projection string is

+proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889 +k=0.999908 +x_0=155000 +y_0=463000 +ellps=bessel +units=m +towgs84=565.2369,50.0087,465.658,-0.406857330322398,0.350732676542563,-1.8703473836068,4.0812 +no_defs <>

Links

• Explanation of the towgs84 parameter on this page
• Some discussion about the RD datum shift on the PROJ.4 mailing list
• A non-technical discourse on datum shift and coordinate systems in Dutch.
• The Dutch national survey has a website on the RD coordinate system.
• There is also a very Web 0.5 site on the RD system and NAP (Normaal Amsterdams Peil, the Dutch standard sea water level which can be observed in the Amsterdam City Hall)

I came across yet another tile caching implementation, GeoWebCache, through this article on the Google Open Source blog. It integrates nicely with the Geoserver OGC server, which should make it very easy to set up on a Windows box. So let’s try that.First, we need to get the Java SDK (not the runtime environment) from Sun; Geoserver needs it. An older 1.4.x version will do, but if you start a-fresh, you might as well get the Java 6 SDK from here. Download and install it.

Then we grab a fresh copy of Geoserver from their web site. (direct download link for 1.6.3)

UPDATE 1.6.4 is out, as Mike Pumphrey pointed out already in the comments section. Improved support for the GeoWebCache plug-in is among the new features. Read on for the implications for this guide.

While you’re there, download the GeoWebCachce extension as well.

Unzip the GeoWebCache extension, which comes as a zip file.

Install the Geoserver package. It will try and locate the Java SDK and notify you about it. I don’t think installing in the default location is such a nice solution, so I changed this to c:\geoserver\ instead. The data directory then defaults to c:\geoserver\data_dir which I left like that.

When Geoserver is installed, we need to add all the JAR files that comprise the GeoWebCache extension to C:\geoserver\webapps\geoserver\WEB-INF\lib.

UPDATE The following config file tweak is obsolete as of Geoserver 1.6.4. Only if you want to stick with 1.6.3 or earlier, the following paragraph applies:

We need to make a small manual change to one of the Geoserver config files, web.xml in C:\geoserver\webapps\geoserver\WEB-INF\web.xml. This is described in the extension README:

find

<mime-mapping>

BEFORE, add

<servlet-mapping>
<servlet-name>dispatcher</servlet-name>
<url-pattern>/gwc/*</url-pattern>
</servlet-mapping>

Before we start Geoserver, we are going to change the default admin credentials just to be on the safe side. To do this, we open C:\geoserver\data_dir\security\users.properties and change ‘admin=geoserver’ to ‘admin=[yourpassword]‘.

Now we’re ready to start Geoserver and try to call the tile cache. We’re not going to add our own layers just yet; Geoserver comes with some simple sample data. To stret Geoserver, use the Start Menu entry or call

C:\geoserver\bin\startup.bat

from the Run box or a command line.

This will open a Java command line which should remain opened. The output shown could also be useful when you start hacking the Geoserver configuration. Your Windows firewall could complain about Java, in which case you could ‘Unblock’ Java to allow http access from outside your box.

To confirm that it all works, type

http://localhost:8080/geoserver/

in your browser, which should yield your Geoserver Admin home page (no maps there).

Now type

http://localhost:8080/geoserver/gwc/service/ve?layers=topp:states&quadkey=02

which should yield a Microsoft Virtual Earth tile schema compliant tile:

The last thing I want to do right now is to integrate this into a Microsoft Virtual Earth map client. This is quite well described in the GWC documentation and is dead simple anyway. Basically, you take a barebones VE map client template and add a VETileSourceSpecification:

var tileSourceSpec3 = new VETileSourceSpecification(”GeoserverSample”, “http://martijne:8080/geoserver/gwc/service/ve?quadkey=%4&format=image/png&layers=topp:states”);
tileSourceSpec3.NumServers = 1;
tileSourceSpec3.MinZoomLevel = 1;
tileSourceSpec3.MaxZoomLevel = 16;
tileSourceSpec3.Opacity = 0.3;
tileSourceSpec3.ZIndex = 100;
vemap.AddTileLayer(tileSourceSpec3, true);

You only need to change the server part of the URL in the first line to your computer name (or localhost if you’re only going to access the sample from your own machine).

Next steps

The major disadvantage of Geoserver for me is that it cannot do cascading WMS, although cascading WFS was recently implemented. So I’d like to set up GeoWebCache together with UMN MapServer to be able to do this.

When that’s done, I’d like to do some performance benchmarking and compare it to the Metacarta TileCache solution.

Well, certainly not today, and certainly not soon, but the introduction of georeferenced photos on Google Maps this week will certainly rock the online photo communities’ boat. Sure, there are tons of websites overlaying flickr photos on top of a web map, and most are richer than what Google Maps currently offers. Take for example loc.alize.us, a flickr/Google Maps mashup that has been around for a while. It offers tag filtering, user filtering, and a very nice and clean interface. To top it off, it offers a bookmarklet that integrates georeferencing into flickr.com very nicely. I still use it, although Yahoo Maps, the mapper of choice for Flickr’s mapping needs, of course, has had adequate coverage of the Netherlands for some time now.

But still.. It’s not directly ON Google Maps, which is – at least in Western Europe at this time – the ubiquitous web map. The general public will rarely discover any layer of the geographic web beyond Google Maps and Google Earth. ‘So, if I want my photos to show up on the web, I need to be on Panoramio.’ – Panoramio being the photo sharing community that has been showing off on Google Earth for as long as I can remember, and as from now on Google Maps as well. Panoramio was acquired by Google in May, 2007.

No, I don’t expect a mass flux of flickr users towards Panoramio. The latter will see a good number of new members though, and if Google remains as picky about which photos to display within Maps – I’m still confused as to where this leaves Picasa; I guess the user base is not large enough – Panoramio might become a force to be reckoned with in the online photo community universe.

The Dutch like to live in new, modern homes with a garden front and back. This leaves the country with many a suburban jungle like the one depicted below. This also means steady jobs for surveyors with the commercial mapping companies – and many a free weekend spent mapping for a Dutch OpenStreetMap contributor.

So, although the Netherlands got a huge boost in OpenStreetMap when AND donated its dataset for the Netherlands to the community last year, we need to continue our efforts to keep the free world map up to date. And next Saturday is as good as any, so we are heading towards the ‘Saendelft‘ suburbia project just north of Amsterdam.

Jochen Topfs maps comparison web application shows that we are lagging behind the Big G here:

If you’d like to join, find all relevant info on the Wiki (in Dutch). If you just want to see results, check OpenStreetMap in about a week’s time.

The Microsoft Virtual Earth API lets you add your own tile layer to your VE Map. My colleague StevenO wrote about preparing a suitable TileCache setup. This used to work in both 2D and 3D map modes. Recently, Microsoft introduced the latest version of the API, 6.1, along with a major data upgrade and a new version of the 3D control. A step forward in many respects, but the tile layers will not show up in 3D mode anymore. Let’s investigate. UPDATED 080508 11pm, see below

Let me start out by saying that I did not get the tile layers to display again in the new 3D control, so my preliminary conclusion is that this is a bug (read: feature) in the new VE version. But let me at least reiterate what I’ve tried. I’m also touching on some more general VE API topics that crossed my path.

First, I decided to define as many of the optional parameters for the VETileSourceSpecification as possible. Almost all are optional; only TileSource and ID are required and set in the constructor. I defined the Bounds property, first as a simple VELatLongRectangle (supplying only the top left and bottom right coordinates), that made no difference whatsoever.

As a sidenote: having a GIS background, I can’t really get used to the way a bounding box, or a simple VELatLong point for that matter, are defined. I am used to defining bounding boxes by supplying their bottom-left and top-right points, but the VE API turns that all around and has you supply the top-left and bottom-right points. Those points, in turn, are defined as lat-long instead of long-lat. Does MS do this just to annoy us, or what?

The VELatLongRectangle can also be defined using four points, which is relevant for 3D mode, as you might not be looking straight down and the bounding box of your viewport might not be a rectangle at all. So I tried to define the full rectangle for the Bounds property as well, with no discernible effect:

var bounds = [new VELatLongRectangle(new VELatLong(57,3),new VELatLong(50,7),new VELatLong(57,7),new VELatLong(50,3))];

Zoom Levels

Next up is the MinZoom and MaxZoom properties. When not set, the tile layer will just show up in every zoom level, which is considered to be a possible performance issue. I don’t really see why, as the tiles will be generated by a tile caching mechanism in any decent implementation. I can see that you want to restrict the visibility of your tile layer to certain zoom levels for aesthetic reasons, however.

In 3D mode, zooming is continuous, so I was wondering what the GetZoomLevel() method would return. The SDK documentation states: ‘This method may not give the same value in 3D mode as in 2D mode.’, without elaborating. It must have something to do with the viewport bounding box in 3D being determined by three variables (heading, pitch and distance to the earth) instead of just one in 2D (just the distance). In any case, you can’t expect the zoom level to remain constant when switching between 2D and 3D modes. It does however provide you with an indication of scale to base layer visibility on. Also note that in 3D mode, the GetZoomLevel() returns a single value, whereas the control internally seems to use a more dynamic approach to zoom levels. Notice that when you tilt your view, tiles that are closer to the ‘camera’ location are rendered with more detail than tiles that are nearer the horizon.

To get back on track; still no luck displaying our tile layers in 3D mode. Let’s see what options are left. There are a couple more properties in the VETileSourceSpecification: NumServers, Opacity and ZIndex. Experimenting with those did not yield any results though. ZIndex looked somewhat promising, but whereas changing values does affect layer ordering in 2D, in 3D we still see no custom layers.

API versions

The last thing I tried was reverting to an older API version. The test page I was using only worked with versions 5 and 6, although older versions down to 3 are still supported. IIRC, the custom tile layer functionality was implemented in version 4, but there could be other backward compatibility issues that I don’t want to investigate right now. Anyway, switching to v6 and v5 did not yield any results in what I was actually trying to achieve: to get the custom tile layers to show up.

I asked Johannes Kebeck about this issue, following the VE Technical Briefing that was held this morning. For those just starting in VE API development, as well as for developers already somewhat experienced, sessions with Johannes are a really good introduction. Keep an eye on his blog or the MS Events site for future events. If and when Johannes gets back to me, I’ll update this post.

UPDATE

After having looked into the issue with Johannes Kebeck, we pinpointed the problem: the tile store was served up from a nonstandard port, 8080. Microsoft confirms that fetching tiles from a port other than 80 is disabled in the 3D control, for security reasons. We chose the nonstandard port in order to be able to serve both the VE web application and the tilecache from our VE appliance. Because TileCache prefers an Apache environment and VE an IIS server environment, different port numbers seemed the easy way to accomplish this.

There comes a time for every geo-ict professional to have his first encounter with GML. Most of the time, this is not a pretty sight. Until now, I have managed to steer clear from GML when it comes to actually incorporating it into my own software. But today, this day dawned.

So here’s what I’m going to do.  I’m going to generate .NET classes for the GML 3.2.1 schema. When that’s done, I’ll try and actually read a GML 3.2.1 document and do something remotely useful and relevant with it. The second bit will be for a followup post, most probably.

To get started, we’re going to get the combined schemas in one zip file from http://schemas.opengis.net/SCHEMAS_OPENGIS_NET.zip

Then, we unzip those into a directory, say c:\ogc\

We then navigate to C:\ogc\gml\3.2.1 and open a VS2008 command prompt there.

Now we are all set to startto generate .NET classes using xsd.exe

First try is

xsd.exe gml.xsd /classes

This generates a whole bunch of error messages

Some research into the limitations of xsd.exe reveals that the schemaLocation attribute in an import element is ignored by xsd.exe.

from http://msdn2.microsoft.com/en-us/library/ew6ts9yw.aspx:

For the <import> element, the Xsd.exe tool ignores the schemaLocation attribute, expecting imported files instead as additional command-line arguments.

from http://msdn2.microsoft.com/en-us/library/ms950721.aspx

Q: Why doesn’t XSD.exe support the schemaLocation attribute on imports and includes?

A: The W3C XML Schema recommendation describes this attribute as a hint, which can be ignored by processors that can use alternate means to locate schemas. XSD.exe only uses schemas that are specified through the command line to convert schema A.xsd, which imports schema B.xsd.

xsd.exe /c A.xsd B.xsd

So it turns out we need to specify all schemas referenced using import elements need to be supplied as command line arguments to xsd.exe. That means we need to find all schema files referenced to using import elements in gml.xsd and - cascadingly - in all schema files referenced using include elements. This is one hell of a job which took me about an hour of concentrated gazing at XML schemas to complete.

The reward was an xsd.exe command line that actually worked:

C:\ogc\gml\3.2.1>xsd.exe gml.xsd ..\..\xlink/1.0.0\xlinks.xsd ..\..\iso\19139\20
070417\gmd\gmd.xsd ..\..\iso\19139\20070417\gco\gco.xsd ..\..\iso\19139\20070417
\gss\gss.xsd ..\..\iso\19139\20070417\gts\gts.xsd ..\..\iso\19139\20070417\gsr\g
sr.xsd /classes
Microsoft (R) Xml Schemas/DataTypes support utility
[Microsoft (R) .NET Framework, Version 2.0.50727.1432]
Copyright (C) Microsoft Corporation. All rights reserved.
Writing file 'C:\ogc\gml\3.2.1\gsr.cs'.

C:\ogc\gml\3.2.1>

The proof of the pudding is in the screenshot:

The result is a gml.cs C#.NET class file that we shoul be able to use in an XmlSerializer. More in a future post.

I have been doing some benchmarking in the wake of my TileCache installation ‘endeavor’ of last week (part 1 - part 2). In a series – well, probably two – articles, I will try to provide some insight into the performance of the TileCache – Python – Apache ensemble.

Let me lay out first how I went about getting the results below. I used ab on my MacBook Pro to generate the HTTP requests. ab – or ApacheBench – is an extremely easy to use benchmarking tool, and don’t be fooled by the name, it will benchmark your lighttpd / iis whatever-based server just as happily. I sent the requests to my desktop PC at the office, on which I danced the TileCache / mod_python setup dance I described in earlier posts. The connection was from my home through a VPN tunnel to the office, so it’s sort of remote – at least physically. I set ab to run for one minute for each session.

I wrote (ahem) a short shell script to do various ab sessions, with the following variables:

• using CGI or using mod_python
• the number of concurrent requests

The former is relevant because I want to show how much faster the mod_python solution actually is. I could not find any good numbers on this specifically related to TileCache. The latter is relevant because a tile server will typically receive many concurrent requests, even from a single client. This specifically applies when TileCache is employed as a caching layer between OpenLayers and a WMS server and OpenLayers is configured to cheat your server and fetch multiple tiles at once, as described here.

So now on to the results. I’ll show you some graphs which are visualizations of ab’s CSV output. They show a devision of the total number of requests in percentiles by time (in ms) needed to serve that percentile of the requests.

Note that the graphs are logarithmic (10logn). I did that to ensure optimal visibility of the results - the differences can be small for most of the percentile range, but will spike at the end of the graph.

With 5 concurrent requests:

…10 concurrent requests…

…50…

…and finally even 100 — which is already quite a heavy load, especially for my poor desktop with a single consumer SATA disk:

I’ll write up my thoughts about these results, as well as ideas for further optimization, in a next post shortly. For now, I leave you to think about this yourselves and – just because I like Excel so much – feed you two more graphs to summarize the mod_python and CGI results:

Still to come:

• Analysis of the results shown
• Further optimization techniques (ideas welcome – I’m new at this!)
• Check the log files – were all requests actually served?
• Longer running benchmarks, how does TileCache hold up in the long run?

Being inside a Conrad store in Germany just makes you buy stuff you normally might not. I was in the Hannover branch last Sunday, on the tail of a CeBIT visit, and bought an iPod Touch. And I’m about as close to being in love as you can be with a non-human subject.The iPod Touch got a (paid) software upgrade in January, and now all of a sudden it has a Maps application, and what’s more: Maps has a location button that invokes some magic to determine your location. Without GPS. This magic is courtesy of Skyhook Wireless and uses the broadcast signals of WiFi access points to triangulate your location. It’s called WPS, WiFi Positioning System.This video is a very good high level introduction to the technology. Skyhook has an introductory page about the technology as well Let me summarize the key pluses and minuses.

• Unlike GPS, WPS functions well indoors and in densely built up areas.
• Location is determined extremely fast when compared to GPS, typically in <1sec.
• No extra hardware is needed, a 802.11 network interface and antenna suffice.
• Reliance on WiFi access points means no WiFi, no location: rural areas and water bodies are out.
• Service coverage is dependent on Skyhook expansion policy: they decide what’s good for us.
• There’s no two-way communication to help Skyhook improve the database.

The coverage of the service is by its nature limited to urban areas. The mapplet on this page shows the current coverage visually. Coverage in the Netherlands is limited to Amsterdam and part of Rotterdam. For Western Europe in general, you could say that the larger built up areas are covered. Skyhook:

WPS currently provides coverage to 70% of the American, Canadian, and Australian populations. By the end of March 2008, Skyhook will have coverage in the top 50 metropolitan areas of Europe as well as cities and towns representing 50% of the UK, French and German markets.  

Skyhook can and will work with partners and customers to add new coverage areas, or to accelerate expansion into planned areas, in support of mutual commercial opportunities.

Well, that’s all marketing bla-bla – what they really should do is open up their database for user submissions. Sure, you can submit an individual access point through the Skyhook web site, but that’s a far cry from an automated harvesting application. All the basic ingredients are there: The iPhone SDK, the Skyhook SDK, and a large user base. A quick look at the Skyhook SDK tells me it’s just about getting a location; I see no functions to submit any kind of feedback - harvesting results - to Skyhook.All in all it’s a start, and part of me is happy to be done with the sub-par performance of GPS in built-up areas. A slightly bigger part of me longs for a solution based on open, user generated content. For the iPhone, the Antenneregister – a government-maintained registry of all GSM and UMTS cell towers in the Netherlands – is promising. The database is right there on their web site: more than 23.000 geocoded cell towers. The only thing that’s missing is ther cellID… Automated harvesting of cell tower data is nothing new either, here’s an implementation called IYOUIT that harvests for a worldwide cell tower database (Google Earth network link) initiated by the Telematica Institute. Further reading aplenty.

The 5 minute install guide for TileCache on Windows I wrote last weekend was intended to show how easy it is to get a TileCache map server up and running. Now that it works, we should be concerned with performance. As my colleague StevenO pointed out, a CGI solution is probably not the way to go if you want to take it to production level. So I decided to try a different approach: install TileCache as a module into the local Python setup and have mod_python handle the python scripts of which TileCache is made up directly. That way, we can dispose of the CGI wrapper and thus the need to call the python interpreter for every tile request being made by the client. In theory, that should give us a huge performance gain.I’m going to look into two topics:

1. Getting TileCache to run under mod_python
2. Benchmarking TileCache and more optimazition techniques

The first topic will be covered in this post, the second in a future post.Getting TileCache to run under mod_pythonI’m going to assume we have a Apache / TileCache setup like the one we ended up with in the 5 minute install guide I wrote. If you’re not there yet and want to follow my lead, I suggest you read that one first. It will only take 5 minutes :)These are the steps to take to set it up:

• Get the mod_python installer (direct download link - always check the site for the latest version)
• Run the installer. At one point it may ask you to locate your Apache installation. Point it to C:\Program Files\Apache Software Foundation\Apache2.2\
• When the installer is done, locate the main Apache configuration file, which is in C:\Program Files\Apache Software Foundation\Apache2.2\conf\, and open it in your favourite text editor. No, not in Word. In this file, find the group of LoadModule directives and paste this line at the bottom:

LoadModule python_module modules/mod_python.so

• While you’re there, add the Directory directive for the TileCache dir:

# THIS IS FOR TILECACHE UNDER MOD_PYTHON
<Directory /Program Files/Apache Software Foundation/Apache2.2/htdocs/tilecache/>
	AddHandler python-program .py
	PythonHandler TileCache.Service
	PythonOption TileCacheConfig C:/Program Files/Apache Software Foundation/Apache2.2/htdocs/tilecache/tilecache.cfg
</Directory>

• Don’t worry careful reader, we will create this directory now: go to C:\Program Files\Apache Software Foundation\Apache2.2\htdocs and create a directory ’tilecache’ in there.
• Extract tilecache-2.0.tar.gz (I assume you still have it from the first episode) in that directory.
• Now we’re going to install TileCache in Python . Open C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\tilecache\setup.py in your text editor and change line 33 to

data_files=['tilecache.cfg'],

• Save and close the file.

• Now open a DOS box and cd to C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\tilecache\ and execute the following line:

c:\python25\python.exe setup.py install

Now Python knows about TileCache and we’re good to go - as soon as we restarted Apache to make it aware of the config file changes. You can do so by invoking the restart script from the start menu or from C:\Program Files\Apache Software Foundation\Apache2.2\bin\ApacheMonitor.exeTo test the new mod_python setup, try

http://localhost/tilecache/tilecache.py/1.0.0/basic/0/0/0.png

This should give you a tile. If it doesn’t, read more carefully. If it still doesn’t, come and beat me at foosball - you’ll find that not too hard.

UPDATE –> I got it fixed in the end. See bottom.

Silverlight 2 beta 1 is out. I’m excited about the DeepZoom / SeaDragon technology making its way into this first beta! If you haven’t seen it, have a look at Blaise Aguera y Arcas’ presentation at TED 2007 and see it in action at the Hard Rock Memorabilia site that got some attention at MIX08. There’s a few things to install to get started developing Silverlight 2 applications:

• The Silverlight 2 beta 1 runtime.
• The SDK
• The Visual Studio 2008 toolkit

Installing the toolkit gave me some trouble I have yet to solve:

So let’s see:

• I have VS2008 (not RTM though, the actual release version), CHECK!
• Web Authoring compent installed, CHECK!
• No old runtime of Silverlight hanging around, CHECK!
• No previous version of the SDK installed, CHECK!
• No KB949325, CHECK!
• No previous version of tools, CH…oops!

I do have this:

But I can’t seem to get rid of it!

It appears I’m not the only one encountering this. I’m not 100% sure the 1.0 Template installation blocks the VS2008 Silverlight 2 tools installation, but I have a good feeling it does.

UPDATEHere’s what needs to be done to get is working:

• Uninstall everything that appears in the Add/Remove Programs list that has the name Silverlight in it. Except for the VS2005 templates, which you apparently cannot uninstall if you no longer have VS2005.
• Get the Silverlight 2 Beta 1 Runtime and install.
• Get the Silverlight 2 Tools for VS2008 and install.

Now that was not so hard after all, was it?