Client side topojson rendering seemingly incorrect paths

Question

I've been attempting to create a TopoJson file with consolidated layer data containing, among other layers, U.S. States, Counties, and Congressional Districts.

Original .shp shapefiles come from the Census Bureau's Cartographic Boundary Files.

These were converted to GeoJson via ogr2ogr.

Then combined into TopoJson format via the node server side library, with quantization of 1e7 and retain-proportion of 0.15. Up to this point there is no indication of any problem.

I view the final topojson file using mapshaper and things seem to look OK:

But, when attempting to render with the topojson client library and D3.geo.path(), I encounter some strange paths in the congressionalDist layer: (notice the large rectangular paths around the continental US, AK, and HI)

A working version of the page can be found here: http://jsl6906.net/D3/topojson_problem/map/

A couple of relevant notes:

• If I change my topojson generation script to remove simplification, the paths then seem to show correctly via the same d3.js page
• If I only keep the congressionalDist layer when creating the topojson, the paths then seem to show correctly via the same d3.js page:

After attempting as much troubleshooting as I've been able to handle, I figured I would ask someone here to see if someone has experienced any similar issues. Thanks for any help.

Answer 1

As I mentioned in the comments, I had noticed that the three offending rectangles all were bound to data with an id property ending in ZZ, while all other paths had IDs ending with numbers.

After some Google searching, I came up with what I think is the answer.

According to this document on the census.gov website,

In Connecticut, Illinois, and Michigan the state participant did not assign the current (113th) congressional districts to cover all of the state or equivalent area. The code “ZZ” has been assigned to areas with no congressional district defined (usually large water bodies). These unassigned areas are treated within state as a single congressional district for purposes of data presentation.

It seems that these three undefined districts would account for the three rectangles. It is unclear at what point in the process they cause the issue, but I believe there is a simple solution to your immediate problem. While searching for information about the ZZ code, I stumbled across this makefile in a project by mbostock called us-atlas.

It seems he had encountered a similar issue and had managed to filter out the undefined congressional districts when running ogr2ogr. Here is the relevant code from that file:

# remove undefined congressional districts
shp/us/congress-ungrouped.shp: shp/us/congress-unfiltered.shp
    rm -f $@
    ogr2ogr -f 'ESRI Shapefile' -where "GEOID NOT LIKE '%ZZ'" $@ $<

I'm betting that if you run your ogr2ogr on your shapefile using the flags shown here it will solve the problem.