Trying to match via region names..

So, the basic idea was to use the region meta-data in the Geonames db to map the Natural Earth regions with the GeoCityLite db. Both Geonames and Natural Earth store different versions of the region names that could be thrown into a word similarity measurement like Levenshtein to compute similarities. Before I actually started to matches the regions I grabbed some statistics on the distribution of countries and region in both datasets. Here's a summary of the results:

In all datasets combined, a total of 237 countries is included. Of those countries, only 90 have the same number of region polygons and region meta-data (shown in green). The red slices represent countries that still have polygons and meta-data available, but there is either a surplus in region meta-data (46) or in region polygons (35). Finally, the blue slices represent countries that have no region polygons at all (60) or that have polygons but no meta-data (6).

To learn a little more about those countries, I displayed the results on a world map:

However, I started the matching and created this more detailed map of coherence between Geonames and Natural Earth regions. Green means perfect matching (no regions left on both sides) while dark red means that almost no region could be mapped properly. The map reveals the differences between France and UK. In one case, only some island regions are missing while in the other case there's a complete mismatch between regions.

..and what I learned from this

The good side of trying out the region name matching was that this made me aware of the UK case, which fundamentally changed my initial assumptions. To begin with, here's the region map of the UK regions in the Natural Earth shapefile:

The first thing I learned is that the Natural Earth regions are very detailed in some cases. In fact, they're too detailed to be useful for our purpose. The regions simply get too small to be clicked. The second thing I learned is that Geonames and Natural Earth have different definitions of administrative level 1 regions. While Geonames sees England, Scotland, Wales and Northern Ireland as first level regions, Natural Earth goes down to a very detailed level shown above. Then I checked if the GeoCityLite database also stores just the four UK "regions", which would be very sad because they're too general. And surprise, GeoCityLite uses different regions for UK.

The implications are that we need a completely different way of matching and that we need to merge regions in some countries to a reasonable degree.

Merging too detailed regions

To find out which countries regions need to be merged I looked at the countries that have the highest number of regions. This involves United Kingdom, Slovenia, Philippines, Macedonia and Uganda.

To merge the regions I used meta-data I (fortunately) found in the Natural Earth shapefile. For instance, the UK provinces (e.g. Derby) stored the name of the region they belong to (e.g. East Midlands). The actual merging was done by my good friend the Python Polygon package.

However, for Macedonia, the region names turned out to be incomplete, so I had to match the regions by hand using an overlay image I took from Wikipedia. Here's a screencast that shows me doing this:

At the end, I got a CSV files that stores all regions that need to be joined along with the new region id. The data is used both for rendering the maps and in the next step of matching the GeoIP regions. For instance, here's how the merged regions look like for the United Kingdom:

And, finally, matching the regions

Since the definitions of what's an admin-level 1 region seem to vary across Natural Earth and GeoCityLite, I needed to use a more low-level approach to match the regions. Fortunately, the GeoCityLite db stores plenty of locations for each regions, which I used to match.

For every source region (GeoCityLite) I randomly selected five locations. Then I did point-in-polygon tests for each location with each of the target regions (Natural Earth), and the region that contains most of the locations probably is the one that matches the region.

I checked the accuracy by counting the number of matched regions:

• regions that matches to no target region: 73
• regions that match to exactly one region: 2434
• regions that match to two regions: 437
• regions that match to three or more regions: ~140

The cause of the missing matches could be that some regions are simply missing in the map (e.g. small island polygons). I think those cases can be ignored. Another reason could be that a country has been split up recently (like Sudan) and thus some regions couldn't be found.

The cause of the multiple matches is that some GeoCityLite regions are more general (or larger) than the regions in the Natural Earth map and one solution would be to merge the affected regions.

Investigating the multiple matches

So, again, let's look at the details of what we've done. Here's a close-up view on a case in Northern Germany where multiple map regions where matched to the same GeoLiteCity region. Obviously, in this case the cause is imprecision of the Natural Earth shapefile.

Here's another example, showing the Northern Switzerland where a region matched to four map regions. We can see that there are errors in the GeoLiteCity locations, too.

Looking at those examples, I think the best idea is to simply take the region that matches the most locations. We'll hopefully get some more feedback from local Piwik users.

