Title OpenStreetMap: Building a great map while everyone tells you you’re doing it wrong.
- ‘The Map’ — http://www.openstreetmap.org . It supports routing now, too.
- QGIS, an open GIS manager. It’s rather good — http://qgis.org/
- The OSM Wiki; ridiculously complete documentation: https://wiki.openstreetmap.org/wiki/
- OSM Help Stack Exchange-style question/answer: https://help.openstreetmap.org/
- All of the OSM stats! — https://wiki.openstreetmap.org/wiki/Stats
- Toronto map growth animation — http://www.geofabrik.de/gallery/history/index.html#toronto
- Crowdsourced geocoding (+ lawsuit from Canada Post) — http://geocoder.ca/
- Open Data Commons Open Database License (ODbL) — http://opendatacommons.org/licenses/odbl/
- Canada’s new Open Government portal — http://open.canada.ca related: Toronto Open Data — http://toronto.ca/open
- CIPPIC Open Licensing Project (CLIP) — http://clipol.org/
- Humanitarian OpenStreetMap Team [HOT] — http://hotosm.org/
- OpenCycleMap — http://www.openstreetmap.org/#map=13/43.6666/-79.3785&layers=C
- The rather wonderful /uMap/ — https://umap.openstreetmap.fr/en/
Original GTALUG note: OpenStreetMap links from the other night.
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="firstname.lastname@example.org"/> <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"/> </node> </osm>
for more details, please see:
Minerals and waste joint plan consultation – North Yorkshire County Council http://northyorks.gov.uk/article/23999/Minerals-and-waste-joint-plan-consultation
Outline traced from http://northyorks.gov.uk/media/30250/Supplementary-sites-consultation—January-2015/pdf/Supplementary_sites_Consultation-_Web_Version.pdf
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?
The tidy, militaristic Ordnance Survey came up with the National Grid reference system, where large grid squares were given letters, and the rest of the reference was given numerically. Wikipedia gives a better graphical explanation than I could:
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.
The reference site for these systems is Thierry Arsicaud’s excellent Notes on the “Modified British System” used on the European Theatre of Operations during the WWII. Thierry, however, wasn’t trying to use these historical map references in a GIS, so his work needs a little massage to get to be used with QGIS.
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:
We can turn this into a PROJ.4 definition:
Projection - Lambert Conical Orthomorphic → +proj=lcc Ellipsoid: Bessel 1841 → +ellps=bessel False Easting : 700000 → +x_0=700000 False Northing : 600000 → +y_0=600000 Central Meridian : 14.0° → +lon_0=14 Central Parallel : 39.5° → +lat_0=39.5 +lat_1=39.5 Scale Factor : 0.99906 → +k_0=0.99906 (other proj.4 terms) +units=m +no_defs
or in one line,
+proj=lcc +lat_0=39.5 +lat_1=39.5 +lon_0=14 +k_0=0.99906 +x_0=700000 +y_0=600000 +ellps=bessel +units=m +no_defs
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.
Huge thanks to Thierry Arsicaud, both for the great reference website, and also for the e-mail correspondence helping explain the parameters for the GSGS Italy South system. Props too to the Geographic Information Systems Stack Exchange folks for help with working out the proj.4 settings.
Hey! This is really old! The current version of Raspbian has QGIS 2.4 included in the repository. Just install that. It won’t run very fast on single-core Raspberry Pis, though.
- Install Raspbian:
- Update Raspbian from its Debian wheezy base to Debian jessie:
sudo vi /etc/apt/sources.list# or use your favourite editor
- change all references of
sudo apt-get update
sudo apt-get upgrade# this will take a long time, with occasional user prompts
sudo apt-get dist-upgrade# this will take a very long time …
- Install qgis:
sudo apt-get install gdal-bin qgis
This will install QGIS 2.2. It’s a bit slow for general use, but it does work …
(modified from my gis.stackexchange answer: linux – GDAL and QGIS Raspberry Pi. Mainly just so I would have a place to put the image.)
Generated using ptrv/gpx2spatialite, rendered in QGIS as lines with 75% transparency.
@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 TAFL databases — which contains locations and technical data for all licensed transmitters — are now open data. You can find them here: Technical and Administrative Frequency List (TAFL).
- 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.
- Here’s a raw dump (very little metadata, sorry) from 2013 in the wonderful uMap: Ontario Microwave Links.
- 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.