Por que posso solicitar uma isócrona de caminhada ou ciclismo por até 2 horas, mas a direção é limitada a 1 hora?
Essa limitação é baseada na complexidade computacional dos cálculos. Um veículo viaja muito mais longe do que um pedestre ou ciclista durante o mesmo período, o que significa que a rede rodoviária subjacente que precisa ser analisada se expande exponencialmente. A direção é restrita a um máximo de 1 hora (3.600 segundos) para garantir que a API possa retornar uma resposta em uma janela síncrona rápida e em tempo real, enquanto a caminhada e o ciclismo são aceitos por até 2 horas (7.200 segundos).
Como faço para calcular uma isócrona de "deslocamento para o trabalho" de entrada (viajar para um destino) em comparação com uma isócrona de saída (viajar de uma origem)?
Os cálculos de entrada e saída são aceitos na API v1 usando o parâmetro travel_direction:
FROM(saída): calcula a área acessívelfromo ponto de origem dentro do limite de tempo especificado. Isso é adequado para casos de uso, como zonas de entrega ou cobertura de serviço.TO(entrada): calcula a área de onde você pode viajartoo ponto de origem dentro do limite de tempo especificado. Isso é adequado para aplicativos como recursos de deslocamento para o trabalho ou para determinar zonas de captação em torno de um escritório central ou centro de trânsito.
Às vezes, o polígono retornado parece irregular ou tem bordas irregulares, especialmente para durações mais longas. Por que o nível de detalhes muda?
A API Isochrones ajusta dinamicamente a resolução da grade de cálculo espacial com base no travel_duration e travel_mode solicitados:
- Durações mais curtas: use uma grade refinada de alta resolução porque a área total é pequena, resultando em um limite detalhado.
- Durações mais longas: faça a transição para uma grade mais grossa e de resolução mais baixa para cobrir a vasta área geográfica com eficiência sem causar latência grave.
Você pode definir o polygon_fidelity opcional como HIGH, MEDIUM ou LOW se precisar de um nível de detalhes específico e consistente, independentemente da duração.
Por que a solicitação de uma isócrona para uma coordenada dentro de um parque, lago ou grande complexo industrial às vezes retorna um erro "Não encontrado"?
A API Isochrones calcula os tempos de viagem usando estradas e caminhos. A API precisa "ajustar" o ponto ao segmento compatível mais próximo antes de iniciar o cálculo se as coordenadas de origem solicitadas não estiverem localizadas em uma estrada reconhecida.
Cada modo de viagem tem um limite máximo de distância de ajuste específico:
DRIVE: 200 metros (ignora caminhos exclusivos para pedestres).BICYCLE: 180 metros.WALK: 150 metros.
Se a coordenada de origem estiver mais distante de um segmento de estrada válido e compatível com o modo do que esses limites, o ajuste falhará e a API retornará um erro NOT_FOUND. Para resolver isso, verifique se as coordenadas estão posicionadas perto de uma rua ou caminho público.
Quando renderizo a resposta GeoJSON no meu mapa, a forma é exibida no lugar errado, é distorcida ou não é renderizada. O que está causando isso?
Isso quase sempre é causado por uma incompatibilidade de ordem de coordenadas.
Seguindo o padrão GeoJSON (RFC 7946), a API Isochrones retorna coordenadas na ordem de [longitude, latitude]. No entanto, muitos SDKs de mapas, incluindo a API Maps JavaScript e vários componentes de mapas para dispositivos móveis, esperam coordenadas ou objetos LatLng na ordem de [latitude, longitude].
Se a renderização do mapa estiver incorreta, você precisará fazer um loop nas coordenadas no payload GeoJSON e transpor os valores antes de transmiti-los ao SDK do mapa.
Por que há "buracos" ocos dentro do meu polígono isócrono e posso ter uma forma sólida?
Os buracos representam áreas sem estradas acessíveis dentro do limite de tempo. Isso é comum em regiões com grandes florestas, corpos d'água, aeroportos ou propriedades particulares onde veículos ou pedestres não podem viajar.
A API v1 externa não expõe um parâmetro para remover buracos automaticamente. Se o aplicativo exigir um limite sólido, por exemplo, para realizar verificações de contenção de ponto no polígono, você pode:
- Defina o parâmetro
polygon_fidelitycomoMEDIUMouLOWpara incentivar o algoritmo a generalizar e mesclar essas lacunas internas. - Use uma biblioteca GIS do lado do cliente (como Turf.js) para analisar o GeoJSON e extrair apenas o primeiro anel de coordenadas (o shell externo), descartando os anéis internos subsequentes (os buracos).
Devo ativar a opção enable_smoothing para análise espacial de back-end?
Não. O parâmetro enable_smoothing foi projetado exclusivamente para estética visual.
Ele arredonda os cantos afiados da grade de cálculo subjacente para fazer com que a forma pareça orgânica em um mapa.
O suavização não é recomendada para análise espacial precisa porque altera os vértices e desloca ligeiramente os limites. Para cálculos de back-end, consultas de banco de dados ou testes de ponto no polígono, mantenha enable_smoothing definido como false para garantir que você esteja usando o limite calculado matematicamente preciso.