8

Mam trochę kodu, który przenoszę z API v2 na v3. W starym kodzie mieliśmy pole dokładności, które powróciło w xml (nie jestem pewien nazwy, ale reprezentował pewien poziom pewności). W nowym interfejsie API nie widzę żadnego takiego pola.Czy interfejs API geokodowania w Mapach Google v3 ma pole reprezentujące dokładność?

Po umieszczeniu w polu wyszukiwania "Oregon, USA" uzyskuję 5 dopasowań. Pierwsze 2 to "Oregon, USA" i "Oregon, OH, USA". Oba mają "partial_match" = false. To nie wydaje się właściwe, wydaje się częściowe, a jedno nie. Poza tym oboje wracają z tym samym "location_type" (APPROXIMATE). W rzeczywistości wszystkie dopasowania są wyświetlane jako nie-częściowe i mają ten sam typ lokalizacji.

Moje pytanie brzmi: czy którekolwiek z pól w zestawie wyników wyrażają pewną pewność co do dokładności wyniku? W mojej próbce wygląda na to, że jeden wynik jest znacznie dokładniejszy niż jakikolwiek inny - tak bardzo, że wejściowy ciąg znaków dokładnie pasuje do zwróconego pola QuickAddress.

Odpowiedz

11

Dwa tygodnie, brak odpowiedzi, więc oto moje rozwiązanie.

Interfejs API zwróci wartość ROOFTOP, GEOMETRIC_CENTER, RANGE_INTERPOLATED lub APPROXIMATE.

Rooftop jest zasadniczo "martwy na" - interfejs API rozwiązał adres budynku. Poza tym masz różne stopnie "zamknięcia". Moim rozwiązaniem było użycie ramki ograniczającej, która została zwrócona, aby określić, jak blisko było. Więc jeśli poprosisz o ulicę (Avenue of the Americas, NY, NY), dostaniesz ogromną skrytkę. Poproś o adres na tej ulicy, który według API jest rzeczywistym adresem, ale nie jest Rooftopem, dostaniesz bardzo małe pole ograniczające. Użyłem obszaru ograniczającego pola, aby określić dokładność wyniku. Moja dokładna/nieścisła przerwa była na 0.9E-6, ale myślę, że musiałbyś ją ulepszyć, aby upewnić się, że czujesz się komfortowo z tym numerem.

+0

Bardzo sprytny. Nie pomyślałbym o tym. Zrobiłem kilka testów z naszymi adresami "spoza dachu" i znalazłem ogromny zakres. Mamy cztery awarie, rooftop, street (tzn. Blok lub ZIP + 4), ZIP + 2 i ZIP. Dla każdego typu lokalizacji poza lokalizacją Google stworzyłem logikę, aby dokładniej analizować dokładność, ponieważ czasami APPROXIMATE kończy się bardziej jak ZIP + 4 (który w obszarach miejskich jest zwykle dość zbliżony do dachu), a RANGE_INTERPOLATED jest bardziej podobny do ZIP, tj. olbrzymi. –

+0

Jedną z rzeczy, które zauważyłem, było to, że czasami Google daje ROOFTOP tylko z adresem ulicy, ale dodanie pakietu/unit/apt/whatever ... sprawiło, że zmienił się na APPROXIMATE, mimo że lat/lon pozostał taki sam. To tutaj przydał się twój pomysł. Innym razem tylko adres ulica APPROXIMATE podczas dodawania podjednostki powoduje przejście do ROOFTOP. Widziałem więcej z pierwszego, tj. Więcej danych, mniej "zaufania". Zastanawiam się nad logiką, aby najpierw wypróbować bez podjednostki, a jeśli nie, ROOFTOP spróbuj z podjednostką. Jeśli nadal nie jest ROOFTOP, porównaj ramki ograniczające i użyj mniejszego. –

+0

@AndrewS dzięki, czułem się jakbym był jedynym w tym szczególnym zakątku internetu - nigdy nie dostałem odpowiedzi w grupach google, o ile pamiętam ... – jcollum

2

Znalazłem przydatnych podczas uaktualniające starszego kodu V2 zależy od 0 do 9 punktów
// Hack Do przeliczenia LOCATION_TYPE (string) do 0-9 wynik przetwarzania danych geograficznych jako wynik 0-9 geocode nie istnieje w 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; 

    } 
} 
Powiązane problemy