Following in the footsteps of the increasingly successful Open Street Map project, OpenAddresses.org has been launched as a web portal for the management of free and open address data, plus free and open geocoding and reverse geocoding. OpenAddresses.org includes actual address data, so it is much finer grained than the similar GeoNames.org database which is limited to places. OpenAddresses.org is intended to be complementary to Open Street Map and not in competition.

I suspect OpenAddresses.org will have data completeness problems: Can it guarantee that it has all (or a reasonably high percentage of all) of the street addresses for a particular area?  Will people delete their own addresses for privacy?

Further information can be found at the Open Addresses User Guide Wiki. We already have a technical overview of GeoNames.org due for publication in the next couple of weeks, and will publish a full overview of OpenAddresses.org in the next couple of months.

This article was previously published on GeoChalkboard, and has been reproduced here with permission. GeoChalkboard is published by Geospatial Training Services who provide a range of geospatial web courses.

Google Maps provides a web mapping application wherein maps are produced in advance and served as a set of small tiles for assembly into one big image in the browser. The advantage of this approach is consistency of appearance and graphical quality of the map and, probably more important, enormous scalability that can be achieved. There is no need for server side processing to generate maps and individual map tiles are much smaller than the whole map presented at the user end, so they are able to be delivered and displayed much faster. The trade off is a big effort up front to generate nice looking maps and the need to fix zoom levels rather than allowing a continuous zoom, as is the case with older web mapping technologies. The approach has been copied by other online map technology providers. But what approach should you take if you’d like to present your own custom data on top of a Google Maps base layer without using markers, polylines, or polygons? Perhaps you have a large dataset stored in a shapefile and you’d simply like to convert this data to a format suitable for display in Google Maps. In this case it would make sense to pre-create custom map tiles of your data at various zoom levels and have them available for display.

Google have just announced a new Geocoding Web Service that implements improvements of version 3 of their Google Maps API. These improvements include a flatter response format that is easier to parse; ability to tag address components; support for full names and abbreviations;ability to differentiate between rooftop and interpolated results; and support for bounding boxes and recommended viewports for each result.

The Geocoding Web Service is also intended to enable pre-caching of results. Ie. you can locally store your geocoded lookups for efficiency. However in the Terms & Conditions, Google restrict this function so that you are only allowed to display cached results (or data derived from them) on a Google Map or Google Earth display.

A Google Maps API key is also no longer required, but requests are limited to 2500 per IP address per day.

Freeing up the conditions regarding data caching is a step in the right direction, but many users will find the limitations of display application and requests per day to be too limiting.