I've searched for existing concepts to define shortened addresses, but didn't find anything yet that fits my needs.

For an example, I have to define object locations for say desks, where desks are numbered D1..Dn for each floor within a building. I need to geocode and reverse-geocode all such objects.

I could of course carry the whole address for all objects, including street, city, etc. But this is a quite verbose. I'd rather use a shortened unique address identifier.

What concepts of shortened address identifiers do you know, and what are their advantages and disadvantages?

  • Geographically, what is the extent of your area of interest? – artwork21 Jun 28 '16 at 23:35
  • The whole world (literally, planet.osm). – benjist Jun 29 '16 at 8:06
  • 1
    I think you are looking for something like this, what3words, but even more precise than their 3mx3m gird. what3words.com – artwork21 Jun 29 '16 at 11:59
  • 1
    Seems a bit broad to me... are you wanting to implement something into a specific program or are you just working on a concept method? If the former and you are using PostgreSQL to geocode then you can create another table to link to. – kttii Jun 29 '16 at 14:16

Full Disclosure: I'm with the company that offers the BAM solution below.

Asset Location Intelligence, LLC has created the BricksAndMortar(tm) SaaS (Software as a Service), a.k.a. BAM for short, which might be able to be used as a sub-component of a solution for your specific problem space (at the moment, it is USA only expanding to Canada in the next 12 months).

There are several possible ways you can use BAM to create...:

  • A more terse human interpretable path to a specific entity within a building
  • A "hashcode" which points to the entity within a building where part of the hash is human interpretable
  • A "hashcode" which points to the entity within a building where no part of the hash is human interpretable

BAM takes as input a USPS street address. It processes the address by first standardizing it and then verifying it. Once those processes complete successfully, it then composes a response the following data points:

  1. The standardized and verified version of the street address
  2. The input address quality metrics which indicate how far the geocoder had to stretch to find a suitable match
  3. The geohash and GPS coordinates for the resolved address in item 1 - this includes a quality level indicating the accuraty of the GPS coordinate
  4. The AliLocator(tm) which is unique identifier consisting of three components which reflect the structure (building), local-unit (apt, ste, etc.) and street-name-selector (for locations with more than a single street name) - the local-unit and street-name-selector are components are optional

Below are clickable examples of a single street address with various versions of input granularity and various levels of input quality. The requests are sent via URI parameters and the responses are with MIME type "application/json":

  • USPS Standardized and Verified - 716 Lake Carolyn Pkwy Apt 231, Irving, Tx 75039-3988
  • Messy Example A: 716 Lake Carolyn #231, Irving, Tx 75039
  • Messy Example B: 716 Lake Carolyn Parkway # 231, Irving, texas
    • "Pkwy" spelled out, replacing "Apt" with "#", replacing "Tx" with "texas", removing whole zip
    • as TBD...
  • Messy Example C: 716 Lake Carolyn Parkway # 231, 75039
    • replacing "Apt" with "Apartment", removing city, removing state, removing plus Zip4
    • as TBD...

Using the JSON returned for any one of these, there are several different things in the response section to which you could use to create a shortened identifier for the street address subspace.

  • The first and most obvious is to use the AliLocator. The 12 character component represents the structure (building) which is the value "SM0V4TGE2BP9" in the above address. The 10 character component represents the local unit (sub-unit) which is the value "NLARC2UNHP" in the above address. In very rare situations, you might want to use the option 3 character component which represents the street specifier which is the value "ULM" in the above address.
    • The benefits of using the AliLocator is to ensure identity continuity through possible changes in reality like city annexations changing the city name
    • The detriment of using the AliLocator is there isn't any human interpretable or parseable information within any of the components; i.e. they follow a strict identity principle
  • The second option is to use the geohash value.
    • The benefits of using the geohash is it is a spatially unique identifer, it can be used to find "nearby" data clustered by geohash and it overcomes the approximation issues (especially with any sort of equals operation) with using floating point values to represent a GPS coordinate
    • The detriment of using the geohash is it much more likely to change than the AliLocator if/when the quality is elevated via curation and/or the geohash is moved due to a large geological event; i.e. an earthquake shifting an area such that there is more than a couple of centimeters of change to the actual local spatial data from which the GPS coordinate approximation is calculated
  • The third option is to use a compressed version of the USPS canonical version of the address.
    • The benefits of using the compressed address is that it is human interpretable and/or parseable
    • The detriment of using the compressed address is that if/when the address changes due to some sort of event like a city annexation, a street name change (imagine "Main St" changing to "Martin Luther King Blvd") or one of many other issues which includes geocoding vendors having data errors like street name misspellings.

If you think this might be something useful to your project, please contact us or register for a free account which will allow you to directly use the service for a limited number of free lookups each day (which is bounded by UTC 0:00).

Not the answer you're looking for? Browse other questions tagged or ask your own question.