On Castine and its many tribulations

Castine is an imaginary country that once existed on the imaginary planet I prefer to call Ogieff. In fact, the imaginary planet doesn’t have an official name – it’s hosted at opengeofiction.net, which all the users call, simply, “OGF”. That initialism leads to my preferred name for the planet – just sound it out.

There is a real place called Castine – it’s a small town in Maine, USA. This is not that Castine.

I joined OGF in 2014, and Castine appeared and began evolving sometime in the year after that, I think – in 2015. I also became an admin on the opengeofiction.net website in that year.

During the period from 2015 to 2017, Castine became the locus of a kind of meta-proxy-war, where I used it as a stand-in for a never-ending argument I liked to have with my fellow OGF admins.

The issue in question was the rule about “verisimilitude”. I had long felt (and continue to feel) that OGF’s verisimilitude rule is a bad idea – it’s vague and impossible to enforce consistently. It has no objectivity. The principle is that mapping on the OGF world is supposed to be “realistic” in the sense that it eschews fantasy and sci-fi elements, and doesn’t contain cultural or cartographic artifacts that couldn’t reasonably exist in the real world. Hence, people who build 50 km bridges or tunnels are called out for violating verisimilitude, likewise more science-fictional elements like space elevators or fantasy elements like dens of dragons or nations of 1920’s-era talking sheep (all these examples really occurred at various times on the OGF planet).

Castine was (is) a borderline case of violating verisimilitude. Some users felt it violated the rule, others felt it was okay. My position was always something like: “since we can’t decide if this violates verisimilitude or not, but it’s really good mapping… c’cmon, people, let’s drop (or at least, fix) this stupid rule.

Of course, this was an unpopular stance. And in the long run, I lost the battle to remove or even alter the verisimilitude rule on Ogieff, and I made my peace with it.

One way that I made that peace with it, was to create my own, separate planet! In 2016, I started the planet Arhet as a kind of alternative project to Ogieff. By 2018, it had several active mappers and its own emerging community. The principle concept behind Arhet is to be a kind of “libertarian” reinterpretation of OGF. It has very few rules: no verisimilitude rule, no assigned territories, etc. And somewhat to my own surprise, it sorta kinda works. The key to it working, I reckon, is that unlike OGF, Arhet is not “open” to any and all comers. There’s an application process to join, and although I enforce almost no rules for the planet, I do stand firm that arguments or disagreements between users that escalate to my remit will simply result in immediate banning of all parties. That keeps everyone participating on best behavior, I guess.

The irony is that then, in 2021, I took over the hosting of the original opengeofiction.net. So now I host a little federation of two imaginary planets, Ogieff and Arhet, which have substantially overlapping user communities but having quite different rule systems. And I’m okay about that. I inevitably yield to my fellow admins, whose hard work and dedication to the project I admire, when it comes to matters of rules and judgements on Ogieff. But off to the side, I run Arhet singularly, and I insist on its fundamentally anarchic state.

In around 2020, the creator of Castine (Ramasham) was banned from Ogieff – ultimately for violating another, different rule: the rule prohibiting direct upload of data copied from OSM. OSM is OpenStreetMap, which is a map of the Real World™ in the same technological vein as our two imaginary planets. This is the so-called “slippy map” paradigm, originally popularized by mapquest and perfected and dominated by google maps. OSM runs on and supports a whole complex ecosystem of software that is all open source, as a kind of alternative to google maps, and that’s why it’s easy (uh, “easy” in a financial sense, not “easy” in a technical sense) for us to use the same software to run OGF and Arhet.

Anyway, there is (and there has always been) a rule prohibiting copying OSM data into OGF. Ostensibly this is motivated by paranoia about copyright violation, but in fact copyright has little to do with it, in my own estimation – there are easy ways to avoid issues around copyright as long as you follow along with OSM’s “attribution and re-use” rules. The real motivation for the prohibition is legitimate, though: on OGF, we want to discourage mappers from spamming the planet’s map with cut-n-paste copies of real-world places. It’s low effort geofiction and discourages creativity.

