¿Cuál es el tipo de datos ideal para usar cuando se almacena la latitud / longitud en una base de datos MySQL?

432

Teniendo en cuenta que realizaré cálculos en pares lat / long, ¿qué tipo de datos es el más adecuado para usar con una base de datos MySQL?

Codebeef
fuente
1
Este enlace me pareció muy útil: howto-use-mysql-spatial-ext.blogspot.com/2007/11/… Puede ser un poco más antiguo, pero contiene una explicación completa que incluye ejemplos.
madc
En mi opinión, la mayoría de las personas aquí no entienden lo que sucede. Tan pronto como el código de la aplicación toca un número, siempre que uno use dobles (que la mayoría lo hace), el número se convierte en la máxima precisión doble . Almacenarlo con incluso un millón de decimales no servirá de nada. Almacenarlo con un número limitado de decimales (por ejemplo, 6) destruye parte de esa precisión y agrega un error acumulado cada vez que se reescribe en la base de datos . Un doble lleva aproximadamente 16 números significativos, potencialmente todos decimales. Eliminar 10 de ellos crea un error acumulado con el tiempo. Es "punto flotante" por la razón. Cont.
Ventormenta
Cont: 6 decimales pueden estar bien cuando se almacena una figura como adquirida de una fuente externa, inalterada y por primera vez, como material fuente. Pero si realiza un cálculo en él incluso una vez, y lo almacena de nuevo, es tonto eliminar parte de su precisión aplicando un formato decimal específico. Realizar el cálculo únicamente dentro del servidor puede ser diferente (el servidor puede o no estar usando otra cosa que no sea el doble internamente), y el uso de representaciones numéricas peores que el doble en el cálculo de la aplicación de c disminuye la necesidad de precisión de almacenamiento por igual.
Ventormenta el
Cont: SI el servidor almacena el número con mayor precisión, a pesar del "9.6" (que no sé si lo hace), entonces nada de todo esto importa, y el formato es puramente una cuestión de conveniencia. hacer con problemas de precisión. Pero no me sorprendería si el servidor realmente redondea cualquier número en precisión decimal 6 con ese formato.
Ventormenta
Cont: Finalmente: para lat, lon, el sexto decimal es cuestión de encajar en un ca. Rejilla de 11 centímetros. Cada vez que uno lee (toca), calcula y almacena de nuevo, con 6 decimales, habrá un nuevo ajuste (= error acumulado). Si todos los errores van en la misma dirección, habrá un gran error. Si realiza multiplicaciones temporales en él (p. Ej., Escala hacia arriba, luego resta y escala hacia abajo), puede crecer aún más. ¡No deseche la precisión sin un buen rason!
Ventormenta

Respuestas:

161

Use las extensiones espaciales de MySQL con SIG.

Kirk Strauser
fuente
25
¿Tiene algún otro enlace a ejemplos o alguna otra información sobre la mejor manera de comenzar con ellos?
Codebeef
66
MYSQL Spatial es una buena opción, pero aún tiene límites y advertencias importantes (a partir de 6). Por favor vea mi respuesta a continuación ...
James Schek
1
@James Schek tiene razón. Además, MySQL hace todos sus cálculos utilizando geometría euclidiana, por lo que no representa un caso de uso del mundo real para lat / lng.
mkuech
FYI; Mysql admite el índice espacial solo con tablas * .myisam, es decir, el motor ISAM. Enlace: dev.mysql.com/doc/refman/5.0/en/creating-spatial-indexes.html
PodTech.io
Eche un vistazo a este artículo al final Parte de actualización: mysqlserverteam.com/mysql-5-7-and-gis-an-example
Jaspal Singh
150

Google proporciona una solución PHP / MySQL de principio a fin para una aplicación de ejemplo "Localizador de tiendas" con Google Maps. En este ejemplo, almacenan los valores lat / lng como "Float" con una longitud de "10,6"

http://code.google.com/apis/maps/articles/phpsqlsearch.html