As suspected, the locations for South Sudan still are assigned to Sudan in the GeoLiteCity database, which is going to be fixed.

At the end, I'm quite happy with this solution. Next time, I will start to write the JS code that "renders" the SVG maps using RaphaelJS and that also allows to display some data – either region-based or location-based – in the map.

Update 1

I further investigated the "missing" regions that can't be matched to any of the map polygons. For instance, here's a close-up view on Southern England, where some regions couldn't be matched. The reason is that the locations are a little bit outside the polygon.

The core of the problem is that the data is not accurate enough: either the region outline or the location coordinates are wrong. An easy fix is to build this inaccuracy into the matching algorithm. Since we don't know the exact coordinates of a given GeoIP location, the same location could as well be moved (slightly) in any direction. The algorithm now also checks the neighborhood for each point, which reduced the number of missing regions to 14.

The remaining missing regions are due to missing polygons for small island parts of countries like the United States or Finland:

Getting the viewport

The first step of drawing a map is to define the viewport, which is a rectangle containing the geometry that will be visible in each map. To simplify things a lot, we decided to use a fixed aspect ratio for the maps. What we need next is a way to get the outer bounding box of the countries.

The simple approach is to use the lat/lon bounding box, but this actually doesn't work for the orthographic projection, as the minimum latitude of a country doesn't necessarily correspond with the minimum y of the projected country. For instance, the following image shows the lat/lon bounding box of China:

Instead, you need to project the polygons first, and then compute the bounding box in x/y space. As explained in the last post, I will use the orthographic projection. To avoid distortions and ensure that the country is fully visible, the projection must be centered on the target country. For the computation of the center latitude and longitude I used the Polygon package (a Python wrapper around the GPC library) which provides a function for computation of center of gravity (also called centroids). Code.

Now we can project the country polygons and compute the exact bounding box, which then can be used to scale and position the map inside the viewport. Here's the bounding box of China, again:

However, while this approach works for most countries, other countries are a bit trickier to handle. As you can see in the next image, Spain has one big polygon commonly known as Spain along with several little polygons (islands) which located far away of the main country. This leads to a much bigger bounding box that we want, since in our scenario, we want the maps to be focused on the major part of each country. We have to find a better way to compute the bounding box.

My first thought was to only consider the largest polygon when computing the bounding box. The shape area computation is done by a nice algorithm I found here and was ported to Python there. Again, this works in many cases (like Spain, USA), but it won't work in other cases, like New Zealand:

My final solution was to compare each country polygon area with the maximum polygon area of that country. Every polygon below a fixed threshold (for instance 10% of the maximum polygon area) is discarded, which seem to work out very well. For five countries (including Japan), I had to manually change the threshold to get a nicer bounding box, which was faster and easier than spending more time in algorithm improvements.

Projection

Now we can proceed with the actual projection of all visible countries. For the orthographic projection, I initially wanted to use the pyproj package, a wrapper around the de facto 'gold standard' PROJ.4. Unfortunately, the design of the map requires that the client-side also needs to be able to perform projections. Therefore, I would have to port parts of the PROJ.4 code to JavaScript, which is something I've done before in ActionScript and actually don't want to do again. Instead, I found a nice and simple Python implementation of the orthographic projection by Niall McCarroll, which was very easy to port to JavaScript.

Using this class it was very easy to render such a beautiful globe in SVG:

The bounding boxes computed in the last step are now used to detect all countries that (probably) intersect our viewport. This is important to know because we need to reduce the data to keep the rendering time low. To give the country a little more context, the bounding boxes are inflated by 30% and then centered inside the viewport. Now every countrys bounding box is checked for  intersections with the viewport.

The basic idea now is to render the inner-country administrative boundaries for the focus country and the national boundaries for the neighbor countries. At the end of this step, we end up with a map like this.

Polygon simplification and clipping

What you can't see in the above screenshot is that the resulting SVG file has a size of 578kB, which is way to much given the fact that we need to store more than 200 maps. I actually agreed with the Piwik core developers that the zipped final size of the SVG maps should not 1 megabyte. So, what we need to do is to simplify or generalize the polygons.

