BIXI Toronto is (nearly) here!
After yesterday’s post, I went a bit nuts with working out the whole amateur radio grid locator thing (not that I’m currently likely to use it, though). I’d hoped to provide a shapefile of the entire world, but that would be too big for the format’s 2GB file size limit.
What I can give you, though, is:
- A Perl program that will generate a shapefile of an entire Maidenhead grid field, down to the subsquare level: make_grid.pl. You’ll need Geo::Shapelib to make this work. 324 (= 182) of these files would cover the whole world, and at 8MB or so a pop, things get unwieldy quickly.
- A Google Earth KML file covering the whole world in 20° by 10° grid fields: Maidenhead_Locator_World_Grid. (If you’re feeling nerdy, here it is in Shapefile format: Maidenhead_Locator_World_Grid-shp).
If anyone would like their grid square in Google Earth format, let me know, or read on …
Making KML Files
Several people have asked, so here’s how you convert to KML. You’ll need the OGR toolkit installed, which comes in several open-source geo software bundles: FWTools/osgeo4w/QGis. Let’s assume we want to make the grid square ‘EN’.
- Run make_grid.pl:
- Convert to KML using ogr2ogr:
ogr2ogr -f KML EN-maidenhead_grid.kml EN-maidenhead_grid.shp
- Alternatively, if you just want to extract a square (say EN82), you can use ogr2ogr’s ‘where’ clause to select just the geometry you want:
ogr2ogr -f KML -where "Square='82'" EN82-maidenhead_grid.kml EN-maidenhead_grid.shp
While we already know how to make trivial shapefiles with shapelib, sometimes that’s too tedious. Very frequently I get data in Comma Separated Value (CSV) format, and reliably importing/converting it can be a pain.
Here’s our sample CSV file,
"Easting","Northing","Library" 625539.6,4837170.9,"Dufferin St. Clair" 625862.0,4838241.1,"Oakwood Village" 626251.0,4835287.2,"Bloor Gladstone" 626671.7,4836922.6,"Davenport" 627227.2,4840006.4,"Forest Hill"
Here’s the VRT file for that CSV:
&amp;lt;OGRVRTDataSource&amp;gt; &amp;lt;!-- note that OGRVRTLayer name must be basename of source file --&amp;gt; &amp;lt;OGRVRTLayer name=&amp;quot;library_test&amp;quot;&amp;gt; &amp;lt;SrcDataSource&amp;gt;library_test.csv&amp;lt;/SrcDataSource&amp;gt; &amp;lt;GeometryType&amp;gt;wkbPoint&amp;lt;/GeometryType&amp;gt; &amp;lt;!-- your SRS goes here; I used EPSG SRID --&amp;gt; &amp;lt;LayerSRS&amp;gt;EPSG:2958&amp;lt;/LayerSRS&amp;gt; &amp;lt;GeometryField encoding=&amp;quot;PointFromColumns&amp;quot; x=&amp;quot;Easting&amp;quot; y=&amp;quot;Northing&amp;quot;/&amp;gt; &amp;lt;/OGRVRTLayer&amp;gt; &amp;lt;/OGRVRTDataSource&amp;gt;
Your CSV file will now behave like a shapefile, or indeed any other geo-format that OGR understands. QGIS is a bit picky – it doesn’t seem to always work out the path of the source file.
To prove these are real coordinates, here’s what I did to make a Google Earth KML file:
ogr2ogr -f KML -t_srs EPSG:4326 library_test.kml library_test.vrt -dsco NameField=Library
Technically, you don’t need to specify the SRS for KML output as it only supports EPSG:4326, but I found you got trivially different results if it was omitted.
Try this in Google Earth: library_test.kml