Существует категория ошибок в координатах, которая никак не связана с качеством геокодирования, а целиком зависит от того, как полученные числа затем хранятся, передаются и используются в вычислениях. Идеально точная пара координат может получить заметную ошибку округления только из-за того, что где-то на пути через вашу систему она была представлена числовым типом с недостаточной точностью, и такой ошибки можно полностью избежать, уделив этому немного целенаправленного внимания.
Числа с плавающей точкой одинарной точности, обычно называемые float32, дают примерно семь значащих десятичных цифр. Для широты или долготы, которым нужно несколько цифр до десятичной точки только для целой части градусов, после точки остаётся заметно меньше цифр реальной точности, чем дал бы для того же значения тип двойной точности, обычно float64. На практике хранение координат как float32 вместо float64 может вносить ошибку округления порядка метра и более, в зависимости от конкретной широты, и эта ошибка полностью отделена от ограничений точности исходного совпадения при геокодировании и добавляется к ним.
Такую ошибку легко внести случайно и легко не заметить, потому что она никак явно не выглядит как ошибка: полученная координата остаётся правдоподобным, корректно оформленным числом, которое просто незаметно немного сместилось от исходного значения. Обычно она проникает через столбец базы данных, определённый с недостаточной числовой точностью, через формат сериализации данных, который по умолчанию использует более узкий числовой тип, чем задумано, или через промежуточное вычисление, формулу расстояния или преобразование координат, выполненное в типе с меньшей точностью, чем в остальной части конвейера.
Практическая рекомендация проста: используйте числа с плавающей точкой двойной точности или эквивалентный десятичный тип с фиксированной точкой и достаточным числом цифр для хранения и вычисления координат во всей системе, от начала до конца, а не только в том месте, где они впервые поступают. Отдельно проверьте схему базы данных, поскольку столбец, определённый более узким типом, чем задумано, является одним из самых распространённых и легко упускаемых источников именно этой проблемы: его часто заводят в начале проекта и больше к нему не возвращаются, как только всё работает достаточно хорошо, чтобы пройти первичное тестирование. Проверьте также любой слой сериализации или API между системами, поскольку некоторые форматы и библиотеки по умолчанию используют одинарную точность, если явно не указано иное, и незаметно понижают точность именно на той границе, где вы меньше всего ожидали бы её искать.
Координаты, которые возвращают наши эндпоинты прямого и обратного геокодирования, содержат десятичные значения полной двойной точности. Стоит напрямую проверить, что эта точность сохраняется в вашем собственном конвейере хранения и вычислений, а не предполагать, что она автоматически переживает каждый этап.