Como armazeno com eficiência todos os dados do OpenStreetMap de maneira indexada?


8

Eu tenho um arquivo PBF que contém as seguintes informações sobre um país:

  • Nós, cada um com sua própria longitude, latitude e propriedades; usado para armazenar pontos em um espaço 2D.

  • Maneiras, cada uma com suas propriedades, elas são conectadas através de nós; usado para armazenar estradas, limites.

Embora esse arquivo tenha apenas 80 MB no formato compactado, ele tem 592 MB quando descompactado e armazenado em um banco de dados.

Sim, e isso é apenas para um país, a Bélgica. Imagine armazenar França, Alemanha e Itália ao lado.


Vamos pegar uma única estrada, por exemplo, de Antuérpia, passando por Bruxelas até Charleroi. Isso consistiria em uma tonelada de nós para armazenar todas as curvas na estrada, mas eu preciso de todas essas curvas? Eu duvido.

Deixe-me dizer o que eu quero poder fazer:

  • Quero ver o mapa em diferentes níveis de zoom; cidades principais, cidades menores e nível das ruas, pelo menos.

  • Quero poder obter informações de roteamento entre dois pontos.

  • Quero poder calcular a estrada mais próxima da minha localização GPS.

  • Pesquise um local por meio de um índice no banco de dados.

Mas o mais importante é que o banco de dados não deve ser muito grande, pois será armazenado em um dispositivo móvel .


Então, pensei em uma combinação de duas técnicas:

  • Blocos de imagem para fins de visualização, para contornar o armazenamento / processamento de todos os nós individuais.

  • Armazenar os pontos finais das estradas para obter informações de roteamento, juntamente com informações sobre a estrada.

O problema é que não consigo calcular a estrada mais próxima da minha localização GPS apenas com essas informações; imagine que, numa curva em uma rodovia, não consigo determinar se estou na rodovia com apenas os dois pontos finais. Eu estava pensando em armazenar nós intermediários entre os pontos de extremidade, mas seria muito caro gerar, eu acho. Além disso, determinar os pontos finais das estradas (que são como uma divisão em T) provavelmente não é tão fácil, pois eu preciso descobrir se preciso armazenar o ponto médio na parte superior dessa divisão em T ou não.

Portanto, a visualização é fácil usando blocos de imagem; mas não consigo encontrar uma maneira fácil de fazer o roteamento e a localização de GPS, em que tipo de técnica de armazenamento devo procurar? Acho um pouco inconveniente que um 80 MBarquivo se transforme em um banco de dados 592 MB. Quero reduzir esse tamanho o máximo possível ...

O que posso fazer para fazer isso da maneira mais eficiente possível? Em termos de disco e CPU. Estou alvejando um WP7 ...


quanto da 580MB é nó de dados / way e quanto é o índice para ter acesso rápido aos dados
k3b

Respostas:


4

Parece-me que o problema principal é incluir apenas nós que adicionam informações significativas sobre uma estrada.

ou seja, sem o seu requisito de GPS, você pode simplesmente armazenar nós nas junções e terminações (que eu acho que você chama de nós de início / fim). Obviamente, incluindo peso / custos, etc.

Uma maneira de pensar em abordar isso é primeiro, adicionar todos os nós de início / fim. Este é o mínimo necessário. Obviamente, isso não explica estradas sinuosas.

Em seguida, para cada estrada (definida como terminando em cruzamento ou cruzamento), faça o seguinte:

  1. Passe por todos os nós intermediários e calcule a distância mínima de cada nó até a estrada, conforme definido pelos nós incluídos até o momento (para começar apenas com o início e o fim).
  2. Se a soma do acima é maior do (some constant threshold * number of intermediate nodes)que precisamos adicionar nós intermediários. Caso contrário, saia do loop.
    • Para adicionar nós intermediários, localize o nó que teve a maior distância da representação atual da estrada e adicione-o.

Isso faz mais sentido, agora só me pergunto o que seria um bom limite. Parece complicado implementar tudo isso, embora eu possa iniciar a partir do banco de dados de 582 MB que já tenho, em vez de iniciar a partir do arquivo compactado de 80 MB. Vai deixar o aberto questão para ver o que outras idéias aparecer ... :)
Tamara Wijsman

Você teria que equilibrar o limite entre incluir mais nós (tamanho maior) e incluir menos nós (menos precisos), eu acho. Suponha que o primeiro passo seja conseguir gerar um banco de dados menor contendo apenas junções e pontos finais.
George Duckett

Você está impedido de ter os dados entre os nós, incluindo o caminho real. Existem custos entre nós, mas eles podem mudar entre interseções. Os limites de velocidade e o número de faixas não mudam apenas nos cruzamentos. É necessário conhecer o caminho exato para calcular a estrada mais próxima. As linhas de conexão entre os nós, além do caminho real, precisarão de todos os metadados para esse segmento. Esses metadados serão necessários para o roteiro e as direções.
22412 mhoran_psprep

Para a localização de caminhos, você provavelmente pode reduzir o número de nós, por exemplo, se uma estrada (entre cruzamentos) tiver vários nós, em que há alterações no limite de velocidade que não importam quando você está nessa estrada você tem que continuar até o próximo cruzamento. Apenas tenha cuidado ao reduzir os nós para levar em conta diferentes limites de velocidade e comprimentos desses limites de velocidade. O mesmo vale para o número de faixas, você apenas teria que reduzi-lo a um peso de borda apropriado.
George Duckett

Depende também da definição de 'junção' o significado que reduziria ao máximo, mas seria menos preciso seria simplesmente onde duas ou mais estradas se encontram. Uma alternativa poderia ser onde uma propriedade da estrada mudou (ie Menor-> Maior, 30km-> 40km etc).
George Duckett
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.