chinnonsantos / sql-paises-estados-cidades

SQL de todos os Países e Nações (c/ Código do Portal do Comércio Exterior ou BACEN) + Estados e Federações Brasileiras (c/ DDD e Código do IBGE) + Cidades e Municípios Brasileiros (c/ Código do IBGE), incluindo as 31 regiões administrativas do DF, Ilhas e Áreas Remotas do Mundo.
MIT License
901 stars 304 forks source link

Latitude e Longitude #11

Closed lucianosb closed 5 years ago

lucianosb commented 6 years ago

O @kelvins já fez o levantamento dos dados de latitude e longitude dos municípios neste repositório: https://github.com/kelvins/Municipios-Brasileiros

Proponho um merge.

luizvaz commented 6 years ago

Eu fiz com essa atualização no PostgreSQL. A implementação do MYSQL deveria usar o tipo nativo POINT e não decimal como ele usou. Ou não adianta de nada para pesquisas espaciais.

chinnonsantos commented 6 years ago

@lucianosb Obrigado pela informação, estou providenciado a atualização desse projeto, mas no nosso caso é mais viável utilizar uma única coluna para armazenar tanto a latitude quanto a longitude.

@luizvaz concordo em parte com sua argumentação, quando se trabalha por exemplo com desenvolvimento na plataforma Android e iOS você só tem bancos de dados em SQLite, e esse somente pode trabalhar com Geolocalização em formato String '12.34987,-9.989844' ou formato double '12.34987' e '-9.989844' armazenando em duas colunas, mesmo que a API do Google Maps tenham métodos que recebem parâmetros do tipo POINT e outras que recebem parâmetros do tipo DOUBLE, não da pra armazenar caso necessário essas informações de forma explicita em POINT no enxuto SQLite, ficando seu banco de dados em nuvem (web-service) em um formato, e seus bancos de dados de aplicações móveis em outro, além de ter que fazer a limpeza/inclusão dos parênteses no momento da sincronização de um banco para o outro, em dados de Geolocalização eu sempre armazeno em uma única coluna com valores numéricos separados por vírgula, é a forma mais simples que eu conheço, pois algumas classes recebem o valor em formato numérico (double ou float) e outras em formato point mas sempre as classes que trabalham com formato point possui métodos nativos de suporte para conversão dos dois valores numéricos em point, já o contrário não, sendo preciso você fazer a separação e conversão manualmente, então é mais simples armazenar essas informações em formato numérico, ou string de dois valores numéricos separados por vírgula.

Como pesquisas espaciais em banco de dados só pode ser feitas por intervalos de valores, isso também pode ser feito em consulta SQL simples do tipo Between, deixando de tipificar o banco de dados e tornando ele mais simples de trabalhar em aplicações multiplataforma, hj quase tudo roda em um celular, e banco de dados de aplicações moveis tem muitas restrições, essa tipificação que é muito eficiente no uso de SGBD robustos como PostgreSQL, MySQL, Oracle, se torna-se trabalhoso quando necessita replicar as informações em um banco SQLite.

phrdev commented 6 years ago

Já foi incluído a latitude e longitude?