That said, when I set up Arhet I decided to also not enforce OGF’s “no real-world (OSM) data” rule. And indeed I myself played around with cutting and pasting some data from OSM, including an ephemeral instance of country I called “Lingit Aani” (this is Tlingit language) – a copy of the islands of Southeast Alaska but minus any nearby continent, as an open-ocean archipelago. I later deleted this, but there are multiple copy-the-real-world geofiction projects going on in Arhet, these days, including clones of Sakhalin Island (Siberia) and Romania’s Bucharest, and at least two Polands – perhaps more.

I guess Castine’s creator, Ramasham, had been doing some copy-pasting of OSM data to increase the detail and complexity of Castine’s cartography. Notably, this airport is a modified cut-n-paste copy of one in the real world, with only the names of things altered. And so Ramasham was banned from OGF. Rules are rules, and that “no copy from OSM” rule is actually probably the most common reason for mappers to be banned from the site.

Now we come to February of this year (2022). The admin team at OGF, moving to “clean up” various abandoned territories around our (imaginary) globe, decided finally to delete Castine once and for all. And I had a moment of deep sadness and regret. Despite my having leveraged Castine back in 2016 as part of my proxy war with the other admins over the verisimilitude rule, in fact I really, really like Castine.

From a technical standpoint, Ramasham was at best a mediocre mapper. But the imaginary country is full of cartographic whimsy and playfulness, the naming is thorough and inventive and culturally intriguing, and the detail in some parts is quite incredible. I thought it was worth preserving.

So I considered: Ramasham’s ban from OGF was for violating the “No OSM data” rule; if there were any other issues with Castine, they were issues with the “verisimilitude” rule; so… hey – Arhet doesn’t have those rules!

The solution was obvious. I decided I’d move Castine to Arhet. And even more conveniently, the exact latitude and longitude of Castine’s old Ogieff location was open an unused on Arhet. I figured it should be quite easy to simply “cut-n-paste” the whole of Castine into Arhet.

Yikes! This turned out to be the far from the case – it was not easy. Not at all. Castine included almost 2 million distinct GIS objects: nodes, ways, relations. This was not trivial to simply cut, paste, and upload into the new site. And further, the data quality was quite poor, from a technical standpoint. Thousands of improperly stacked ways on shared nodes, hundreds of lazily-crafted or incomplete data relations, etc.

I have spent the last week in a kind of Alice-in-Wonderland nightmare of trying to rescue Castine and upload it to the Arhet planet. I think that as of this morning, that I have succeeded, but not before almost destroying the Arhet server altogether in the process.

Without going into a lot of detail, it seems that there were a couple of relations (a technical term in this case for a type of data object used in OSM GIS software) that were apparently so badly constructed that they broke the server’s database. Since I had to do a kind of trial-and-error search to finally identify these objects, it took a very long time. I’d upload some subset of the full Castine dataset, and watch to see if the database crashed or not. If it didn’t, fine, I’d try another set of data. If it crashed, I’d have to go back to the last backup of the server, restore it, and try again. I think I did a backup-restore cycle maybe 12 or 14 times over the last week on the Arhet server. It was painful, and tedious, and immensely frustrating.

The crash-provoking objects in question are puzzling. I still don’t understand why they crash the database. And given my difficulties in identifying them (and surviving them – see below), I probably won’t spend time, any time soon, trying to figure them out. They are “Giant Chessboards” – three of them. Interestingly, Castine also has other “Giant Chessboards” (e.g. here) that do not cause any kind of data problem. They are apparently implemented differently, in their details.

The problem was compounded yesterday, when, much to my shocked dismay, the server-level backup-restore functionality offered by my hosting provider, Linode – that I’d been so repeatedly abusing – suddenly and inexplicably failed to work.

So for a day (yesterday) the world was Arhetless. The server was down. I was in a panic because it seemed I’d have to fully rebuild the server from scratch. And it was only pure luck that I even had a copy of the map data, because I was still running a kludgey render engine (map drawing process) for Arhet on a different machine.

