Deproiezione Web Mercator

Tile, layer vettoriali ed esportazioni GIS spesso memorizzano posizioni come easting e northing in metri su una sfera di raggio 6378137 metri anziché come gradi di latitudine e longitudine. Questa capacità esegue quella conversione in modo deterministico da due campi numerici, rifiuta coordinate che cadono fuori dall’estensione quadrata del mondo proiettato usata dalle mappe slippy, e restituisce JSON strutturato con nomi di campo corti e lunghi per lon e lat.

Cosa calcola la deproiezione Web Mercator e quali ingressi sono validi

Invii i campi obbligatori x e y come numeri finiti misurati in metri in EPSG:3857, noto anche come Pseudo-Mercatore di Visualizzazione Popolare o il sistema proiettato di Bing e Google Maps. La longitudine si recupera come x diviso per il raggio della sfera per centottanta su pi; la latitudine come due volte l’arcotangente di e elevato a y su R, meno pi su due, poi convertita in gradi. L’estensione mondiale pubblicata è più o meno pi per R metri, circa venti milioni trecentosettantacinquemila e otto metri su ciascun asse. Le stringhe numeriche si analizzano quando coincidono con notazione decimale o scientifica ordinaria. Il motore interpreta x come easting e y come northing relativi all’origine equatore e meridiano di Greenwich a zero zero. Valori fuori da quel quadrato sono invalid_input perché giacciono oltre il ritaglio di latitudine vicino a più o meno ottantacinque virgola zero cinque gradi dove la mappa Mercatore diventa infinita. Alias mercator_x e easting per x, e mercator_y e northing per y, sono accettati così i payload orientati al GIS si mappano in modo pulito. Campi mancanti, valori non finiti e coordinate fuori estensione non producono mai un NaN silenzioso; falliscono con un messaggio chiaro invalid_input e non sono addebitati. Entrate identiche producono sempre lo stesso JSON perché il percorso è aritmetica pura senza rete, senza seme casuale e senza orologio di parete.

Lettura di lon, lat, etichette CRS e costanti di estensione

Usi lon e lat costruendo coordinate GeoJSON Point in ordine longitudine prima; usi latitude e longitude legando etichette UI che preferiscono i nomi lunghi. L’origine zero zero si deproietta all’isola nulla del Golfo di Guinea a zero gradi nord e zero est. x positivo si sposta a est; y positivo a nord fino al ritaglio polare. La proiezione diretta da lat/lon a metri resta intenzionalmente fuori ambito affinché questa pagina resti incentrata sull’intento di ricerca deproiezione. Il campo crs_in è sempre EPSG:3857 e crs_out sempre EPSG:4326 affinché il codice a valle affermi la trasformazione senza annusare forme. radius_m riporta sei milioni trecentosettantottomila centotrentasette, il semiasse maggiore WGS-84 che EPSG:3857 usa come raggio di sfera, e max_extent_m riporta pi per quel raggio così i client possono validare lato client prima di chiamare l’API. L’etichetta method è sempre web_mercator_inverse. Abbini questo endpoint a strumenti di tile o quadkey quando ha già indici di pixel o tile e serve ancora gradi geografici per un marker.

Uso API, prezzi, flussi GIS e limiti pratici

Invii un corpo JSON con x e y numerici in metri Web Mercator. Usi l’API prepagata quando un backend cartografico, un job ETL o una cache offline mobile necessita di un contratto stabile sotto saldo KIT a $0.002 per elemento riuscito; i fallimenti di validazione non consumano mai il saldo dopo il rifiuto del motore. Gli autori di SDK possono mappare i campi lon e lat direttamente in bersagli di fotocamera mappa, mentre le pipeline analitiche possono archiviare radius_m e max_extent_m accanto al risultato per piste di audit.