mappe - Qual è il modo migliore per memorizzare le coordinate(longitudine/latitudine, da Google Maps) in SQL Server?



sql-server sql-server-2008 (8)

Sto progettando una tabella in SQL Server 2008 che memorizzerà un elenco di utenti e una coordinata di Google Maps (longitudine e latitudine).

Avrò bisogno di due campi, o può essere fatto con 1?

Qual è il migliore (o il più comune) tipo di dati da utilizzare per la memorizzazione di questo tipo di dati?

https://ffff65535.com


NOTA : Questa è una risposta recente basata sul recente server SQL, aggiornamenti dello stack .NET

latitute e longitudine da google maps devono essere memorizzati come dati Point (nota capitale P) nel server SQL sotto tipo di dati geografici.

Supponendo che i tuoi dati attuali siano memorizzati in una tabella Sample come varchar sotto le colonne lat e lon , sotto query ti aiuterà a convertire in geografia

alter table Sample add latlong geography
go
update Sample set latlong= geography::Point(lat,lon,4326)
go

PS: la prossima volta che effettui una selezione su questa tabella con i dati geografici, oltre alla scheda Risultati e messaggi, otterrai anche la scheda Risultati spaziali come di seguito per la visualizzazione


Archiviare entrambi come float e utilizzare parole chiave univoche su them.i.em

create table coordinates(
coord_uid counter primary key,
latitude float,
longitude float,
constraint la_long unique(latitude, longitude)
);

Il modo in cui lo faccio: memorizzo la latitudine e la longitudine e poi ho una terza colonna che è un tipo geografico derivato automatico delle prime due colonne. La tabella si presenta così:

CREATE TABLE [dbo].[Geopoint]
(
    [GeopointId] BIGINT NOT NULL PRIMARY KEY IDENTITY, 
    [Latitude] float NOT NULL, 
    [Longitude] float NOT NULL, 
    [ts] ROWVERSION NOT NULL, 
    [GeographyPoint]  AS ([geography]::STGeomFromText(((('POINT('+CONVERT([varchar](20),[Longitude]))+' ')+CONVERT([varchar](20),[Latitude]))+')',(4326))) 
)

Questo ti dà la flessibilità delle query spaziali sulla colonna geoPoint e puoi anche recuperare i valori di latitudine e longitudine quando ne hai bisogno per la visualizzazione o l'estrazione a fini CSV.


Odio essere un controcante di quelli che hanno detto "ecco un nuovo tipo, usiamolo". I nuovi tipi spaziali di SQL Server 2008 hanno alcuni vantaggi: l'efficienza, tuttavia non si può dire ciecamente usare sempre quel tipo. Dipende davvero da alcuni problemi di immagine più grandi.

Ad esempio, integrazione. Questo tipo ha un tipo equivoco in .Net - ma per quanto riguarda l'interoperabilità? Che dire del supporto o dell'estensione delle versioni precedenti di .Net? Che dire dell'esposizione di questo tipo attraverso il livello di servizio ad altre piattaforme? Che dire della normalizzazione dei dati? Forse sei interessato a lat o long come pezzi di informazione autonomi. Forse hai già scritto una complessa logica di business per gestire long / lat.

Non sto dicendo che non dovresti usare il tipo spaziale, in molti casi dovresti. Sto solo dicendo che dovresti fare alcune domande più critiche prima di intraprendere questa strada. Per rispondere alla tua domanda con la massima precisione, avrei bisogno di sapere di più sulla tua situazione specifica.

Memorizzare long / lat separatamente o in un tipo spaziale sono entrambe soluzioni valide, e uno può essere preferibile all'altro a seconda delle circostanze.



Se hai appena intenzione di sostituirlo in un URL, suppongo che un campo lo farebbe, quindi puoi creare un URL come

http://maps.google.co.uk/maps?q=12.345678,12.345678&z=6

ma siccome sono due pezzi di dati li conserverei in campi separati


Non conosco la risposta per SQL Server ma ...

In MySQL salvalo come FLOAT( 10, 6 )

Questa è la raccomandazione ufficiale dalla documentazione per gli sviluppatori di Google .

CREATE TABLE `coords` (
  `lat` FLOAT( 10, 6 ) NOT NULL ,
  `lng` FLOAT( 10, 6 ) NOT NULL ,
) ENGINE = MYISAM ;

Giusto avvertimento! Prima di prendere il consiglio di usare il tipo GEOGRAPHY, assicurati di non aver intenzione di usare Linq o Entity Framework per accedere ai dati perché non è supportato (a partire da novembre 2010) e sarai triste!

Aggiornamento luglio 2017

Per coloro che leggono questa risposta ora, è obsoleto in quanto si riferisce allo stack tecnologico retrodatato. Vedi i commenti per maggiori dettagli.





spatial