8

Ho un codice che sto trasferendo da API v2 a v3. Nel vecchio codice avevamo un campo di precisione che tornava nell'xml (non sicuro del nome, ma rappresentava un livello di confidenza di sorta). Nella nuova API, non vedo alcun campo del genere.L'API di geocoding di Google Maps v3 ha un campo che rappresenta l'accuratezza?

Se inserisco "Oregon, USA" nel campo di ricerca ottengo 5 corrispondenze. I primi 2 sono "Oregon, USA" e "Oregon, OH, USA". Entrambi hanno "partial_match" = false. Questo non sembra giusto, uno sembra parziale e uno no. Inoltre, stanno entrambi tornando con lo stesso "location_type" (APPROXIMATE). In effetti, tutte le partite vengono visualizzate come non parziali e hanno lo stesso tipo di posizione.

La mia domanda è, qualcuna delle caselle nel set di risultati trasmette una certa confidenza nella precisione del risultato? Nel mio esempio sembra davvero che un risultato sia molto più accurato di qualsiasi altro, tanto che la stringa di input corrisponde esattamente al campo Indirizzo rapido restituito.

risposta

11

Due settimane, nessuna risposta, ecco la mia soluzione.

L'API restituirà ROOFTOP, GEOMETRIC_CENTER, RANGE_INTERPOLATED o APPROXIMATE.

Il tetto è essenzialmente "morto" - l'API ha risolto l'indirizzo di un edificio. Oltre a questo, ottieni diversi gradi di "chiusura". La mia soluzione era usare il riquadro di delimitazione che è stato restituito per determinare quanto fosse vicino. Quindi se chiedi una strada (Avenue of the Americas, NY, NY) otterrai un'enorme finestra di delimitazione. Chiedi un indirizzo su quella strada che l'API pensa sia un indirizzo reale ma non è un tetto, otterrai un riquadro di delimitazione molto piccolo. Ho utilizzato l'area del riquadro di delimitazione per determinare l'accuratezza del risultato. La mia interruzione accurata/non accurata era a 0.9E-6, ma penso che dovresti armeggiare con esso per assicurarti che tu sia a tuo agio con quel numero.

+0

Molto intelligente. Non ci avrei pensato. Ho fatto alcuni test con i nostri indirizzi "non sul tetto" e ho trovato una vasta gamma. Abbiamo quattro guasti, sul tetto, sulla strada (ad es. Blocco o ZIP + 4), ZIP + 2 e ZIP. Per ognuno dei tipi di posizione non sul tetto di Google ho creato la logica per analizzare ulteriormente l'accuratezza perché a volte APPROXIMATE si presenta più simile a ZIP + 4 (che nelle aree urbane è usuale piuttosto vicino al tetto) e RANGE_INTERPOLATED è più simile a ZIP, ovvero enorme. –

+0

Un'altra cosa che ho notato è che a volte Google dà a ROOFTOP solo l'indirizzo stradale, ma aggiungendo suite/unità/apt/qualsiasi cosa ... è passato a APPROXIMATE anche se il lat/lon è rimasto lo stesso. È qui che la tua idea è stata utile. Altre volte solo l'indirizzo stradale APPROXIMATE mentre si aggiunge l'unità secondaria si passa a ROOFTOP. Ho visto più del primo, cioè più dati, meno "confidenza". Sto pensando di costruire in logica per provare senza sub-unità prima e se non ROOFTOP provare con sub-unità. Se ancora non ROOFTOP, confronta i riquadri di delimitazione e usa quello più piccolo. –

+0

@AndrewS grazie, mi sentivo come se fossi l'unico in questo particolare angolo di internet - non ho mai avuto risposta su google groups come ricordo ... – jcollum

2

Ho trovato questo codice V2 legacy nell'aggiornamento utili dipende da un punteggio da 0 a 9
// Hack per convertire location_type (stringa) per 0-9 punteggio Geocode come 0-9 punteggio Geocode non esiste in v3 API

function get_numeric_score(results) { 
switch(results[0].geometry.location_type){ 
     case "ROOFTOP": 
      return 9; 
     break; 

     case "RANGE_INTERPOLATED": 
      return 7; 
     break; 

     case "GEOMETRIC_CENTER": 
      return = 6; 
     break; 

     case "APPROXIMATE": 
      return 4; 
     break; 

     default: 
      return 0; 

    } 
}