There are several algorithms for polygon simplification, like the ones by Douglas & Peuker and Visvalingam, but I used a very fast and simple one. Actually, it's the same algorithm that I used a few years ago, when I rendered my first world maps in Flash.

Since we don't need the surrounding countries in the same quality as the focus country, I used different qualities for the simplification, which is great for reducing the map size. After simplification, the file size has reduced to 21kB or 3%.

The next task was to throw away everything that lays outside of the viewport. It's important to do this after simplification since otherwise the simplification could destroy the viewport borders.

To clip the polygons to the viewport I used the Python Polygon package again, which allows for syntactic sugar like this:

clippedPoly = polygon & viewport

Conclusion

After clipping, I rendered the polygons as SVG file to get the final map. The final zip-file with  all 238 country maps is 840kB.

In the next post I will write about how to connect the region ids of the Natural Earth shapefile with the region ids of the GeoIP database.

Update (Nov. 3)

Instead of the Orthographic projection, the maps now are projected using the Lambert Azimuthal Equal Area projection, which is widely used in cartography. For most countries, the differences are invisible, but the surrounding of larger countries like Russia look much less distorted.

What to do with those tiny island states?

To get started I opened a world shapefile and computed the areas of all 3761 polygons (multiple polygons per countries). Filtering every polygon smaller than 10 square km would remove 434 polygons, or 11% of the polygons. I checked the names of the countries which the removed polygons belong to and found many island states among them (as expected).

However, I think a hard cut at 10 sq km has some problems: One the one hand it removes some countries entirely (like the Maldives Islands) while still keeping many very many small islands (starting from 11sqkm). Click image to zoom.

Then I tried a different rule: remove all polygons smaller than 5% of the maximum polygon area of that country. Since the maximum area of the Maldives is 9sqkm, all islands are kept, while all small islands of the USA are removed. Also this halved the resulting SVG file size keeping the map correct in terms of includedness of countries.

However, removing every polygon smaller than 5% of the maximum per country is not satisfactory as well. Big and also well-known islands like Hawaii or  Novaya Zemlya shouldn't be removed in my opinion. Finally I came up with a combination of both rules: remove every polygon smaller than the minimum of x square km and 5% of the maximum area per country. This removes the small and unimportant islands but keeps the tiny island states.

Being very happy with this solution I looked at the Maldives islands for the first time (those black little dots on the left). Obviously, the islands seem to be way too small to be rendered in a meaningful way. This leads to this important question:

Does the map need to include all countries or is it acceptable to ignore some countries, like the Maldives Islands?

In the old map widget this wasn't important because there was no country level view.

One projection for all countries?

A few thoughts regarding the projection that's going to be used for the country-level views. I would like to simplify the whole thing by using the same projection for every country, but with different parameters (namely the projection center).

One of the simpler projections is the orthographic projection, which looks the same as if looking onto a 3D globe. This gives quite good and less-distorted views for almost every country. The only country that looks quite distorted is Russia.

My opinion is that this distortion is acceptable given the simplicity of rendering maps in a single projection. In an ideal mapping world, however, one would use specialized projection for every country, like the New Zealand Map Grid for New Zealand etc.

Fixed vs. dynamic aspect ratio

The next design decision has to do with the aspect ratio of the maps. At some point in the map generation process I need to crop the country-level maps to a bounding box. The idea is to fit the countries as big as possible into the views while also showing a bit of their neighbour countries for navigation.

Now the question arises to which aspect ratio the maps should be cropped. As far as I see do we have to options:

1. A fixed aspect ratio (presumably some wide-screenish format) would be the simplest solution. The complete cropping could be done in the preprocessing stage, which would reduce complexity of map rendering. However, the obvious drawback of this solution is that the maps won't look as good as they could when displaying countries in the "opposite" aspect ratio. For some portrait countries (like Germany), this should be acceptable. For other, more extreme aspect ratios (my favourite example is Chile) don't.
2. In the latter cases, a dynamic aspect ratio would make much more sense. It would be perfect if we could present the Chilean Piwik users (I assume there are some) with a portrait view of their country. Dynamic aspect ratios could be done either by choosing a fixed ratio per country or by cropping the maps at rendering time. Choosing a fixed ratio per country has the drawback that those countries could not fit a landscape ratio in fullscreen mode. In contrast, cropping at runtime may take more CPU. Also, I don't know if the current dashboard supports dynamic resizing of widgets, but this may be easy to implement.