Ted Avery
fuente
11
Google claramente no entiende cómo funciona la especificación FLOAT: FLOAT(10,6)deja 4 dígitos para la parte entera de la coordenada. Y no, el signo no cuenta, eso proviene del atributo (no) firmado.
Alix Axel
2
Pero si necesita almacenar como parte integral los valores de [0, 180] deberían ser más que suficientes, ¿verdad?
Hrvoje Golcic
37
@AlixAxel Creo que Google sabe lo que está haciendo. Porque establece que: " Con las capacidades de zoom actuales de Google Maps, solo debería necesitar 6 dígitos de precisión después del decimal. Eso permitirá que los campos almacenen 6 dígitos después del decimal, más hasta 4 dígitos antes del decimal, por ejemplo : 123.456789 grados ". Si se marca sin firmar, el patrón será 1234,567890 . Entonces no hay problemas.
1.44mb
16
@AlixAxel Él cuenta los números en la secuencia; no utiliza una coordenada real ...
Andrew Ellis
8
Usando el tipo Doublede datos para Laravel
FooBar
134

Básicamente depende de la precisión que necesita para sus ubicaciones. Usando DOUBLE tendrás una precisión de 3.5nm. DECIMAL (8,6) / (9,6) baja a 16 cm. FLOTADOR es 1.7m ...

Esta tabla muy interesante tiene una lista más completa: http://mysql.rjweb.org/doc.php/latlng :

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

Espero que esto ayude.

Simón
fuente
2
Necesito escribir un comentario constructivo y detallado centrado en el contenido de las publicaciones, por lo que diré que mientras observaba la tabla de precisión proporcionada por el sitio web de Rick James, me divirtió un poco la descripción de la resolución "pulgas en un perro" y lo sentí digno de felicitaciones. Técnicamente hablando, esta fue una representación útil que me ayudó a decidir qué tipo de datos usar al almacenar coordenadas para medir la distancia entre dos direcciones, lo cual, @ Simon, me gustaría agradecerle por compartir.
Sam_Butler
FWIW, el uso de ese enlace de "SMALLINT escalado" es terriblemente ineficiente. La respuesta de Oguzhan es una excelente manera de almacenar long / lat con 7 dígitos después del punto decimal, en un int de 4 bytes con signo. Gran precisión (~ 1 cm) en un tamaño pequeño (4B).
ToolmakerSteve
74

Las extensiones espaciales de MySQL son la mejor opción porque tiene la lista completa de operadores e índices espaciales a su disposición. Un índice espacial le permitirá realizar cálculos basados ​​en la distancia muy rápidamente. Tenga en cuenta que a partir de 6.0, la extensión espacial aún está incompleta. No estoy dejando de lado MySQL Spatial, solo para informarles sobre las trampas antes de avanzar demasiado en esto.

Si está tratando estrictamente con puntos y solo con la función DISTANCE, está bien. Si necesita hacer algún cálculo con polígonos, líneas o puntos almacenados, los operadores espaciales no proporcionan resultados exactos a menos que use el operador "relacionar". Vea la advertencia en la parte superior de 21.5.6 . Las relaciones como contiene, dentro o intersectan están utilizando el MBR, no la forma geométrica exacta (es decir, una Elipse se trata como un Rectángulo).

Además, las distancias en MySQL Spatial están en las mismas unidades que su primera geometría. Esto significa que si está usando grados decimales, sus mediciones de distancia están en grados decimales. Esto hará que sea muy difícil obtener resultados exactos a medida que salga del ecuador.

James Schek
fuente
26
Reestableciendo: Las extensiones espaciales de MySQL no son adecuadas para calcular grandes distancias circulares entre puntos en la superficie de la tierra representados por lat / long. Sus funciones de distancia, etc., solo son útiles en coordenadas cartesianas, planas.
O. Jones
71

Cuando hice esto para una base de datos de navegación construida a partir de ARINC424, hice una buena cantidad de pruebas y, mirando hacia atrás en el código, utilicé un DECIMAL (18,12) (en realidad un NUMERIC (18,12) porque era firebird).

