Address Management

I assume you know your address. But do you realize how often you are asked for that piece of information? And how often have you received mail at your address that was meant for a previous resident? This time I want to discuss some of the issues of managing addresses and how they might be solved using the new buzz: web services.

We came to realize this fact once again upon moving to Redlands. We provided address information Social security, driver’s licenses, visa, utilities, tax, and (to some of our family) more important matters such as cable television and Internet.

For us simple folks, the administrative part of moving to a new address may sometimes be irritating but imagine that you are a utility company, a bank or the Internal Revenue Service. Not knowing where to send your bills or sending bills to the wrong address can result in a considerable loss of revenues.

Being a geographer, knowing where to send a bill is one thing, but knowing where your customers are is another. The well-known process of geocoding allows for geographic analysis that is beyond the extent of address-based analysis.

One of the prerequisites for the results of this analysis to be valuable is that the addresses used are accurate. Not only in the sense that it corresponds to the information that is analyzed, but also that the address actually exists and can therefore be located on the earth’s surface.

After capturing address information by an organization, it also propagates through organizations as part of information exchange, aggregation and reporting to (for example) higher government bodies. At any stage of this process, people verify the validity of address related information before actually using it. There is definitely room for improvement here.

In my last column I discussed software development in relation to geographic information systems. One of the laws of software development states that solving errors early in the development process saves as opposed to solving the problem at the end of the project. The same applies to having correct addresses. Instead of having a multitude of organizations checking the validity of addresses and spending amounts of time in the geocoding process, we could try to start out with correct address information at the source.

Those of you, who have actually set up a geocoding function, know that it uses a geographic dataset with street information and address ranges. And you also know that this dataset needs to be maintained as new streets get created on almost a daily basis. The decision for what area the street dataset is acquired and maintained greatly affects the cost of the geocoding function.

With the introduction of web services such as ArcWeb from ESRI, it is now possible to offer a high quality geocoding function at a low cost for organizations. The cost associated with maintaining the dataset is shared between a large number of users.

Applications pass an address to the geocoding web service and the result, consisting of a geographic location, a standardized (!) address and possibly a map of the surroundings of the address are returned to the applications. This is all done through agreed upon web interfacing standards, including as XML, SOAP, WSDL and UDDI. If necessary, the requests and results transmitted through the web can be encrypted when address information is considered sensitive information and privacy should be protected. Using an application independent transaction identifier, privacy protection can be enhanced even more.

Equipped with this new web service, the utility companies and all the other organizations can stop guessing who is living in my house, resulting in a better cost-benefit balance for them and less unwanted mail for me. Sounds like one of those win-win situations we’re all waiting for.

Appeared in GeoInformatics Magazine (www.geoinformatics.com) in October/November 2002

Directions web service arrives at Google I/O

Google I/O is always a fantastic opportunity for the Maps API team to meet face to face with some of the many Maps API developers worldwide. We believe our developer community is one of the biggest strengths of the Google Maps API, and with over 350,000 web sites actively using the Maps API, there is no shortage of skilled and helpful expertise to tap into.

However Google I/O is not the only way in which we engage with developers. The Google Maps API Google Groups are thriving communities and many of us on the Maps API team enjoy listening and engaging in discussions held on these Groups. In addition we also have the Google Maps API Issue Tracker, a tool with which any Maps API developer can report problems with the API, suggest new features that they would benefit from, or star existing issues or features.

The Google Maps API team takes the problems and ideas featured on the Issue Tracker very seriously, and although we can not always address every issue that is raised, we do consider any that attract a lot of stars. Recently one feature request in particular has been head and shoulders above the rest in terms of the number of stars it has attracted. It therefore only seems appropriate today, as we sit down with our developer community for a Fireside Chat, that we respond to that request by launching a Directions Web Service.

The Directions Web Service is a companion to the existing Geocoding and Elevation Web Services, and allows applications to obtain Driving, Bicycling, and Walking directions through an XML/JSON REST interface. All of the features of the Map API v3 Directions service are supported, including “avoid highways”, “avoid tolls”, and waypoint optimization (travelling salesman solver). For more information, check out the Directions Web Services documentation.

If you have a great idea for a new Maps API feature, please don’t hesitate to submit it to the Issue Tracker. If your idea proves to be popular, we’ll do our best to make it a reality.

Posted by Thor Mitchell, Maps API Product Manager