Come faccio a calcolare un'isocrona in entrata per il "tragitto giornaliero" (viaggio verso una destinazione) rispetto a un'isocrona in uscita (viaggio da un'origine)?
I calcoli sia in entrata che in uscita sono supportati nell'API v1 utilizzando il parametro travelDirection (travel_direction):
FROM(Partenza): calcola l'area raggiungibilefromdal punto di partenza entro il limite di tempo specificato. Questo è adatto per casi d'uso come zone di consegna o copertura del servizio.TO(In entrata): calcola l'area da cui puoi viaggiaretoverso il punto di partenza entro il limite di tempo specificato. Questo è adatto per applicazioni come le funzionalità di tragitto casa-lavoro o la determinazione delle zone di attrazione intorno a un ufficio centrale o a uno snodo di trasporto pubblico.
Quali sono le differenze tra le quattro modalità di viaggio (DRIVE, TWO_WHEELER, BICYCLE e WALK)?
Ogni modalità utilizza le proprie regole di accesso alla rete stradale, i costi di svolta e il modello di velocità:
DRIVE: attraversa strade percorribili utilizzando le velocità pubblicate o a flusso libero o le velocità del traffico in tempo reale (TRAFFIC_AWARE), fino a 3600 secondi (60 minuti).TWO_WHEELER: attraversa strade accessibili ai veicoli a due ruote a motore con velocità modellate inferiori rispetto aDRIVEsu strade ad alta velocità e routingTRAFFIC_AWAREfacoltativo, fino a 3600 secondi (60 minuti). Di conseguenza, un isocrono diTWO_WHEELERè più grande diBICYCLE, ma più piccolo diDRIVElungo le autostrade ad alta velocità.BICYCLE: attraversa strade, corsie ciclabili e percorsi accessibili alle biciclette con velocità regolate in base al tipo di strada e alla pendenza (escluse autostrade e superstrade), fino a 7200 secondi (120 minuti).WALK: attraversa marciapiedi, sentieri e strade pedonali con velocità di camminata regolata in base alla pendenza (ignorando le limitazioni per i veicoli a senso unico), fino a 7200 secondi (120 minuti).
L'API Isochrones include traghetti o attraversamenti d'acqua?
No. L'API Isochrones attraversa solo i collegamenti di strade, ponti, tunnel e percorsi. Le rotte dei traghetti e i tragitti in acqua sono esclusi da tutte le modalità di viaggio. Le isole o le penisole collegate solo tramite traghetto non verranno incluse in un isocrono generato dalla terraferma.
A volte il poligono restituito sembra squadrato o ha bordi frastagliati e a gradini, 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 ai valori travel_duration e travel_mode richiesti:
- Durate più brevi: utilizza una griglia ad alta risoluzione e molto precisa perché l'area totale è ridotta, il che si traduce in un confine dettagliato.
- Durate più lunghe: passa a una griglia più grossolana e a risoluzione inferiore per coprire l'ampia area geografica in modo efficiente senza causare una latenza elevata.
Puoi impostare il valore facoltativo polygon_fidelity su HIGH, MEDIUM o LOW se hai bisogno di un livello di dettaglio specifico e coerente, indipendentemente dalla durata.
Perché la richiesta di un isocrono per una coordinata all'interno di un parco, di un lago o di un grande complesso industriale a volte restituisce un errore "Non trovato"?
L'API Isochrones calcola i tempi di percorrenza utilizzando strade e percorsi. 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 distanza massima di aggancio di circa 200 metri o meno.
WALK e BICYCLE utilizzano distanze più brevi rispetto a DRIVE e TWO_WHEELER, mentre DRIVE e TWO_WHEELER ignorano i percorsi esclusivamente pedonali.
Se la coordinata di origine si trova più lontana da un segmento di strada valido e compatibile con la modalità rispetto a questa distanza, l'aggancio non va a buon fine e l'API restituisce un errore NOT_FOUND. Per risolvere il problema, assicurati che le coordinate siano posizionate vicino a una strada o un percorso pubblico.
Perché ricevo un errore quando richiedo il calcolo del percorso sensibile al traffico per camminare o andare in bicicletta?
Le condizioni del traffico in tempo reale (TRAFFIC_AWARE) sono supportate per le modalità di viaggio DRIVE e TWO_WHEELER. Se provi a richiedere un isocrono per WALK o BICYCLE con routingPreference impostato su TRAFFIC_AWARE, l'API restituisce un errore 400 INVALID_ARGUMENT.
Quando eseguo il rendering della risposta GeoJSON sulla mia mappa, la forma viene visualizzata nel punto 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 mappatura e oggetti geometrici personalizzati prevedono le coordinate nell'ordine [latitude, longitude].
Se il rendering della mappa non è corretto, controlla in che modo l'SDK Maps 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 eseguire un ciclo attraverso le coordinate nel payload GeoJSON e trasporre i valori[lng, lat]in coppie[lat, lng]prima del rendering.
Perché ci sono "buchi" vuoti all'interno del mio poligono isocrono e posso ottenere una forma solida?
I vuoti rappresentano aree senza strade raggiungibili entro il limite di tempo. Questo è comune nelle regioni con grandi foreste, specchi d'acqua, aeroporti o proprietà private in cui veicoli o pedoni non possono transitare.
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-in-poligono, puoi:
- Imposta il parametro
polygon_fidelitysuMEDIUMoLOWper incoraggiare l'algoritmo a generalizzare e unire questi gap interni. - Utilizza una libreria GIS lato client (come Turf.js) per analizzare il GeoJSON ed estrarre solo il primo anello di coordinate (il guscio esterno), ignorando eventuali anelli interni successivi (i fori).
Devo attivare l'opzione enable_smoothing per l'analisi spaziale del backend?
No. Il parametro enable_smoothing è progettato esclusivamente per l'estetica visiva.
Arrotonda gli angoli acuti della griglia di calcolo sottostante per dare alla forma un aspetto naturale su una mappa.
La smussatura non è consigliata 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 point-in-polygon, mantieni enable_smoothing impostato su false per assicurarti di utilizzare il confine calcolato matematicamente preciso.