Los flotadores y los dobles no son tan precisos y pueden dar lugar a errores de redondeo que pueden ser algo muy malo. No recuerdo si encontré datos reales que tenían problemas, pero estoy bastante seguro de que la imposibilidad de almacenar con precisión en un flotante o un doble podría causar problemas

El punto es que cuando usamos grados o radianes sabemos el rango de los valores, y la parte fraccionaria necesita la mayor cantidad de dígitos.

Las extensiones espaciales de MySQL son una buena alternativa porque siguen el modelo de geometría OpenGIS . No los usé porque necesitaba mantener mi base de datos portátil.

Richard Harrison
fuente
3
Gracias, esto fue útil. Se siente extraño leer todas estas preguntas y respuestas de 2008 al darse cuenta de que ya era hace 8 años.
aexl
1
@TheSexiestManinJamaica: antes de IEEE 754-1985, el hardware de punto flotante de la computadora era caótico. Incluso hubo en la máquina donde a*bno era igual b*a(para algunos valores). Había muchos ejemplos algo así como: 2+2 = 3.9999. El estándar limpió mucho desorden, y fue adoptado 'rápidamente' por prácticamente todas las piezas de hardware y software. Entonces, esta discusión ha sido válida, no solo desde 2008, sino durante un tercio de siglo.
Rick James
42

Depende de la precisión que requiera.

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

De: http://mysql.rjweb.org/doc.php/latlng

Resumir:

  • La opción disponible más precisa es DOUBLE.
  • El tipo visto más común utilizado es DECIMAL(8,6)/(9,6).

A partir de MySQL 5.7 , considere usar Tipos de datos espaciales (SDT), específicamente POINTpara almacenar una sola coordenada. Antes de 5.7, SDT no admite índices (con la excepción de 5.6 cuando el tipo de tabla es MyISAM).

Nota:

  • Cuando se usa la POINTclase, el orden de los argumentos para almacenar coordenadas debe ser POINT(latitude, longitude).
  • Hay una sintaxis especial para crear un índice espacial .
  • El mayor beneficio de usar SDT es que tiene acceso a las funciones de análisis espacial , por ejemplo, calcular la distancia entre dos puntos ( ST_Distance) y determinar si un punto está contenido dentro de otra área ( ST_Contains).
Gajus
fuente
2
Copia parte pegada de una respuesta anterior y "resume" con algo que el tipo que creó esa tabla no recomendó : «¿Cómo PARTICIPAR? Bueno, MySQL es muy exigente. Entonces FLOTANTE / DOBLE están fuera. DECIMAL está fuera. Entonces, estamos atrapados con un poco de kludge. Esencialmente, necesitamos convertir Lat / Lng a algún tamaño de INT y usar PARTITION BY RANGE ». Y «FLOTADOR tiene 24 bits significativos; DOBLE tiene 53. (No funcionan con PARTICIONAMIENTO, pero se incluyen para completar. A menudo las personas usan DOBLE sin darse cuenta de cuánto es una exageración y cuánto espacio ocupa). »Simplemente deje la parte SDT que escribió.
Brazo
1
@Armfoot Si nos fijamos en el momento de las ediciones, es la otra respuesta que me copió. No es que importe: estoy viendo que Stack Overflow es más una "nota para el futuro de mí".
Gajus
1
No, él no te copió, simplemente pegó la tabla como lo hiciste desde el enlace al que hizo referencia en 2014 (tu publicación es de 2015). Por cierto, creo que escribiste mal "Especial" cuando vinculaste Tipos de datos espaciales . Esta parte que escribió es realmente útil para las personas que desean comenzar a usarlos, si agrega algunos ejemplos más CREATE TABLE geom (g GEOMETRY NOT NULL, SPATIAL INDEX(g)) ENGINE=MyISAM;y la advertencia sobre las limitaciones de SDT, como James mencionó , tal vez su respuesta sea más concisa y precisa para ayudar a otras personas también. ..
Armfoot
@Gajus - ¡Me siento honrado de que dos de ustedes hayan encontrado mi documento! (No, no sé qué tan grande es una pulga, pero sentí que llamaría la atención de alguien.)
Rick James
Cuando se utiliza la clase POINT, el orden de los argumentos para almacenar coordenadas debe ser POINT (longitud / X, latitud / Y).
AndreyP
19

