Perguntas frequentes sobre a API Isochrones

Como calcular uma isócrona de "deslocamento para o trabalho" de entrada (viajando para um destino) em comparação com uma isócrona de saída (viajando de uma origem)?

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

• FROM (saída): calcula a área acessível from do ponto de origem dentro do limite de tempo especificado. Isso é adequado para casos de uso como áreas de entrega ou cobertura de serviço.

• TO (entrada): calcula a área de onde é possível viajar to o ponto de origem dentro do limite de tempo especificado. Isso é adequado para aplicativos como recursos de deslocamento diário para o trabalho ou para determinar zonas de influência em torno de um escritório central ou de um hub de transporte público.

Observação: os polígonos FROM e TO para a mesma origem e duração podem ser assimétricos em todos os modos. Para DRIVE, TWO_WHEELER e BICYCLE, as causas incluem ruas de mão única e restrições de conversão. Para DRIVE e TWO_WHEELER, as vias de acesso, as saídas de rodovias e o congestionamento direcional também contribuem. Para WALK e BICYCLE, a inclinação também é importante porque a subida é mais lenta do que a descida.

Qual é a diferença entre os quatro modos de viagem (DRIVE, TWO_WHEELER, BICYCLE e WALK)?

Cada modo usa as próprias regras de acesso à rede rodoviária, custos de conversão e modelo de velocidade:

• DRIVE: percorre vias transitáveis usando velocidades de fluxo livre ou velocidades de trânsito em tempo real (TRAFFIC_AWARE), até 3.600 segundos (60 minutos).
• TWO_WHEELER: percorre vias acessíveis a veículos motorizados de duas rodas com velocidades modeladas mais baixas do que DRIVE em vias de alta velocidade e rotas TRAFFIC_AWARE opcionais, até 3.600 segundos (60 minutos). Como resultado, um isócrono de TWO_WHEELER é maior que BICYCLE, mas menor que DRIVE em rodovias de alta velocidade.
• BICYCLE: percorre ruas, ciclovias e caminhos acessíveis para bicicletas com velocidades ajustadas para o tipo de via e a inclinação (exceto rodovias e vias expressas), até 7.200 segundos (120 minutos).
• WALK: atravessa calçadas, trilhas e ruas de pedestres com velocidade de caminhada ajustada para inclinação (ignorando restrições de veículos de mão única), até 7.200 segundos (120 minutos).

A API Isochrones inclui balsas ou travessias de água?

Não. A API Isochrones atravessa apenas conexões de estradas, pontes, túneis e caminhos. As rotas de balsa e as travessias de transporte aquático são excluídas em todos os modos de viagem. Ilhas ou penínsulas conectadas apenas por balsa não serão incluídas em uma isócrona gerada a partir do continente.

Às vezes, o polígono retornado parece em blocos ou tem bordas irregulares e escalonadas, 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 nos valores de travel_duration e 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: mude para uma grade mais ampla e de menor resolução para cobrir a vasta área geográfica de forma eficiente sem causar latência severa.

É possível definir o polygon_fidelity opcional como HIGH, MEDIUM ou LOW se você precisar de um nível de detalhe específico e consistente, independentemente 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 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 em uma via reconhecida.

Cada modo de transporte tem uma distância máxima de ajuste de cerca de 200 metros ou menos. WALK e BICYCLE usam distâncias mais curtas do que DRIVE e TWO_WHEELER, e DRIVE e TWO_WHEELER ignoram caminhos exclusivos para pedestres.

Se a coordenada de origem estiver mais distante de um segmento de via válido e compatível com o modo do que essa distância, 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 que consideram o trânsito para caminhadas ou ciclismo?

As condições de trânsito em tempo real (TRAFFIC_AWARE) estão disponíveis para os meios de transporte DRIVE e TWO_WHEELER. 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 é exibida 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 mapa processa o GeoJSON:

• API 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, será necessário percorrer as coordenadas no payload GeoJSON e transpor os valores [lng, lat] em pares [lat, lng] antes da renderização.

Por que há "buracos" vazios dentro do meu polígono de isócrona? Posso ter uma forma sólida?

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 em que veículos ou pedestres não podem circular.

A API externa v1 não expõe um parâmetro para remover furos automaticamente. Se o aplicativo exigir um limite sólido, por exemplo, para realizar verificações de contenção de ponto em polígono, você poderá:

• 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 (a casca externa), descartando os anéis internos subsequentes (os furos).

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 que a forma pareça orgânica em um mapa.

A suavização não é recomendada para análises espaciais precisas 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 em polígono, mantenha enable_smoothing definido como false para garantir que você esteja usando o limite calculado matematicamente preciso.