Построение lineArcs с помощью turf.js, которые не совпадают с окружающими их геодезическими строками

Фон

Нам предоставлены некоторые данные AIXM (надмножество GML на основе XML), которые описывают области полигонов на карте как смесь GeodesicStrings (список координат) и ArcByCentrePoints (координата центральной точки с радиусом, начальным направлением и конечным направлением). . Мы берем эти данные и преобразовываем их в простой список координат, который затем отображаем с помощью ломаной линии Google Maps.

Проблема

Когда мы рисуем фигуру с дугой, начальная и конечная точки дуги обычно не совпадают с конечной точкой предыдущей линии и начальной точкой последующей линии. Похоже, что радиальное расстояние отличается на величину, которая не кажется пропорциональной радиусу. Смотрите скриншот: интересно, что меньшая дуга вверху выглядит нормально, но большая дуга вставлена.

Плохая дуга

Мы почти уверены, что данные верны, потому что они выглядят нормально, когда мы используем сторонний инструмент для их визуализации, поэтому мы делаем что-то не так.

Реализация

Мы используем библиотеку turf.js для преобразования описания дуги в набор точек, используя их lineArc функция. Внутренне это использует их функцию destination, которая использует формулу Haversine для учета глобальной кривизны. Мы объединяем эти сгенерированные точки в правильной последовательности с точками, взятыми непосредственно из предыдущего и последующего элементов GeodesicString, чтобы получить наш окончательный многоугольник.

Данные

Помощь!

Я знаю, что в этом вопросе мало кода, но я надеюсь, что описал проблему адекватно, и что какой-нибудь добрый человек с большими знаниями ГИС, чем я (›0), сможет указать мне правильное направление. Спасибо :)


google-maps geospatial turfjs gml
person Jerome    schedule 04.10.2018    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Я сделал пару презентаций по отладке и одна из вещей, которые я хочу сказать, это то, что вы должны быть непредубежденными и не должны слишком зацикливаться на возможной причине ошибки, потому что вы можете потратить много времени на отслеживание ошибки. ложный вывод.

К сожалению, в данном случае я не последовал своему собственному совету. Я был настолько одержим идеей, что проблема возникла из-за сложной причины, такой как проблемы с реализацией формулы Хаверсина, что я упустил из виду гораздо более простой ответ. Мой код принимал строковое представление радиуса, включая единицы измерения (например, морские мили или метры), и преобразовывал его в километры. К сожалению, я использовал parseInt, а не parseFloat как часть этого, и поэтому мгновенно терял точность. Это было просто - ошибка школьника.

Большое спасибо Стефано Борги, сопровождающему Turf JS, за всю его помощь в этом и за то, что помог мне увидеть лес за деревьями.

person Jerome    schedule 02.12.2018