Úselo DECIMAL(8,6)para la latitud (90 a -90 grados) y DECIMAL(9,6)para la longitud (180 a -180 grados). 6 decimales están bien para la mayoría de las aplicaciones. Ambos deben estar "firmados" para permitir valores negativos.

Alex Holsgrove
fuente
DECIMALtipo está destinado a cálculos financieros donde no floor/ceilse acepta ningún . El llano FLOATsupera significativamente DECIMAL.
Kondybas
1
@Kondybas: dado que el costo principal en una base de datos es buscar filas, la diferencia de rendimiento entre flotante y decimal no debería ser una preocupación.
Rick James
14

No es necesario ir lejos, según Google Maps, lo mejor es FLOTAR (10,6) para lat y lng.

Mariano Peinador
fuente
¿de dónde sacaste esta información que no puedo encontrar? por si algo cambia.
webfacer
1
@webfacer, está en la sección "Crear una tabla en MySQL" aquí: developers.google.com/maps/documentation/javascript/… eg lat FLOAT( 10, 6 ) NOT NULL, lng FLOAT( 10, 6 ) NOT NULL
turrican_34
1
@webfacer, parece que esa FLOATsintaxis está obsoleta a partir de mysql 8.0.17. Mysql ahora recomienda usar FLOATsin parámetros de precisión dev.mysql.com/doc/refman/8.0/en/numeric-type-overview.html y dev.mysql.com/doc/refman/5.5/en/floating-point- types.html
turrican_34
7

Almacenamos latitud / longitud X 1,000,000 en nuestra base de datos Oracle como NÚMEROS para evitar errores de redondeo con dobles.

Dado que la latitud / longitud hasta el sexto lugar decimal era 10 cm de precisión, eso era todo lo que necesitábamos. Muchas otras bases de datos también almacenan lat / long al sexto lugar decimal.


fuente
2
Multiplicar por un gran número (como un millón) es excelente si tiene muchos datos porque las operaciones de enteros (por ejemplo, la recuperación indexada) son mucho más rápidas que las flotantes.
Kaitlin Duck Sherwood
@KaitlinDuckSherwood: los bits son bits: no conozco ninguna razón por la que un flotante de 32 bits sea más lento para la recuperación (indexado o no) que un entero de 32 bits. Incluso las matemáticas flotantes en estos días son lo suficientemente rápidas como para no ser un problema. Sin embargo, estoy de acuerdo con el comentario de usar un multiplicador implícito con un número entero: maximiza la precisión que obtienes de 32 bits. Un poco de futuro a medida que la tecnología mejora.
ToolmakerSteve
6

En una perspectiva completamente diferente y más simple:

De esta manera, no necesita preocuparse por indexar números y todos los demás problemas asociados con los tipos de datos que pueden arruinar sus coordenadas.

Brazo
fuente
No es bueno. OP dijo que estaría realizando cálculos en los pares lat / lng - sus respuestas lo excluyen
Yarin
44
@Yarin Esta es una pregunta popular en la que algunas (o muchas) personas solo necesitan una respuesta sobre cómo almacenar las coordenadas de acuerdo con sus propias necesidades (muchas de ellas pueden simplemente usar los mapas de Google). Su voto negativo sugiere que esta respuesta puede no ayudarlos ... Al almacenar las coordenadas en una cadena, sabrán exactamente los valores originales que se les proporcionaron (por ejemplo: Google), lo que los ayudará más adelante si deciden evolucionar su propia aplicación y realizar cálculos sobre ellos. En ese momento, seguirán teniendo los datos sin procesar originales solo porque no lo estropearon con las conversiones.
Armfoot
4

