What's so wrong with HSV?

Well, the main problem is that the value component of HSV is just a measure for the physical lightness of color, but not for the perceived brightness. Thus, fully saturated yellow has the same "value" as blue. The same is true for the HSL color space. Here is a set of six colors of the same value to demonstrate this effect. The second row shows how the colors look after converting to grayscale via Photoshop.

Beside of this strong hue-dependency of brightness, there is also no linear brightness gradient within a single hue. For instance, in the following HSL color scale the brightness step between the second and the third red appears much bigger than the step between the 3th and 4th color. Even worse, this effect seems to differ across different hues, as the comparison to the blue scale shows.

After all, this should be enough reason to avoid equidistant HSV/HSL scales. But what options do we have instead?

For the lazy ones: Use ColorBrewer

So the question is, what shall we do about it? In the comments someone mentioned ColorBrewer, which is in fact a great solution for those who just want to get some colors without caring too much about the details. Here's a selection of sequential ColorBrewer scales.

One drawback of this solution is that you're limited to a fixed number of colors. For each color scale, the collection gives you variants from 3 to 9 colors. Another drawback is that sticking to a predefined set of colors means giving away some artistic freedom. Also, and most importantly, it's not half as fun to pick existing solutions, isn't it?

For the color geeks: Make friends with CIE L*a*b*

At this point, you better prepare yourself for some ultimate color geekyness. Thanks to the gentle introduction of David Dalrymple, I finally dared to enter the magic world of the CIE L*a*b* color space. To get a better understanding of this color model, I ported David's code to JavaScript and built a tiny Lab color selector. The vertical slider allows you to navigate through the space. Also you can change the x and y axis using the links next to the slider.

In general, the Lab color space has one component for Lightness and two bipolar color components a (yellow-blue) and b (green-magenta). While the lightness ranges from 0% to 100%, determining the valid ranges for a and b is somewhat tricky.

The problem is that CIE L*a*b* contains more colors than are available in RGB. For instance, the "valid" range for a depends on the lightness and the second color channel. Another problem is that it's hard to select colors by mixing four colors. To get around those issues, David Dalrymple suggests a fancy transformation of the Lab space.

CSL: Making CIE Lab more accessible

