Топожсон на стороне клиента, отображающий, казалось бы, неправильные пути

Я пытался создать файл TopoJson с данными консолидированного слоя, содержащими, среди прочего, штаты США, округа и избирательные округа.

Оригинальные шейп-файлы .shp взяты из картографических файлов границ Бюро переписи населения. .

Они были преобразованы в GeoJson через ogr2ogr.

Затем объединены в формат TopoJson через серверную библиотеку узла с квантованием 1e7 и коэффициентом сохранения 0,15. До этого момента нет никаких признаков какой-либо проблемы.

Я просматриваю окончательный файл topojson с помощью mapshaper, и все выглядит нормально:отрендерено через Mapshaper

Но при попытке рендеринга с клиентской библиотекой topojson и D3.geo.path() я столкнулся с некоторыми странными путями в слое congressionalDist: (обратите внимание на большие прямоугольные пути вокруг континентальной части США, AK и HI)квадратные пути

Рабочую версию страницы можно найти здесь: http://jsl6906.net/D3/topojson_problem/map/

Пара соответствующих замечаний:

  • Если я изменю свой скрипт генерации topojson, чтобы удалить упрощение, пути, похоже, правильно отображаются на той же странице d3.js.
  • Если я сохраняю только слой congressionalDist при создании topojson, пути, похоже, правильно отображаются на той же странице d3.js:

хорошо

После стольких попыток устранения неполадок, с которыми я был в состоянии справиться, я решил попросить кого-нибудь здесь узнать, сталкивался ли кто-нибудь с подобными проблемами. Спасибо за любую помощь.


javascript d3.js topojson
person Josh    schedule 04.06.2014    source источник
comment
Это кажется/может быть связано с проблемами, упомянутыми в stackoverflow.com/questions/23953366/. Там вычисление границы пошло не так, и некоторые области также привели к большим прямоугольникам. Например, в вашем примере d3.geo.bounds(cds[84]) приводит к «[[-180, -90], [180, 90]]», что кажется неверным. Хотя я не знаю, почему это происходит.   -  person Jan van der Laan    schedule 02.07.2014
comment
До сих пор не уверен, что вызывает это, но я заметил одну интересную вещь: свойство id данных, привязанных к оскорбительным прямоугольникам, заканчивается на ZZ, тогда как идентификаторы всех других объектов заканчиваются двумя числами. Ответственные идентификаторы: 09ZZ, 17ZZ и 26ZZ. Например, попробуйте следующее: d3.selectAll(d3.selectAll('.cd')[0].filter(function(d) { return d3.select(d).attr('id').slice(-2) === 'ZZ' })).style('stroke', 'red') и вы заметите, что только эти прямоугольники окрашены в красный цвет.   -  person jshanley    schedule 02.08.2014
comment
Кажется, ZZ - это код, присвоенный неопределенным избирательным округам. Я не совсем уверен, что это означает, но вы можете увидеть, как это происходит в этот набор данных в столбце CD113FP, если столбец NAMELSAD содержит неопределенные избирательные округа. Также есть ссылка на удаление таких районов при запуске ogr2ogr в < b>этот файл, который является частью us-atlas   -  person jshanley    schedule 02.08.2014
comment
Если это может оказаться полезным, вот мой полный рабочий процесс: 1. Загрузите шейп-файлы (census.gov/geo/maps-data/data/tiger-cart-boundary) 2. Преобразование шейп-файлов в формат geoJson (jsl6906.net/D3/topojson_problem/3create_geo_jsons.bat.txt) 3. Объедините файлы geoJson в topoJson (jsl6906.net/D3/topojson_problem/3create_topo_json.js)   -  person Josh    schedule 04.08.2014
comment
Возможно ли, что ваши пути вывернуты наизнанку (против часовой стрелки или по часовой стрелке)? Что произойдет, если вы назначите цвет заливки Аляске или Гавайям — заполнит ли он все в прямоугольнике, кроме островов/штата? См., например. stackoverflow.com/q/21786168/3128209   -  person AmeliaBR    schedule 07.08.2014

Ответы (1)


arrow_upward
4
arrow_downward

Как я упоминал в комментариях, я заметил, что все три оскорбительных прямоугольника были привязаны к данным со свойством id, оканчивающимся на ZZ, в то время как все остальные пути имели идентификаторы, заканчивающиеся числами.

После некоторого поиска в Google я нашел то, что, как мне кажется, является ответом.

Согласно этому документу на веб-сайте census.gov,

В Коннектикуте, Иллинойсе и Мичигане участник от штата не назначил нынешние (113-е) округа Конгресса для покрытия всего штата или эквивалентной территории. Код «ZZ» был присвоен районам, для которых не определен избирательный округ (обычно крупные водоемы). Эти неназначенные территории рассматриваются в пределах штата как единый избирательный округ для целей представления данных.

Кажется, что эти три неопределенных района составляют три прямоугольника. Неясно, на каком этапе процесса они вызывают проблему, но я считаю, что есть простое решение вашей непосредственной проблемы. При поиске информации о коде ZZ я наткнулся на этот make-файл в проекте mbostock под названием us-atlas.

Похоже, он столкнулся с похожей проблемой и сумел отфильтровать неопределенные избирательные округа при запуске ogr2ogr. Вот соответствующий код из этого файла:

# 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'" $@ $<

Держу пари, что если вы запустите ogr2ogr в своем шейп-файле, используя показанные здесь флаги, это решит проблему.

person jshanley    schedule 02.08.2014
comment
Интересно, спасибо. Я посмотрю на это подробнее в ближайшие пару дней. Хотя кажется, что это может быть корнем проблемы, это не объясняет, почему пути отображаются нормально, если я не комбинирую их с шейп-файлами штата/округа, или почему, если я не упрощаю фигуры с помощью topojson, проблемы не существует. Любая быстрая реакция на это? - person Josh; 02.08.2014
comment
Не в данный момент. Если вы продолжаете изучать детали, я бы посоветовал вам проверить, как выглядит ваш набор данных на каждом этапе процесса преобразования, обращая особое внимание на любые существенные различия в типе данных, которые представляют неопределенные районы по сравнению с данными по другим районам. Я предполагаю, что после одного из шагов эти данные будут в формате, который d3 не может правильно отобразить. - person jshanley; 02.08.2014
comment
Мне приходит в голову еще одна возможность... Когда вы говорите, что объединяете эти данные с границами штатов и т. д., есть ли в этом процессе этап, на котором сами формы или пути каким-то образом сливаются в единую форму или путь? Если это так, возможно, что части этих неопределенных районов, которые находятся над водоемами, не смогут быть объединены с границами штата или округа, если те же самые водоемы используются как границы в набор данных штата/округа. - person jshanley; 02.08.2014
comment
К сожалению, при ближайшем рассмотрении кажется, что пути «ZZ» не являются причиной проблемы. Но спасибо за наводку. - person Josh; 04.08.2014