dependiendo de su aplicación, sugiero usar FLOAT (9,6)

las teclas espaciales le darán más funciones, pero en los puntos de referencia de producción los flotadores son mucho más rápidos que las teclas espaciales. (0,01 VS 0,001 en AVG)

Torben Brodt
fuente
1
¿Puede proporcionar los resultados de su prueba con detalles aquí?
NameNotFoundException
4

MySQL usa double para todos los flotantes ... Así que usa type double. El uso de flotante dará lugar a valores redondeados impredecibles en la mayoría de las situaciones.

mlinuxgada
fuente
1
MySQL realiza operaciones enDOUBLE . MySQL le permite almacenar datos como 4 bytes FLOATu 8 bytes DOUBLE. Por lo tanto, es probable que haya una pérdida de precisión al almacenar una expresión en una FLOATcolumna.
Rick James
4

Si bien no es óptimo para todas las operaciones, si está haciendo mosaicos de mapas o trabajando con grandes cantidades de marcadores (puntos) con una sola proyección (por ejemplo, Mercator, como Google Maps y muchos otros marcos de mapas resbaladizos esperan), he encontrado lo que Yo llamo "Vast Coordinate System" para ser muy, muy útil. Básicamente, almacena las coordenadas de píxel x e y de alguna manera ampliada: utilizo el nivel de zoom 23. Esto tiene varios beneficios:

  • Realiza la costosa transformación de píxeles de lat / lng a mercator una vez en lugar de cada vez que maneja el punto
  • Obtener la coordenada de mosaico de un registro dado un nivel de zoom requiere un desplazamiento a la derecha.
  • Obtener la coordenada de píxeles de un registro requiere un desplazamiento a la derecha y un AND a nivel de bits.
  • Los cambios son tan ligeros que es práctico hacerlos en SQL, lo que significa que puede hacer un DISTINCT para devolver solo un registro por ubicación de píxel, lo que reducirá el número de registros devueltos por el back-end, lo que significa menos procesamiento en el Interfaz.

Hablé sobre todo esto en una reciente publicación de blog: http://blog.webfoot.com/2013/03/12/optimizing-map-tile-generation/

Kaitlin Duck Sherwood
fuente
4

Estoy muy sorprendido por algunas respuestas / comentarios.

¿Por qué alguien estaría dispuesto a "disminuir" la precisión, y luego realizar cálculos con los peores números? Suena en última instancia estúpido.

Si la fuente tiene una precisión de 64 bits, ciertamente sería tonto arreglar la escala de forma voluntaria, por ejemplo. 6 decimales, y limite la precisión a un máximo de 9 dígitos significativos (lo que sucede con el formato decimal 9.6 comúnmente propuesto).

Naturalmente, uno almacena los datos con la precisión que tiene el material de origen. La única razón para disminuir la precisión sería un espacio de almacenamiento limitado.

  • Almacene las figuras de origen con precisión original
  • Almacene las cifras calculadas a partir de la fuente en la precisión con la que se realiza el cálculo (por ejemplo, si el código de la aplicación usa dobles, almacene los resultados como dobles)

El formato decimal 9.6 provoca un fenómeno de ajuste a la cuadrícula. Ese debería ser el último paso, si es que va a suceder.

No invitaría errores acumulados a mi nido.

Ventormenta
fuente
2
Debido a que la mayoría de las herramientas y aplicaciones de GPS solo tienen una precisión de 6 decimales. No tiene sentido almacenar datos con mayor precisión que las herramientas que pueden medir gis.stackexchange.com/questions/8650/…
Yarin
1
@Yarin Sí, de hecho, pero hablamos de mediciones y GPS, que no se mencionan en la pregunta. Ciertamente existen cifras más precisas. Pero consideremos el GPS; digamos un conjunto de datos fuente de flotantes de 64 bits, que ya contiene una inexactitud. 6 decimales significa ajustar una latitud al ca 11 centímetros más cercano. Por lo tanto, ahora solo almacenando los datos (con 6 decimales), se abre para una posible imprecisión de 22 cm (si originalmente también era de 11 cm). Voluntariamente, probablemente para hacer un cálculo de 64 bits sobre eso, antes de almacenar una tercera vez, ahora una ventana de inexactitud de 33 cm, + -16 cm. Suena tonto, en mi humilde opinión.
Ventormenta
@Rick James probablemente lo almacene como 64 bits, es decir. 0.3333333333333333. Hablamos de geodatos, ¿verdad? "1/3" rara vez aparece en la naturaleza donde las cosas se miden normalmente, con una precisión razonable.
Ventormenta
4