So, let's start the project. A year ago, I already wrote a proposal for some new features for the Piwik map, which I now want to implement. The first part of the work will be to prepare the maps, the second part will be to render the maps using SVG and, presumably, a JS/SVG framework like RaphaelJS. The process underlying the first part looks like this:

In this post I will focus on the initial step, the map data source.

Finding a map data source

The biggest challenge was to find map data of inner-country regions (like the U.S. states, the German Bundesländer or the Regions of France) for all countries of the world. Initially I thought of extracting the administrative boundaries from the huge OpenStreetMap database, but this is not as easy as it sounds. Finally I decided to look for other data sources – and succeeded. I found gadm.org, a website whose entire purpose is to provide free map files of the worlds administrative boundaries and they had exactly what I was looking for: a shapefile of all countries with their first-level sub-divisions.

Update: I will use the Natural Earth shapefile instead of GADM, see below.

Handling huge shapefiles

After unpacking, the shapefiles where 439MB big. I wanted to know a little more about the data before starting to actually work with them, so I wrote a small Python script to get some information. There are plenty of Python libraries for reading shapefiles, I kind of like this one, mostly because its simplicity. So here's the script:

import shapefile, csv
# create a new csv file for writing and write csv header
csvout = csv.writer(open('shp_meta.csv', 'w'))
# open the shapefile and read records
sf = shapefile.Reader('gadm1_lev1.shp')
shape_records = sf.shapeRecords()
 
for record in shape_records:
	numPoints = len(record.shape.points)
	numParts = len(record.shape.parts)
	shapeMeta = record.record
	csvout.writerow([ numParts, numPoints] + record.record)

The first interesting fact is that executing the script took my Macbook a little more than three minutes and the RAM usage peaked at something around 3GB(!). This means that the script might not run on some machines. Maybe I should consider trying out other shapefile libraries later, to test their shapefile reading performance.

Analyzing the map data

However, here's the resulting csv file. The most interesting thing about it is what is stored in the shape record dBase metadata. Fortunately, the shapefile stores the countries ISO codes, which I need for mapping them to the country ids used in Piwik. Next good thing is that we also have official two-letter codes and names language for the level-1 boundaries. The names are provided both in English and in the countries local language, which is very good since we can use them later for the map rendering.

Another thing of great interest is the quality of the shapefile. The big file size is a first indicator for a high level of detail, but I wanted to know more about it. This is why I added two more columns: the total number of points per shape and the number of shape parts (a shape may contain multiple parts, which are polygons in our case). To analyze this data in more detail, I loaded the csv file into R, which is a great (if not the best) software for data analyzing:

data = read.csv('shp_meta.csv', header=TRUE)
pc = data$point.count
sc = data$shape.count
country = data$iso3
region = data$region.code

The first thing I looked at was the total number of points in the shapefile, which is 28.5 million points(!) or something around 8500 points per shape.

> sum(pc)
[1] 28565495
> mean(pc)
[1] 8486.481
> plot(pc)

However, after looking at the scatterplot of point counts I saw that only few of the shapes seem to have that much of points.

Here's a look at the distributions of parts per shape, points per shape, points per part and points per country. I used a boxplot of the log10 counts for each measurement. One can now see, that the median of parts per shape is at 10^0, which means that at least half of the shapes consist of only one part. However there are some shapes that are made up of almost 10^4 or 10000 shapes, which I assume to be near pole-regions that contain many small island-like parts. The points per shape has it's median at 10^3 or 1000 with a few outliers to the top. Points per country peaks at 10^6, which means we have to deal with up to one million points per country.

Of course I wanted to know what countries and regions are responsible for those outliers in point counts, so I replaced the dots with labels. Interestingly, it's Chile, Canada and the United States.

plot(pc, col="white")
text(1:length(pc), pc, iso3)

This is the region Magallanes and Antártica Chilena, which is the one with an outstanding number of about 1.2 million points.

One of the next smaller regions is Alaska, which has about 600 000 points.

Closing thoughts

Since the admin-level 1 shapefile doesn't contain the admin-level 0 boundaries, at least not explicitly, we will either need to compute them using the "outer" regional boundaries of each country, or take them from the admin-level 0 shapefile from gadm.org.

