Tag Archives: Spatial Data Infrastructure

Phoenix is finished

After several years of doing research with touch tables and GIS we’ve finally build an application which is so intuitive that even children can use it:

YouTube Preview Image

This application (Phoenix) is a spatial discussion platform where people can discuss issues while standing around an interactive map. Different ideas we have tried out in earlier prototypes have been polished into a consistent application which is extendible with plugins. I made a teaser movie for those who are not in the neighbourhood to play with it themselves:

YouTube Preview Image

 

 

Dynamic pie-charts

Spatial data traditionally has been displayed using maps and tables. Maps, though good in showing the spatial extent, are not always optimal in showing aggregated data. The human mind can easily be tricked into believing that a bigger country has a bigger share of the pie. Tables show the individual records, but still lack the overview of aggregated data, also tables are notoriously hard to read.

To view the information in an aggregated form one has to build complex queries. These are often slow and do not scale well and the user either has to interpret the resulting map or compare numbers in a table. The first being not very precise the second not very intuitive.

Within EuroGeoSource, a cross European project that allows users to identify, access, use and reuse aggregated geographical information on geo energy and mineral resources, we have come up with a new way. The users are not typical GIS experts and do not have the knowledge to build custom spatial queries. Instead we have determined the most important types of aggregation (eg. by country, by deposit-type etc).

The user can search for one or more commodities. Using MapQuery and gRaphael, an SVG chart library, we than present these commodities aggregated in (pie) charts. He can use the charts as a selection method, for instance by clicking on a country he will see all the occurrences of the commodity in that country on the map.

The result is a fast and intuitive way to search for aggregated data. Providing overview on the distribution of data in multiple domains and still giving access to detailed data in a traditional GIS manner.

Spatial data traditionally has been displayed using maps and tables. Maps, though good in showing the spatial extent, are not always optimal in showing aggregated data. The human mind can easily be tricked into believing that a bigger country has a bigger share of the pie. Tables show the individual records, but still lack the overview of aggregated data, also tables are notoriously hard to read.

To view the information in an aggregated form one has to build complex queries. These are often slow and do not scale well and the user either has to interpret the resulting map or compare numbers in a table. The first being not very precise the second not very intuitive.

Within EuroGeoSource, a cross European project that allows users to identify, access, use and reuse aggregated geographical information on geo energy and mineral resources, we have come up with a new way. The users are not typical GIS experts and do not have the knowledge to build custom spatial queries. Instead we have determined the most important types of aggregation (eg. by country, by deposit-type etc).

The user can search for one or more commodities. Using MapQuery and gRaphael, an SVG chart library, we than present these commodities aggregated in (pie) charts. He can use the charts as a selection method, for instance by clicking on a country he will see all the occurrences of the commodity in that country on the map.

The result is a fast and intuitive way to search for aggregated data. Providing overview on the distribution of data in multiple domains and still giving access to detailed data in a traditional GIS manner.
DSC_0187

Wiekwiek

Climate models have several scenario’s to calculate different futures, depending on some starting parameters. The outcomes of these scenario’s can be visualized with maps. Comparing maps of the same variable in different scenario’s is one way to quickly grasp the impact of the starting parameters.

We’ve build a tool for the Surface to browse these different maps with a flick of the wrist: the wiekwiek. You select a variable from the list and a map showing the current situation is shown. By turning the wiekwiek one can display the different scenario’s and visually compare the impact of a scenario.

YouTube Preview Image

WPVS

The past three years we’ve been involved in the Tripod project. The goal of Tripod is to create new, easy, ways to find visual media. One of the approaches is to use the geographic metadata stored with pictures nowadays to figure out what is on that picture. Once you know what is on a picture, you could search for instance for ‘Stephanskirche’ and get pictures of that particular church, even without users manually adding tags or captions.

The available metadata of photos is increasing with the number of sensors available in cameras. Already all digital cameras record the focal length, aperture and such. Using information from GPS, compass and accelerometer sensors you can also include the location, direction and roll, pitch, yaw of the photo. With this information you can recreate the photo in a 3D environment. If you have geodata available in that 3D environment, you can return information of the visible features.

Take for instance this picture:

We know the location and the direction of the picture. With a simple GIS operation you can find out that the picture is taken in Bamberg, Germany. However you don’t yet know what’s in the picture. For a start the actual picture is shot at the ‘Obere Seelgasse’, which is two streets away from the church. Also the area is both urban and hilly. This means that you could either see a house in that particular street, or a hill nearby, both blocking the view of the church.

So you need to do a 3D analysis of the image. We have a detailed 3D model of Bamberg and a digital terrain model to be able to calculate which features are in the view. To do this we use the Web Perspective View Service (WPVS) from deegree. This is a proposed OGC standard which allows us to both render a perspective view given location, orientation and field of view and to query geo-databases using locations on the photo.

Using the WPVS we get this image:

WPVS view of the Stephanskirche

For automatic identification, it is easier if each building has one color, this way we can calculate the area occupied by a specific building. So we had to uglyfy the image by removing anti-aliasing and shading. We wrote a service called the Feature Identification Service (FIS) which, given a georeferenced photo, will determine the most prominent features and return a list of visible features. In this case it would tell us that it contains the Stephanskirche in Bamberg.

Stephanskirche

CSW made simple

The nationaal georegister (NGR) asked us to develop a simple way for third parties to use NGR’s catalogue service. NGR implemented geonetwork as their catalogue-software and it supports CSW v2.0.2. As such anyone or anything that talks CSW can already use NGR’s service. With CSW you can search the NGR database for online geo-information. This could be useful for developers who want to add relevant maps to their websites.

Continue reading

INSPIRE Geographical Names viewer

In the INSPIRE framework we are working on the ESDIN project and are using the EuroGeoNames (EGN) project as an implementation of ESDIN. INSPIRE is a big thing within the GIS world in Europe and loads of documents have been written so far.

We’re involved in both ESDIN and EGN and we decided to use the latter as a trial for the first. Together with our partners we’ve setup a series of servers to fulfill the needs of the projects. The main standard used is the latest WFS and GML versions, which have the annoying disadvantage that there are few clients available.

To be able to show nicely (as in not an XML file) that everything worked I was asked to build a webclient which would show a map and the data from the EGN service for that area. I figured that this was once again a good reason to look into the latest developments for OpenLayers. I quickly discovered that the released version (2.7) doesn’t support WFS 1.1.0 so I asked on the mailinglist if people already tried to implement it (and if not, pointers how to do so). Luckily people already did the work and created various patches for the support. (thanks tschaub, bartvde and others)

The most important patch is the one which implements protocols for WFS: ticket 1648 and its wfs.patch The main disadvantage of this patch was in my case that it tried to minimise the number of requests to the WFS server (which in general is a good thing). It requests all the features which are within twice the size of the viewport and it doesn’t request new features when you zoom in. However our server is limited to 10 features per request this results in very interesting behavior. For a starter all the 10 feature could be outside your viewport and also very funny is that shown feature might dissappear when you move the page too much (it requests new features in that case and the first 10 might be outside the viewport). A second patch, on ticket 1830, provided a more aggressive feature update: each zoom action triggers a new request and I set the request-boundingbox-ratio to 1, meaning only those feature within the viewport are requested. This means that every action triggers a new request, which is heavy on the server.

However this is just a reference implementation and hopefully for actual implementations they remove the 10 feature limit. For those interested the reference implementation can be found at http://research.geodan.nl/egn