Я читал этот вопрос здесь:
Какой тип данных использовать при хранении данных широты и долготы в SQL-базах данных?
И, похоже, общий консенсус заключается в том, что использование Decimal (9,6) - это путь. Вопрос для меня в том, насколько точно мне это нужно?
Например, Google API возвращает результат, например:
"lat": 37.4219720,
"lng": -122.0841430
Из -122.0841430, сколько цифр мне нужно? Я читал несколько руководств, но я не могу сделать из них достаточного смысла, чтобы понять это.
Чтобы быть более точным в моем вопросе: если я хочу быть точным в пределах 50 футов от точного местоположения, сколько десятичных точек мне нужно хранить?
Возможно, лучшим вопросом будет вопрос, не связанный с программированием, но это было бы: насколько точнее ваша десятичная точка?
Это просто?
Точность по сравнению с десятичными знаками на экваторе
decimal degrees distance
places
-------------------------------
0 1.0 111 km
1 0.1 11.1 km
2 0.01 1.11 km
3 0.001 111 m
4 0.0001 11.1 m
5 0.00001 1.11 m
6 0.000001 0.111 m
7 0.0000001 1.11 cm
8 0.00000001 1.11 mm
ref: https://en.wikipedia.org/wiki/Decimal_degrees#Precision
+----------------+-------------+
| Decimals | Precision |
+----------------+-------------+
| 5 | 1m |
| 4 | 11m |
| 3 | 111m |
+----------------+-------------+
Если вы хотите, чтобы точность в 50 футов (15 м) составляла 4 цифры.
Итак, decimal(9,6)
Я проектирую базы данных и изучаю этот вопрос некоторое время. Мы используем готовое приложение с бэкэнд Oracle, где были определены поля данных, чтобы разрешить 17 знаков после запятой. Смешной! Это в тысячных долях дюйма. Никакой GPS-инструмент в мире не настолько точен. Поэтому давайте отложим 17 десятичных знаков и рассмотрим практические вопросы. Правительство гарантирует, что их система хороша для "наихудшего случая" с точностью менее 7,8 м при уровне достоверности 95% ", но затем продолжает говорить, что фактическая FAA (используя их высококачественные инструменты) показала, что показания GPS обычно бывают хорошими для в метрах.
Итак, вы должны задать себе два вопроса: 1) Каков источник ваших ценностей? 2) Какими будут использоваться данные?
Сотовые телефоны не особенно точны, а показания Google/MapQuest, вероятно, хороши только для 4 или 5 десятичных знаков. Высококачественный прибор GPS может получить вас 6 (в пределах Соединенных Штатов). Но захватить больше, чем это пустая трафаретная печать и место для хранения. Кроме того, если какие-либо поиски выполняются по значениям, приятно, что пользователь должен знать, что 6 будет самым нужным (очевидно, что любое введенное значение поиска должно быть округлено до той же точности, что и поиск значения данных).
Кроме того, если все, что вам нужно сделать, это просмотреть местоположение на Картах Google или поместить его в GPS, чтобы добраться туда, четыре или пять - это много.
Мне приходится смеяться над людьми, которые здесь вводят все эти цифры. И где именно они берут это измерение? Ручка передней двери? Почтовый ящик спереди? Центр строительства? Верх башни клетки? И... каждый постоянно принимает его в одном месте?
Как хороший дизайн базы данных, я бы принимал значения от пользователя, возможно, несколько более пяти десятичных цифр, затем округлял и фиксировал только пять для согласованности (возможно, шесть, если ваши инструменты хороши, и ваше конечное использование гарантирует это).
Расстояние между каждой степенью широты изменяется из-за формы земли, и расстояние между каждой степенью долготы уменьшается по мере приближения к полюсам. Поэтому позвольте говорить о экваторе, где расстояние между каждой степенью составляет 110.574 км для широты и 111.320 км по долготе.
50ft составляет 0,01524 км, поэтому:
Вам нужны четыре цифры шкалы, достаточные для того, чтобы спуститься до десятитысячных долей, с точностью до семи цифр.
DECIMAL(7,4) должно быть достаточно для ваших нужд.
Не сохраняйте значения с плавающей запятой. Хотя вы можете предположить, что они точны, это не так. Это приближение. И получается, что на разных языках существуют разные методы "разбора" информации с плавающей запятой. И разные базы данных имеют разные методы реализации приближений значений.
Вместо этого используйте Geohash. Это видео представляет и визуально объясняет Geohash менее чем за 5 минут. Geohash BY BY FAR - лучший способ кодировать/декодировать долготу/широту информации согласованным образом. Никогда не "сериализуя" приблизительные значения с плавающей запятой долготы/широты в столбцах базы данных, а вместо этого, используя Geohash, вы получите ту же желаемую согласованность в тесном контакте, которую вы получите со значениями String. Этот сайт отлично подходит для игры с Geohash.
Принимая во внимание различные части сферы и диагональное расстояние, здесь приведена таблица доступных разрешений:
Datatype Bytes resolution
------------------ ----- --------------------------------
Deg*100 (SMALLINT) 4 1570 m 1.0 mi Cities
DECIMAL(4,2)/(5,2) 5 1570 m 1.0 mi Cities
SMALLINT scaled 4 682 m 0.4 mi Cities
Deg*10000 (MEDIUMINT) 6 16 m 52 ft Houses/Businesses
DECIMAL(6,4)/(7,4) 7 16 m 52 ft Houses/Businesses
MEDIUMINT scaled 6 2.7 m 8.8 ft
FLOAT 8 1.7 m 5.6 ft
DECIMAL(8,6)/(9,6) 9 16cm 1/2 ft Friends in a mall
Deg*10000000 (INT) 8 16mm 5/8 in Marbles
DOUBLE 16 3.5nm ... Fleas on a dog
- http://mysql.rjweb.org/doc.php/latlng#representation_choices
Если вы щелкнете по местоположению на Картах Google, вы получите широту и долготу с 7 знаками после запятой