The trick is easy. You use the a and b components to compute a color angle (hue) and a radius (saturation). Because it's not exactly the same as hue in HSV, it's named c (for chroma). Basically this gives this us the CSL color space (although I'm not sure how this is named in vis science).

While the problem of non-existent colors still remains (especially if you increase saturation) this looks like something we can start to work with. For instance, if we take a look at equidistant CSL colors of the same lightness we get a much better result. Actually, if you'd convert this into grayscale again you get the exact gray value for all colors. Well, this is no big surprise, I bet Photoshop itself uses CIE L*a*b* for grayscale conversions.

Now, let's grab some colors..

This is where the fun begins, so I'm glad you made it up to here. To learn more about the difference of equidistant colors across color spaces, I visualized the linear gradient in the color selector. Feel free to experiment with them and check how the CSL color space compares to other spaces like LAB, HSV, HSL or RGB.

Also, it's interesting to directly compare the interpolated colors across different color spaces:

Nice! How do I get those colors?

To make things easy, I packed everything up in a small JavaScript library named chroma.js. It has a simple yet powerful API,check out the Github repository to learn more. Since this is still in early beta phase, l'd appreciate if you document bugs you may encounter.

// most simple interpolation in CSL space
chroma.interpolate("#383D41", "#EFEE69", 0.5, 'csl').hex(); 
// returns "#5C9A7C"
 
// also, you can instantiate CSL colors directly 
chroma.csl(60, .7, 1).hex();
// returns "#C6A860"

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.

More for exercising than for competition reasons, I recently recreated a great Processing visualization by Ben Fry using HTML5. I had the strong feeling that the kind of animation is totally doable without plugins like Java and Flash. This post sums up what I learned.

Initially I wanted to use the relatively new PaperJS library for the animation part. I managed to use JQuery along with PaperJS, loaded the CSV file and started to draw all those company lines (500 per year for 55 years = 27500 lines). Since using the Path for just drawing simple 1px lines would be way to much overhead, I grabbed the canvas context directly and used the "native" fillRect(). The drawing took around 900ms. Removing the PaperJS library reduced drawing time to 350ms. Then I replaced the fillRect() with direct pixel manipulation using getImageData() and finally got to 50ms which is like 20 fps.

After showing this to the world, Moritz Stefaner reminded me to use requestAnimationFrame instead of setInterval(), which gave the visualization the final performance boost.

For drawing of the spline I could've used the bezierCurveTo() function, but this way I would have to hazzle around with the curve control points, which I didn't want to. Instead, I added another canvas "layer" on top, that is now used by PaperJS to draw the smoothed paths. Both apps communicate through a simple and global accessible API which allows the jQuery-app to draw, update and remove splines. This was fast enough to animate the curves.

The data is served as pure CSV and all parsing and data wrangling is done in JavaScript. Since the size of the data is 1.1MB, I told the web server to serve the CSV file gzipped using the .htaccess code below. This reduced the data size to 360kB.

AddOutputFilterByType DEFLATE text/html text/plain text/csv

After all, remaking an existing visualization was quite a fun thing to do. I learned some new things about working with HTML5 and finally had the chance to use the promising PaperJS library for the first time. Also, in Ben's initial version the profits view doesn't show companies with negative profits, which I didn't realize until I started working with the raw data myself.

If you're interested, here's the link to my version. Also you're invited to inspect the source code and data.

My wife recently observed my two-year-old son eating green strawberries and is now curious if he has some kind of red-green color blindness. Unfortunately, he is not yet able to give us the name of numbers, so the commonly used Ishihara test images won't do. Well, I thought it´s a nice idea for this rainy Sunday afternoon to generate some of those images myself. Instead of numbers I used simple images of things I knew my son is able to name. If you like, find the source files here. The icons are taken from thenounproject.

My wife recently watched my 2 years old son eating green strawberries and was now curious if he has some kind of red-green color blindness. Unfortunately, he is not yet able to tell us the name of numbers, so the commonly used Ishihara test images won't work in this case. Well, I thought it would be a nice idea for this rainy Sunday to generate some of those images myself. Instead of numbers I used simple images of things I knew my son is able to name. If you like, find the source files here. Icons taken from thenounproject.

var paper = Raphael("canvas", "800", "600");
var icon = paper.path(svgPath);
icon.attr({ fill: '#000', stroke: 'none' });
 
timer = window.setInterval(animate, 1000/30);
 
function animate() {
	t += .1;
	icon.scale((Math.sin(t)+1)*.5 + 1);
}

Here are the links to the demos.

The result: we should forget about SVG animation by now. SVG animations are a little slower than flash.

Update: Erik Dahlstrom told me about the fact that RaphaelJS re-draws the SVG paths on every scale() call. I now implemented the scaling using svg transformations.Um eins gleich vorweg zu nehmen: Ich liebe SVG. Ein offener Standard zur Beschreibung von Vektorgrafiken, darstellbar in so gut wie allen gängigen Browsern, mit einer beinahe endlosen Vielfalt an Möglichkeiten. Was will man noch mehr? Naja, eine Sache fällt mir da ein. Es wäre toll, wenn SVG auch noch einigermaßen fix gerendert würde. Hier mal ein kleines Beispiel. Ich habe ein Icon vom wundervollen Nounproject genommen, den SVG-Pfad daraus kopiert und mit Hilfe des RaphaelJS Frameworks eingebunden. Dazu kommt jetzt noch eine einfache Animation, die das Icon größer und kleiner werden lässt:

var paper = Raphael("canvas", "800", "600");
var icon = paper.path(svgPath);
icon.attr({ fill: '#000', stroke: 'none' });
 
timer = window.setInterval(animate, 1000/30);
 
function animate() {
	t += .1;
	var s = (Math.sin(t)+1)*.5 + 1;
	icon.node.setAttribute("transform", "translate(55,34) scale("+s+") translate(-55,-34)");
}

Hier sind die Links zu den Demos.

Das simple Ergebnis: Animation von Vektorgrafiken kann man mit SVG derzeit einfach vergessen schon begrenzt für Visualisierungen verwenden. Trotzdem noch etwas langsamer als Flash.

Update: Erik Dahlstrom hat mich freundlicherweise darauf hingewiesen, dass RaphaelJS die SVG-Pfade bei jedem scale() Aufruf neu zeichnet. Habe die Skalierung jetzt über SVG-Transformationen gelöst.

Fazit:

• RaphaelJS ist ein geiles Framework. Hat richtig Spaß gemacht damit zu arbeiten. Einarbeitung hat keine 10 Minuten gedauert.
• Die Entwicklung ging wesentlich schneller als ich dachte. Ohne irgendwelchen Code zu portieren hat mich der komplette rewrite from scratch nur vier Stunden gekostet.
• Leider ist das SVG-Rendering zwischen den Browsern nicht 100% einheitlich.
• Das Text-Rendering sieht in allen Browsern merkwürdig aus, besonders wenn der Text gedreht wird. In Chrome wirkt der Text verwaschen, in Firefox scheinen sich die Buchstaben mitten im Wort nach oben und unten zu verschieben. Das kann Flash deutlich besser (siehe Bild).
• Einige Effekte lassen sich nur über CSS realisieren und sind nur eingeschränkt benutzbar. Firefox kann z.B. kein text-shadow für SVG-Text, und transparente Schatten kennt die CSS3 überhaupt nicht.
• Für komplizierte Vektorgrafiken wie Bögen oder Bezierkurven bietet SVG bessere Unterstützung an als Flash. Auch das Darstellen von Liniendicken < 1 sieht bei SVG besser aus als in Flash.

Hat also alles seine Vor- und Nachteile. Am sinnvollsten erscheint mir daher, Info-Visualisierungen sowohl in Flash als auch in SVG anzubieten, Flash als Standard und SVG als Fallback für IPhone/IPad-Benutzer.

If you know Edward Tufte's wonderful book The Visual Display of Quantitative Information you might already know the following visualization. The cool new thing is that it's rendered in Flash using OpenFlashMaps - a new open source map visualization framework that I'm currently working on.

The data is taken from U.S. Census Bureau and shows the percentage of people living in poverty in 2006.

Simplification is a common task in vector-based map visualization. In some situations you don't want to display a map in its full resolution for reasons like the overall filesize and the rendering time. One major class of simplification algorithms works by removing some vertices without moving the remaining ones. While there are already some good tutorials for implementation of line simplification algorithms online¹, none of them takes into account the special requirements of map data simplifications. This gap will be closed by this post.

At first I want to introduce the used data set. It's a very basic map of all european countries. The first image shows the output of the map rendering without simplification.

While there are many simplification algorithms out there, this tutorial uses a very simple one. It's strategy is to remove certain points that are too close to the last kept point. This is not the smartest algorithm ever, but still one of the fastest, because it don't needs recursion and runs in O(n).

const minDistSq:Number = 100000 * 100000; // radius 100km
var countries:Array, shapes:Array, shape:Array, pt:Object, lastPt:Object, distSq:Number;
 
for each (shapes in countries) {
	for each (shape in shapes) {
		lastPt = shape[0];
		for each (pt in shape) {
			if (pt == shape[0]) continue; // skip first point
			distSq = (lastPt.x * lastPt.x - pt.x * pt.x) + (lastPt.y * lastPt.y - pt.y * pt.y);
			if (distSq < minDistSq) pt.deleted = true;
			else lastPt = pt;
		}
	}
}

This algorithm works perfect on single polygons, but there are some drawbacks when using it for simplication of country outlines. As you can see in the next image, the simplification introduced overlappings and gaps between the countries.

The problem here is that different polygons that share the same boundary were treated seperately. To fix this we need to refine the current map topology (CONTINENT > COUNTRY > SHAPES) in a way, that the "shared vertices" were stored only once.  The algorithm simply iterates over all points and stores them into a global point register. Every new point will then be checked for equality (same x and y coordinates) with any of the previously saved points. If the algorithm finds an equal point, the reference to the duplicate point will be replaced and the custom property inner will be set to true (which means that this point lays on more than one country border). Incidentally this will also decrease the map file size and gives us a classification of  "inner" and "outer" points for free.

When we run the algorithm again, we need to remeber wether the simplification already visited point, to avoid double removal. The results look much better than before, but still need some improvements:

Obviously, there is one case we forgot, which I call three-country-crossings, which means all points that lay on more than two country borders. Removing one of these points leads to triangle shaped holes inside the continent area. To avoid those holes, we got to mark all three-country-crossings as undeletable. We can find three-country-crossings by counting how often we visit a single point during the topology initialization.

Now we are nearly finished. It took me a few days to notice that there is another case, we have to consider. If you compare at the crossover between Spain and France at the Mediterranean Sea side, then you note the tiny cut into the landscape, that is introduced by the simplification.

To avoid those cuts we must identify all vertices that connects two countries and lay on the outside of a continent area. We can do so by comparing the current visited point with the last visited point, and if one lays on two countries and the other only on one, we mark the one on two countries as undeletable. The last picture shows the final output of the simplification:

I hope this tutorial was useful to you, if anyone needs more code examples on this topic, let me know via comment.