Obviously, 1.2 mio points for a single shape are way too much for display in a browser using SVG. Therefore, in the next session we will proceed with map projection and the polygon simplification process. We will take a good look to Magallanes and Antártica Chilena then.

Update (Oct, 25)

Unfortunately, the GADM maps are licensed under a not-so-free license, which doesn't permits commercial use. Also, it seems that GADM doesn't update their shapefiles very frequently, since it still doesn't contain South Sudan. Fortunately, Manu told me about Natural Earth, a site which I doesn't only provide hi-res images of the earth (which I initially thought), but also provides detailed shapefiles. I checked the Admin 1 - States and Provinces shapefile and it contains South Sudan. And all data is licensed as public domain. That's not a great reason to switch. So, no GADM anymore.

Recently I finished the work on the interactive Bubble Tree for the OpenSpending project. This tutorial demonstrates how to use the visualization for display of your own data. Here's the link to the resulting visualization.

Setting up the page

You need to checkout the Github repository or download the source files to go through this tutorial yourself. At first we're going to create the container HTML page.

<html>
<head>
	<meta charset="UTF-8"/>
	<title>Minimal BubbleTree Demo</title>
	<script type="text/javascript" src="bubbletree/lib/jquery-1.5.2.min.js"></script>
	<script type="text/javascript" src="bubbletree/lib/jquery.history.js"></script>
	<script type="text/javascript" src="bubbletree/lib/raphael.js"></script>
	<script type="text/javascript" src="bubbletree/lib/vis4.js"></script>
	<script type="text/javascript" src="bubbletree/lib/Tween.js"></script>
	<script type="text/javascript" src="bubbletree/build/bubbletree.js"></script>
	<link rel="stylesheet" type="text/css" href="bubbletree/build/bubbletree.css" />	
	<script type="text/javascript">
 
		$(function() {
			new BubbleTree({
				data: data,
				container: '.bubbletree'
			});
		});
</script></head>
<body>
	<div class="bubbletree-wrapper">
		<div class="bubbletree"></div>
	</div>
</body>
</html>

Now the BubbleTree would load and try to display what's inside the data, which we will build in the next step.

Building the random data

The next thing we do is to prepare a random data set. The BubbleTree uses a very simple nested tree structure. The nodes must follow the following format:

var data = {
	label: "I am a node",
	amount: 123456789
}

We could now run the visualization and would get the following result:

We can insert child nodes by putting them into the children Array:

var data = {
	label: "I am a node",
	amount: 1000000,
	children: [{
		label: "I am the 1st child",
		amount: 400000
	}, {
		label: "I am the 2nd child",
		amount: 600000
	}]
}

Instead of inserting all the children by hand, we will use a function to generate a random set of children for a given node.

function generateChildren(node) {
	var numChildren = 8;
	node.children = [];
	var amount = node.amount;
	for (var i=0; i<numchildren ; i++) {
		var child = { 
			label: 'Child #'+(i+1), 
			amount: i+1 < numChildren ? 
				amount*Math.random()*.6 : amount
		};
		amount -= child.amount;
		node.children.push(child);
	}
}
 
var data = {
	label: "I am a node",
	amount: 1000000,
};
 
generateChildren(data);

Et voila, the result looks like this:

Adding some color to the nodes

This is the perfect time to setup some styling for the nodes. I will use my little helper library vis4color to generate nice random HSL colors.

child.color = vis4color.fromHSL(i/numChildren*360, .7, .5).x;
}

Generating children of children of children

The last thing to do is to call our generateChildren recursively for each child node we generate. To know when to stop the recursion, we will also pass a new parameter level to the function.

For a little extra fun, I added an Array randomNames which contains a set of randomly chosen forenames. I will use this array to add random labels to the nodes.

var randomNames = ['Burgis', 'Pascal', 'Lysann', 'Theo', ...];
 
