Conferma indirizzo. Esempi

Questo prodotto o questa funzionalità è in anteprima (pre-GA). I prodotti e le funzionalità pre-GA potrebbero avere supporto limitato e le modifiche ai prodotti e alle funzionalità pre-GA potrebbero non essere compatibili con altre versioni pre-GA. Le offerte pre-GA sono coperte dai Termini specifici di servizio di Google Maps Platform. Per saperne di più, consulta le descrizioni della fase di lancio.

Questo documento descrive una serie di scenari reali in cui l'API Address Validation fornisce indicatori di risposta per gli indirizzi che giustificano un comportamento di conferma da parte del sistema. Gli esempi qui riportati sono illustrativi, ma non esaustivi. Per maggiori informazioni, consulta la sezione Panoramica del flusso di lavoro in Creare la logica di convalida.

Suggerimento: apri la demo della convalida degli indirizzi e prova a convalidare gli indirizzi di esempio.

Esempi comuni: conferma

L'esempio seguente illustra il caso delle aree metropolitane con nomi di vie simili. Supponiamo che un utente intenda inserire l'indirizzo dell'edificio D di Google a Kirkland, WA, Stati Uniti. Tuttavia, anziché Kirkland come città, inseriscono inavvertitamente Seattle.

Indirizzo inserito	Regione
Edificio D, 451 7th Avenue South, Seattle, WA 98033	US

Verdetto per i dati sostituiti

L'esempio riportato di seguito mette in evidenza gli indicatori importanti del verdetto.

{
  "inputGranularity": "SUB_PREMISE",
  "validationGranularity": "PREMISE_PROXIMITY",
  "geocodeGranularity": "PREMISE_PROXIMITY",
  "addressComplete": true,
  "hasUnconfirmedComponents": true
  "hasReplacedComponents": true
}

Il livello di PREMISE_PROXIMITY granularità indica l'approssimazione di un indirizzo a livello di edificio, ma non è dettagliato come SUB_PREMISE, ovvero la granularità fornita in input. La risposta contiene anche componenti non confermati e sostituiti, quindi la combinazione rientra nella categoria Conferma.

Una query dei componenti dell'indirizzo rivela le seguenti aree di interesse:

{
  "componentName": {
    "text": "451",
  },
  "componentType": "street_number",
  "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
}
...
{
  "componentName": {
    "text": "98104",
  },
  "componentType": "postal_code",
  "confirmationLevel": "CONFIRMED",
  "replaced": true
}
...
{
  "componentName": {
    "text": "Building D",
    "language_code": "en"
  },
  "componentType": "subpremise",
  "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
}
.......

    "unconfirmedComponentTypes": [
      "street_number",
      "subpremise"
    ]

In questo caso, l'API Address Validation ha trovato un'approssimazione vicina all'indirizzo fornito a Seattle e ha sostituito il codice postale, un componente di livello superiore, per risolvere l'indirizzo a Seattle. Potrebbe essere una sostituzione valida, ma insieme al fatto che i componenti non sono stati confermati, è opportuno assicurarsi che l'utente intenda inserire un indirizzo di Seattle e non qualcos'altro, come Kirkland.

Suggerimento: controlla l'indirizzo corretto nella demo, utilizzando 451 7th Avenue South, Kirkland, WA 98033 per visualizzare la risposta per l'indirizzo originariamente previsto.

Azione: conferma l'inserimento dell'indirizzo con il cliente.

Esempi di casi limite: conferma

Gli esempi riportati di seguito illustrano i seguenti tipi di casi limite:

• Inferenze minori che SONO confermate. L'API Address Validation deduce il paese, il codice postale o lo stato, ma tutto il resto viene fornito e confermato. La combinazione di granularità e livello di conferma crea un'inferenza minore che non richiede necessariamente un'azione di conferma.
• Elemento dell'indirizzo imprevisto NON confermato. I componenti dell'indirizzo non confermati aumentano il livello di rischio dell'indirizzo. Questo potrebbe richiedere una conferma.
• Elemento dell'indirizzo imprevisto che È confermato. Il componente non è strettamente necessario per un indirizzo corretto e l'API Address Validation lo rimuove dall'output. I problemi di formattazione in genere non richiedono una conferma.

Inferenze minori CONFERMATE

Se combinata con dati confermati di un livello più granulare, l'API può comunque fare un'inferenza corretta se nell'input manca solo un componente dei seguenti tipi:

• Città
• Stato
• Codice postale
• Paese

Ad esempio, un cliente fornisce un indirizzo stradale valido per un ristorante McDonald's a Springfield, Massachusetts, ma dimentica di inserire la città e fornisce un codice postale senza l'estensione di 4 cifre.

Indirizzo inserito	Regione
1402 Allen St, MA 01118	US

Verdetto per la città mancante

{
  "inputGranularity": "PREMISE",
  "validationGranularity": "PREMISE",
  "geocodeGranularity": "PREMISE",
  "addressComplete": true,
  "hasInferredComponents": true
}