I wrangled with tech support at Linode, and they finally held my hand (or was it that they held my server’s hand?) through a successful if stressful restoration of the server’s image.

Let’s just say, these days Castine now has a quite colorful meta-history.

I reached out to the creator of Castine, sending an email to the address on record at OGF, announcing its restoration in Arhet. I would absolutely welcome and be pleased if that person would come back and take up work on the country, again – they won’t be constrained by the rules and regulations on Ogieff. Unfortunately I haven’t heard back. I speculate that there might be some bitterness about the whole business of having been first praised and then banned, back a few years ago.

The link to Castine-in-Arhet is here:


Please feel free to explore. I decided not to bother with adding extensive screenshots for this blog post – the point of having the Castine map hosted on the server is that you can explore easily directly on the website.

Happy mapping.

Music to view geofiction to: Dawg Yawp, “Lost At Sea.”

The State of the OGF Topo Layer

This will be a fairly long write-up, so depending on your interests, you can skip sections that aren’t useful to you.

First I will write about the OGF topo layer, and give a tour of its current status, with some discussion of how it works.

Then in subsequent sections I will try to discuss how to create or edit your own contributions to the OGF Topo layer.

Part I – Introducing The OGF Topo Layer

The term “topo” (short for topographic) refers to a style of map that shows the physical elevation of land, either through shading or drawing contour lines or both. There are many topo renders available for the OpenStreetMap platform. My own favorite for daily use is the Cycle Map layer on OSM – not for any specific reason except that it’s easy to get to – it’s included right there in the layer selector for the OSM site. The best known, however, and one of the oldest, is the separately built and maintained OpenTopoMap. The code for OpenTopoMap is freely available on github.

All the various implementations of topo style for OpenStreetMap rely on the easy availability of free data from the United States’ NASA. This agency did a planet-wide survey of the elevation of all the land in the world on an arc-second (approx. 30-meter) grid, using radar, and published that data, online, for anyone to use. This data is called “SRTM”. Developers implementing OpenStreetMap’s various topo layers are able to download and use this SRTM data to use as a raw source of the detailed topographic information needed to draw the map. So, in the case of OpenTopoMap, the SRTM data is loaded to the render machine, processed in various ways, and turned into the hillshading, contour lines, and map-elevation color shading that we all know and love.

For the real world, getting topo data is matter of launching a spacecraft or satellite with a little radar range-finder on it, and flying over the surface of the earth finding how high each part of the earth is relative to some baseline (i.e. mean high sea level). Easy! But OpenGeofiction is on a fictional planet. To repurprose Virginia Woolf’s famous line: There’s no there, there.

Instead we have to sit down and make up each square of elevation information – there’s got to be a 30-meter square grid for our entire imaginary planet, and we have to invent the elevation for each and every square! And just randomizing this isn’t going to work – real world topographic data betrays the evolved geophysical patterns of our planet, influenced by everything from plate tectonics to vulcanism to erosion to human landscaping. The data is going to have to either be “drawn” by creative human hands, or “drawn” by well-trained machine-learning AI’s. Both are possible in principle, but then we have the data problem.

The data problem is this: the NASA SRTM format was developed for storing real world data. But no one ever thought: we need a nice, user-friendly, SRTM file editor! Why? Because no one needs to edit real-world data. It came from a super-precise scientific gadget, who’s going to need to edit that? They could only mess it up.

So there simply does not exist any easy way to get the “imaginary” SRTM files that we need for our topo layer. Some geofiction genius is going to need to write a converter.

Luckily, OpenGeofiction has such a genius. The original creator of OpenGeofiction, Thilo, wrote a little program that turns a standard OSM XML format file (.osm) that has been filled with hand-drawn contour lines (tagged contour=elevation / ele=nnn) into a pseudo-SRTM format file (.hgt). Then we just need to install the standard OpenTopoMap software on our render server, copy the pseudo-SRTM files across, and voila, topo for OGF!

