¿PostGIS ofrecería una ventaja sobre MySQL para una aplicación de granja de producción?


23

Tengo una aplicación web que almacena las ubicaciones de las granjas en el oeste de Michigan. Puede buscar un producto (por ejemplo, "brócoli") y le mostrará todas las granjas que cultivan ese producto.

En este momento estoy usando MySQL y usando trigonometría para calcular la diferencia entre la ubicación del usuario y la ubicación de cada granja. No es un mal camino, pero tomó algo de trabajo.

Otra cosa que quiero hacer pronto es mapear las estaciones de crecimiento para diferentes productos para diferentes regiones. (Por ejemplo, quiero mostrar que los aguacates crecen en cierta época del año en California pero nunca en Ohio).

Me doy cuenta de que esta es una pregunta abierta y posiblemente ingenua, pero ¿podría valer la pena hacer el cambio a PostgreSQL / PostGIS para aprovechar sus capacidades espaciales?


1
¿Estás planeando mapas dinámicos de "estaciones" o mapas estáticos?
oscuro

Si entiendo lo que estás preguntando, dinámico. Ejemplo: la temporada de crecimiento de las manzanas cerca de Grand Rapids, MI, es de agosto a octubre.
Jason Swett

Respuestas:


21

Soy un gran fanático de PostGIS y no tengo experiencia con MySQL, así que podría ser parcial.

Pero por lo que escribes, pienso en dos razones para cambiar.

primero, seguramente será mucho más fácil implementar nuevas características como el mapa de temporada que mencionaste.

segundo, cuando hoy haces tus cálculos de trigonometría, supongo que lo estás haciendo fuera de la base de datos. si haces todo eso en la base de datos, en cambio, eres mucho más libre en el desarrollo de las aplicaciones superpuestas.

probablemente no tendrá que hacer ningún cálculo fuera de la base de datos si ejecuta postgis.

Lo de la temporada que mencionó podría ser factible en MySQL ya que suena muy básico, pero obtendrá más flexibilidad en PostGIS con acceso a todas las funciones espaciales.

/ Nicklas


18

Aunque solo sea porque tendrá muchas más opciones en aplicaciones de terceros para generar mapas de su información (servidor de mapas, geoservidor, etc.) cargando datos (ogr2ogr, fme, etc.) PostGIS haría una mejor elección. MySQL solo se adaptará si sus necesidades continúan siendo relativamente limitadas.


FME es compatible con MySQL y PostGIS.
Raven

8

MySQL también tiene una extensión espacial pero, que yo sepa (nunca la he usado), no es tan rica en características y estable como PostGIS .

Si está considerando usar una base de datos espacial, PostGIS es una buena opción y el esfuerzo de cambio valdrá la pena.

Si bien MySQL ya proporciona alguna funcionalidad para almacenar y operar con datos geoespaciales, la funcionalidad deja mucho que desear y está lejos de proporcionar compatibilidad total con OpenGIS.

Lo más notable es que todas las funciones que consultan datos espaciales solo operan en MBR (rectángulos de límite mínimo), para simplificar las operaciones.

http://forge.mysql.com/wiki/GIS_Functions


6

La batalla MySQL vs Postgis se eleva una vez más:

http://ambergis.wordpress.com/2008/02/19/mysql-vs-postgis/

Tenga en cuenta que los comentaristas más son de aquí (intercambio de pila gis).

enlaces también

http://www.spatiallyadjusted.com/2008/02/05/bringing-open-source-gis-into-an-esri-shop/#comment-32680

He tenido implementaciones más exitosas con postgis que mysql. (depende de la configuración de los clientes y de lo que intentan lograr)

Mi única sugerencia para Paul Ramsey (y el equipo de PostGIS) es una buena GUI para postgis a través de PgAdmin (v4 ...?) Con un visualizador (como FME de software seguro), no solo los atributos serían una gran ventaja. Actualmente utilizo QGIS para visualizar datos postgis.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.