Criando polígonos de tempo de unidade usando ferramentas de código aberto?

Alguém está usando ferramentas de código aberto e / ou dados para gerar polígonos de tempo de unidade que irradiam de um determinado local? Por exemplo, usei produtos ESRI como Network Analyst e Business Analyst para gerar limites de polígonos que representam a distância máxima que uma pessoa pode percorrer ao longo de uma rede rodoviária a partir de um determinado ponto dentro de um período de tempo definido pelo usuário (digamos 5, 10 e / ou 15 minutos). Existem alternativas similares de código aberto ou baseadas na Web?

Vi este post, mas ele realmente não oferece opções alternativas: você pode criar um polígono de região de viagem com a API do Google Maps?

Fiquei particularmente curioso para saber se alguém pode (ou pode) usar o OpenStreetMap para fazer análises de tempo de condução?

Além disso, existe alguma implementação dos utilitários pgRouting que possa ser usada para gerar polígonos? http://pgrouting.postlbs.org/

O GRASS v.net.iso fornecerá um resultado como este:

Você pode não querer executar um algoritmo de casco convexo nesta saída. Imagine as estradas azuis: um casco convexo ao seu redor conteria muitas partes que não são alcançáveis ​​no tempo representado por "azul".

Em vez disso, convém procurar formas alfa (pergunta relacionada: o que são definição, algoritmos e soluções práticas para casco côncavo? )

Você pode criar isócronas de tempo de unidade usando pgRouting e QGIS ( conforme descrito aqui ). Eu não usei o OSM nesse caso, mas é claro que você pode construir sua rede roteável com base no OSM (consulte a ferramenta osm2pgrouting ).

( resolução total )

Para uma solução PostGIS pura, você pode usar a função de formato alfa pgRouting . Aqui está uma comparação das formas alfa conforme implementadas no pgRouting e a abordagem que apresentei na atualização anterior:

Áreas coloridas representam os resultados da função de forma alfa, linhas pretas são os resultados da abordagem de interpolação descrita anteriormente. As áreas de captação são menos detalhadas usando as formas alfa do pgRouting. Além disso, parece não haver maneira de variar o valor de alfa para criar representações mais detalhadas.

O GRASS 'v.net.iso pode ser usado para criar a' rede 'do tempo de acionamento, que você pode passar para um comando' casco convexo 'para obter um polígono. Talvez não seja o ideal, mas funcionaria!

Bem, potencialmente você poderia usar o v.net.iso do GRASS GIS. No entanto, ele não cria polígonos (AFAIK), mas divide as linhas por classes de custo da origem.

Quanto ao cálculo do tempo de acionamento do OSM, você pode importar os dados para o GRASS com v.in.osm e usar o v.net.iso para calcular as zonas de custo. Se você quisesse tempos de viagem e não tivesse limites de velocidade na estrada, poderia calcular o limite de velocidade com base em alguma função da classe de estrada.

Você pode usar o GraphHopper para essa tarefa, que também suporta modos diferentes, como caminhar ou andar de bicicleta, e usa o OpenStreetMap por padrão. Você precisará de alguma codificação Java que explora a rede rodoviária desde o ponto de partida, semelhante à maneira como os algoritmos Dijkstra funcionam, mas poderá obter algo como o seguinte, mesmo em tempo real (<0,5s):

O código coletará os pontos que você deve converter em um polígono com, por exemplo, as ferramentas JTS . A velocidade depende em grande parte deste último passo. Sem isso, seria possível abaixo de 0,5s, mesmo para grandes distâncias.

Outra maneira seria com o OpenTripPlanner .

o osrm-isochrone é uma pequena biblioteca node.js para gerar tempos de transmissão.

Convém verificar a API JavaScript Route360 ° aberta , que funciona com os mapas Leaflet e Google. Ele retorna polígonos de tempo de viagem para os seguintes modos de viagem: caminhada, bicicleta, carro, trânsito.

É gratuito e de código aberto, e a cobertura é muito boa. Você pode encontrar muitos tutoriais diferentes sobre como usá-lo no site.

Apesar de não responder diretamente à sua pergunta, você deve dar uma olhada na API Mapnificent .

Mapnificent fornece mapas dinâmicos de tempo de viagem de transporte público para muitas cidades nos EUA e em algumas partes do mundo. Você pode usar a API Mapnificent para aumentar seu aplicativo do Google Maps com sobreposições de tempo de viagem de transporte público.overlays.

Dê uma olhada em Londres aqui .

Também me deparei com a extensão de rede do gvSIG , mas a documentação de configuração que encontrei até agora é bastante ruim. Tenho grandes esperanças, só preciso descobrir os detalhes para calcular o custo.

Eu estava usando os dados do US Census TIGER para a rede de estradas e, na verdade, gerou alguns polígonos, mas não consegui fazer com que as unidades de custo fizessem realmente sentido. Se alguém implementou essa ferramenta com êxito, eu adoraria ouvir sobre ela.

Também encontrei o Quantum Navigator para QGIS, mas não encontrei nenhuma atualização recente.

O resultado com a abordagem do casco côncavo é ótimo e eu me inspirei bastante nas imagens acima. Mas notei que os resultados podem incluir algumas áreas inacessíveis por estrada (como o rio, por exemplo). Sem dúvida, isso não é um problema em termos de busca de recursos relevantes (centróides da população, número de residências) por distância ou tempo a partir da origem. Mas também funciona apenas em cada extremidade de cada link. Novamente, isso não é um problema na grande maioria dos casos (como as ligações rodoviárias mais longas têm controle de acesso - você normalmente não pode sair delas até chegar ao próximo cruzamento / interseção).

No entanto, por tudo isso, tenho trabalhado em uma abordagem diferente com base nos LINKS retornados pelo PgRouting / (ou um algoritmo "Dijkstra" bruto) ordenado por hora no nó de origem. É relativamente simples e categoriza os links por faixa de tempo e também divide os links que ultrapassam os limites de tempo. Em seguida, os links com a mesma categorização (por exemplo, 0-2 minutos, 2-4 minutos) são armazenados em buffer por 250 metros.

No WhereCampPDX deste ano, vários representantes do OpenStreetMap declararam que o uso de dados OSM para roteamento é bastante comum na Europa. No entanto, é mais raro nos EUA, porque o mapa geralmente não é bom o suficiente. Você pode verificar um serviço de roteamento baseado em OSM em:

http://openrouteservice.org/