Global Address Object:FAQ: Difference between revisions

From Melissa Data Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
[[Global Address Object|← Global Address Object]]
[[Global Address Object|← Global Address Object]]
{{CustomTOC}}
{{CustomTOC}}
==What are the DLLs required for the global address engine to work?==
{{FAQ-GlobalAddressProCon}}
mdGlobalAddr.dll is the main global address engine that the application program will be accessing. mdAddr.dll, mdGeo.dll, mdRightFielder.dll are helper libraries used by mdGlobalAddr.dll in certain cases. These libraries are not to be used directly.


==What are the minimum hardware and OS requirements for the Global Address On-Premise API?==
:The Global Address On-Premise API does not have strict minimum requirements; it will run on most systems but just slower. Our recommended system environment is:
:*4-8+ Core Modern Server CPU
:*16GB+ RAM
:*150GB+ Hard Drive Space
:*SSD level or faster disc access speed (important)


==What are the default locations for global address engine DLLs?==
:Global Address is only supported on 64-bit architecture. Currently, we support the following operating systems:
The default location for these DLLs is address\windows\dll_64bit
:*Windows
:*Linux (GCC 4.1 built on CentOS 5)


==What type of global address information can I send?==
:Global Address is designed to take full standard addresses. This means that the address must, in most cases, have a house number, a street (or thoroughfare) and identifiable area data (like postal code and locality). The service will not behave particularly well for partial addresses, point of interest information (like a park or plot of land without a formal address), Directions (e.g. "across the street from ABC Bank") or non-address information (like phone numbers). The reason for this is that address verification relies on having a good address data source behind it in order to confirm its validity, and non-formal address data is not good enough to power our verification solution.


==Where are the data files located?==
==What are the minimum input fields required?==
The location on the download is \address\data. When the product is installed, it defaults to D:\Program Files\Melissa DATA\DQS\Data unless the path is changed in the setup prompt.
:The only field that is really required is the country input. We cannot verify an address without a country. Secondly, almost all addresses must effectively have an AddressLine input. While it is theoretically possible to verify an address with a very unique piece of information like a postal code in certain countries and areas, that is very rare.


==How should I send in my address input data?==
:Your input address can be sent in a number of ways. Our main advice is to try and send the data you have with as little manipulation as possible if you have a full address. The most common ways to send it are:


==Which architecture do these DLLs support?==
<ol>
There is support only for 64-bit architecture.
<li>Full address in the AddressLines:</li>
<pre style="margin-left:20px;">AddressLine1: 22382 Avenida Empresa
AddressLine2: Rancho Santa Margarita CA, 92688
Ctry: US
</pre>


<li>Full address in the AddressLines + Parsed Area:</li>
<pre style="margin-left:20px;">AddressLine1: 22382 Avenida Empresa
Locality: Rancho Santa Margarita
AdministrativeArea: CA
PostalCode: 92688
Ctry: US</pre>
</ol>


==What are the operating systems that the object supports?==
:'''Note:''' What you want to avoid as much as possible is sending in duplicated information, like this '''<span style="color:red;">BAD example below'''</span>:
The object is currently available across windows and linux platforms.
<pre style="color:red; margin-left:40px;">AddressLine1: 22382 Avenida Empresa
AddressLine2: Rancho Santa Margarita CA, 92688
Locality: Rancho Santa Margarita
AdministrativeArea: CA
PostalCode: 92688
Ctry: US</pre>


==What encoding does Global Address use?==
:Global Address uses UTF-8 Unicode encoding. It is very important to make sure your data is in UTF-8 when sending to our service, especially for non-Latin countries. Be on the lookup for question marks (?), squares (▖) or other weird characters like �. They may be an indication of encoding issues and may result in data loss.


==What are the programming languages in which the application can be designed in order to use these objects?==
==Why are there different levels of Address Verification Result Codes?==
For windows platform, there are wrappers available for Java, .NET and Python. For linux platform, there are wrappers available for Java, Perl, PHP, Python and Ruby.
:The address source data that is available to use as part of our Address validation product can differ from country to country. For most developed countries with a major postal agency like the United States, Great Britain, France, etc, we will have delivery point data available. However, there may be countries where that detailed data is not available, or simply does not exist. In those cases, we will use less detailed information. Here is an overview and inside peak of the types of data available:
:*'''Delivery Point Data'''
::Source: 1 Main St Apartment 12, Anytown 12345, USA
::Max Verification Level: AV25


:*'''Range Data'''
::Source: 100-200 Main St, Anytown 12345, USA
::Max Verification Level: AV24


==How does the update process work?==
:*'''Thoroughfare Data'''
For each update, the two items that will change are the dll’s and the data files. Those are the files that must be updated, and should be updated in conjunction. To perform the update, you can do either of the following steps:
::Source: Main St, Anytown 12345, USA
::Max Verification Level: AV23


