Major Enhancements to Esri World Geocoding service! (June 2017)

The ArcGIS Online World Geocoding service update that was released last night is not just another regular data update. It’s a major release with significant enhancements. This blog will guide you through some of the new features and improvements you can expect to see in the service. You can find a complete list of changes and detailed information about available functionality in the World Geocoding service documentation.

1. Geocoding in more countries – You can now search for addresses in more countries than before. Previously the World Geocoding service boasted support for address-level geocoding in 109 countries. The list has expanded to an even more impressive 135 countries. We’ve also updated the reference data for most countries and added new authoritative address data sources for Australia (G-NAF) and Austria (BEV).

Figure 1: This Geocoding Coverage map demonstrates the countries for which there is address coverage in the World Geocoding Service and the languages they support, grouped by relative geocoding quality. The darker the shade, the higher the quality of geocoding. Complete coverage information and languages supported are available in the developer documentation.

2. Improved matching logic – We’ve enhanced the behind-the-scenes matching logic for better handling of poorly-formed address searches. Geocoding in the USA consistently yields high match rates, but your address database may include questionable addresses with misspellings or extra information that can’t be geocoded, such as person names. The enhanced service is capable of handling this type of incorrect information. Below are a few examples of how these improvements can boost geocoding match rates even higher.

Figure 2: Geocode addresses with errors or extraneous information

3. Enhanced coordinate search – Our Defense and Intel users have always been able to easily search for MGRS (Military Grid Reference System) coordinates in ArcGIS Desktop. Unfortunately it wasn’t so simple to do the same in ArcGIS Online. For the first time, you will be able to search for MGRS coordinates – along with postal codes, addresses, populated places, and points of interest – from a single endpoint in ArcGIS Online with the World Geocoding service.  Additionally, you can now search for latitude/longitude coordinates in different formats, such as degrees-minutes-seconds (DMS), and can also find United State National Grid (USNG) coordinates.

Figure 3: Search for coordinates in many different formats, including MGRS, with the World Geocoding service

4. More than addresses – Another useful feature in the updated service is the ability to batch geocode Point of Interest (POI) names. You may have tables that include both addresses and place names, and in the past when you tried to batch geocode them there were no matches for the place names. However, you could find the same place names with geosearch. There’s no longer such a disconnect because the enhanced geocoding service can now handle the same types of input for batch geocoding as it does for geosearch, which means you can batch geocode addresses, postal codes, and POIs, or any combination of these.

Figure 4: Batch geocoding POI names is now supported

As an added bonus you can now combine POI names with addresses and postal codes in a single search. Overall the World Geocoding service allows more search flexibility than ever before.

Figure 5: Search for POIs with address and postal code

5. Improved intersection geocoding – With the updated service you’re no longer limited to finding intersections between streets that are physically connected. In many cases two streets may nearly intersect each other but are separated in some way. For example, a street ending in a cul-de-sac or dead end may be close to a cross street but separated from it by a walkway. A highway overpass is elevated above the road beneath it, so they cross each other but aren’t connected. The streets entering a roundabout intersect the roundabout itself but not each other. The World Geocoding service now has the ability to find intersection matches for each of these cases, and any scenario in general where two streets are close to each other but don’t actually intersect.

Figure 6: Find disconnected intersections, such as cul-de-sacs, overpasses, and roundabouts

6. Enhanced reverse geocoding – In the past, reverse geocoding was the process of taking X/Y coordinates and converting them to an address or intersection. However, when you reverse geocode a location you’re really trying to find an answer to the question “What’s near me?”, or more specifically, “What’s near this location?” Sometimes the best answer to that question isn’t a street address. Maybe you see an interesting landmark on a map and you want find out what it is. Or maybe the spot you click on the map is far away from any streets and no address is returned, but you still want to know the city or postal code at that location. With the updated service you’ll always get a match to the most relevant feature near your location when you reverse geocode. It may be a restaurant, park, address, postal code, or city. For example, if you drop a point in the middle of Disneyland Paris that’s what the service will return.

Figure 7: Reverse geocode POIs and other feature types

