Uno Sguardo nel Buio:AventuriaMap/en

Da Uno Sguardo nel Buio.

Indice 1 The implementation 1.1 Maps acquisition 1.2 Combining maps 1.3 The Tiles 1.4 The Google Map API 1.5 Server side components 1.6 Placing Aventuria 2 To do list 3 Tools 4 Links

One of the wiki related projects is Aventuria Map. This is the Aventuria map management based on the Google Map API, so the user can browse the map and (in the future) he will be able to position the cities, the most important places and adventures routes.

For a more efficient and convenient usability of Aventuria Map we decided to create a subdomain, ad hoc. Thence, to access the current version of Aventuria Map is sufficient to go to http://maps.usnb.it.

You can select a city from the list and center the map with Go! button, a click on the town marker will show the wiki page of www.usnb.it.

You can link the page focusing on a town or city:

http://maps.usnb.it/index.html?citta=Vinsalt

or on a specific point:

http://maps.usnb.it/index.html?lat=30&lng=5

at given zoom level too:

http://maps.usnb.it/index.html?citta=Vinsalt&zoom=7
http://maps.usnb.it/index.html?lat=30&lng=5&zoom=9

The implementation

The project completion, at present, required some basic operations, which we shall see in detail, including:

• scanning and acquisition of original maps
• combining all maps
• defining the tiles
• writing the javascript code to implement the map with Google Map API
• implementing all the necessary server components

Maps acquisition

We purchased the official Kartenset 1 and 2, the ones related to the South and the Central region of the continent. The third Kartenset was not found, so it was necessary to find each single map.

The acquisition was done at 300 dpi, a good compromise between quality and file size, the original files in TIFF format were then converted to PNG format because it provides good compression without losing quality.

Combining maps

This was one of the more expensive step. In many cases, because of the huge size of files we obtained, it was not possible to work with the entire map file; so we had to cut it into two or more smaller images.

This last aspect has led to a significant work on the original maps to have the borders matched. At the moment, however, no serious action to solve the color problem was performed and this is the cause of the presence of boxes of different shades on the overall map.

We immediately noticed that:

• maps were not all the same color rendering, perhaps because they were realized at different times by different authors or printed with different techniques. Standardize the colors soon proved a task of some complexity, therefore we preferred to defer accepting the idea of having panels with different colors. The largest discrepancy in colours was undoubtedly the island of Maraskan.

• contiguous maps did not overlap, again probably because they are made at different times and not with the idea to combine them (an idea that probably came later, as the most recent maps were combined quite well). In this case, maps were properly rescaled to make up to match the rivers and roads, in some cases it was necessary to repaint border areas to move rivers or roads.

In the end all the maps have been recombined in frames 4096 x 4096 pixels for the implementation of the tiles in the next step.

The Tiles

As you know, the Google Map API are expected to manage layers obtained by combining squares (tiles) of 256 pixels per side. As you set the zoom level, each tile is identified by two serial numbers (row and column).

In particular, at level 0, the whole world is mapped by a single piece, at level 1 there are four and so on. Basically, stated the level number N, the number of tiles required is given by 4^N. Note that in each level, the tile coordinate (0,0) is placed "in the top left" that is, its upper left corner is located at coordinates Lat. 90° N, Lng. 180° W.

For the cutting of the square maps of 4096 pixels per side was used and modified the software Tile Cutter, made in C # by Anatole Golovco. The changes included the ability to automate the process (cutting all maps within a sub-folder according to a specific numbering), to create, from a given layer, a new layer at lower zoom level, to set the image quality of the pieces in terms of level of JPEG compression (which as we know it is with loss of information).

The Google Map API

The first problem to be solved was the choice of the type of projection. Basically, the Google Map API expects to handle maps made with the Mercator projection, which tend to enlarge the maps at Poles. You can verify this by opening any map on Google and checking on the scale indicator without changing the zoom level and moving to the north, you'll notice that the indicator shows progressively larger scales.

In the case of our maps, it was assumed that the designers have worked on "flat" maps, i.e. Euclidean projection type. The design does not take into account the fact that you are projecting on a flat surface that is the development of a sphere.

This observation has implicated the first two interventions on the javascript code: the creation of a custom Scale Control, which does not take into account the latitude, but the level of zoom only and a custom Projection that implement custom Euclidean projections.

