Как правильно импортировать данные о широте/долготе в MySQL?

У меня есть набор данных о названиях городов с соответствующими широтами/долготами, которые я загрузил в таблицу MySQL, например:Как правильно импортировать данные о широте/долготе в MySQL?

city_id | city_name | широта DECIMAL (9,6) | долгота DECIMAL (9,6)

Типичные координаты широты/долготы могут выглядеть так: 54.284758/32.484736.

Однако, я получаю значения со шкалой 2, чтобы правильно отображаться в моей таблице, другими словами, эквивалент DECIMAL (5,2). Данные загружаются из текстового CSV, который был экспортирован из OpenOffice Calc для целей UTF-8. Я знаю, что OpenOffice имеет некоторые проблемы с десятичными знаками, но полная широта/долгота, безусловно, находится в экспортированном CSV. Если я открою CSV с помощью Блокнота, данные будут точными.

Может ли кто-нибудь увидеть, что я могу делать неправильно?

Спасибо.

ОБНОВЛЕНИЕ: Получил работу, спасибо за все входные данные. Я воссоздал все с нуля, новый файл схемы (я использую ORM), новый CSV-экспорт, новую таблицу, новый LOAD DATA INFILE и работает с правильным десятичным выходом. Ударь меня.

источник

2010-01-27 Tom

Когда вы говорите «неверно» в своей таблице, вы имеете в виду, когда вы набираете «SELECT * FROM mytable» в приглашении MySQL? Или у вас есть зритель? – Tenner

@Tenner .... Я использую MySQL workbench, но результат тот же, когда я вытягиваю координату через PHP. – Tom

Учитывая, что типы данных являются 'DECIMAL (9,6)', а CSV корректен, когда вы просматриваете его в «Блокноте» - что-то происходит с тем, что вы используете для импорта данных. Взгляните на использование MySQL LOAD DATA INFILE, если он обходит любую проблему, с которой вы сталкиваетесь: http://dev.mysql.com/doc/refman/5.1/en/load-data.html –

Это может быть излишним для ваших нужд, но при работе с географическими данными вы можете рассмотреть возможность использования MySQL Spatial Extensions.

Я добавлю, что тип данных, который вы используете в настоящее время, достаточно для представления данных, как в вашем CSV-файле. В вашем импортере есть что-то, что прерывает его во время импорта, или все, что вы используете для просмотра данных, обрезает его.

источник

2010-01-27 15:53:42

Спасибо, посмотрел раньше ..... его немного overkill :) – Tom

Я бы предложил использовать строковый тип данных, такой как varchar для хранения Lat, Long. Я работаю над приложением, которое широко использует эти координаты, и я не сталкивался с какими-либо проблемами, сохраняя его как строку. Сохраняя его как число, вы столкнетесь с проблемами точности.

Просто что-то рассмотреть.

источник

2010-01-27 15:32:35 Lukasz

Спасибо Lukasz. Что вы имели в виду по вопросам точности? Я не буду использовать данные очень строгим образом. Только для создания некоторых кодов Google Map и мини-приложений. Я бы подумал, что шкала 6 довольно точна? – Tom

Как вы сортируете? Или искать в радиусе? Кажется, что сохранение этих строк приведет к большому количеству ненужных кастингов во время выполнения. – Tenner

Точный мудрый Я бы рекомендовал использовать строку или достаточно большое десятичное число. Например, с помощью float может произойти следующее.У меня есть эта координата, которая была возвращена с Bing Maps, 43.371240452765925, сохраняя это значение как float, в результате получилось 43.3712404527659. Это не огромная ошибка, но это ошибка. Что касается сортировки, сортировки T-SQL с использованием порядка Lexicographic, что означает, что строка и числа будут сортироваться аналогичным образом, поэтому нет необходимости бросать. – Lukasz

Почему бы вам просто не объявить поля как имеющие тип DOUBLE в вашей таблице MySQL? Квалификаторы для числа цифр и цифр после десятичной точки являются необязательными.

источник

2010-01-27 15:56:21 vicatcu

Спасибо, попробуем это в одно мгновение, но, как написано в руководстве по MySQL, DOUBLE/FLOAT не является правильным форматом, когда необходима точная точность, тогда как DECIMAL. – Tom

Как правильно импортировать данные о широте/долготе в MySQL?

ответ

Смежные вопросы