Come importare correttamente i dati di latitudine/longitudine in MySQL?

Ho un set di dati di città con le loro latitudini/longitudini corrispondenti che ho caricato in una tabella MySQL, in questo modo:Come importare correttamente i dati di latitudine/longitudine in MySQL?

city_id | nome_città | latitudine DECIMALE (9,6) | longitudine DECIMAL (9,6)

Le coordinate di latitudine/longitudine tipiche potrebbero essere le seguenti: 54.284758/32.484736.

Tuttavia, sto ottenendo solo valori con una scala di 2 per apparire correttamente nella mia tabella, in altre parole, l'equivalente di DECIMAL (5,2). I dati vengono caricati da un CSV di testo che è stato esportato da OpenOffice Calc per scopi UTF-8. So che OpenOffice ha alcuni problemi con i decimali, ma la piena latitudine/longitudini sono certamente nel CSV esportato. Se apro il CSV con Blocco note, i dati vanno bene.

Qualcuno può vedere cosa potrei fare di sbagliato?

Grazie.

UPDATE: Funzionante, grazie per l'input. Ho ricreato tutto da zero, nuovo file di schema (sto usando un ORM), nuovo export CSV, nuova tabella, nuovo LOAD DATA INFILE, e funziona con l'output decimale corretto. Mi batte

fonte

2010-01-27 Tom

Quando si dice "errato" nella tabella, si intende quando si digita "SELECT * FROM mytable" su un prompt MySQL? O hai uno spettatore? – Tenner

@Tenner .... Sto usando il workbench MySQL, ma il risultato è lo stesso quando tiro una coordinata tramite PHP. – Tom

Dato che i tipi di dati sono 'DECIMAL (9,6)', e il CSV è corretto quando lo si visualizza in Blocco note - qualcosa è in su con qualsiasi cosa si sta usando per importare i dati. Dai un'occhiata all'utilizzo di MySQL LOAD DATA INFILE nel caso in cui ignori qualsiasi problema tu stia incontrando: http://dev.mysql.com/doc/refman/5.1/en/load-data.html –

Questo potrebbe essere eccessivo per le vostre esigenze, ma quando si lavora dati geografici si potrebbe prendere in considerazione l'utilizzo di MySQL Spatial Extensions.

Aggiungo che il tipo di dati attualmente in uso è sufficiente per rappresentare i dati così come sono nel file CSV. C'è qualcosa nel tuo importatore che lo sta tagliando al momento dell'importazione, o qualsiasi cosa tu stia usando per visualizzare i dati lo sta troncando.

fonte

2010-01-27 15:53:42

Grazie, ha avuto un aspetto prima ..... è un po 'eccessivo :) – Tom

Suggerirei di utilizzare un tipo di dati stringa come varchar per la memorizzazione di Lat, Long. Sto lavorando su un'app che fa un uso estensivo di queste coordinate e non ho avuto problemi con la memorizzazione come stringa. Memorizzandolo come un numero incontrerai problemi di precisione.

Solo qualcosa da considerare.

fonte

2010-01-27 15:32:35 Lukasz

Grazie Lukasz. Cosa intendevi per problemi di precisione? Non userò i dati in maniera molto severa. Solo per generare alcune coordinate e mini-app di Google Map. Avrei pensato che una scala di 6 fosse abbastanza accurata? – Tom

Come si ordina? Oppure cerca in un raggio? Sembra che la memorizzazione di questi come stringhe comporterebbe un lancio non necessario di runtime. – Tenner

Precision wise Suggerirei di utilizzare una stringa o un decimale sufficientemente grande. Ad esempio, utilizzando float può succedere quanto segue.Ho questa coordinata che è stata restituita da Bing Maps, 43.371240452765925 che memorizza quel valore come risultato float in 43.3712404527659. Non è un errore enorme, ma è un errore. Per quanto riguarda l'ordinamento, T-SQL ordina l'ordine lessicografico, il che significa che stringa e numeri verranno ordinati in modo simile, quindi non è necessario eseguire il cast. – Lukasz

Perché non dichiarare semplicemente i campi come di tipo DOPPIO nella tabella MySQL? I qualificatori per il numero di cifre e cifre dopo il punto decimale sono facoltativi.

fonte

2010-01-27 15:56:21 vicatcu

Grazie, ci proverò in un attimo, ma come dice il manuale MySQL, DOUBLE/FLOAT non è il formato giusto quando è richiesta precisione esatta, mentre DECIMAL è. – Tom

Come importare correttamente i dati di latitudine/longitudine in MySQL?

risposta

Problemi correlati