Still, we have a whole planet to cover. At this point in time (the time of writing this article, early 2022) the overall coverage for OGF’s topo layer is tiny, and of fairly low quality, on average, so far.

One of the main reasons I started my “OGF Mirror” project, last year, was because Thilo had decided he could no longer invest the time and energy required to support the topo layer for OpenGeofiction. I had a strong desire to see the topo layer continue to be supported and expand. Eventually that “OGF Mirror” became the migration project and I and user wangi and some other admin took over running OGF from Thilo, with his blessing. So it was my interest in topo that led to my taking on all this work for OGF, and therefore it remains of a focus of my efforts, moving forward.

Part II – The Current OGF Topo Zones

OpenGeofiction currently has 14 actively maintained topo zones. Here they are, in alphabetical order.


This zone has been created by mapper SwissCrusader. It’s a first draft, and clearly needs a lot of cleanup work, but it’s an excellent and ambitious start.



This zone actually is two smaller areas that have been combined because of their close proximity. The older is the topo work for Khaiwoon, on the eastern tip of the Gobrassanya peninsula. The territory is one of the oldest on OGF. It was developed by user isleño with a lot of additional mapping by user histor. The contours were drawn as a collaboration between thilo and isleño. The other is the background topo for Gobras City, to the northwest. Gobras City is one of the most successful wholly public and collaborative projects on OGF, created by a very large number of different mappers over almost a decade, now. User Ūdilugbulgidħū volunteered to draw contours for the city, and in my opinion, they are quite excellent. Obviously, since the contours were drawn after much of the city, and since there is work in the city drawn without a strong awareness of the contours, there are areas where the human development (roads, etc) doesn’t really properly “match” the contours as drawn.



This zone is also actually two adjacent areas combined because of proximity. The older part, to the west, is my own work (user Luciano), drawn for my territory Ardisphere, in 2014-2016. I think it has well-done areas, but it’s quite noticeably incomplete, full of lacunae and missing expanses and weird glitches where the contour work is too sparse to properly cover the map. The newer part, currently in development by user Martinawa, is the largest single expanse of topo work on OGF, and still in early stages across most of the territory, but it’s got a lot of promise.



This is a quite small but complete set of contours for an island territory drawn by mapper Ūdilugbulgidħū.



This zone includes several islands in a chain called Iscu, drawn by mapper Lithium-Ion. The contours are quite detailed and excellent.



This zone includes a few of the southern islands of a the nation called Izaland, by the user Izaland Terramorphing Committee. I’m looking forward to seeing more of Izaland getting contours.



I (user Luciano) drew these islands as part of a collaborative effort between myself and mapper deltanz. I later turned over the islands to deltanz. Personally I think they are my “most complete” set of contours among those I have done.



This is a new effort by mapper Huachachi. Kofuku is an immense territory and so far these are just a few islands off that country’s north coast. They are excellently done, and I’m looking forward to seeing more of Kofuku with contours.



I (user Luciano) did a small spot of contours in collaboration with user Leowezy some years ago, in the southernmost spot of this zone, at the Joenji Peninsula. Leowezy has subsequently been gradually adding other areas of coverage for his territory, Kojo. Hopefully will come in the future.



This zone actually overlaps not just the territory of Makaska, but also the one to the south, called Ooayatais. I (user Luciano) own both of these territories. The northern territory, Makaska, has a very complete set of contours and is work I’m quite proud of. The southern territory, Ooayatais is much lower quality and, for now, also quite incomplete. It’s my “current project” with contour mapping, however, and hopefully sometime later this year I’ll upload a major update.



This is the oldest and, arguably, best of all the topo zones on OGF. User thilo, the original creator of OpenGeofiction, uploaded this topo zone when he first created the OGF server, for his territory Roantra. It is the archetype of OSM-style topo work.



This is a small project done by user Toadwart for his outlying (overseas) territory of his country, KA076 (apparently this mapper recently decided to change the name of the country, and the new name hasn’t been decided on). Anyway, the contours are clearly still in development but I’m looking forward to seeing more progress.



