Perguntas frequentes sobre a API Isochrones

Como faço para 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 v1 da API usando o parâmetro travel_direction:

• FROM (saída): calcula a área acessível from um 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 viajar to o 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 na travel_duration e no 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).
• TWO_WHEELER: 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 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 caminho público.

Por que recebo um erro ao solicitar o roteamento com reconhecimento de trânsito para caminhada ou ciclismo?

As condições de trânsito em tempo real (TRAFFIC_AWARE) são compatíveis com os modos de viagem DRIVE e TWO_WHEELER. Se você tentar solicitar uma isócrona 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 mapas 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 nativamente 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 fazer um loop nas coordenadas no payload GeoJSON e transpor os valores [lng, lat] em pares [lat, lng] antes da renderização.

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 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 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 acentuados 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á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.