#Run the installer. The installer will automatically copy over the new dll’s and new data files.
:*'''Locality Data'''
#Manually copy the dll’s and data files. To do this, follow these steps:
::Source: Anytown 12345, USA
##Go to /address/windows/dll_64bit or /address/linux/dll_64bit and copy all the object (.dll for windows, .so for linux) and replace your current objects.
::Max Verification Level: AV22
##Go to /address/data and copy all files and/or directories over your current data files.


Note that the update process will likely require that any applications using the objects or data files be restarted.
==What speed can I expect from Global Address Web Service?==
:The response time of the Global Address API is highly dependent on a number of factors:
:*'''The country of the input.''' This is one of the most important factors as each country has its own engine in the background and its own verification paths and algorithms. A well-structured country like the US will be much faster than a less structured one like India. Also, a Latin-based address system will usually be faster than a non-Latin system.
:*'''The quality of the address.''' A good address will be faster than a bad or partially bad address. Bad addresses will require extra steps, additional fuzzy matching logic, and extra parses before we either find a match or give up.
:*'''The number of threads.''' You can increase the speed by increasing the number of threads until your system starts running out of resources. The important thing to pay attention to is that each thread has its own instance of the API.


:The country in question will have the biggest impact on the speed. You may get anywhere from 100K/hour to over a million. Additionally, you can increase that speed likely 2X-5X by increasing the number of threads.


==What are the languages/scripts supported by the Global Address Object?==
==How does the Global Address engine handle different Scripts?==
Global Address Object supports the native language and script for each country that we support. For countries with native languages that does not use latin script, transliterated version of the address can be provided. We currently support the following languages:
:Global Address has an option called <code>OutputScript</code> that has 3 possible values:
:*<code>NoChange</code>: We will detect the script of the input and leave output in that same script.
:*<code>Latn</code>: We will change the output to Latin on output.
:*<code>Native</code>: We will change the output to the native script of the country (Like Cyrillic for Russia)


 
:Here are some things to make note of when trying to understand this functionality.
{|class="alternate01" cellspacing="0"
:#Global Address essentially supports up to two scripts per country. Latin and if the country uses a language that is not Latin based, we convert to that language if Native is set.
!Output Value!!Definition
:#Note that Script and Language are not the same. English, Spanish, French are all Latin Script even if their alphabet and diacritics used are slightly different.
|-
:#We can only change scripts for a record if we are able to verify and validate the address.
|Latn||Latin (English transliteration wherever possible)
:#For Latin based languages, if you specify <code>OutputScript=Latn</code>, we will also remove the diacritics (<code>Gjøvik</code> vs <code>Gjovik</code>)
|-
|Cyrl||Cyrillic (Russia)
|-
|Grek||Greek (Greece)
|-
|Hebr||Hebrew (Israel)
|-
|Hani||Kanji (Japan)
|-
|Hans||Simplified Chinese (China)
|-
|Arab||Arabic (United Arab Emirates)
|-
|Thai||Thai (Thailand)
|-
|Hang||Hangul (South Korea)
|}
 
 
==Result Codes==
===How do I use Results Codes for the Global Address Object?===
:The Global Address Object will return a number of codes to inform you of the status of an global address. These codes can be divided into AV codes for status, AE codes for errors, and AC codes for changes.
 
===AV Codes===
:These codes tell you how good the returned address is. They are slightly different than the AS codes you are used to in our US only products.
:*AV2X denotes an address that has been fully verified.
:*AV1X denotes a partially verified address, but something was invalid.
:*The second number (X) indicates the level of verification to which the output address is valid up to. The possible values from between 1 to 5.
 
:[[File:TUT WS GlobalAV AVChart.jpg|450px]]
 
:;For example:
:#AV25 indicates the output address was fully verified to the SubPremises(level 5.)
:#AV24 indicates the output address was fully verified to the Premises(level 4.)
:#AV22 indicates the output address was fully verified to the Locality(level 2.) but we did not have data above the locality.
:#AV14 indicates the output address was partially verified but is good up to the Premises(level 4.) You can imply that this means something was wrong with the sub-premise.
:#AV13 indicates the output address was partially verified but is good up to the Thoroughfare(level 3.) You can imply that this means something was wrong with the premise.
 
====AV24 vs AV25====
:Both of these codes are similar in that they tell you the address is fully good down to the delivery address. You will get an AV24 if the destination address is a house or building without any sub-premises (therefore level 5 is impossible). AV25 means the address was fully good and that the destination address does contain sub-premises. If you have a apartment complex and you enter a wrong suite, you will get an AV14 (partially good address, good to the premise).
 
