Rendering lato client di rendering topojson apparentemente errati

Ho tentato di creare un file TopoJson con dati di livello consolidato contenenti, tra gli altri strati, Stati Uniti, contee e distretti congressuali.Rendering lato client di rendering topojson apparentemente errati

Gli shapefile originali .shp provengono dal Census Bureau Cartographic Boundary Files.

Questi sono stati convertiti in GeoJson via ogr2ogr.

Quindi combinato in formato TopoJson tramite la libreria lato server nodo, con quantizzazione di 1e7 e percentuale di mantenimento di 0,15. Fino a questo punto non vi è alcuna indicazione di alcun problema.

ho visualizzare il file topojson finale utilizzando mapshaper e le cose sembrano guardare OK: rendered via mapshaper

Ma, quando si tenta di rendere con la libreria client topojson e D3.geo.path(), ho incontrato alcuni strani percorsi in lo strato congressionalDist: (notare le grandi percorsi rettangolari in tutto l'Uniti continentali, AK, e HI) square paths

una versione funzionante della pagina può essere trovato qui: http://jsl6906.net/D3/topojson_problem/map/

Un paio di note rilevanti:

Se cambio il mio script generazione topojson per rimuovere la semplificazione, i percorsi poi sembrano mostrare correttamente tramite la stessa pagina di d3.js
Se continuo a solo lo strato congressionalDist durante la creazione del topojson, i percorsi poi sembrano mostrare correttamente tramite la stessa pagina d3.js:

good

Dopo aver tentato la risoluzione dei problemi tanto come io sono stato in grado di gestire, ho pensato che sarebbe chiedere a qualcuno qui per vedere se qualcuno ha avuto alcun simile problemi. Grazie per qualsiasi aiuto.

fonte

2014-06-04 Josh

Questo sembra essere/potrebbe essere correlato ai problemi menzionati in http://stackoverflow.com/questions/23953366/d3-large-geojson-file-does-not-show-draw-map-properly-using- proiezioni/24055015 # 24055015. Lì il calcolo del limite è andato male con alcune regioni risultanti anche in rettangoli di grandi dimensioni. Nell'esempio, ad esempio, 'd3.geo.bounds (cds [84])' risulta in '[[-180, -90], [180, 90]] 'che sembra non essere corretto. Non so perché questo succede però. –

Ancora non sono sicuro di cosa stia causando questo, ma una cosa interessante che ho notato è che la proprietà 'id' dei dati legati ai rettangoli incriminati finisce in' ZZ', mentre tutti gli altri oggetti hanno un id che termina con due numeri. I responsabili dell'ID sono: 09ZZ, 17ZZ e 26ZZ. Ad esempio, prova quanto segue: 'd3.selectAll (d3.selectAll ('. Cd') [0] .filter (function (d) {return d3.select (d) .attr ('id'). Slice (- 2) === 'ZZ'})). Stile ('tratto', 'rosso') 'e noterai che solo quei rettangoli sono colorati in rosso. – jshanley

Sembra che "ZZ" sia il codice assegnato ai distretti congressuali "indefiniti". Non sono esattamente sicuro di cosa significhi, ma puoi vederlo in [questo set di dati] (http://www.census.gov/geo/reference/codes/files/national_cd113.txt) sotto la colonna CD113FP, dovunque la colonna NAMELSAD contiene "Distretti congressuali non definiti". C'è anche un riferimento alla rimozione di tali distretti quando si esegue ogr2ogr in [** questo file **] (https://github.com/mbostock/us-atlas/blob/bf502099b48e54116c88f277e6d800836ecbc210/Makefile#L276-L279) che fa parte di ['us-atlas'] (https://github.com/mbostock/us-atlas) – jshanley

Come ho menzionato nei commenti, avevo notato che i tre rettangoli incriminati erano tutti associati a dati con una proprietà id che termina con ZZ, mentre tutti gli altri percorsi avevano ID che terminavano con numeri.

Dopo aver cercato su Google, ho trovato quella che penso sia la risposta.

Secondo this document sul sito census.gov,

Nel Connecticut, Illinois, Michigan e il partecipante Stato non ha assegnato le correnti (113 °) distretti congressuali per coprire tutta l'area dello stato o equivalente . Il codice "ZZ" è stato assegnato a in aree senza distretto del Congresso (di solito grandi corpi idrici). Queste aree non assegnate sono trattate all'interno dello stato come un singolo distretto congressuale ai fini della presentazione dei dati.

Sembra che questi tre quartieri non definiti rappresenterebbero i tre rettangoli. Non è chiaro a quale punto del processo essi causano il problema, ma credo che ci sia una soluzione semplice al tuo problema immediato. Durante la ricerca di informazioni sul codice ZZ, mi sono imbattuto in this makefile in un progetto di mbostock chiamato us-atlas.

Sembra che abbia riscontrato un problema simile ed è riuscito a filtrare i quartieri congressuali indefiniti quando è in esecuzione ogr2ogr. Ecco il codice corrispondente da quel file:

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

scommetto che se si esegue la ogr2ogr sul vostro shapefile utilizzando le bandiere mostrato qui che possa risolvere il problema.

fonte

2014-08-02 03:49:10 jshanley

Interessante, grazie. Lo esaminerò ulteriormente nei prossimi due giorni. Anche se sembra che questa possa essere la radice del problema, non sembra spiegare perché i percorsi siano validi se non li combino con shapefile state/county, o perché se non li semplifichi usando Topojson, il il problema non esiste Qualche reazione rapida a questo? – Josh

Non al momento. Se continui a indagarne i dettagli, ti suggerisco di esaminare l'aspetto del set di dati in ogni fase del processo di conversione, prestando particolare attenzione a eventuali differenze significative nel * tipo * di dati che rappresentano i distretti non definiti quando confrontati ai dati per altri distretti. La mia ipotesi è che dopo uno dei passaggi, questi dati saranno in un formato che d3 non può eseguire correttamente. – jshanley

Un'altra possibilità che mi viene in mente ... Quando si dice che si combinano questi dati con i confini dello stato ecc. C'è un passaggio in quel processo in cui le forme oi percorsi stessi sono in qualche modo uniti in una singola forma o percorso? Se è così, è possibile che le parti di questi distretti indefiniti che si trovano su corpi idrici potrebbero non essere in grado di fondersi con i confini dello stato o della contea se quegli stessi corpi idrici sono usati * come * i confini del set di dati stato/contea . – jshanley

Rendering lato client di rendering topojson apparentemente errati

risposta

Problemi correlati