Domande frequenti sull'API Isochrone

Perché posso richiedere un isocrono a piedi o in bicicletta fino a 2 ore, ma la guida è limitata a 1 ora?

Questa limitazione si basa sulla complessità computazionale dei calcoli. Un veicolo percorre una distanza molto maggiore di un pedone o di un ciclista nello stesso periodo di tempo, 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 fino a 2 ore (7200 secondi).

Come faccio a calcolare un'isocrona "casa-lavoro" in entrata (viaggio verso una destinazione) rispetto a un'isocrona 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 il punto di origine entro il limite di tempo specificato. È adatto a casi d'uso come zone di consegna o copertura del servizio.

• TO (Inbound): calcola l'area da cui puoi viaggiare to il punto di partenza entro il limite di tempo specificato. Questa opzione è adatta ad applicazioni come le funzionalità di spostamento casa-lavoro o per determinare le zone di utenza intorno a un ufficio centrale o a un hub di transito.

A volte il poligono restituito appare squadrato o presenta bordi frastagliati, soprattutto per durate più lunghe. Perché il livello di dettaglio cambia?

L'API Isochrone regola dinamicamente la risoluzione della griglia di calcolo spaziale in base al travel_duration e al travel_mode richiesti:

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

Puoi impostare il valore facoltativo polygon_fidelity su HIGH, MEDIUM o LOW se richiedi un livello di dettaglio specifico e coerente, indipendentemente dalla durata.

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

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

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

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

Se le coordinate di origine si trovano più lontano da un segmento stradale valido e compatibile con la modalità rispetto a queste soglie, l'allineamento non riesce e l'API restituisce un errore NOT_FOUND. Per risolvere il problema, assicurati che le coordinate si trovino vicino a una strada o un sentiero pubblico.

Quando visualizzo la risposta GeoJSON sulla mia mappa, la forma viene visualizzata nel posto sbagliato, è distorta o non viene visualizzata. Qual è la causa?

Questo problema è quasi sempre causato da una mancata corrispondenza dell'ordine delle coordinate.

In conformità allo standard GeoJSON (RFC 7946), l'API Isochrones restituisce le coordinate nell'ordine [longitude, latitude]. Tuttavia, molti SDK di mapping, tra cui l'API Maps JavaScript di Google e vari componenti di mappe mobile, prevedono coordinate o oggetti LatLng nell'ordine [latitude, longitude].

Se il rendering della mappa non è corretto, devi scorrere le coordinate nel payload GeoJSON e trasporre i valori prima di passarli all'SDK Maps.

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

I buchi rappresentano le aree senza strade raggiungibili entro il limite di tempo. Questo è comune in regioni con grandi foreste, specchi d'acqua, aeroporti o proprietà private in cui non possono transitare veicoli o pedoni.

L'API v1 esterna non espone un parametro per rimuovere automaticamente i fori. Se la tua applicazione richiede un confine solido, ad esempio per eseguire controlli di contenimento punto nel 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 GeoJSON ed estrarre solo il primo anello di coordinate (il guscio esterno), scartando gli anelli interni successivi (i fori).

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 più organica su una mappa.

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