While I’ve used OpenStreetMap data before, I’ve never added anything to it. That changed after going to Mappy Hour last night, and meeting Richard Weait. He has a bunch of useful tutorials on his website.
in which I discover OpenStreetMap editing
toronto data updated
Hey, they’ve updated most of the data sets on toronto.ca | Open!
Leave the first comment ▶More on iPhoto GPS weirdness
Okay, so I geek out a lot here, so here’s a summary: In a test of 1600 images, iPhoto moved the recorded GPS location of a picture an average of 6.17m, and in one case moved the image 11.25m from its correct position.
I created a 40×40 array of points approximately 5m (okay, 5 UTM units apart, precisely) and assigned the locations to JPEG files using ExifTool. These files were imported into iPhoto, then exported. The before and after coordinates were plotted and compared:
- The green crosses are the original coordinates
- The red crosses are the coordinates assigned by iPhoto
- The dashed lines map the before coordinates to the after.
In real life, I realise it’s difficult with most consumer GPS units to resolve points 5m apart. It’s pretty egregious of Apple, however, who appear to take great pains to retain all the camera’s metadata, to mash the stored coordinates so badly.
Leave the first comment ▶My Neighbourhood, Canada Day 2010
I went for a bike ride on Canada Day. Click on a bicycle icon to see what I saw.
2 comments so far, add yours ▶Don’t trust iPhoto’s exported GPS coordinates
John the new jersey geographer put this better than me, but it appears that iPhoto rounds exported GPS coordinates to the nearest integer second of arc. There’s really no reason for them to do this, and it’s caused me to waste several hours tracking down why my tagged and exported photos didn’t match up.
Looking at the output data, I’m not sure if it’s to a second of arc – it appears to be rounding to the nearest hundredth minute, or approximately 0.000167°. Since GPS location uncertainty is in the fifth decimal place, this aliasing of the data is annoying.
Leave the first comment ▶The highest point in Toronto
The highest point in Toronto has an elevation of 211m, and appears to be in the middle of one of York University‘s playing fields, just southwest of Keele & Steeles W:
The red blob is the 211m contour, and the centre point is at 43.779325°N, 79.492655°W. The contour was derived from the MNR DEM data for the province.
The city says the highest point is 209 m (at intersection of Steeles Ave West and Keele St), which is pretty close in all three axes.
Leave the first comment ▶MNR DEM tiles
So I got the DEM tiles for my zone, couriered from Peterborough. Even zipped, they are several gigabytes. Here’s a visual guide to the tiles I got:
It seems that every project I work on is split across several tiles. My fair city is no exception:
Most of the city is in tile 87, but the northern and eastern corners poke into tiles 91 & 92. Merging the files and pulling out the area isn’t that hard.
First off, we need to know the extents we want. Conveniently, I’d already transformed the Open Toronto data to the same CRS, so I could just go from the extents of one of the city shape files:
$ ogrinfo -al ../open-toronto-shp/dest/2958/city-wards/TCL3_ICITW.shp | grep '^Extent' Extent: (609538.195527, 4826360.800158) - (651613.577420, 4857439.389359)
You can then use gdal_merge.py to merge the tiles. Annoyingly, rather than using the familiar ‘lower left – upper right’ coordinate convention for bounding box, it uses ‘upper left – lower right’, so working out a buffered bounding box is a bit of a pain:
gdal_merge.py -v -of EHdr -o Toronto.flt -n -9999 -ul_lr 609000 4858000 652000 4826000 `find . -iname 'd*.flt'`
The MNR DEMs are shipped as ESRI .hdr Labelled files, 32-bit floating point. The CRS used is NAD83 Zone 17N. For all that they’re large, they’re quite quick to load and move around.
Leave the first comment ▶Land Information Ontario – or, how I semi-accidentally ordered 3.5GB of terrain data
The Ontario Ministry of Natural Resources has a fairly well-hidden service that provides free geodata to the general public. One has to register with a sign and e-mail form, but there’s a large number of useful data sets available. The only disadvantage is that you can’t tell if your order will be delivered by download, or physically burnt to DVD and mailed from the MNR in Peterborough. The municipalities shown above were a download; the DEMs of my entire UTM zone? They’re in the mail …
untangling CanVec
It’s almost as if NRCan doesn’t want anyone to use CanVec. I mean, it’s a free and comprehensive data set for the whole country; anyone who can type in a postal code and click a couple of times can download the CanVec map tile for where they live. But on the other hand, cracking open that download reveals an impenetrable mess of information that probably makes most users go away.
I’ve played with it before, and do occasionally drag out a layer at work, but have never got much further than that. GIS types must be very quiet, because Using CanVec – maphew and CanVec – OpenStreetMap Wiki are about the only public discussions of its content.
CanVec is delivered in two formats: Geography Markup Language (GML), and our friend, the Shapefile. While the GML version contains relatively few files, all the tools I have choke on the data. So shapefiles it is.
Opening up the archive for the Toronto area (it’s tile 030m11) I see 192 files. Four of those are (not very useful) metadata files. Realising that a shapefile ships as four files (the mandatory shp, dbf and shx files, plus the optional prj file) that’s 47 layers. The file names look a bit like this: 030m11_6_0_BS_1250009_0.shp, 030m11_6_0_BS_1370009_2.shp, 030m11_6_0_BS_2010009_0.shp. The names really do mean something:
030m11_6_0_BS_1370009_2.shp |--+-| |+| |----+-----| | | \ Layer Code and Type | \ Version \ Map tile
CanVec – Entity Names and Codes, Edition 1.1.0 (XLS) explains the layers, and how they relate to the shapefile names. Rather than relating unique layer codes to layer descriptions, the Entity Names & Codes document has it backwards. So I made the much simplified canvec_simple-20100523.csv which lists layer codes against attributes in a more sensible manner. I added a derived ‘name’ column, which I use for layer naming from these files. The layers use EPSG:4617 (NAD83 CSRS) coordinates.
Tip of the hat to maphew – Revision 123: /trunk/gis/canvec for providing a file that was the ‘Aha!’ moment.
One comment so far, add another ▶use and abuse of elevation contours
I’d never really looked at elevation in GIS data before, mainly because the data sets are big and I didn’t understand the format. I believe that in GeoGratis, NTDB and its successor CanVec provide elevation data, but those are vector formats. Most terrain data is delivered in DEM rasters, and in Canada you can get them from GeoBase.
GeoBase DEM files come in archives containing two tiles, the east and the west. I’m not quite sure why they do this. Unless you live in an area of spectacularly interesting terrain, loading them straight into your mapping package will likely result in a large splodge of flat greyness. Because they are 2D arrays of spot heights, there’s not much variation between neighbouring points, unless you’re at a cliff.
Another issue you need to address in reading DEM files is the handling of unknown values. gdalinfo will show you the value in a line like
NoData Value=-32767
Unless you filter that value out, your DEM file will appear to have holes approximately 4x the height of Everest. This causes problems if you try to make a colour map.
Here’s the DEM for my neighbourhood, translated and cropped using gdalwarp, and false-coloured in QGIS:
Not surprisingly, Taylor Creek runs through the lowest ground (funny how water does that …). I could have picked off spot heights with QGIS’s ‘Identify Features’ tool, but contours are neater:
I made the 5m contours with gdal_contour, using the following command (on the terrain data which I’d converted to GeoTIFF):
gdal_contour -a elev -3d kennedy_park.tif kennedy_park-contours.shp -i 5.0 -snodata -32767
Looking at that map, and despite the somewhat wibbly nature of raster-vector converted contours, the elevation of my house is about 167m. My GPS – a Garmin GPSMAP 60CSx – contains a barometric pressure sensor, and on a day I’d remembered to calibrate it by the lake, it said I was at 166.9m above sea level. Neato!
Update: just to show that Canada has some wiggly bits, here are some contours for Grotto Mountain, not far from Canmore, AB:
These are 50m contours, though – 5m would just be a blur.
