Perguntas frequentes sobre a API Isochrones

Por que posso solicitar um isócrono de caminhada ou ciclismo por até 2 horas, mas o de carro é limitado 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 viária subjacente que precisa ser analisada aumenta exponencialmente. O tempo de carro é limitado a uma hora (3.600 segundos) para garantir que a API possa retornar uma resposta em uma janela síncrona rápida e em tempo real. Já o tempo a pé e de bicicleta é de até duas horas (7.200 segundos).

Como calcular uma isócrona de "trajeto para o trabalho" de entrada (viagem para um destino) em vez de uma isócrona de saída (viagem de uma origem)?

Os cálculos de entrada e saída são compatíveis com a API v1 usando o parâmetro travel_direction:

• FROM (saída): calcula a área alcançável from o 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 é possível viajar to do ponto de origem dentro do limite de tempo especificado. Isso é adequado para aplicativos como recursos de deslocamento para o trabalho ou determinação de zonas de influência em torno de um escritório central ou hub de trânsito.

Às vezes, o polígono retornado parece blocoso ou tem bordas irregulares, principalmente 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 no travel_mode solicitados:

• Durações mais curtas: use uma grade altamente refinada e 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 grosseira e de resolução mais baixa para cobrir a vasta área geográfica de maneira eficiente sem causar latência grave.

É possível definir o polygon_fidelity opcional como HIGH, MEDIUM ou LOW se você precisar de um nível de detalhes específico e consistente, independente da duração.

Por que solicitar 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 vias 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 via 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 via válido e compatível com o modo do que esses limites, o ajuste vai falhar, e a API vai retornar um erro NOT_FOUND. Para resolver isso, verifique se as coordenadas estão posicionadas perto de uma rua ou via pública.

Por que recebo um erro ao solicitar rotas com informações de trânsito para caminhada ou ciclismo?

As condições de trânsito em tempo real (TRAFFIC_AWARE) são compatíveis exclusivamente com o modo de transporte DRIVE. Se você tentar solicitar um isócrono para WALK ou BICYCLE com routingPreference definido como TRAFFIC_AWARE, a API vai retornar um erro 400 INVALID_ARGUMENT.

Quando renderizo a resposta GeoJSON no meu mapa, a forma aparece no lugar errado, fica distorcida ou não é renderizada. O que está causando isso?

Isso quase sempre é causado por uma incompatibilidade na ordem das coordenadas.

Seguindo o padrão GeoJSON (RFC 7946), a API Isochrones retorna coordenadas na ordem de [longitude, latitude]. No entanto, muitos SDKs de mapeamento e objetos de geometria personalizados esperam coordenadas na ordem de [latitude, longitude].

Se a renderização do mapa estiver incorreta, verifique como o SDK do Maps processa o GeoJSON:

• API Google Maps JavaScript:se você estiver usando a camada de dados (map.data.addGeoJson()), essa ordem será processada de forma nativa, e nenhuma ação será necessária.
• Objetos personalizados ou outros SDKs:se você estiver analisando manualmente a resposta em objetos LatLng, faça um loop nas coordenadas no payload GeoJSON e transponha os valores [lng, lat] em pares [lat, lng] antes da renderização.

Por que há "buracos" ocos dentro do meu polígono de isócrona? Posso ter um formato sólido?

Os buracos representam áreas sem vias 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 circular.

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 em polígono, você pode:

• Defina o parâmetro polygon_fidelity como MEDIUM ou LOW para 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 invólucro externo), descartando os anéis internos subsequentes (os furos).

Devo ativar a opção "enable_smoothing" para a análise espacial de back-end?

Não. O parâmetro enable_smoothing foi criado apenas para estética visual. Ele arredonda os cantos acentuados da grade de cálculo subjacente para que a forma pareça orgânica em um mapa.

Não é recomendável usar o suavização para análises espaciais precisas porque ela altera os vértices e muda ligeiramente os limites. Para cálculos de back-end, consultas de banco de dados ou testes de ponto em polígono, mantenha enable_smoothing definido como false para garantir que você esteja usando o limite calculado matematicamente preciso.