Domande frequenti sull'API Isochrone

Perché posso richiedere un isocrono a piedi o in bicicletta per un massimo di 2 ore, ma in auto il limite è di 1 ora?

Questa limitazione si basa sulla complessità computazionale dei calcoli. Un veicolo percorre una distanza significativamente maggiore rispetto a un pedone o a un ciclista nella stessa durata, il che significa che la rete stradale sottostante da analizzare si espande in modo esponenziale. La guida è limitata a un massimo di 1 ora (3600 secondi) per garantire che l'API possa restituire una risposta in una finestra sincrona rapida e in tempo reale, mentre la camminata e la bicicletta sono supportate per un massimo di 2 ore (7200 secondi).

Come faccio a calcolare un isocrono "casa-lavoro" in entrata (viaggio verso una destinazione) rispetto a un isocrono in uscita (viaggio da un'origine)?

I calcoli in entrata e in uscita sono supportati nell'API v1 utilizzando il parametro travel_direction:

• FROM (in uscita): calcola l'area raggiungibile from punto di origine entro il limite di tempo specificato. È adatto a casi d'uso come zone di consegna o copertura del servizio.

• TO (in entrata): calcola l'area da cui puoi viaggiare to il punto di origine entro il limite di tempo specificato. È adatto ad applicazioni come le funzionalità casa-lavoro o per determinare le zone di influenza intorno a una sede centrale o a un hub di transito.

A volte il poligono restituito sembra a blocchi o ha bordi frastagliati, soprattutto per durate più lunghe. Perché il livello di dettaglio cambia?

L'API Isochrones regola dinamicamente la risoluzione della griglia di calcolo spaziale in base a travel_duration e travel_mode richieste:

• Durate più brevi: utilizza una griglia ad alta risoluzione e molto raffinata perché l'area totale è piccola, il che comporta un confine dettagliato.
• Durate più lunghe: passa a una griglia più grossolana a risoluzione inferiore per coprire in modo efficiente la vasta area geografica senza causare una latenza elevata.

Se hai bisogno di un livello di dettaglio specifico e coerente indipendentemente dalla durata, puoi impostare il parametro facoltativo polygon_fidelity su HIGH, MEDIUM o LOW.

Perché a volte la richiesta di un isocrono per una coordinata all'interno di un parco, un lago o un grande complesso industriale restituisce un errore "Non trovato"?

L'API Isochrones calcola i tempi di percorrenza utilizzando strade e sentieri. Se le coordinate di origine richieste non si trovano su una strada riconosciuta, l'API deve "agganciare" il punto al segmento compatibile più vicino prima di iniziare il calcolo.

Ogni modalità di viaggio ha una soglia di distanza di aggancio massima specifica:

• DRIVE: 200 metri (ignora i percorsi solo pedonali).
• BICYCLE: 180 metri.
• WALK: 150 metri.

Se la coordinata di origine si trova a una distanza maggiore da un segmento stradale valido e compatibile con la modalità rispetto a queste soglie, l'aggancio non riesce e l'API restituisce un errore NOT_FOUND. Per risolvere il problema, assicurati che le coordinate siano posizionate vicino a una strada o a un sentiero pubblico.

Perché ricevo un errore quando richiedo il routing con informazioni sul traffico per la camminata o la bicicletta?

Le condizioni del traffico in tempo reale (TRAFFIC_AWARE) sono supportate esclusivamente per la modalità di viaggio DRIVE. Se tenti di richiedere un isocrono per WALK o BICYCLE con routingPreference impostato su TRAFFIC_AWARE, l'API restituirà un errore 400 INVALID_ARGUMENT.

Quando eseguo il rendering della risposta GeoJSON sulla mappa, la forma viene visualizzata nel posto sbagliato, è distorta o non viene eseguito il rendering. Qual è la causa?

Quasi sempre la causa è una mancata corrispondenza dell'ordine delle coordinate.

Seguendo lo standard GeoJSON (RFC 7946), l'API Isochrones restituisce le coordinate nell'ordine [longitude, latitude]. Tuttavia, molti SDK di mappatura e oggetti geometrici personalizzati prevedono coordinate nell'ordine [latitude, longitude].

Se il rendering della mappa non è corretto, controlla in che modo l'SDK della mappa gestisce GeoJSON:

• API Maps JavaScript: se utilizzi il livello dati (map.data.addGeoJson()), questo ordine viene gestito in modo nativo e non è richiesta alcuna azione.
• Oggetti personalizzati o altri SDK: se analizzi manualmente la risposta in oggetti LatLng, devi scorrere le coordinate nel payload GeoJSON e trasporre i valori [lng, lat] in coppie [lat, lng] prima del rendering.

Perché all'interno del poligono isocrono ci sono "buchi" vuoti e posso ottenere una forma solida?

I buchi rappresentano le aree senza strade raggiungibili entro il limite di tempo. È comune nelle regioni con grandi foreste, corpi idrici, aeroporti o proprietà private in cui i veicoli o i pedoni non possono viaggiare.

L'API v1 esterna non espone un parametro per rimuovere automaticamente i buchi. Se la tua applicazione richiede un confine solido, ad esempio per eseguire controlli di contenimento punto-in-poligono, puoi:

• Imposta il parametro polygon_fidelity su MEDIUM o LOW per incoraggiare l'algoritmo a generalizzare e unire questi spazi interni.
• Utilizza una libreria GIS lato client (ad esempio Turf.js) per analizzare il file GeoJSON ed estrarre solo il primo anello di coordinate (il guscio esterno), scartando gli anelli interni successivi (i buchi).

Devo attivare l'opzione enable_smoothing per l'analisi spaziale di backend?

No. Il parametro enable_smoothing è progettato esclusivamente per l'estetica visiva. Arrotonda gli angoli acuti della griglia di calcolo sottostante per rendere la forma organica su una mappa.

Lo smoothing non è consigliato per un'analisi spaziale precisa perché altera i vertici e sposta leggermente i confini. Per i calcoli di backend, le query di database o i test punto-in-poligono, mantieni enable_smoothing impostato su false per assicurarti di utilizzare il confine calcolato matematicamente preciso.