[GIS] How to merge TopoJSON features

geojsonqgistopojson

I currently have a coordinate based map of the US and it's states for topojson (https://github.com/mbostock/topojson).

The coordinates are a JSON array (as topojson works), data looks like this:

[-123.233256,42.006186], [-122.378853,42.011663]...

Now what I'd like to do is combine states into regions, outside of doing this by hand (and that idea makes me feel sick), are there any tools which I can use to accomplish this?

I have QGIS but have no clue where to even start (let alone how to combine states in QGIS).

Best Answer

You can use topojson.merge to do this, as shown in bl.ocks.org/5416405:

There are a few limitations to this approach (such as its dependence on an exact topology and lack of detection of holes), but it might for you as-is or with a few adjustments.

There is also the simpler approach of drawing the set of polygons for each region twice, once with a stroke and once with a fill, as shown in bl.ocks.org/5416440:

Related Solutions

[GIS] TopoJSON without Quantization

TopoJSON uses fixed-precision integer coordinates, so no, you can’t create a TopoJSON file without first quantizing coordinates. The precision is controlled with the -q argument to topojson, as described in the command-line reference.

(Edit: as of TopoJSON 1.4, you can now construct lossless TopoJSON without quantization by saying --no-quantization (or equivalently -q 0).)

That said, it doesn’t sound like quantization is your problem here. Instead, I would guess that your input coordinates are not in WGS84 / EPSG:4326. I would use ogr2ogr to convert your geometry to spherical coordinates in degrees before converting to TopoJSON. For example:

ogr2ogr -f 'ESRI Shapefile' -t_srs EPSG:4326 input-fixed.shp input.shp
topojson -o output.json -- input-fixed.shp

Quantization is unlikely to be the problem here because quantization is localized to the input features’ bounding box, and thus automatically adapts to both small and large features. If you have a map of a very small space (such as building floor plans, and not the western hemisphere), the quantized coordinates will be correspondingly more precise, even at the same value of Q (topojson's -q), because the scale of the topology’s transform will be that much larger.

For example, say the bounding box of your input features is [[-122.395, 37.794], [-122.391, 37.797]], approxiamtely San Francisco’s Ferry Building. And say you used the default Q = 10,000. The quantized fixed coordinate [0,0] then maps to [-122.395, 37.794], and the fixed coordinate [9999,9999] maps to [-122.391, 37.797]. In other words, each increment in longitude corresponds to approximately 0.0000004° (4e-7), a tiny amount.

In contrast, with a world map spanning [[-180, -90], [180, 90]] at the same Q = 10,000, each increment in longitude corresponds to approximately 0.036°.

[GIS] D3 for maps—at what stage to bring in data to the geo

Ask yourself two questions:

Are you going to reuse the geography on multiple datasets?

If you’ll use the same geography with multiple datasets, then it makes sense to keep the geography and data separate, and join them in the client. Many of my examples have separate CSV (or TSV) files for this reason. This way, the TopoJSON for U.S. states and counties or likewise world countries can be reused, instead of creating separate TopoJSON for every example.

On the other hand, if you’ll only use this geography once, then you should probably “bake” the data into the geography as properties, if only to simplify the code. This approach is simpler because you only need to load a single file (so no queue.js), and since the data is stored as properties of each feature, you don’t need to join the data in the client (so no d3.map).

Side note: TSV and CSV are often much more efficient at storing properties than GeoJSON and TopoJSON, simply because the latter must repeat property names on every object. File size can be another reason to store your data in a separate file and join it in the client.
Is your data already bound to geography (e.g., a property of your shapefile)?

Assuming you answered “no” to the first question and want to bake the data into the geography (rather than doing it in the client), how you do this depends on the format of the data.

If your data is already a property of your shapefile, then use topojson -p to control which properties are saved to the generated TopoJSON file. You can also use this to rename properties and coerce them to numbers, as well. See Let’s Make a Map for examples.

If your data is in a separate CSV or TSV file, then use topojson -e (in addition to -p) to specify an external properties file that can be joined to your geographic features. Cribbing the example from the wiki, if you had a TSV file like this:
```
FIPS    rate
1001    .097
1003    .091
1005    .134
1007    .121
1009    .099
1011    .164
1013    .167
1015    .108
1017    .186
1019    .118
1021    .099
```
Using -e, you can map these to a numeric output property named “unemployment”:
```
topojson \
  -o output.json \
  -e unemployment.tsv \
  --id-property=+FIPS \
  -p unemployment=+rate \
  -- input.shp
```
An example of this approach is the Kentucky population choropleth, bl.ocks.org/5144735.

Best Answer

Related Solutions

[GIS] TopoJSON without Quantization

[GIS] D3 for maps—at what stage to bring in data to the geo

Related Question