Visual representation of capitals

[cburroughs]

I offer this more as a discussion topic rather than something I'm sure is a good idea, but with v4 on the horizon it felt like the appropriate time.

Aside from tiny islands in need of a zoom box (generally already covered by tickets, and greatly improved over the past year!) I find that Capital-->Country tends to be where I struggle the most. I suspect this is because my brain doesn't have anything visual to latch (flags, maps) onto, so it turns into a rote "what does this name I may struggle to pronounce point to". Sometime I can go back and try to come up with my own mnemonics, or read the wikipedia article on the capital and hope that gives me some context to latch on to. Both of those go one at a time and I tend to only realize I need to do it once I have a leech on my hands.

From doing this I noticed that in most (all?) cases the wikipedia article for capitals has a map of where the capital is within the country. I wonder if would be sensible and (relatively) low effort to include that map as a field and use it for additional context. So concretely the card for Country-->Capital would be Country-->Capital,CapitalMap. I know this is somewhat inconsistent with how the rest of the fields are used, but I wanted to offer my experience as a learner before all my Ultimate Geography cards are mature (I hope soon!).

[Erim24]

I totally agree with you and would wish that such maps could be included.

The way how wikipedia does this is by adding a pin via some extra markup to a map. A while ago I was wondering if Anki would support something like that as well? (But I wasn't familiar enough with how Anki works to achieve that)
If possible that would enable Ultimate Geography to just add some relative coordinates to add a pin as an overly onto the current maps. In that way the size of the deck wouldn't increase too much (since I remember that being a concern in the past)

[aplaice]

Anki's "cards" are embedded HTML pages usually scriptable with JavaScript, almost exactly like normal web pages.

Anki desktop, Ankidroid and Ankimobile (iOS) all definitely have JS support. There are slight differences, but it's not much worse than the diversity among web browsers. I'm not sure about Ankiweb — I haven't tested and there might be security concerns regarding AnkiWeb allowing what is effectively third-party JS running on their pages.

Hence, something like Wikipedia's approach should be doable.

The main issue is that the "panning" of our (AUG) maps differs from map to map, and isn't known for the vast majority of them.

For each map we know the projection (Winkel Tripel with the standard value of φ_1, always(?)) and the central longitude (usually 0°, 11°30' East or 150 ° East), but we don't know how the map was panned or zoomed (we're not displaying the entire globe). I'm not sure how easy it'd be to extract this information from the SVGs. (I've been thinking about this for a while — it'd be also useful for #267 — and have some ideas, but I haven't tried anything yet — too many things to do, and too little time...)

If this information were obtained, then displaying a pin should be relatively straightforward. (In order to calculate the position of the pin on the map AFAICT we just need:

1. the longitude of the capital,
2. the latitude of the capital,
3. the central longitude for the W3 projection
4. the "x" panning of the map
5. the "y" panning of the map
6. the zoom level of the map

This position information could be stored as a list of numbers in an extra field. We could also have some JS in the relevant template that'd process this info and display a pin on top of the map, just like Wikipedia.)

---

If we don't want a JS-solution, for whatever reason, we could generate SVG overlays for each of the capitals. These would just be SVG "pins" in the correct positions, in transparent canvases. They could be applied to our existing maps via CSS filters.

Since such SVG overlays would be extremely lightweight, we wouldn't add much to the size of the deck.

(Obviously, we'd still need to solve the panning/zoom information problem.)

---

OTOH if we make the maps with pinned capitals optional, then having hardcoded images wouldn't be too much of a problem. It'd have the advantage that we could use Wikipedia's "pin" maps, which have known panning/zoom level. It'd have the disadvantage that the "style" of these maps wouldn't fit the style of our existing AUG maps.

---

We could also look at what the Anki UK geography deck does — they seem to have pins for cities!

[drake-macmillan]

I have used the following code to have a map for each capital:

<iframe src="https://maps.google.com/maps?q={{Capital}}&t=&z=6&ie=UTF8&iwloc=&output=embed" id="gmap_canvas" frameborder="0" scrolling="no" style="width: 98%; height: 600px;"></iframe>

Adjusting the "z=" part can make the map more zoomed in or out.

I also put a Wikipedia page within the card with this:

<iframe src="https://en.wikipedia.org/wiki/{{Capital}}" style="height: 100vh; width:100%;" seamless="seamless"></iframe>

End result looks like this:

[melissis]

Hence, something like Wikipedia's approach should be doable.

If I understand anything at all, the HTML for displaying map and pin on Wikipedia is generated from this lua script: Module:Location map. It can also fetch a map file based on what location name you enter.

[aplaice]

I have a partial implementation of adding capital markers to our maps. It's not finished yet, but in the interest of getting feedback, I'm posting some images. (Long comment — the images and then the style section are probably of most interest (if at all :D).)

Style

In general, I've tried to follow the design recommendations for Wikimedia's locator maps, since they generally seem sane and look nice.

Marker shape

For the marker, I used a star from the maps template on Wikimedia, linked from the Wikipedia maps conventions page and also more specifically the SVG locator maps design scheme. I'm not a huge fan of the star, but it's not terrible and I can't think of anything better. A plain circle is the most obvious alternative, and also not terrible but IMO slightly worse.

(For the capitals of dependent territories (I haven't yet reached these, yet), if we were to follow the linked conventions, we should use the four-pointed star. I'm not 100% convinced we should distinguish capitals of sovereign states and dependent territories (they'll be on their own separate maps anyway), but weakly leaning towards it. Once I get there, I'll post relevant images (assuming we don't overhaul the entire approach).)

Colours

Locator map conventions

Simplifying slightly, the SVG locator maps seem to use a three-level hierarchy, for land:

1. red (main highlight)
2. light cream (context of highlight)
3. light gray (background)

For our current country maps, only two levels of the hierarchy are used — the country/territory in question is in red and all other countries are light cream (the country's surrounding region is the "context").

However, in more complicated cases all three levels are used. For instance for Reunion in France, Reunion is red, France is light cream and the rest of the world is light gray. For Pec in Serbia/Kosovo, Pec (sub-division of Kosovo) is red, Kosovo is light cream and the rest of Europe is light gray (with Serbia hatched between light cream and light gray).

Capital marker and country colours

Here, I've gone with red for the capital marker, light cream for the relevant country and light gray for the rest of the world (with claims/disputed territories hatched between light cream and light gray). IMO this best follows the above conventions and most importantly best highlights the capital within the country, while also distinguishing the country from its surroundings.

This means that to adapt our current country maps, (obviously in addition to placing the capital marker) we need to change red->light cream (relevant country) and light cream->light gray (rest of world). This colour adjustment constrains the technical implementation (see below), but I don't think that we could make the capital marker stand out if we kept the current red country colour (since it's pretty much the most "salient" colour already).

(One alternative to red (capital), light cream (country) and light gray (world) would be red (capital), light red (country) and light cream (world), but I think that the former is clearer.)

Marker scale

Currently, the markers are adjusted such that their size in the output PNG is always the same (this actually requires adjustment, because the pixel width of the original SVGs varies between countries).

In the case of countries with zoom boxes, I think that it would make sense to add the marker to both the main map and to the zoom box. However, I'm not sure whether the absolute size of the two markers should be the same or not. (I've not yet reached this stage, though.)

Alternatives

If anybody has suggestions regarding colours or marker shapes or anything else then I'd be eager to try them out and post them, here!

(With the colour rewriting code, changing the colours is trivial, while changing the marker is also straightforward.)

---

Choice of using new static images

I've taken the approach of generating new, additional images (adjusting the source SVGs along the lines described in the style section), which has the clear disadvantage that we would be ~doubling the space taken up by the maps. (Not quite doubling since some notes don't include capitals.) Each final PNG is 50 kB, and the total amount of space taken up by our maps is currently 12 MB. Adding another 12 MB of space usage would not be prohibitive, but it's still sub-optimal.

The two main alternatives (discussed in the previous comments and elsewhere) would be:

1. Adding markers to our existing images, either via JavaScript or some CSS overlays/filters. Unfortunately, given that the images are PNGs, this is not feasible (or at least not easy! (a WASM port of imagemagick would probably do the job but probably isn't desirable as part of an Anki deck...)) due to the adjustment of the colours of the underlying map (see above).

2. Adding capital markers to the new, fully interactive maps (currently in the experimental deck).

2 has many advantages (little additional memory burden; the inherent interactiveness of the maps).

However, due to the limitations of the underlying library, our current implementation of the interactive maps has many limitations (zoom boxes, dealing with sub-regions, dealing with disputed territories etc.) — none of which are in principle insurmountable, but also probably non-trivial to resolve. (This is in no way meant to throw shade at either our implementation or the underlying library!)

Also, images are, in a way, more flexible, since we only need to make the final, static result consistent, and it doesn't matter much how we get there — we can, say, generate most maps programmatically, but also manually adjust special cases (e.g. zoom boxes). For interactive maps we can also clearly have special cases, but making them feel seemless/consistent is probably trickier.

Finally, I started this a while ago (getting to a ~30% solution about a year ago and leaving it in stasis until recently) before the new interactive maps existed, so given that both solutions (static images vs. interactive) have advantages and disadvantages, I decided to stick with the one I had started on.

---

Implementation details

For each country map (SVG), we first estimate the parameters of the Winkel tripel projection and the geometric transformations used in its creation. (These are the central longitude for the projection, and the x,y-translations as well as the scaling of the map.) They're necessary in order to project the capital marker in the correct place. This is done by taking the (image/SVG) coordinates (x, y) of a set of points whose (real world) coordinates (lat, lon) are known, and then iteratively guessing (differential evolution) which parameters best reproduce the image coordinates.

The points chosen are the extremal points of countries (northmost and southmost — the east/westmost points are not actually preserved under the Winkel tripel projection (i.e. the eastmost point won't necessarily be the leftmost in the projection)). This is possibly because the paths in the SVG are generally cleanly labelled and the labelling is relatively consistent between different images (but unfortunately not universally).

(It's a shame that the precise translation and scaling of the map isn't available in the SVG/any metadata so that they need to be recalculated from scratch. The central longitude usually is available, but having four instead of three parameters doesn't change much.)

The coordinates of the capital are fetched from Wikidata and using the estimated parameters "projected" onto the map — the capital's x,y coordinates calculated.

The colours in the image are adjusted (red->cream etc. as above), though unfortunately the precise shade of colours in the source images is not 100% consistent between images (it is consistent within the image), so the best match is found and then replaced.

Finally, the centre of the capital marker is placed at the x,y coordinates of the capital.

---

Remaining tasks

As noted, my current implementation is partial. Some further work (mainly for my own reference, but also in case anybody has suggestions/objections):

1. Extend the extraction of characteristic/extremal points to all the maps.

2. Fix some of the hatching (e.g. just noticed that Kenya's hatching is the wrong colour — the hatching needs to be specially handled and unfortunately Ukraine's didn't carry over).

3. Deal with zoom boxes (probably manually for the zoom box marker — doing it automatically is probably overkill).

4. Use slightly different marker for dependent territories. (If desired.)

5. Fetch the capital coordinates from Wikipedia to compare them with the Wikidata ones. (I don't think the Wikidata ones are wrong, but it doesn't hurt to double-check.)

6. Triple check the estimates of the projection parameters are correct by generating a shadow map overlay for comparision. (AFAICT they are correct, because the capital markers seem to be in the correct places (by visual comparison), but it'd be useful to know how accurate they are. Also, given that for Add zoom boxes to maps of Pacific islands #267 we'll want to project island boundary marks onto existing maps, anyway, this work won't be a waste of effort (and much of it exists already given the previous work on the sea maps).)

7. Some clean up (e.g. some of our maps currently have additional modifications (e.g. removal of meridians/circles of latitude) compared to the source SVGs).

8. Allowing displaying multiple capitals (should be trivial).

---

Integration into decks

(Assuming we want something like this in the first place) I think that in the short/medium term this should be implemented either as a second experimental/variant deck (similarly to the interactive map one) or possibly as a soft fork. We probably will be adding another field (unless we use a CSS hack like for blurred/unblurred flags...), so even if we want to integrate this into the extended deck, we probably won't be able to easily add into it the "standard" one. Given the space considerations, keeping it as a variant deck in the long term may well make sense.

[ohare93]

This looks great! I think it would be a great update for the deck 👏

[axelboc]

Impressive work! 😎

Before going for static maps, I would really recommend clarifying (and agreeing upon) whether these new maps are actually going be used and in which template(s) and which deck(s) (standard/extended).

Because there seems to be a lot of complexity behind generating them, like dealing with small countries/territories (which risk being entirely covered by the marker), multiple/disputed capitals, map projections, colour standardisation, etc. And it does feel like this is the sort of feature that would be much easier to implement dynamically within a world SVG map (i.e. within the interactive deck).

Perhaps users interested in this feature would be happy using the interactive deck once it's stable?

I'll be able to comment on the styling and implementation details once I know more about the destination. In the meantime, if you want a place to put the static maps you've already generated, then I think the sandbox repo would be perfect!

[aplaice]

Because there seems to be a lot of complexity behind generating them, like dealing with

small countries/territories (which risk being entirely covered by the marker),

Yes, true, but this applies even more to the interactive maps. Irrespective of technical solution (static image vs. interactive map) we have two main approaches:

1. A zoombox or in some cases even a nested zoombox

2. Just displaying a (very) zoomed-in map.

(You can argue that with an interactive map the distinction between 1 and 2 is moot because the user can zoom-in/zoom-out, but IMO presenting all the relevant at a glance is important. Giving them the option to pan around is valuable, but it's also time-consuming, so for most reviews the user probably won't.)

I'd be in favour of 1 because:

A. The regional context is just as important as the location of the capital within the country (or even more). For some of my capital leeches that occasionally come up, I'd welcome† even displaying our current capital-less country map (on the back side), as a way of associating the capital with some known point in space. In contrast, (to take an extreme example), I'm not sure if displaying, say, Manama within a zoomed-in map of Bahrain would be that useful. Obviously, having both would be ideal!

† (yes, adding that in for myself would be trivial, but that would be bad for dogfooding)

B. In terms of mnemonic value, I think that re-using our country<->map maps (whether they're static or interactive (for interactive maps re-using the country map zoom-level/panning)), just with capital info added, is optimal, since it's best to attach new memories to existing ones.

---

However, irrespective of whether we go with 1 or 2, the current interactive map isn't ready for high zoom levels. We can add in more resolution, but this will come at the expense of file size and hence increased storage (probably not an issue), latency (might be an issue — even with the current version there's a small but noticeable delay before the map is displayed) and possibly even performance (for some devices). The underlying library can probably be optimised to reduce latency (at least to some extent, with some effort (for some value of "some" :))), and we can certainly minimise the increase in file size by using tricks such as providing greater resolution only for small countries/their vicinity, but these are non-trivial and (at least the former) uncertain.

---

Regarding zoomboxes: getting the "projection information" of each map (for displaying the capital), also makes generating zoomboxes much easier. Hence, I think the effort (assuming the high zoom level is fixed for the interactive case) is probably roughly the same for interactive and static maps.

disputed capitals

Interesting, what do you mean? (Also displaying alternative capitals like Tel Aviv/Ramallah/Cetinje? I'm not sure if we want that.) I don't think it'd be particularly hard to display for either static or interactive maps, though.

map projections

Yes, this is the greatest cost of re-using our static maps. It's not that bad, though, and it also makes enhancing the maps in various other ways (zoom boxes, maritime borders etc.) much easier.

colour standardisation

I think the implemented approach should mostly just work in all cases now.

---

Perhaps users interested in this feature would be happy using the interactive deck once it's stable?

As described above, I'm not convinced that properly implementing this in the interactive deck is at all less effort than with static images. Much of the effort would indeed be shared with generally improving the interactive deck, but not all of it, and also I don't think that the issues that are critical to making the interactive map stable for the country->map cards and those critical to making it stable for country<->capital cards overlap. I'm also not all convinced that we should be tying this to the interactive map, which is currently experimental, especially given that interactiveness doesn't provide much benefit for this use-case — country->map cards are different since there interactivity enables something that is otherwise impossible.

---

in which template(s)

I think that adding the map-with-capital to the back side of both the Country - Capital and the Capital - Country cards would make sense.

and which deck(s) (standard/

As described in the previous comment, adding this to the standard deck in the cleanest way would be impossible. The cleanest way is creating a new field (Capital Map). Unfortunately, AFAIR (last I checked ~two years ago) it is not possible to update decks using AnkiWeb to add new fields (I think they're just ignored).

A hacky way could be to add the capital map to the map field, add appropriate suffixes to the image names and use CSS selectors to display the correct map in the correct place (like we do for blurred/non-blurred flags). (I think that updates to CSS can be deliverd via AnkiWeb.)

(Alternatively, maybe AnkiWeb note type updates have improved?) (There's also the option of making the upgrade a hard one (i.e. reset from zero), and if we want to deliver a large number of "AnkiWeb-update-breaking changes" it might be worth it, but I'd avoid this, if possible.)

extended)

No (technical) reason not to add it to the extended deck if it's seen as desirable.

However, as a first step, an experimental deck (along the lines of the interactive one) would probably be best, to gauge interest.

[axelboc]

Fair points all around, thanks for indulging me! Seems that static maps are the better approach, you're right. Even better if it can help improve the existing maps with zoom boxes and the like.

Thanks also for clarifying which templates would make use of the new capital maps. I'm not opposed to a CSS-based approach similar to the blurred flags to be honest, if it saves us from a breaking change.

Concerning the colours, I think your reasoning of adhering to the locator maps' three-level hierarchy is spot on. It looks great too.

Like you, I'm not 100% convinced with the star marker, though. I feel like it would make sense if we were using it together with the other makers for major cities and such. On its own, it looks a bit too much. Have you considered using the marker for capitals of subdivisions below (but in red, still)?

I wouldn't bother using a different marker for dependent territories.

When a zoom box is present, my gut feeling would be to show a simple red dot on the zoomed-out map  -- or even no marker at all if it would cover most of the territory -- and the main marker above inside the zoom box.

[aplaice]

I'm again at a stage where design feedback would be helpful (feedback from anybody/everybody is very welcome!).

---

I've added the capital markers to most of our maps and dealt with ~most of the edge-cases for these maps. (See #722.) (I'm not 100% sure how I'll deal with the remaining maps, but it's likely that it'll involve manually adding the markers, rather than automatically estimating the "parameters" of the maps and adding markers automatically, so I'd rather re-do this as few times as possible.)

I've gone with the marker for capitals of subdivisions, like you (@axelboc) suggested and I think it looks great! Thanks!

Zoomboxes

For maps with zoomboxes, I used small dots in the zoomed out map (again like @axelboc suggested). For now, I've only added a marker to the zoombox of the Comoros (see below), but I think that at least here, this configuration looks OK.

---

Accuracy of placement

Regarding the accuracy of the placement of the markers: I used the estimated map "parameters" to generate overlay coastlines (for each map) and checked that they overlapped with the existing coastlines. (See below for illustration; due to the overlap you can only really see it in the minimap (where only the overlay, not the original, is present).) For all of the maps, the two overlapped fully, showing that the estimated "parameters" were correct. Hence, (assuming that the capital coordinates (lon, lat) scraped from Wikidata are correct — I'll double check these later), the positions of the markers are correct.

Overlay border outlines

---

Markers near coasts

One slight possible issue for some of the capitals very close to the coast is that the placement of the centre of the markers on the coastline itself makes it look like the capital is partially in the sea (a particularly bad case is Senegal, where the capital marker hides the presence of a small peninsula, so it seems that the capital is completely in the ocean). However, it should be hopefully clear that the position of the capital is represented by the centre of the marker (how else?) and that the inner circle is no way linked to the spatial extent of the capital (some capitals will be much smaller than the marker, while some will be larger). I also can't think of a solution that doesn't cause a misleading effect in the opposite direction (making the capitals appear further inland than they are).

(TBH I'm not sure how Wikidata chooses the coordinates of cities, which obviously have non-zero (and sometimes) significant extent. When I compare with Wikipedia's coordinates (which I believe aren't always identical...), I'll see how much of an effect this has.)

---

Highlight circles

Some of our maps with small, but relatively "compact" islands or groups of islands have highlight circles. (e.g. Cape Verde).

The highlight circles usually have a fully opaque red border and a translucent (opacity≈0.12) red interior.

For the capital markers we're moving the focus from the country to the capital, so (as noted above), we change the colouring of other countries from cream to gray, that of the country in question from red to cream and make only the capital red.

It's not entirely clear what to do with the highlight circles. Some options:

1. Remove them altogether.
2. Change them from red to cream.
3. Change them from red to cream, but also reduce their prominence (make them less opaque). (How much?)

I ended up going with 3, keeping the 0.12 opacity of the interior, but also making the border less opaque (0.4). (Removing the circle completely caused the country to not stand out, while the border with a cream colour, but at full opacity looked weird.) I tested different values for the opacity of the border and ended up settling on the aforementioned 0.4, but I'm not confident of my choice.

Cape Verde

1 Circle completely removed

2 Cream circle (at full opacity)

3a Cream circle (border opacity 0.4)

3b Cream circle (border opacity 0.6)

3c Cream circle (no border — only "interior")

Malta

1 Circle removed:

2 Cream circle (at full opacity)

3a Cream circle (border opacity 0.4)

3b Cream circle (border opacity 0.6)

3c Cream circle (no border — only "interior")

Highlight "glow"

Some of our maps with extended island chains consisting of small islands have highlight glows. (e.g. Kiribati)

The highlight "glows" usually have a fully opaque red border and a translucent (opacity≈0.2) red interior.

Like for the highlight circles it's not entirely clear what to do when switching focus from country to capital. Here, I don't think that removing the "glow" altogether is at all viable, so there are two main options:

1. Change the glow from red to cream.
2. Change the glow from red to cream, but also reduce its prominence (make it less opaque). (How much?)

I ended up going with 2, keeping the opacity of the interior, but also making the border less opaque (0.6). Again (like for the circles), after many tests I think that this results in a decent appearance, but again I'm not confident. (The higher opacity than for the circles is because the glow is usually "closer fitting" and more "integral" to the country, but I'm not entirely sure.)

Kiribati

1 Cream glow (at full opacity)

2a Cream glow (border opacity 0.4)

2b Cream glow (border opacity 0.6)

2c Cream glow (no border — only interior)

2d Cream glow (border opacity 0.7)

Maldives

1 Cream glow (at full opacity)

2a Cream glow (border opacity 0.4)

2b Cream glow (border opacity 0.6)

2c Cream glow (no border — only interior)

2d Cream glow (border opacity 0.7)

Maybe 0.7 is better than 0.6?

---

An incomplete list of some of the remaining tasks:

1. Add markers to the remaining maps (8-ish).
2. Add markers to most of the zoomboxes.
3. Apply the modifications from the "Modifications" column. (This includes adding in some zoomboxes.)
4. Fix the glows in some of the zoomboxes (e.g. Antigua and Barbuda, Aruba)
5. Compare with 698.
6. Add sea "borders" to some of the Pacific Ocean islands (Add zoom boxes to maps of Pacific islands #267 (comment)). As mentioned in a previous comment, this should now be relatively straightforward. It'd be also better to do this before the final generation of the capital maps, to avoid redoing them.
7. Add some of the "parameters" of the maps (the projection/translation/zoom as well as the final coordinates of the capital(s)) and possibly the relevant wikidata id to the repo, in some "data dump" subdirectory. (I'm not convinced about this, but I expect that they might be potentially useful in the future, and as long as they're "versioned" (it's mentioned which version of the maps they apply to, and there's no expectation to keep them up-to-date) I don't think they'd add any maintenance burden.)

[ukanuk]

Those markers are far larger than necessary, and the "official" double-circle symbol has a white interior as you can see on examples at https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Maps/Conventions/Exchanges_maps

Also using special symbols for different city types is only really useful when the map has more than one city type. The Wikipedia maps with just a capital pin just use a plain dot (sometimes red, sometimes green).

Imo a plain red dot is better for these maps than the double-circle symbol.

The "official" list of symbols for reference are at https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Maps/Conventions