====Using the AV Codes====
:One use of the AV codes is to simply look for AV2. This will indicate that all addresses have been fully verified with no errors up to the data available. However, if you want to ensure all addresses are correct down to the delivery address, you should look for AV24 or AV25.
 
===AE Codes===
:AE codes will tell you what type of error occurred when verifying the address. It is possible to get AE codes along with AV codes (like Sub-premise invalid, multiple match) or AE codes by themselves (postal code error).
 
===AC Codes===
:AC codes will tell you what we changed in the output address when compared to the input address. Standardizations (Street to St) do not count as changes.
 
 
==Inputs==
The Global Address Object has a number of different input fields. They include AddressLines 1-8 as well as parsed input fields like locality, administrative area, postal code, etc. You can pass an address into the global Object in two ways:
;1. Pass the entire address using just the Address Lines
:Address1: 2 Holt Street
:Address2: Surry Hills
:Address3: NSW 2010
:Country: AU
 
;2. Pass the delivery address in the Address Lines and the area information in using the parsed inputs.
:Address1: 2 Holt Street
:Locality: Surry Hills
:AdministrativeArea: NSW
:PostalCode: 2010
:Country: AU
 
===Additional Tips===
:#If you have the area information parsed out already and you trust it, pass it into the input parsed fields (method #2 above). We do not want to lose that piece of information and making the service re-parse introduces an unnecessary area for errors. If you are not sure that your parsed area information is correct, pass it into the address lines.
:#Be wary of duplicate information. Try not to pass in duplicate information if possible. A common example is the address lines containing the locality and also passing the same value into the input locality.  
:#Country input is required. It can contain a country name or an ISO 3166 code, but it must be there.
 
<!--
==Outputs==
The Global Address Object has a decent number of output fields. These fields can return duplicate information so it is important to understand exactly what each field returns. Please see the [[Global Address Object:Output Parameters|Output Parameters]] for more detailed information. For this FAQ, we will focus on which pieces will return you back a full address:
 
===Normal Mode===
:;FormattedAddress
::Returns the mailing address in one line.
 
:;Organization + AddressLine1-8
::Returns the full address back in multiple lines
 
:;ParsedAreaFields
::Returns the parsed area fields. These fields do not constitute a full address and its data duplicated in FormattedAddress and AddressLines1-8. This data can be used for profiling or de-duping.
::(These are the additional fields which include: locality, dependent locality, administrative area,  sub administrative area, sub national area, & postal code.)
 
