8

Tengo un código que transfiero de API v2 a v3. En el código anterior, teníamos un campo de precisión que regresaba en el xml (no estoy seguro del nombre, pero sí representaba un tipo de nivel de confianza). En la nueva API, no veo ningún campo como ese.¿La API de geocodificación de Google Maps v3 tiene un campo que representa la precisión?

Si pongo "Oregon, USA" en el campo de búsqueda obtengo 5 coincidencias. Los primeros 2 son "Oregon, USA" y "Oregon, OH, USA". Ambos tienen "partial_match" = false. Esto no parece correcto, uno parece parcial y el otro no. Además, ambos vuelven con el mismo "tipo de ubicación" (APROXIMADO). De hecho, todas las coincidencias se muestran como no parciales y tienen el mismo tipo de ubicación.

Mi pregunta es, ¿alguno de los campos en el conjunto de resultados transmiten algún tipo de confianza en la precisión del resultado? En mi ejemplo, realmente parece que un resultado es mucho más preciso que cualquier otro, tanto así que la cadena de entrada coincide exactamente con el campo QuickAddress que se devuelve.

Respuesta

11

Dos semanas, sin respuestas, así que aquí está mi solución.

La API devolverá ROOFTOP, GEOMETRIC_CENTER, RANGE_INTERPOLATED o APPROXIMATE.

Rooftop es esencialmente "inactivo": la API resolvió la dirección de un edificio. Aparte de eso, obtienes diversos grados de "cerca". Mi solución fue utilizar el cuadro delimitador que se devolvió para determinar qué tan cerca estaba. Entonces, si solicita una calle (Avenue of the Americas, NY, NY), obtendrá un gran cuadro delimitador. Pida una dirección en esa calle que la API cree que es una dirección real, pero no es una azotea, obtendrá un cuadro delimitador muy pequeño. Usé el área del cuadro delimitador para determinar la precisión del resultado. Mi descanso preciso/no preciso fue de 0.9E-6, pero creo que tendrías que jugar con él para asegurarte de que te sientas cómodo con ese número.

+0

Muy inteligente. No hubiera pensado en eso. Hice algunas pruebas con nuestras direcciones "sin techo" y encontré un amplio rango. Tenemos cuatro averías, en la azotea, calle (es decir, bloque o ZIP + 4), ZIP + 2 y ZIP. Para cada uno de los tipos de ubicación fuera del tejado de Google, creé la lógica para analizar más a fondo la precisión porque a veces APROXIMADO termina como ZIP + 4 (que, en áreas urbanas es habitual cerca de la azotea) y RANGE_INTERPOLATED es más como ZIP, es decir enorme. –

+0

Otra cosa que noté fue que a veces Google le da a ROOFTOP solo la dirección de la calle pero agregando suite/unit/apt/whatever ... lo hizo cambiar a APROXIMADO aunque el lat/lon permaneció igual. Aquí es donde tu idea fue útil. Otras veces, solo la dirección APROXIMADA de la calle al agregar la subunidad hace que cambie a ROOFTOP. Vi más de los primeros, es decir, más datos, menos "confianza". Estoy pensando en construir en lógica para probar sin subunidades primero y, si no, intentar con la subunidad. Si todavía no es ROOFTOP, entonces compare los recuadros delimitadores y use el más pequeño. –

+0

@AndrewS gracias, me sentía como si fuera el único en esta esquina particular de Internet, nunca obtuve una respuesta en los grupos de google, según recuerdo ... – jcollum

2

He encontrado este código V2 legado al actualizar útil depende de una puntuación de 0 a 9
// Hack para convertir location_type (cadena) a 0-9 puntuación Geocode como marcador 0-9 Geocode no existe en 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; 

    } 
} 
Cuestiones relacionadas