TL; DR

Use FLOAT (8,5) si no está trabajando en la NASA / militares y no está haciendo sistemas de aeronaves navi.


Para responder completamente a su pregunta, deberá considerar varias cosas:

Formato

  • grados minutos segundos : 40 ° 26 ′ 46 ″ N 79 ° 58 ′ 56 ″ W
  • grados minutos decimales : 40 ° 26.767 ′ N 79 ° 58.933 ′ O
  • grados decimales 1 : 40.446 ° N 79.982 ° W
  • grados decimales 2 : -32.60875, 21.27812
  • ¿Algún otro formato casero? Nadie le prohíbe hacer su propio sistema de coordenadas centrado en el hogar y almacenarlo como rumbo y distancia de su hogar. Esto podría tener sentido para algunos problemas específicos en los que está trabajando.

Entonces, la primera parte de la respuesta sería: puede almacenar las coordenadas en el formato que utiliza su aplicación para evitar conversiones constantes de un lado a otro y hacer consultas SQL más simples.

Lo más probable es que use Google Maps u OSM para mostrar sus datos, y GMaps está usando el formato "grados decimales 2". Por lo tanto, será más fácil almacenar coordenadas en el mismo formato.

Precisión

Luego, le gustaría definir la precisión que necesita. Por supuesto, puede almacenar coordenadas como "-32.608697550570334,21.278081997935146", pero ¿alguna vez le han importado los milímetros mientras navegaba al punto? Si no está trabajando en la NASA y no está haciendo satélites o cohetes o trayectorias de aviones, debería estar bien con una precisión de varios metros.

El formato de uso común es de 5 dígitos después de los puntos, lo que le brinda una precisión de 50 cm.

Ejemplo : hay una distancia de 1 cm entre X, 21.278081 8 y X, 21.278081 9 . Entonces, 7 dígitos después del punto le dan precisión de 1 / 2cm y 5 dígitos después del punto le darán precisión de 1/2 metros (porque la distancia mínima entre puntos distintos es 1m, por lo que el error de redondeo no puede ser más de la mitad). Para la mayoría de los propósitos civiles, debería ser suficiente.

grados formato de minutos decimales (40 ° 26.767 ′ N 79 ° 58.933 ′ W) le ofrece exactamente la misma precisión que 5 dígitos después del punto

Almacenamiento de espacio eficiente

Si seleccionó el formato decimal, su coordenada es un par (-32.60875, 21.27812). Obviamente, 2 x (1 bit para signo, 2 dígitos para grados y 5 dígitos para exponente) serán suficientes.

Así que aquí me gustaría apoyar a Alix Axel de los comentarios que dicen que la sugerencia de Google para almacenarlo en FLOAT (10,6) es realmente adicional, porque no necesita 4 dígitos para la parte principal (ya que el signo está separado y la latitud es limitada a 90 y la longitud se limita a 180). Puede usar fácilmente FLOAT (8,5) para una precisión de 1 / 2m o FLOAT (9,6) para una precisión de 50 / 2cm. O incluso puede almacenar lat y long en tipos separados, porque FLOAT (7,5) es suficiente para lat. Consulte la referencia de tipos flotantes de MySQL . Cualquiera de ellos será como FLOAT normal e igual a 4 bytes de todos modos.

