This tutorial assumes you have either a SHP file or GeoJSON file with your data ready to go and project at WGS1984 (i.e., 4326). It also assumes you are operating under a Unix environment.
- OGR
- Brew
- Tippecanoe
- Mapbox.com Account
SELECT | |
huc_6_name, | |
ST_AsGeoJson(ST_Multi(ST_Union(CAST(t.geometry AS Geometry)))) as huc_6_dissovled | |
FROM | |
territory AS t | |
WHERE | |
huc_6_name = 'Potomac' | |
GROUP BY | |
huc_6_name |
SELECT | |
r.id AS report_id, | |
t.id AS territory_id, | |
t.huc_12_name, | |
t.huc_10_name, | |
t.huc_8_name, | |
t.huc_6_name | |
FROM | |
territory t, | |
report r |
CREATE EXTENSION postgis; | |
If this fails to run make sure GDAL is installed: | |
apt-get install gdal-bin | |
## Convert your SHP File to a GeoJSON File | |
1. Download and Unzip your SHP file | |
2. Change to the SHP file directory | |
3. Convert the SHP file to a GeoJSON file | |
```` | |
ogr2ogr -f "GeoJSON" my_file.geojson my_file.shp | |
```` | |
## Convert your GeoJSON File to Mapbox Vector Tiles |
Effectively selecting colors for your choropleth map can be intimidating. Thankfully there are a couple of resources that can help us out.
The first is the ColorBrewer website which allows you to tinker with a preset or custom color pallette over a live map.
The second is a preconstructed D3 Map from the mbostock library that contains pre-defined colors, constructed using ColorBrewer.
Before we can setup PostGIS we need to have a local version of Postgresql installed and running. The most effecient way to do this is to download and install Postgres.app.
Once Postgres.app is installed in your computers /Applications
directory. Open the Terminal and enter the following two commands
psql -d DATABASE_NAME -f /Applications/Postgres.app/Contents/Versions/9.3/share/postgresql/contrib/postgis-2.1/postgis.sql
I'm a Python programmer and frequently work with the excellent [virtualenv][] tool by Ian Bicking.
Virtualenv is a great tool on the whole but there is one glaring problem: the activate
script that virtualenv provides as a convenience to enable its functionality requires you to source it with your shell to invoke it. The activate
script sets some environment variables in your current environment and defines for you a deactivate
shell function which will (attempt to) help you to undo those changes later.
This pattern is abhorrently wrong and un-unix-y. activate
should instead do what ssh-agent
does, and launch a sub-shell or sub-command with a modified environment.