Nelle situazioni in cui l'API Address Validation deduce i componenti di livello superiore per produrre un indirizzo recapitabile, puoi avere un livello di confidenza più elevato che i dati del sistema siano corretti. Questo perché i componenti dedotti che rappresentano un'ampia regione geografica vengono abbinati più facilmente ai componenti dell'indirizzo confermati che sono più granulari. Anche nei paesi in cui i nomi delle città si ripetono, come Springfield negli Stati Uniti, gli altri componenti combinati possono fornire un indirizzo univoco.

Utilizzando l'esempio precedente, una scansione di tutti i componenti dell'indirizzo mostra che ogni componente è confermato, il che significa che corrisponde ai dati memorizzati dall'API Address Validation e che il servizio deduce anche due componenti di livello superiore.

{
  "componentName": {
    "text": "Springfield",
    "languageCode": "en"
  },
  "componentType": "locality",
  "confirmationLevel": "CONFIRMED",
  "inferred": true
},
{
  "componentName": {
    "text": "1806"
  },
  "componentType": "postal_code_suffix",
  "confirmationLevel": "CONFIRMED",
  "inferred": true
}

Azione: accetta. Indirizzi come questi forniscono una granularità confermata sufficiente, insieme alla conferma dei componenti dedotti, affinché la tua logica possa accettarli come validi senza la necessità di chiedere al cliente.

Componente dell'indirizzo imprevisto NON confermato

Questo scenario illustra l'importanza di verificare quando i componenti non sono confermati. Se un componente dell'indirizzo è imprevisto, l'API Address Validation lo rimuove dall'output. In questi casi, puoi accettare l'indirizzo o riconfermarlo con il cliente, a seconda del tuo livello di rischio e di confidenza.

Ad esempio, un indirizzo potrebbe provenire da una regione in cui i clienti spesso inseriscono informazioni innocue ignorate dall'autorità postale, nel qual caso accetteresti l'indirizzo. Tuttavia, in alcuni casi un componente non confermato potrebbe non essere quello che il cliente desidera.

Indirizzo inserito	Regione
1 Rue Grenache, la caritat 2, 34630 Saint-Thibéry	Francia

Verdetto per il componente dell'indirizzo imprevisto non confermato

{
  "inputGranularity": "PREMISE",
  "validationGranularity": "PREMISE",
  "geocodeGranularity": "PREMISE",
  "unconfirmedComponents": true
}

Oltre a un verdetto con componenti non confermati, l'API Address Validation restituisce il seguente indirizzo formattato:

"formattedAddress": "1 Rue Grenache, 34630 Saint-Thibéry, France",

Una scansione dei componenti non confermati mostra che l'API ha rimosso la caritat 2 dall'indirizzo restituito:

{
  "componentName": {
    "text": "la caritat 2",
    "languageCode": "fr"
  },
  "componentType": "sublocality_level_1",
  "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
  "unexpected": true
}

Azione: conferma. In questo caso, la località secondaria, che può indicare un quartiere residenziale o un vicinato, potrebbe essere corretta ma comunque ignorata dall'autorità postale. Tuttavia, dato che queste informazioni **non** sono confermate dall'API Address Validation, è opportuno confermarle con il cliente. A questo punto, ignori la rimozione o la confermi.

Componente dell'indirizzo imprevisto che È confermato

Questo esempio illustra l'inclusione di una contea del Regno Unito nell'indirizzo fornito, il che è una pratica comune. Tuttavia, questo non è un requisito dell'autorità postale del Regno Unito e viene sostanzialmente ignorato. Consulta postoffice.co.uk e Come indirizzare la posta nel Regno Unito e a livello internazionale.

Di conseguenza, quando un cliente fornisce una contea in un indirizzo del Regno Unito, il servizio la valuta come input imprevisto.

Indirizzo inserito	Regione
33 Dunalley St, Cheltenham, Gloucestershire, GL50 4AP	Regno Unito

Verdetto per il componente dell'indirizzo imprevisto CONFERMATO

{
   "inputGranularity": "PREMISE",
   "validationGranularity": "PREMISE",
   "geocodeGranularity": "PREMISE"
}

In questo caso, address_complete restituisce il valore false e un'analisi del componente dell'indirizzo rivela un flag imprevisto.

{
  "componentName": {
    "text": "Gloucestershire",
    "languageCode": "en"
  },
  "componentType": "administrative_area_level_2",
  "confirmationLevel": "CONFIRMED",
  "unexpected": true
}

Questo componente è sia imprevisto che confermato, il che significa che:

• Confermato come dati corretti. Indica che il componente è la contea corretta che contiene l'indirizzo.
• Unexpected as input. Indica un componente non necessario per la corretta formattazione dell'indirizzo.

Sebbene il Gloucestershire sia la contea corretta per l'indirizzo inserito, l'indirizzo stesso non è formattato correttamente. Ricorda che l'API Address Validation valuta anche le informazioni per la corretta formattazione.

Azione: per questo scenario, l'azione consigliata è ignorare questo segnale e accettare l'indirizzo.