function generateChildren(node, level) {
	if (!level) level = 1;
	var numChildren = 8;
	node.children = [];
	var amount = node.amount;
	for (var i=0; i<numchildren ; i++) {
		var child = { 
			label: randomNames[Number(String(level-1)+String(i))], 
			amount: i+1 < numChildren ? 
				amount*Math.random()*.6 : amount
		};
		if (level == 1) {
			// random color for level 1 children
			child.color = vis4color.fromHSL(i/numChildren*360, .7, .5).x;
		}
		if (level == 2) {
			// children of level 2 will get a similar color of their parent
			child.color = vis4color.fromHex(node.color)
				.lightness('*'+(.5+Math.random()*.5)).x;
		}
		amount -= child.amount;
		node.children.push(child);
		if (level < 4) generateChildren(child, level+1);
	}
}

Here is our final output. Click on the image to get to the interactive demo. You will find all the source files inside the demos/random/ folder in the Github repository.

]]> http://vis4.net/blog/posts/tutorial-bubble-tree/?piwik_campaign=rss&piwik_kwd=2695/feed/ 1 http://vis4.net/blog/posts/rendering-world-maps-in-as3/?piwik_campaign=rss&piwik_kwd=1248 http://vis4.net/blog/posts/rendering-world-maps-in-as3/?piwik_campaign=rss&piwik_kwd=1248#comments Mon, 26 Apr 2010 22:52:30 +0000 Gregor Aisch http://vis4.net/blog/?p=1248

This tutorial is the third part of a tutorial series about customized map projection in flash/actionscript. It demonstrates how to draw a world map using the as3-proj library and some helper classes. I assume that we read in a shapefile using the SHP library as shown in the previous tutorial.

1 Reading Shapefiles in PHP, 2 Reading Shapefiles in ActionScript, 3 Displaying a Static World Map in ActionScript.

This tutorial assumes that we read in a shapefile using the SHP library as shown in the previous tutorial. At first I present you a very quick and dirty way of rendering a map, which means that I tried to reduce dependencies to other classes or libraries and put almost all code in one function. On the next page you'll see a solution that are more (re-)usable.

The Quick and Dirty Way

After we read in the shapefiles, we're now going to project the coordinates. Therefore we must chose and initialize a map projection. I'm using the Wagner V projection of the as3-proj library.

var projection:Projection = new Wagner5Projection();
projection.initialize();

The next thing we need to do is to calculate the range of the projected coordinates in order to map them to our desired map size. Since we don't know the output range of the projection formulas we initialize the variables for the minimum and maximum values with infinite numbers.

var min_x:Number = Number.POSITIVE_INFINITY, 
    max_x:Number = Number.NEGATIVE_INFINITY,
    min_y:Number = Number.POSITIVE_INFINITY, 
    max_y:Number = Number.NEGATIVE_INFINITY;

Now we iterate over all coordinates, project them with the Projection.project() method and update the min/max values.

for each (var record:ShpRecord in records) {
    if (record.shapeType == ShpType.SHAPE_POLYGON) {
        var poly:ShpPolygon = record.shape as ShpPolygon;
        for each (var coords:Array in poly.rings) {
            for each (var pt:ShpPoint in coords) {
                var o:Point;
                o = projection.project(deg2rad(pt.x), deg2rad(pt.y), new Point());
                min_x = Math.min(min_x, o.x);
                max_x = Math.max(max_x, o.x);
                min_y = Math.min(min_y, o.y);
                max_y = Math.max(max_y, o.y);
            }
        }
    }
}

Once we have the min/max values for x and y we can proceed with the map drawing. We need to scale and translate the projected coordinates to place them inside our desired map. The scale is calculated beforehand. The drawing is done using the moveTo() and lineTo() methods of the flash drawing api.

var w:Number = stage.stageWidth, h:Number = stage.stageHeight;
var s:Number = Math.min(w / (max_x - min_x), h / (max_y - min_y)); // the scale
 
for each (record in records) {
    if (record.shapeType == ShpType.SHAPE_POLYGON) {
        poly = record.shape as ShpPolygon;
        for each (coords in poly.rings) {
            graphics.lineStyle(0, 1);
            for each (pt in coords) {
                o = projection.project(deg2rad(pt.x), deg2rad(pt.y), new Point());
                o.x = (o.x - min_x) * s + (w-(max_x-min_x)*s)/2;
                o.y = h - (o.y - min_y) * s - (h-(max_y-min_y)*s)/2;
                if (pt == coords[0]) graphics.moveTo(o.x, o.y);
                else graphics.lineTo(o.x, o.y);
            }
            graphics.lineStyle();
        }
    }
}

