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 raggiungibilefrompunto 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 viaggiaretoil 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 un ufficio centrale o a un hub di transito.
A volte il poligono restituito appare a blocchi o presenta 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 si traduce in 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'isocrona 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 tratto compatibile più vicino prima di iniziare il calcolo.
Ogni modalità di viaggio ha una soglia di distanza di allineamento massima specifica:
DRIVE: 200 metri (ignora i percorsi solo pedonali).TWO_WHEELER: 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'allineamento 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 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 tenti di richiedere un'isocrona 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 mappa, la forma viene visualizzata nel posto sbagliato, è distorta o non viene eseguito il rendering. Qual è la causa di questo problema?
Questo problema è quasi sempre causato da 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 di eseguire il rendering.
Perché all'interno del poligono dell'isocrona sono presenti "buchi" vuoti e posso ottenere una forma solida?
I buchi rappresentano le aree senza strade raggiungibili entro il limite di tempo. Questo è comune nelle regioni con grandi foreste, corpi idrici, aeroporti o proprietà private in cui veicoli o 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_fidelitysuMEDIUMoLOWper 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 (la shell esterna), 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.