There may be situations where you only want the closest address or intersection to be returned for an input location, and the World Geocoding service supports this too. You can control which features are returned by using the new featureTypes parameter, available with the reverseGeocode operation through the service REST API. For instance, referring to the previous image, if you want the service to find an intersection instead of Disneyland Paris you can pass featureTypes=StreetInt in your reverseGeocode request and the service will return this:

Figure 8: Choose the features you want reverse geocoding to return

You can find more details in the developer documentation.

7. Data refresh – The World Geocoding service will continue to be updated with new reference data at regular intervals, providing you with detailed global coverage using high-quality authoritative datasets. The service released last night was built with the most current available address data.

As you can see, the geocoding team has been working hard to deliver the best possible geocoding experience to you. Our work isn’t done though, as we’re planning additional improvements for subsequent releases in the near future, so stay tuned! We hope you’ll find these latest enhancements useful in your ArcGIS applications and projects.

If you have any feedback, please send it to GeocodeQA@esri.com, or stop by and chat with us at the User Conference in San Diego.

- The Geocoding team

This entry was posted in Analysis & Geoprocessing, App Developers, Apps, ArcGIS Earth, ArcGIS Online, ArcGIS Pro, Community Maps, Developer, Location Analytics and tagged , , , , , , , . Bookmark the permalink.

Leave a Reply