The result is a nicely centered world map (click image to see the swf):

The quick and dirty way has a few drawbacks and a lot of potential for improvements.

Avoiding duplicate projection calculations

Instead of calculating the projection twice for each point it would be better to store the points after the first projection. We could do this using normal arrays but I suggest the usage of my helper classes Polygon and PointSet. We can also replace the calculations of minimum and maximum coordinates using the boundingBox property of the polygons together with the Rectangle.union() method.

var record:ShpRecord, poly:ShpPolygon, coords:Array, pt:ShpPoint;
var polygons:Array = [];
var bounds:Rectangle = new Rectangle();
 
for each (record in records) {
    if (record.shapeType == ShpType.SHAPE_POLYGON) {
        poly = record.shape as ShpPolygon;
        for each (coords in poly.rings) {
            var out:PointSet = new PointSet;
            for each (pt in coords) {
                out.push(projection.project(deg2rad(pt.x), deg2rad(pt.y), new Point()));
            }
            var out_poly:Polygon = new Polygon(out);
            // store polygon and update the bounding box
            polygons.push(out_poly);
            bounds = bounds.union(out_poly.boundingBox);
        }
    }
}

SolidPolygonRenderer and DataView

Because the rendering of polygons and the following view calculations must be done for every map projection I thought it would be a good idea to put this functionality into separate classes. That makes our code shorter and also more readable. The polygon rendering is done by the OutlinePolygonRenderer class, which implements the IPolygonRenderer interface to enable easy exchanges of renderer classes without having to change the rest of the code. The scaling and translation of the projected points is done by the DataView class, which works nicely together with the PolygonRenderer. After all, the rendering code has shrinked to the following few lines:

var renderer:IPolygonRenderer = new OutlinePolygonRenderer(0x000000, 1);
var screen:Rectangle = new Rectangle(0,0, stage.stageWidth, stage.stageHeight);
var view:DataView = new DataView(bounds, screen);
 
for each (out_poly in polygons) renderer.render(out_poly, graphics, view);

Taking care of the projection limitations

Some projections are limited to a specific latitude or longitude range (e.g. the mercator projection, which is not able to display latitudes of 90° because this would lead to infinite y values). This means we have to check each coordinate before we project it. To simplify this check I added the method Projection.testPointDeg() to the Projection api.

In the end, the complete rendering looks like this:

// see the previous tutorial
var records:Array = ShpTools.readRecords(shp);
 
// step1: preprocessing and polygon creation
var projection:Projection = new Wagner5Projection();
projection.initialize();
 
var polygons:Array = [];
var bounds:Rectangle = new Rectangle();
 
for each (var record:ShpRecord in records) {
    if (record.shapeType == ShpType.SHAPE_POLYGON) {
        var poly:ShpPolygon = record.shape as ShpPolygon;
        for each (var coords:Array in poly.rings) {
            var out:PointSet = new PointSet;
            for each (var pt:ShpPoint in coords) {
                if (projection.testPointDeg(pt.y, pt.x)) {
                    var o:Point;
                    o = projection.project(deg2rad(pt.x), deg2rad(pt.y), new Point());
                    o.y *= -1;
                    out.push(o);
                }
            }
            var out_poly:Polygon = new Polygon(out);
            // store polygon for later rendering
            polygons.push(out_poly);
            // update bounding box
            bounds = bounds.union(out_poly.boundingBox);
        }
    }
}
 
// step2: polygon rendering
var renderer:IPolygonRenderer = new OutlinePolygonRenderer(0x000000, 1);
var screen:Rectangle = new Rectangle(0,0, stage.stageWidth, stage.stageHeight);
var view:DataView = new DataView(bounds, screen);
 
for each (out_poly in polygons) renderer.render(out_poly, graphics, view);

Rendering of Sea and Graticule

A great way to improve the visual understanding of a map projection is to integrate the sea boundary and a graticule. If you're interested in how to draw them in detail, please take a look at the source files.

Hope this tutorial was useful to you, sorry for any grammar and spelling errors. If you like you can donate an amount of your choice via paypal. Thanks!