This zone, a small island, was created by mapper Ūdilugbulgidħū, but he subsequently gave up the territory. It’s someone’s chance to take on an already-existing topo project.



This is another of my own (user Luciano) territories. The Duchy of Tárrases is the one case where I quite successfully imposed a set of contours on an already-created map. I’m quite happy with the result. The surrounding islands used to be owned by me, too, but for now they are in a bit of limbo. For that reason I haven’t bothered to repair the mess of half-finished contours on those surrounding islands.


Part III – Create A New Topo Zone

There is quite a bit of work involved in creating a new topo zone for the ogf-topo rendering process. Multiple new working and data directories must be created, code must be added to xml layer specifications and data-processing scripts, and the proper raw contour templates need to be created and populated with initial draft contour data.

Therefore if you want to create a new topo zone for your OGF territory, you need to contact me and we can discuss, so I can get things set up and I can create the templates you’ll need to draw your contours (see next section). There is nothing wrong with diving in and drawing contours for yourself before contacting me, but bear in mind you’ll probably end up doing a lot of cutting and pasting and manipulation using the JOSM editor once I’ve created those templates for you, because I will no longer accept contour data drawn in files other than the pre-created templates.

If you’re trying to decide whether or not you want to create a topo zone, one good way to get a feel for what’s involved is to download one of the osm-squares from the server (see below) and just go ahead and open that up in JOSM and try to get a feel for how it works and what’s involved. Start with something small, complete and well-done, like the January Islands or Hesperis (see above).

Part IV – Edit or Improve An Existing Topo Zone

In the past, I’ve allowed users to simply submit new, hand-drawn “contour files” which I then clean up and process using the tools at hand. However, I have found that the first step – cleaning up the submitted files – can be quite tedious and time-consuming, and further, I often end up repeating work as newly submitted files have the same problems as previous iterations.

I would like to move toward a more reliable system of iterative improvement. To do this, if there is an already-existing topo zone and you want to add to it or improve it, you must download the existing osm-squares (contour files) from the ogfsrtm server, edit those, and send the edited copies of those files back to me. Do not try to bypass this process – I have special tags embedded in those contour files as found on the server, and I’ll know if you haven’t used those as a basis for your edits.

You can find downloadable individual squares for most topo zones at this location on the ogfsrtm server: https://ogfsrtm.rent-a-planet.com/osm-squares/

If a given square is missing from the server, contact me and I’ll create an initial template for that square and post it there, that you can then edit. Don’t try to create squares not found on the server.

Part V – An Alternative Pathway To Maintaining Your Own Topo Zone

If all this business of drawing vast numbers of contour lines in JOSM is not your style, there is, in fact, an alternative. You can directly submit NASA-SRTM format compliant .hgt files. This bypasses the whole contour conversion process, and would be quite a bit easier for me to do.

That said, so far, no one has done this successfully. There have been challenges to finding a program that produces .hgt files in the exact NASA-SRTM format expected by the OpenTopoMap rendering software. If, as a community, we find such a tool in the future, that may make a lot of what’s written above obsolete and we’ll have a better way to do things, moving forward.

Regardless, if you want to try doing it this way, you still need to contact me in advance, so I can set up the new zone on the render server – that aspect won’t change. Then you’d send me the pseudo-SRTM files (.hgt) so I can post them on the ogfsrtm server in the proper directory, since that’s where the render server expects to find them.

Music to draw contours to: Haddaway, “What is love?”

On render “ghosts”

Thank you to everyone on the Opengeofiction server.

We had unexpected longer downtime last night and this morning.

The render server had some problem (not really clear what went wrong), and needed to be restored from backup (not part of the plan), and then the ogf-carto render was reset (which had been the plan).

Just want to say thank you to the community for your patience.

Those who have been struggling with “render ghosts” – I think they are all fixed now. You can see one really good example here:


For comparison, the ogf-topo render still has the ghosts (yes, topo needs maintenance work, I know!):


UPDATE: by the way, Happy mapping!

Music to fix servers by: Cake, “Long Line Of Cars.”