24 Comments

  1. rhupp says:

    We had an issue with the World Geocoding service update that affected one of our public applications that our users identified. We had implemented a modified version of the My Government Services app (2014) and had the World Geocoding service set in the configuration to return candidate addresses for addresses searched in search box. The application stopped returning address candidates and would throw an invalid search error. We had made no changes to the data or the code fueling the app and on the day of the update June 28th we began getting reports from users that the search address function was not working. After trouble shooting the issue we noticed that the json response for specified candidate outfields was only returning one of three requested for the locator.
    The application is using the JS API version 3.11. Using the esri/task/locator class we had the method addressToLocations params for outFields set as ["Loc_name, Score, Match_addr"] and were only getting back the “Loc_name”: attribute. Just by chance we changed the outFields params to ["Loc_name,Score,Match_addr"], simply removing the spaces after the commas, and all three candidate attributes were returned and the search address function in the app began working again. Not sure if the update to the World Geocoding service was the root cause of the issue but our search address feature of our app stopped working in conjunction with the update. Posting this more of an FYI to others who may experience a similar issue.

  2. yanhuabi says:

    your upgrade broke our service. we have a service to call ArcGIS online to get latitude/longitude and all the mapping records. the names of the address types were changed. now, all address types are World. they used to be:
    for USA, address types are:
    USA.PointAddress
    USA.StreetName
    USA.BuildingName
    USA.StreetInt”
    USA.PostalExt
    USA.StreetAddress
    USA.Postal
    USA.AdminPlaces
    for Canada, the types are:
    CAN.PointAddress
    CAN.StreetName
    CAN.BuildingName
    CAN.StreetInt
    CAN.StreetAddress
    CAN.Postal
    CAN.PostalExt
    CAN.AdminPlaces
    we do the match based on address types and the score. this upgrade totally failed us. I wonder why I did not get notified for the address type change. this is a big issue.

  3. brad5993 says:

    We appreciate the feedback.

    We recommend using the “Addr_type” field to inspect the type of geocode that is returned by the Geocode Service. If country is also needed, we recommend using the “Country” field to inspect which country the result was geocoded to.

    Also, “Loc_name” is not supported for use by the API. It is for internal use only.

    If you have any additional questions or concerns, please feel free to contact us by emailing and we will work through them with you.

    • dewright_ca says:

      Brad, are the updates noted in bullet-2 available in the 10.5.1 Server & Desktop engine?

      • patel_nick says:

        Thanks for your question.
        If you are connecting to the ArcGIS Online World Geocoding service from within those apps (Desktop, Server, and Engine), you can experience the geocoding benefits right away. For organizations wanting to see these benefits reflected in their own locators or using StreetMap Premium locators, those will be introduced later this year through first half of 2018 in beta. We will announce when organizations can request to participate in the beta program. We will announce the full roadmap during the various geocoding sessions at the UC or come talk to one of us at the Spatial Analysis (Geocoding) booth. Please email GeocodeQA@esri.com if you have additional questions or comments.

        • dewright_ca says:

          Ok, so that means with 10.5.1 new Geocoders built using our own data (commercial TomTom & HERE) won’t have access to the “Improved matching logic” ?

  4. Brad Niemand says:

    It has come up for a few users that the latest World Geocoding service update has broken some of their apps because they were using the “Loc_name” field values to filter results from the service to be specific to their app. The “Loc_name” field is for internal purposes only and instead of using this field, users can use the “Country” output field to inspect what country the results are returned for and the “Addr_type” output field for the precision of the geocoding match (PointAddress, StreetAddress, StreetName, etc…). For more information about the output fields that are returned by the World Geocoding service please see the following documentation: Geocoding Service output documentation

    If a specific country is what you are looking for, another way to handle this type of filtering is to use the “CountryCode” input parameter and pass in the value to the country that you would like matches for (ex. CountryCode=CAN). In addition to that, users have the ability to use our category API and the results will be limited to the category values the application used (Ex. category=PointAddress,StreetAddress,StreetName). For more information on these inputs for the World Geocoding service, please see the following documentation: findAddressCandidates request parameters and Category filtering

    • kevin.rathgeber says:

      Interesting as it was ESRI’s provided templates like the Municipal Government Services template that used those values in the locator.

  5. stefano.angarano93 says:

    We are using the geocode service from Web Appbuilder.
    Geocoding in Italy, after the update, doesn’t seem to recognize some address which were recognized correctly before the update.
    Example: “Piazza Diaz, Milano” is recognized as “Piazza Armando Diaz, 20020, Busto Garolfo, Milano” instead of “Piazza Generale Armando Diaz, 20123, Milano”, the correct one, as it was couple weeks ago.
    Another example is: “Via Canova, Milano” recognized as “Cascina Canova, 20060, Mediglia, Milano” instead of “Via Antonio Canova, 20145, Milano”.

    The only way to get the correct results is to write in the search terms the full address.
    Is there a way to resolve these issues?

    • patel_nick says:

      Hello Stefano, thanks for your question. Submitting an incomplete address with missing key location components will lead to false-positive or unreliable matches with any geocoding solution. In any case, we will check with our Esri Italy team to review the case above and loop you in to the discussion. thank you for the feedback!

      • stefano.angarano93 says:

        Thank you, Patel. Have you got any news on this topic? News from Esri Italy?

        • patel_nick says:

          hi Stefano, thanks for your feedback on the Italian geocoding. Our team has introduced several fixes for Italy last night that should improve the Italy geocoding experience. Please check it out and let us know what you think!!

  6. acigarini says:

    We are using the service from Android and iOS SDK and still have many problems with the italian addresses.

    Examples
    1. Search “via marie curie, modena”, found “Marie Ct, Modena, New York, 12548″, instead of “Via Maria Sklodowska Madame Marie Curie, 41126, Modena” (or simply Via Marie Curie).
    2. Search “viale da vinci, modena”, found “Modena”, instead of “Viale Leonardo da Vinci, 41126, Modena”.
    3. Search “via tintoretto, carpi”, found “Carpi, Modena”, instead of “Via Jacopo Robusti Tintoretto, 41012, Carpi, Modena”.
    4. Search “via rizzoli, bologna” found “Via Rizzoli, 40055, Castenaso, Bologna”, instead of “Via Francesco Rizzoli, 40126, Bologna”.
    5. Search “viale amendola, modena” found “Via Amendola, 41051, Castelnuovo Rangone, Modena”, instead of “Viale Giovanni Amendola, 41124, Modena”.

    Basically, it seems that the service fails to find the address unless you type the full street name.
    Most users don’t know the full name, so the app is unusable. It’s a really big problem for us.

    • patel_nick says:

      hi acigarini, thanks for your feedback on the Italian geocoding. Our team has introduced several fixes for Italy last night that should improve the Italy geocoding experience. Please check it out and let us know what you think!!

  7. gavinj says:

    I am in no way a programmer, our programmer who originally put this together has moved on to better pastures. Below is what I believe is the reason why my address search doesn’t work anymore…..can someone please let me know what I need to change regarding the code below to make this work again? Any help is appreciated.
    Thanks

    Locators: [{
    DisplayText: "Search Address", //Set placeholder text
    DefaultValue: "15 Baxter Ln", // Set default address to search.
    LocatorParameters: ["SingleLine"], // Set Locator fields (fields to be used for searching).
    LocatorURL: “http://geocode.arcgis.com/arcgis/rest/services/World/GeocodeServer”,
    CandidateFields: “Loc_name, Score, Match_addr”, //Set which fields are returned in results
    DisplayField: “${Match_addr}”, //Set which field from results is displayed
    AddressMatchScore: 80, //Set minimum score to be considered a match
    LocatorFieldName: ‘Loc_name’, //The returned field which specifies match type (specific locator within composite)
    LocatorFieldValues: ["USA.StreetName", "USA.PointAddress", "USA.StreetAddress"] //List of acceptable individual locators (within composite)

    • Brad Niemand says:

      You will need to change CandidateFields and how LocatorFieldName is used by LocatorFieldValues but the code above does not show how the latter two are used. Loc_name is an internal field which value has changed and the code should instead return Addr_type and Country. The values of these two fields can be concatenated and used by LocatorFieldValues

      CandidateFields: “Addr_type,Country,Score,Match_addr”, //Set which fields are returned in results

      Ex result using the new CandidateFields
      “address”: “380 New York St, Redlands, California, 92373″,
      “location”: {
      “x”: -117.1956703176181,
      “y”: 34.056488119308924
      },
      “score”: 100,
      “attributes”: {
      “Score”: 100,
      “Match_addr”: “380 New York St, Redlands, California, 92373″,
      “Addr_type”: “PointAddress”,
      “Country”: “USA”
      },
      “extent”: {
      “xmin”: -117.1963135,
      “ymin”: 34.055108000000011,
      “xmax”: -117.19431349999999,
      “ymax”: 34.057108000000007
      }

      You can see that the Addr_type and Country fields can be concatenated like this: Country + “.” + Addr_type

      I could potentially help with how to plug this in if you provide the additional code that shows how LocatorFieldName is used.

      Brad

      • gavinj says:

        Brad,
        Thanks for the help! I made a couple of adjustments from what you sent me above and it is working perfectly! Below are the changes I made. I’m not really sure what I would need to send as far as additional code for the LocatorFieldName usage (programming ignorance)…but the changes that I made seem to have made the difference. Thank You!

        Locators: [{
        DisplayText: "Search Address",
        DefaultValue: "690 Chesterfield Parkway West",
        LocatorParameters: ["SingleLine"],
        LocatorURL: “http://geocode.arcgis.com/arcgis/rest/services/World/GeocodeServer”,
        CandidateFields: “Addr_type,Country,Score,Match_addr”,
        DisplayField: “${Match_addr}”,
        AddressMatchScore: 90,
        LocatorFieldName: ‘Addr_type’,
        LocatorFieldValues: ["StreetName", "PointAddress", "StreetAddress"]
        }]

        • Brad Niemand says:

          Yeah what you did will work for sure if all you care about is matching to those levels. If the country they are in is also important then you will need to modify it further to take into account the value returned from the country.

          Brad

  8. patel_nick says:

    Hello Stefano, and Luciob, could you please email GeocodeQA@esri.com with your problem addresses and issues please – I can’t see what your email address is. It may be that we need to adjust/add to the variations that may exist for some of these popular street names and street types. We’d like a chance to follow up on your queries and improve our geocoding service with your feedback and help. We have also reached out to our Esri Italy team.
    Thanks!

  9. patel_nick says:

    Hi Stefano and Lucio,
    Thank you for your feedback. We acknowledge the issues you’ve reported, and happy to report that the team is working on a fix. We will target releasing a fix to production in 2-3 weeks. Thank you for you alerting us to those issues!

  10. stefano.angarano93 says:

    Thank you. We will wait for the fix!

  11. patel_nick says:

    hi Stefano, thanks for your feedback on the Italian geocoding. Our team has introduced several fixes for Italy that should improve the Italy geocoding experience. Please check it out and let us know what you think!