In 2007 (that is 3 years ago!) Blaise Aguera y Arcas, along with Microsoft, astonished us by presenting the Seadragon and Photosynth technology. It was, and still is very very impressing and embedded below.

On this years TED conference he was at it again – and – astonishing everyone again with an augmented reality “intelligent” map application. It is amazing what his team manage to develop!

The obvious competitor is Google Maps which probably has a better grip at the market. However, Google does not compete at all with the technology presented at TED – although they do have more users – and maybe an easier solution fitting more users?

Anyway – watch the talks if you haven’t yet.

Ever found yourself struggling to figure out the bus routes when you are planning to get from A to B?

Obscure bus stop names are almost a de-facto standard, at least in Norway – and quite often they do not have a name (or any other identifier) at all. Even if you know the bus stop name from where you are going to take the bus and the destination, you don’t always know where these stops are.

In Trondheim a natural language system has been developed called BussTUC (Buss The Understanding Computer) or more commonly “Bus Oracle”. Here you can write, in natural language, a question about bus routes. I.e. “When is the next bus from busStopA to busStopB?” and similar. The answer is quite good, and is correct according to the current routes.

However, the problem occurs when you don’t know the bus stop name – but you know where you want to travel, or approximately where you want to travel.

To better fit this Atle and I developed a prototype of a map interface to BussTUC. In essence it is a map where you can click where you are and where you want to go. The system then finds the nearest bus stops to this and suggest the closest, all represented visually in the map. While using the map interface to input where you want to go, suggestions of relevant query to BussTUC are suggested – and a link to submit the query is provided.

The system currently knows about almost all bus stops provided by Team Trafikk and works quite well.

Extensions to the system are:

• Enable for mobile devices – primarily location-enabled devices
• Add the spatial route-data suggested by BussTUC in the map (i.e. draw the actual route)
• Speed up BussTUC or develop own route suggestion system based solely on spatial information

Suggested improvements (numbered for identification purposes only):

1. Display all nearest markers regardless of selected (emphasize the one selected) [Thanks to anders]
2. Enable user to define “near” using circle (or similar + visual representation
3. On the fly display of near markers when hovering mouse (i.e. indicate what to expect from query)
4. Enable user to config how many markers to display near a point
5. Clustering/star-shaping overlapping markers (ClusterMarker)
6. Visual-magnifier over selected areas (i.e. similar to: Map Magnifier)
7. Retain simplicity of system, regardless of functionality (i.e. enable configuration)
8. Release Open Source (CC, Public Domain, limited license?) [Atle, Magnus]

The system is developed in PHP, JavaScript with a PostGIS enabled database. Source code is available by contacting me or Atle. Give it a try and give some feedback!

http://geomatikk.eksplisitt.net/atle/buss/

Screenshot of BussTUC map interface

The system is (unfortunately) not affiliated with Team Trafikk and is a prototype not designed to scale very good.

Finally the promised follow-up to the post on data modelling in PostGIS. In this post I will cover how I populated the database using a graphical tool called uDig.

uDig is actually a (lightweight) GIS-tool by the same guys which make PostGIS. It supports for editing and analysis of spatial data. I actually don’t know that much about uDig, but it is easy to use, and fulfilled my needs:)

So. What I needed was to draw polygons from a floor plan. The floor plan was in .jpg format, so useless to “import” directly in the database. So I needed to georefer the floor plan “photo” and draw on top of it. Fairly similar to old map making techniques using aerial photographies to make “abstract” maps.

First the georeferencing. The actual coordinate system and extent of the floor plan wasn’t actually that important. It was nice if it started close to (0,0) and had some extent (and of course scaled 1:1).  Convinced (but not certain) that uDig could handle this I set of and tried to add a layer using Layer-Add .. files and selecting the .jpg file. However that resulted in some obscure error saying; “unrecognized service…” Well, off to Google. After some searching I found that for .jpg’s to be added in uDig, they first need to be georeferenced. To me that sounds a bit strange, as one might want to actually do just this in a GIS tool. So after some more searching I discovered that one could “manually” rough-georeference a .jpg using the world-file format, named .jgw – which in essence; locks one coordinate of the image to a geo-coordinate and defines the extent of the pixels on both axis. So I guessed somewhat on the parameters and came up with a .jgw. And add layer in uDig worked like a charm.

Floor map image in uDig

Secondly I needed to connect to my PostGIS database. This is very, very easy, as expected, since the two softwares are made by the same “team”. Just add layer -> PostGIS -> Type in credentials -> Select tables and you’re off:)

Add layers from a PostGIS database

Then it was time to edit/draw/insert data into the PostGIS database. This is fairly intuitive. I found that enabling “snapping” is very useful, and quite good implementation of this feature in uDig also. However, you need to enable it: “window->preferences->tool->edit tool->snap behaviour” Why hide this? Well, maybe not everyone are interested.. Anyway. Here you can set the snap behaviour and radius to whatever suits your need. I choose “all layers” and found it working surprisingly well on drawing the “route graph” which consists of several “connected” lines.

Enabling snapping in uDig

After some editing the data looked somewhat like this:

Inserted data

Of course the entities (i.e. rows in the DB) have other properties other than their geographic extent. And uDig provides an editor to enable direct editing of these properties. However…. This is where you really experience the short-comings of an open-source, “experimental” GIS-tool.. Not all editors are in place, such as BigDecimal. This is OK, as it is a minor thing and not that much of use. However, when the table has constraints, such as “NOT NULL”, then uDig just breaks, no errors, no confirms, no notices of what is going on. A bit disappointing. Additionally when editing, often the data isn’t commited properly to the database, and some error (again no messages) occurs. Resulting in the layer can’t be rendered and you need to remove it from uDig and add it from the database again. Luckily this isn’t a complex process though:) But a bit annoying. I ended up with using PgAdmin for the non-spatial data management and uDig solely for the spatial data. Which worked quite well despite the annoyancies.

My task was fairly non-complex, for larger tasks I wouldn’t rely on uDig – yet. However the simplicity of the tool is attracting! And for easy, lightweight tasks it is perfect:)