===DeliveryLines Options===
:This option must be turned on. Please see [[Global Address Verification:Request#DeliveryLines|the DeliveryLines option]] for information on how to do this.
 
:;formattedAddress
::Returns the mailing address in one line.
 
:;Organization + AddressLine1-8
::Returns just the delivery address (including the dependent locality). Any area information locality or larger is not included.
 
:;ParsedAreaFields
::Returns the area information in their individual fields not included in AddressLine1-8.
::(These are the additional fields which include: locality, dependent locality, administrative area,  sub administrative area, sub national area, & postal code.)
 
 
==Encoding==
The Global Address Object uses UTF-8. Make sure you are storing your address data in Unicode (nvarchar) and passing them to the object in UTF-8. Be on the lookup for question marks (?), squares (▖) or other weird characters like �. They may be an indication of encoding issues and may result in data loss.
-->




[[Category:FAQ]]
[[Category:FAQ]]
[[Category:Global Address Object]]
[[Category:Global Address Object]]

Latest revision as of 17:56, 28 June 2022

← Global Address Object


What are the Pros and Cons of using Global Address Public Cloud vs On-Premise?

In terms of the global address verification functionality, the Public Cloud and the On-Premise both will product the same verification results. Our public cloud offer is after all simply a web application layer built on top of the On-Premise API. You will receive the same global coverage regardless of which one you pick. The main reasons for picking one or the other are due to architectural as well as organization policy reasons.


Public Cloud On-Premise
Privacy and Security Data is hosted on Melissa servers in a secure and private environment. We undergo security audits like SOC2 and no PII data is stored. The most private and secure option. The Global Address library and data files are located on your own servers and nothing leaves your network.
Maintenance Start verifying addresses with no setup or installation. No maintenance of servers or data updates to worry about. Updates provided on a quarterly basis that will need to be updated on all machines hosting the on-premise product. Install is included or simply use a copy/replace operation.
Pricing Transactional Pricing. Best and cheapest way to get started and only pay for exactly what you use. Bulk pricing. We are required to charge bulk pricing for putting data on premise. Most cost efficient for high volumes.
Ease of Use Ready to use web application that supports REST/XML/JSON/SOAP on a globally hosted redundant infrastructure. API for use in a programming language like Java/Python/.NET, etc. A low-level API that can be integrated to exactly your needs, but is not a ready to go web service like Public Cloud.


What are the minimum hardware and OS requirements for the Global Address On-Premise API?

The Global Address On-Premise API does not have strict minimum requirements; it will run on most systems but just slower. Our recommended system environment is:
  • 4-8+ Core Modern Server CPU
  • 16GB+ RAM
  • 150GB+ Hard Drive Space
  • SSD level or faster disc access speed (important)
Global Address is only supported on 64-bit architecture. Currently, we support the following operating systems:
  • Windows
  • Linux (GCC 4.1 built on CentOS 5)

What type of global address information can I send?

Global Address is designed to take full standard addresses. This means that the address must, in most cases, have a house number, a street (or thoroughfare) and identifiable area data (like postal code and locality). The service will not behave particularly well for partial addresses, point of interest information (like a park or plot of land without a formal address), Directions (e.g. "across the street from ABC Bank") or non-address information (like phone numbers). The reason for this is that address verification relies on having a good address data source behind it in order to confirm its validity, and non-formal address data is not good enough to power our verification solution.

What are the minimum input fields required?

The only field that is really required is the country input. We cannot verify an address without a country. Secondly, almost all addresses must effectively have an AddressLine input. While it is theoretically possible to verify an address with a very unique piece of information like a postal code in certain countries and areas, that is very rare.

How should I send in my address input data?

Your input address can be sent in a number of ways. Our main advice is to try and send the data you have with as little manipulation as possible if you have a full address. The most common ways to send it are:
  1. Full address in the AddressLines:
  2. AddressLine1: 22382 Avenida Empresa
    AddressLine2: Rancho Santa Margarita CA, 92688
    Ctry: US
    
  3. Full address in the AddressLines + Parsed Area:
  4. AddressLine1: 22382 Avenida Empresa
    Locality: Rancho Santa Margarita
    AdministrativeArea: CA
    PostalCode: 92688
    Ctry: US
Note: What you want to avoid as much as possible is sending in duplicated information, like this BAD example below:
AddressLine1: 22382 Avenida Empresa
AddressLine2: Rancho Santa Margarita CA, 92688
Locality: Rancho Santa Margarita
AdministrativeArea: CA
PostalCode: 92688
Ctry: US

What encoding does Global Address use?

Global Address uses UTF-8 Unicode encoding. It is very important to make sure your data is in UTF-8 when sending to our service, especially for non-Latin countries. Be on the lookup for question marks (?), squares (▖) or other weird characters like �. They may be an indication of encoding issues and may result in data loss.

Why are there different levels of Address Verification Result Codes?

The address source data that is available to use as part of our Address validation product can differ from country to country. For most developed countries with a major postal agency like the United States, Great Britain, France, etc, we will have delivery point data available. However, there may be countries where that detailed data is not available, or simply does not exist. In those cases, we will use less detailed information. Here is an overview and inside peak of the types of data available:
  • Delivery Point Data
Source: 1 Main St Apartment 12, Anytown 12345, USA
Max Verification Level: AV25
  • Range Data
Source: 100-200 Main St, Anytown 12345, USA
Max Verification Level: AV24
  • Thoroughfare Data
Source: Main St, Anytown 12345, USA
Max Verification Level: AV23
  • Locality Data
Source: Anytown 12345, USA
Max Verification Level: AV22

What speed can I expect from Global Address Web Service?

The response time of the Global Address API is highly dependent on a number of factors:
  • The country of the input. This is one of the most important factors as each country has its own engine in the background and its own verification paths and algorithms. A well-structured country like the US will be much faster than a less structured one like India. Also, a Latin-based address system will usually be faster than a non-Latin system.
  • The quality of the address. A good address will be faster than a bad or partially bad address. Bad addresses will require extra steps, additional fuzzy matching logic, and extra parses before we either find a match or give up.
  • The number of threads. You can increase the speed by increasing the number of threads until your system starts running out of resources. The important thing to pay attention to is that each thread has its own instance of the API.
The country in question will have the biggest impact on the speed. You may get anywhere from 100K/hour to over a million. Additionally, you can increase that speed likely 2X-5X by increasing the number of threads.

How does the Global Address engine handle different Scripts?

Global Address has an option called OutputScript that has 3 possible values:
  • NoChange: We will detect the script of the input and leave output in that same script.
  • Latn: We will change the output to Latin on output.
  • Native: We will change the output to the native script of the country (Like Cyrillic for Russia)
Here are some things to make note of when trying to understand this functionality.
  1. Global Address essentially supports up to two scripts per country. Latin and if the country uses a language that is not Latin based, we convert to that language if Native is set.
  2. Note that Script and Language are not the same. English, Spanish, French are all Latin Script even if their alphabet and diacritics used are slightly different.
  3. We can only change scripts for a record if we are able to verify and validate the address.
  4. For Latin based languages, if you specify OutputScript=Latn, we will also remove the diacritics (Gjøvik vs Gjovik)