Topojson client side displaying seemingly wrong paths

I am trying to create a TopoJson file with consolidated level data containing, among other layers, the states of the USA, the county and county of Congress.

Original .shp shapefiles come from the Census Bureau Cartographic border files .

They were converted to GeoJson via ogr2ogr.

It is then combined into TopoJson format through the node server library with 1e7 quantization and a preserved aspect ratio of 0.15. There are still no signs of any problems.

I am viewing the final topojson file using mapshaper and everything looks fine: rendered via mapshaper

But when trying to render with the topojson and D3.geo.path () client library, I come across some strange paths in the congressionalDist layer: (note the large rectangular paths around the continental USA, AK and HI) square paths

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

A few notes:

  • If I change my generation of topojson script to remove the simplification, the paths seem to display correctly on the same d3.js page
  • If I save only the congressionalDist layer when creating topojson, then the paths seem to display correctly through the same d3.js page:

good

After I tried to troubleshoot how I could handle it, I decided that I would ask someone here to see if anyone had similar problems. Thanks for any help.

+8
javascript topojson
source share
1 answer

As I mentioned in the comments, I noticed that all three distortion rectangles were attached to data with the id property ending in ZZ , while all other paths had identifiers ending with numbers.

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

According to this document on the census.gov website,

In Connecticut, Illinois, and Michigan, a state member did not designate the current (113th) congressional districts to cover all state or equivalent territory. The code "ZZ" is assigned to areas where the congress area is not defined (usually large ponds). These unrecognized areas are considered statewide as a single congressional district for reporting purposes.

It seems that these three undefined constituencies will make up three rectangles. It is not clear at what point in the process they cause the problem, but I believe there is a simple solution to your immediate problem. While searching for information on ZZ code, I came across this makefile in an mbostock project called us-atlas .

It seems he faced a similar problem and managed to filter out congressional districts undefined when ogr2ogr started. Here is the corresponding code from this 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 am sure that if you run your ogr2ogr in your shapefile using the flags listed here, it will solve the problem.

+4
source share

All Articles