It looks like the Bitcoin Map website adds points illicitly to OSM through a Google Maps interface. This is rather bad.
Update: they’re fixing this …
Here’s a test run I took to see if the data was really being added to OSM:
Here’s the POI data, in raw OSM XML:
<?xml version="1.0" encoding="UTF-8"?>
<osm version="0.6" generator="CGImap 0.3.3 (28262 thorn-02.openstreetmap.org)" copyright="OpenStreetMap and contributors" attribution="http://www.openstreetmap.org/copyright" license="http://opendatacommons.org/licenses/odbl/1-0/">
<node id="3383877893" visible="true" version="1" changeset="29257856" timestamp="2015-03-05T02:56:47Z" user="BitcoinMaps" uid="2135320" lat="43.7298277" lon="-79.2721787">
<tag k="addr:city" v="Bemidji"/>
<tag k="addr:housenumber" v="134"/>
<tag k="addr:street" v="Woodfern Drive"/>
<tag k="contact:email" v="email@example.com"/>
<tag k="contact:phone" v="+1 416 555 1234"/>
<tag k="contact:website" v="http://example.com/"/>
<tag k="description" v="i have totally made this up to see if it will be added to OSM even though the location was derived from Google Maps"/>
<tag k="name" v="Entirely FictitiousName"/>
<tag k="payment:litecoin" v="yes"/>
<tag k="shop" v="books"/>
Growing up in a small country, I assumed the whole world used metric grid map coordinates. I mean, why would anyone bother with those tedious latitudes and longitudes when you could have your location defined by something as neat as NS539555?
During WW2, the UK war office extended this system across most of Europe. Since most European countries didn’t use exactly the same Transverse Mercator projection as the UK did, a number of existing mapping systems were pressed into use, but using the same interleaved alphanumeric format as the OS grid reference.
In this example, I’m going to concentrate on the South Italy zone, as that’s where I was asked to look at some war diaries from 1943. The system is similar to the OS grid, but the main difference is that the major grid reference is often given in lower case. So RN in OSGB would most often be denoted rN in the Modified British system. Both would refer to a 100 km square at (700, 700) km from the origin. (The exceedingly nitpicky might point out that RN is never used in the UK as it’s somewhere in the Atlantic, west of Ireland. To them, I say: Well, bless your heart …)
The key to both the OSGB grid and the Modified British system is a 2500 × 2500 km square, split into 25 500 km squares, and given a letter, a … z with i excluded:
Each letter encodes both an easting and a northing; so r is (500000, 500000). About the easiest way to unpack this encoding is through a simple string lookup:
result = SEARCH(letter, "VWXYZQRSTULMNOPFGHJKABCDE")-1
easting = result MOD 5
northing = INT(result / 5)
where SEARCH is a function which returns the position of a letter in a string (so SEARCH(“V”, “VWXYZ…”) returns 1).
When applied as per the GSGS South Italy system, you get something like this:
These major grid squares are in turn split into 25 minor squares of 100 km side:
Or overlaid on a map:
For grid references of higher precision, a series of numbers is appended. There should always be an even count of these numbers, for reasons which should become clear soon. Here is the rC square, split into 10 km references:
These two digit references are about the shortest/least precise you might ever see. Overlaid on an appropriate sheet from the McMaster archive WWII Topographic Map Series (which are CC BY-NC; for which, many thanks), you get:
The actual projection details are given on each map:
In QGIS, you can plug those values into the Custom CRS manager, and you will be able to work in these antiquated coordinate systems with ease:
I haven’t yet quite managed to work out some of the other GSGS coordinate systems. My work on North Italy is a stubborn 100 km off true, for no well-defined reason. I haven’t managed to work out unpicking alphanumeric grid references into geometries automatically, either. These will come later.
Finally, some of the coordinates you might see might not meet these specifications. In the limited survey I’ve done, I’ve noted:
references with the major grid missing, so rCxy… was written as Cxy….
references to ‘MR’ (map reference), with no alphanumeric part, such as MR 322142 (from here), which would be more correctly given as rC322142.
@MaptimeTO asked me to summarize the brief talk I gave last week at Maptime Toronto on making maps from the Technical and Administrative Frequency List (TAFL) radio database. It was mostly taken from posts on this blog, but here goes:
One of the many constraints in building wind farms is allowing for radio links. Both the radio and the wind industries have agreed on a process of buffering and consultation. Here’s how I handled it in Python: Making weird composite shapes with Shapely.
The format is a real delight for all legacy-data nerds: aka a horrible mess of conditional field widths and arcane numeric codes. I wrote a SpatiaLite SQL script to make sense of it all: scruss/taflmunge. This (kind of) explains what it does: TAFL — as a proper geodatabase.
In a fabulous piece of #opendatafail, Industry Canada have migrated all the microwave data (so, all links ≥ 960 MHz) to a new system which doesn’t work yet, and also stripped out all of the microwave data from recent TAFL files. They claim to be fixing it, but don’t hold your breath. If you want data to play with, here’s Ontario’s data from October 2013 (nb: huge) — ltaf_ont_tafl-20131001.
I’ve used Shapely before for more sensible things, but it’s a dab hand at driving anything Cartesian — like my old HP-7470A pen plotter. Here’s some crude code to draw shapes and hatches in HP-GL: hpgl-shapely_hatch.py.
More silliness like this in my other blog under the plotter tag.