O PostGIS ofereceria uma vantagem sobre o MySQL para um aplicativo de farm de produção?


23

Eu tenho um aplicativo da web que armazena os locais das fazendas no oeste de Michigan. Você pode procurar um produto (por exemplo, "brócolis") e ele mostrará todas as fazendas que cultivam esse produto.

No momento, estou usando o MySQL e a trigonometria para calcular a diferença entre a localização do usuário e a localização de cada farm. Não é um caminho ruim, mas demorou um pouco.

Outra coisa que quero fazer em breve é ​​mapear as épocas de cultivo de diferentes produtos para diferentes regiões. (Por exemplo, quero mostrar que o abacate cresce em uma determinada época do ano na Califórnia, mas nunca em Ohio.)

Sei que essa é uma pergunta aberta e possivelmente ingênua, mas pode valer a pena mudar para o PostgreSQL / PostGIS para tirar proveito de suas capacidades espaciais?


1
Você está planejando mapas dinâmicos de "temporada" ou estáticos?
Underdark

Se eu entendo o que você está perguntando, dinâmico. Exemplo: a estação de crescimento para maçãs perto de Grand Rapids, MI, de agosto a outubro.
precisa

Respostas:


21

Sou um grande fã do PostGIS e não tenho experiência com o MySQL, por isso devo ser tendencioso.

Mas pelo que você escreve, penso em duas razões para mudar.

primeiro, certamente será muito mais fácil implementar novos recursos, como o mapa da temporada que você mencionou.

segundo, quando hoje você faz seus cálculos de trigonometria, acho que está fazendo isso fora do banco de dados. se você fizer tudo isso no banco de dados, ficará muito mais livre no desenvolvimento dos aplicativos de sobreposição.

você provavelmente não precisará fazer nenhum cálculo fora do banco de dados se executar o postgis.

a coisa da temporada que você mencionou pode ser possível no MySQL, pois parece muito básico, mas você terá uma maior flexibilidade no PostGIS com acesso a todas as funcionalidades espaciais.

/ Nicklas


18

Se apenas porque você terá muito mais opções em aplicativos de terceiros para gerar mapas de suas informações (servidor de mapas, servidor geográfico, etc, etc), carregar dados (ogr2ogr, fme, etc) O PostGIS faria uma escolha melhor. O MySQL servirá apenas se suas necessidades continuarem relativamente limitadas.


O FME suporta MySQL e PostGIS.
Raven

8

O MySQL também tem uma extensão espacial , mas, tanto quanto eu sei (nunca o usei), não é tão rico em recursos e estável quanto o PostGIS .

Se você está pensando em usar um banco de dados espacial, o PostGIS é uma boa escolha e o esforço de alternar valerá a pena.

Enquanto o MySQL já fornece algumas funcionalidades para armazenar e operar dados geoespaciais, a funcionalidade deixa muito a desejar e está longe de oferecer compatibilidade total com o OpenGIS.

O mais notável é que todas as funções que consultam dados espaciais operam apenas em MBRs (retângulos limitantes mínimos), para simplificar as operações.

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


6

A batalha entre MySQL e Postgis surge novamente:

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

Observe que os comentaristas mais são daqui (gis stack exchange).

links também

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

Tiveram implementações mais bem - sucedidas com o postgis do que o mysql. (dependem da configuração dos clientes e do que eles estão tentando alcançar)

Minha única sugestão para Paul Ramsey (e equipe do PostGIS) é uma boa interface gráfica para postgis via PgAdmin (v4 ..?) Com um visualizador (como o FME do software seguro) - não apenas os atributos seriam uma grande vantagem. Atualmente, use o QGIS para visualizar dados postgis.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.