Por lo general, el espacio no es un problema hoy en día, pero si desea optimizar realmente el almacenamiento por alguna razón (Descargo de responsabilidad: no optimice previamente), puede comprimir lat (no más de 91 000 valores + signo) + largo (no más de 181 000 valores + signo) a 21 bits, que es significativamente menor que 2xFLOAT (8 bytes == 64 bits)

El Padrino
fuente
3

Las funciones espaciales en PostGIS son mucho más funcionales (es decir, no están limitadas a las operaciones de BBOX) que las de las funciones espaciales de MySQL. Compruébalo: texto del enlace

Dylan
fuente
1
  1. Las latitudes varían de -90 a +90 (grados), por lo que DECIMAL (10, 8) está bien para eso

  2. las longitudes varían de -180 a +180 (grados), por lo que necesita DECIMAL (11, 8).

Nota: El primer número es el número total de dígitos almacenados, y el segundo es el número después del punto decimal.

En breve: lat DECIMAL(10, 8) NOT NULL, lng DECIMAL(11, 8) NOT NULL

mahfuz
fuente
0

Le sugiero que use el tipo de datos Float para SQL Server.

Anderson Ribeiro
fuente
-2

Los cálculos Lat Long requieren precisión, por lo tanto, utilice algún tipo de tipo decimal y haga que la precisión sea al menos 2 mayor que el número que almacenará para realizar los cálculos matemáticos. No conozco los tipos de datos de mi sql, pero en el servidor SQL la gente a menudo usa flotante o real en lugar de decimal y se mete en problemas porque estos son números estimados, no números reales. Así que solo asegúrese de que el tipo de datos que usa sea un tipo decimal verdadero y no un tipo decimal flotante y que debería estar bien.

HLGEM
fuente
1
ambos tipos flotante y decimal tienen su lugar. Como regla general, los flotantes significan variables físicas y los decimales son para entidades contables (principalmente dinero). no veo por qué preferirías decimal para lat / long
Javier
1
También creo que float está bien para lat / long. Al menos en SQL Server (4bytes, 7 dígitos).
Dragoljub Ćurčić
El flotador no es exacto, se estima, ¡el lago de exactitud en un lat largo es fatal! Podría señalarle un lugar completamente diferente en el mundo.
HLGEM
2
El error máximo de los tipos de datos flotantes es lo suficientemente bajo como para que esto no sea un problema. Quiero decir, debes tener en cuenta la multiplicación / acumulación de errores con ambas implementaciones de todos modos.
Spidey
@HLGEM - Redondear a una cierta cantidad de decimales también te lleva a un lugar diferente en el mundo. La pregunta es si ese punto diferente está tan cerca que no importa.
Rick James
-3

A FLOATdebería darle toda la precisión que necesita y ser mejor para las funciones de comparación que almacenar cada coordenada como una cadena o similar.

Sin embargo, si su versión de MySQL es anterior a la 5.0.3, es posible que tenga que prestar atención a ciertos errores de comparación de coma flotante .

Antes de MySQL 5.0.3, las columnas DECIMAL almacenan valores con precisión exacta porque se representan como cadenas, pero los cálculos de los valores DECIMAL se realizan mediante operaciones de punto flotante. A partir de 5.0.3, MySQL realiza operaciones DECIMAL con una precisión de 64 dígitos decimales, lo que debería resolver los problemas de imprecisión más comunes cuando se trata de columnas DECIMAL

ConroyP
fuente
2
Necesita un tipo de datos de coordenadas de latitud / longitud real para facilitar las matemáticas. Imagine la conveniencia de algo como el equivalente de "seleccionar * de las tiendas donde la distancia (tiendas.ubicación, miubicación) <5 millas"
Kirk Strauser
1
No había oído hablar de las extensiones espaciales antes, eso suena muy conveniente, ya que previamente trabajé en una aplicación heredada que hace bastantes cálculos geográficos, debe verificarlo.
ConroyP
@ConroyP - No. Esa cita señala que DECIMALtenía (antes de 5.0.3) ciertos errores debido al uso de la implementación flotante.
Rick James