Ervin Ruci

3geonames.org is a free api for fast reverse geocoding, using a new technique of locality-preserving hashing of 2d/3d spatial points to 1d integers via a combination of Hilbert curve and bit interlacing. This talk expands on the use-case and the performance/accuracy advantages of this technique. (The talk slides will be available at: https://3geonames.org/prizren.html )

https://api.3geonames.org/ Fast Reverse Geocoder Lite - A simple but fast reverse geocoding API up to city/neighborhood granularity level. Convert a geographic coordinate (latitude and longitude) into city, neighborhood name, wikipedia, wikidata, geocode, elevation, timezone, country, region and OSM tags. Generate a truly random location anywhere on Earth; or in a particular country. Get locality results in either XML or JSON. This reverse geocoding API is ideal for applications which process location data (for example mobile GPS data) and need to correlate this quickly with real place names. It takes as input a Latitude, Longitude pair, and outputs either XML (default) or JSON text with the name of the nearest city/neighborhood and other regional information based on both Geonames.org and OpenStreetMap.org regional/city/neighborhood polygons. Send a reverse geocoding request as per API spec: /latitude,longitude e.g., https://api.3geonames.org/51.4647,0.0079 (XML output - Default) or https://api.3geonames.org/51.4647,0.0079.json (JSON output) Other API Functions Pick a random location at or near land: http://api.3geonames.org/randomland Pick a random location anywhere: http://api.3geonames.org/random - (Note: Since the earth is mostly Ocean, most returned results will have no placename reverse geocoding responses, only latitude,longitude, geocode, geonumber and threegeonames) Pick a random location in a give country (eg., Germany - DE): http://api.3geonames.org/randomland.DE (XML Default)- http://api.3geonames.org/randomland.DE.json (JSON)

Encoding geographic coordinates into a string is a trivial thing. Yet, there are many grid based systems (geohash, PlusCodes, Mapcodes), and some even turn the thing into a business (Zippr, What3Words). I agree with the commonly stated motivation that Latitude and Longitude are not sufficient for identifying a place in both an unambiguous and human friendly way. A single string for this pair of numbers is a better representation, if only it can preserve all the information contained in the original latitude,longitude pair, something no existing geo-encoding system does. That's my goal.

Geocode is a one-dimensional location code. It uses a simple space-filling technique to map a two dimensional point (latitude,longitude) to either an alphanumeric string or a geoname triple with no loss of information. It is a one-to-one mapping (no two geocodes map to the same point and no two points map to the same geocode).

Geocode has several advantages over similar systems.

The alphanumeric geocode is short (10 bytes), has higher accuracy (up to 1 meters) and avoids the borderline discontinuities and many to one mappings of other one-dimensional location codes such as geohashes.

Triple geoname codes on the other hand are more memorizable, are intuitively reprentative of the location and are composed of relatively short existing geo names (up to 8 letters).

The first name in a triple geoname code represents the most prominent location name inside a 21,403 km² area containing the point.

For example, 34.05223,-118.24368 (a location in Los Angeles), is encoded to EKEAJ18E08 or as three geonames: LA-GASPAR-YANSI or as a hybrid code LA-MJKQH4. Another location about 1 m away, say (34.05223,-118.24369), is EKEAJ18E1D or LA-GASPAR-HINGWEN or LA-MJKQI9.

The human readable algorithm uses 146300 geonames from http://geonames.org and http://geonames.nga.mil/gns/html/gis_countryfiles.html with several requirements for the names (chosen to be recognizable, short, easy to pronounce, distinct from each other and evenly spread throughout the earth.) We also shorten geonames to their acronyms whenever possible (LA -> Los Angeles, NY -> New York, etc)

Unlike many grid-based location codes, geocodes represent points not areas. Each geocode maps to a latitude,longitude pair with accuracy up to the 5th decimal point (i.e. 1 meter)

In a nutshell, latitude,longitude values are represented as two linear curves, converted to binary numbers then combined by interleaving their bits. As a result of this technique, similar geocodes are located geographically close together in both alphanumeric and triple geoname formats.

A geolocation expressed as (latitude,longitude) can be converted offline into a geocode, and vice versa using a data structure embeded in the software.

The software is in the public domain to be used without any restrictions.

Geocoding is the bridge that links location strings to points on a map. This talk will discuss the state of opensource and commercial geocoders, then provide a solution based on the openaddresses.io data repo running on a free micro instance on the Amazon Cloud.

Geocoding, as an information retrieval process, is divided into Forward Geocoding (a location described in words into a latitude,longitude point) and Reverse Geocoding (a point into a location description).

Ever since the advent of the online map, this problem has attracted considerable attention. The main players today are commercial vendors such as Google Maps. Open source alternatives have usually fallen short (for eg, Openstreetmap's Nominatim). In fact all geocoders (commercial and free) fall short in various ways as I will demonstrate in this talk.

I'll also demonstrate how you can build your own geocoder if the data is available. I've built my own over the last 11 years (written in ModPerl) and you can too (in your language of choice) using openaddresses.io, the free and open global address collection, which currently provides over 200 Million addresses.

My solution runs on minimal resources (just 1G or Ram and 1 vCpu on a free micro instance) and may be a bit slow, if you need performance get a faster server. I'll also show how to extract and standardize addresses from bodies of text very quickly, regardless of the amount of text.