Strona klienta topojson renderowanie pozornie niepoprawne ścieżki

Próbowałem utworzyć plik TopoJson ze skonsolidowanymi danymi warstw zawierającymi, między innymi, Stany Zjednoczone, Powiaty i Okręgi Kongresowe.Strona klienta topojson renderowanie pozornie niepoprawne ścieżki

Oryginalne pliki shp .shp pochodzą z Cartographic Boundary Files Biura Spisu Powszechnego (Census Bureau).

Zostały one zamienione na GeoJson przez ogr2ogr.

Następnie połączone w formacie TopoJson przez bibliotekę po stronie serwera węzła, z kwantyzacją 1e7 i zachowaniem proporcji 0,15. Do tego momentu nic nie wskazuje na żaden problem.

wyświetlić ostateczny plik topojson użyciu mapshaper i rzeczy wydają się wyglądać OK: rendered via mapshaper

Ale podczas próby renderowania z biblioteki klienta topojson i D3.geo.path(), spotykam dziwne ścieżki w warstwa congressionalDist: (zauważyć duże prostokątne ścieżki na całym kontynencie amerykańskim, AK, i HI) square paths

wersja robocza stronie można znaleźć tutaj: http://jsl6906.net/D3/topojson_problem/map/

kilka odpowiednich notach:

Jeśli zmienię mój skrypt generacji topojson usunąć uproszczenie, ścieżki następnie wydają się wskazywać prawidłowo za pośrednictwem tej samej stronie d3.js
Gdybym tylko utrzymać warstwę congressionalDist podczas tworzenia topojson, ścieżki następnie wydają pokazać prawidłowo za pomocą tej samej stronie d3.js:

good

Po próbując jak najwięcej rozwiązaniu problemów, jak byłem w stanie obsłużyć, wyobraziłem chciałbym poprosić kogoś, żeby zobaczyć, czy ktoś doświadczył każdy podobny problemy. Dzięki za pomoc.

Źródło

2014-06-04 Josh

Wygląda na to, że jest/może być związane prognozy/24055015 # 24055015. Tam obliczenia granicy poszły nie tak z niektórymi regionami, w wyniku czego powstały również duże prostokąty. W twoim przykładzie na przykład 'd3.geo.bounds (cds [84])' powoduje, że '[[-180, -90], [180, 90]] 'wydaje się niepoprawne. Nie wiem, dlaczego tak się dzieje. –

Nadal nie jestem pewien, co jest przyczyną tego, ale jedną interesującą rzeczą, którą zauważyłem jest to, że właściwość "id" danych związanych z obrażającymi prostokątami kończy się na 'ZZ', podczas gdy wszystkie inne obiekty mają id kończący się dwoma liczbami. Odpowiedzialnymi za to identyfikatorem są: 09ZZ, 17ZZ i 26ZZ. Na przykład spróbuj wykonać następujące czynności: 'd3.selectAll (d3.selectAll ('. Cd') [0] .filter (function (d) {return d3.select (d) .attr ('id'). Slice (- 2) === 'ZZ'})). Style ('stroke', 'red') 'i zauważysz, że tylko te prostokąty mają kolor czerwony. – jshanley

Wygląda na to, że 'ZZ' to kod nadany" niezdefiniowanym "okręgom kongresowym. Nie jestem do końca pewien, co to oznacza, ale widać, że zdarza się to w [tym zbiorze danych] (http://www.census.gov/geo/reference/codes/files/national_cd113.txt) pod kolumną CD113FP, gdziekolwiek kolumna NAMELSAD zawiera "Okręgi kongresowe nieokreślone". Istnieje również odniesienie do usuwania takich dzielnic podczas działania ogr2ogr w [** tym pliku **] (https://github.com/mbostock/us-atlas/blob/bf502099b48e54116c88f277e6d800836ecbc210/Makefile#L276-L279), który jest częścią ['us-atlas'] (https://github.com/mbostock/us-atlas) – jshanley

Jak wspomniano w komentarzach, ja zauważyłem, że trzy obrażając prostokąty wszystkie były związane z danymi o własności id kończącym się w ZZ, podczas gdy wszystkie inne ścieżki miały identyfikatory kończące się cyframi.

Po kilku poszukiwaniach w Google wpadłem na to, co uważam za odpowiedź.

Według this document na stronie internetowej census.gov,

W Connecticut, Illinois, Michigan i uczestnik stan nie przypisać bieżące (113.) Kongresu dzielnic na pokrycie całego obszaru państwa lub równoważnego . Kod "ZZ" został przypisany do obszarów bez zdefiniowanego okręgu kongresowego (zazwyczaj duże zbiorniki wodne). Te nieprzypisane obszary są traktowane na terenie stanu jako pojedynczy okręg kongresowy dla celów prezentacji danych.

Wygląda na to, że te trzy nieokreślone dzielnice odpowiadają za trzy prostokąty. Nie jest jasne, w którym momencie procesu powodują problem, ale uważam, że istnieje proste rozwiązanie twojego bezpośredniego problemu. Podczas wyszukiwania informacji o kodzie ZZ natknąłem się na this makefile w projekcie mbostock o nazwie us-atlas.

Wygląda na to, że napotkał podobny problem i udało mu się odfiltrować niezdefiniowane okręgi kongresowe podczas pracy pod numerem ogr2ogr. Oto odpowiedni kod z tego pliku:

# 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] $<

Założę się, że jeśli uruchomić ogr2ogr na shapefile wykorzystaniem flagi pokazane tutaj będzie rozwiązać ten problem.

Źródło

2014-08-02 03:49:10 jshanley

Interesujące, dziękuję. Zajmę się tym dalej w ciągu najbliższych kilku dni. Choć wydaje się, że to może być przyczyną problemu, nie wydaje się, aby wyjaśniać, dlaczego ścieżki są w porządku, jeśli nie łączę ich z shapefiles stanu/hrabstwa, lub dlaczego, jeśli nie upraszczam kształtów za pomocą topojson, problem nie istnieje. Jakaś szybka reakcja na to? – Josh

Nie w tej chwili. Jeśli nadal będziesz sprawdzać szczegóły, sugerowałbym sprawdzenie, jak wygląda twój zestaw danych na każdym etapie procesu konwersji, zwracając szczególną uwagę na wszelkie znaczące różnice w * rodzaju * danych reprezentujących niezdefiniowane dzielnice w porównaniu do danych dla innych dzielnic. Domyślam się, że po jednym z tych etapów dane będą miały format, który nie może być renderowany poprawnie. – jshanley

Inna możliwość, która mi się przydarza ... Kiedy mówisz, że łączysz te dane z granicami stanu itp., Czy jest jakiś krok w tym procesie, w którym kształty lub ścieżki same są w jakiś sposób połączone w jeden kształt lub ścieżkę? Jeśli tak, to możliwe, że części tych nieokreślonych okręgów, które są nad zbiornikami wodnymi, mogą nie być w stanie połączyć się z granicami stanu lub hrabstwa, jeśli te same zbiorniki wodne są używane * jako * granice w zestawie danych państwo/okręg . – jshanley

Strona klienta topojson renderowanie pozornie niepoprawne ścieżki

Odpowiedz

Powiązane problemy