Another set of interventions have been about the customization of the interface. Here we adopted a library (ExtInfoWindow) that allow customization of default Google Info Window and then we made the images to compose the custom marker.

Server side components

The georeferential data are stored in a MySQL database: only pinpoint objects, namely those represented by a simple marker, and path, represented by a polyline, are currently managed and we are working on shapes (areas). For those objects the following data are stored:

• marker: the name, latitude and longitude, and the name of wiki page that contains information about the referred object;
• polyline: the name, latitude and longitude of the starting point, the encoded points coordinates, and the name of wiki page that contains information about the referred object;

When polyline objects are painted, also a marker is placed at starting point, to obtain a clickable object for wiki page. As example, check the following adventure track: [1].

As you know the Google Map API are based on AJAX, and in particular for server calls they use XMLHttpRequest object that does not allow calls to a different host, to avoid cross-scripting. Thus, to populate the ExtInfoWindow with the proper wiki page it was necessary to create a PHP script that receives the request from the client and make the actual page request to the wiki. This PHP script also allows you to perform some processing on the page to be forwarded to the client to remove/modify some items.

Another PHP script provides the XML file with all the data requested by the client. These informations are used, for example, to populate the combobox for searching cities.

Placing Aventuria

Whilst we could, in effect, put the map, or their tiles, assuming any starting meridian/equator reference, we preferred to place the map accordingly to some information provided by official sources:

• a first fact is that the base meridian pass through the city of Vinsalt, this means that the reference to the longitude is fixed: Vinsalt is at longitude 0°.

• the Aventuria dimensions are reported in "Uno Sguardo nel Buio II", as 3000 Km in South-North direction and 1900 Km in East-West direction. Anyway several people, and we too, preferred to play with a double sized continent, to have a more realistic situation compared to Earth. ^[1]

• More problematic is the definition of the equator position, since the known informations state only that the equator passes south of the continent. Some considerations reported in "Das Land des Schwarzen Auges" and "World of Aventuria" suggest that the continent is placed between Lat. 10° Nord and Lat. 45° Nord.

Now, to correctly position the map the geographical coordinates of at least two points are required, or alternatively the coordinates of a point and the distance in kilometers between two points. In fact, with a single point you can get the positioning of the map, but not the scale level.

In our playing system we adopted the following:

• base meridian passing through the city of Vinsalt;
• double sized Aventuria, thus assuming 1 mls about 2 km;
• the south border of Aventuria is the southernmost point of Benbukkula island and is placed at Lat. 11,41° North.
• the north border of Aventuria is the northernmost point of Yeti island and is placed at Lat. 61,88° North.
• the west border of Aventuria is the westernmost point of Sorkten island, placed at Lng. 11,27° West.
• the east border of Aventuria is the easternmost point of Setokan island, placed at Lng. 19,97° East, whilst the last known area of Bronze Sword is at Lng. 20,39° East.

To do list

• I should realize an interface to allow authorized users from inserting objects on the map;
• Aventuria map must be integrated into the wiki so that we can get the map from the pages that require it, so, for example, on each page of the city must be a link that opens Aventuria Map centered on the city itself;
• polylines must be managed in encrypted format to avoid excessive loading and repaint time.

Tools

For acquisition we used a AGFA A3 scanner with its software.

Graphic editing were made with open source software GIMP and Paint.NET. The latter has proved very useful for its ability to handle very large maps in memory. GIMP was used for all editing operations such as recovery of the slight deformation created by the acquisition, borders removal, images scaling, the redesign of rivers, roads and other boundary elements in order to obtain border matching.

The javascript code testing has been made both on IE7 and on Firefox 3.0.14, both with the plugins needed to debug javascript and CSS.

Links

• GIMP is a open source graphics software used especially for cleaning up the maps and align any distortions caused by the scanning process;
• Paint.NET is an open source graphics software, very useful for the process of assembly of maps, handles well large images, even on 32 bit;
• Google Map Tutorial is a tutorial by Mike Williams on Google Map: a good starting point, it sets out clearly all aspects of Google Map, rich with examples and guidance on the choices to take to achieve goals;
• Google Map Documentation is the official documentation on the Google Map API, rich and comprehensive, has now also the new API version 3;
• Encoded polyline utility is the tool showing how to use encoded polylines;
• ExtInfoWindow is the extension used to customize the information windows with our CSS;
• PHP is the language used to implement the server components;
• MySQL is our database engine.

---

Note