Hay muchos analizadores de direcciones. Vienen en dos sabores básicos: los que tienen bases de datos de nombres de lugares y nombres de calles, y los que no.

Un analizador de direcciones de calle de expresión regular puede obtener una tasa de éxito de hasta un 95% sin muchos problemas. Entonces empiezas a golpear los casos inusuales. El de Perl en CPAN, "Geo:: streetAddress:: US", es sobre eso bueno. Hay puertos Python y Javascript de eso, todos de código abierto. Tengo una versión mejorada en Python que se mueve la tasa de éxito aumentó ligeramente al manejar más casos. Para obtener el último 3% correcto, sin embargo, necesita bases de datos para ayudar con la desambiguación.

Una base de datos con códigos POSTALES de 3 dígitos y nombres y abreviaturas de estados de los Estados Unidos es una gran ayuda. Cuando un analizador ve un código postal y un nombre de estado consistentes, puede comenzar a bloquear el formato. Esto funciona muy bien para los EE.UU. y el Reino Unido.

El análisis correcto de la dirección de la calle comienza desde el final y funciona hacia atrás. Así es como lo hacen los sistemas de USPS. Las direcciones son menos ambiguas al final, donde los nombres de los países, los nombres de las ciudades y los códigos postales son relativamente fáciles de reconocer. Los nombres de las calles generalmente pueden ser aislados. Las ubicaciones en las calles son las más complejas de analizar; allí se encuentran cosas como" Quinto Piso "y"Staples Pavillion". Es entonces cuando una base de datos es una gran ayuda.

Libpostal: una biblioteca de código abierto para analizar direcciones, entrenamiento con datos de OpenStreetMap, OpenAddresses y OpenCage.

Https://github.com/openvenues/libpostal (más información al respecto)

Otras herramientas / servicios:

• Http://www.gisgraphy.com Servicios web de geocodificación y geolocalización gratuitos, de código abierto y listos para usar, que integran OpenStreetMap, GeoNames y Quattroshapes.

• Https://github.com/kodapan/osm-common Biblioteca para acceder a los servicios de OpenStreetMap, analizar y procesar datos.

• Http://wiki.openstreetmap.org/wiki/Nominatim

• Http://address-parser.net/

• Http://geoservices.tamu.edu/Services/AddressNormalization/

ACTUALIZACIÓN: Geocódigo.xyz ahora funciona en todo el mundo. Para ejemplos ver https://geocode.xyz

Para los estados UNIDOS, México y Canadá, ver geocoder.ca.

Por ejemplo:

Entrada: algo está pasando cerca de la intersección de main y arthur kill rd nueva york

Salida:

<geodata>
  <latt>40.5123510000</latt>
  <longt>-74.2500500000</longt>
  <AreaCode>347,718</AreaCode>
  <TimeZone>America/New_York</TimeZone>
  <standard>
    <street1>main</street1>
    <street2>arthur kill</street2>
    <stnumber/>
    <staddress/>
    <city>STATEN ISLAND</city>
    <prov>NY</prov>
    <postal>11385</postal>
    <confidence>0.9</confidence>
  </standard>
</geodata>

También puede comprobar los resultados en la interfaz web o obtener la salida como Json o Jsonp. eg. Estoy buscando restaurantes alrededor de 123 Main Street, Nueva York

¿No hay código? ¡Qué vergüenza!

Aquí hay un simple analizador de direcciones JavaScript. Es bastante horrible por todas las razones que Matt da en su disertación anterior (con la que casi el 100% estoy de acuerdo: las direcciones son tipos complejos, y los humanos cometen errores; es mejor externalizar y automatizar esto, cuando se puede permitir).

Pero en lugar de llorar, decidí intentarlo:

Este código funciona bien para analizar la mayoría de los resultados de Esri para findAddressCandidate y también con algunos otros geocodificadores (inversos) que devuelven dirección de una sola línea donde la calle/ciudad/estado están delimitados por comas. Puede extender si lo desea o escribir analizadores específicos del país. O simplemente use esto como estudio de caso de lo difícil que puede ser este ejercicio o de lo pésimo que soy en JavaScript. Admito que solo pasé unos treinta minutos en esto (las iteraciones futuras podrían agregar cachés, validación zip y búsquedas de estado, así como el contexto de ubicación del usuario), pero funcionó para mi caso de uso: El usuario final ve un formulario que analiza la respuesta de búsqueda geocodificada en 4 cuadros de texto. Si el análisis de direcciones sale mal (lo cual es raro a menos que los datos de origen sean pobres) no es gran cosa - ¡el usuario puede verificarlo y arreglarlo! (Pero para soluciones automatizadas podría descartar / ignorar o marcar como error para que dev pueda admitir el nuevo formato o corregir los datos de origen.)

/* 
address assumptions:
- US addresses only (probably want separate parser for different countries)
- No country code expected.
- if last token is a number it is probably a postal code
-- 5 digit number means more likely
- if last token is a hyphenated string it might be a postal code
-- if both sides are numeric, and in form #####-#### it is more likely
- if city is supplied, state will also be supplied (city names not unique)
- zip/postal code may be omitted even if has city & state
- state may be two-char code or may be full state name.
- commas: 
-- last comma is usually city/state separator
-- second-to-last comma is possibly street/city separator
-- other commas are building-specific stuff that I don't care about right now.
- token count:
-- because units, street names, and city names may contain spaces token count highly variable.
-- simplest address has at least two tokens: 714 OAK
-- common simple address has at least four tokens: 714 S OAK ST
-- common full (mailing) address has at least 5-7:
--- 714 OAK, RUMTOWN, VA 59201
--- 714 S OAK ST, RUMTOWN, VA 59201
-- complex address may have a dozen or more:
--- MAGICICIAN SUPPLY, LLC, UNIT 213A, MAGIC TOWN MALL, 13 MAGIC CIRCLE DRIVE, LAND OF MAGIC, MA 73122-3412
*/

var rawtext = $("textarea").val();
var rawlist = rawtext.split("\n");

function ParseAddressEsri(singleLineaddressString) {
  var address = {
    street: "",
    city: "",
    state: "",
    postalCode: ""
  };

  // tokenize by space (retain commas in tokens)
  var tokens = singleLineaddressString.split(/[\s]+/);
  var tokenCount = tokens.length;
  var lastToken = tokens.pop();
  if (
    // if numeric assume postal code (ignore length, for now)
    !isNaN(lastToken) ||
    // if hyphenated assume long zip code, ignore whether numeric, for now
    lastToken.split("-").length - 1 === 1) {
    address.postalCode = lastToken;
    lastToken = tokens.pop();
  }

  if (lastToken && isNaN(lastToken)) {
    if (address.postalCode.length && lastToken.length === 2) {
      // assume state/province code ONLY if had postal code
      // otherwise it could be a simple address like "714 S OAK ST"
      // where "ST" for "street" looks like two-letter state code
      // possibly this could be resolved with registry of known state codes, but meh. (and may collide anyway)
      address.state = lastToken;
      lastToken = tokens.pop();
    }
    if (address.state.length === 0) {
      // check for special case: might have State name instead of State Code.
      var stateNameParts = [lastToken.endsWith(",") ? lastToken.substring(0, lastToken.length - 1) : lastToken];

      // check remaining tokens from right-to-left for the first comma
      while (2 + 2 != 5) {
        lastToken = tokens.pop();
        if (!lastToken) break;
        else if (lastToken.endsWith(",")) {
          // found separator, ignore stuff on left side
          tokens.push(lastToken); // put it back
          break;
        } else {
          stateNameParts.unshift(lastToken);
        }
      }
      address.state = stateNameParts.join(' ');
      lastToken = tokens.pop();
    }
  }

  if (lastToken) {
    // here is where it gets trickier:
    if (address.state.length) {
      // if there is a state, then assume there is also a city and street.
      // PROBLEM: city may be multiple words (spaces)
      // but we can pretty safely assume next-from-last token is at least PART of the city name
      // most cities are single-name. It would be very helpful if we knew more context, like
      // the name of the city user is in. But ignore that for now.
      // ideally would have zip code service or lookup to give city name for the zip code.
      var cityNameParts = [lastToken.endsWith(",") ? lastToken.substring(0, lastToken.length - 1) : lastToken];

      // assumption / RULE: street and city must have comma delimiter
      // addresses that do not follow this rule will be wrong only if city has space
      // but don't care because Esri formats put comma before City
      var streetNameParts = [];

      // check remaining tokens from right-to-left for the first comma
      while (2 + 2 != 5) {
        lastToken = tokens.pop();
        if (!lastToken) break;
        else if (lastToken.endsWith(",")) {
          // found end of street address (may include building, etc. - don't care right now)
          // add token back to end, but remove trailing comma (it did its job)
          tokens.push(lastToken.endsWith(",") ? lastToken.substring(0, lastToken.length - 1) : lastToken);
          streetNameParts = tokens;
          break;
        } else {
          cityNameParts.unshift(lastToken);
        }
      }
      address.city = cityNameParts.join(' ');
      address.street = streetNameParts.join(' ');
    } else {
      // if there is NO state, then assume there is NO city also, just street! (easy)
      // reasoning: city names are not very original (Portland, OR and Portland, ME) so if user wants city they need to store state also (but if you are only ever in Portlan, OR, you don't care about city/state)
      // put last token back in list, then rejoin on space
      tokens.push(lastToken);
      address.street = tokens.join(' ');
    }
  }
  // when parsing right-to-left hard to know if street only vs street + city/state
  // hack fix for now is to shift stuff around.
  // assumption/requirement: will always have at least street part; you will never just get "city, state"  
  // could possibly tweak this with options or more intelligent parsing&sniffing
  if (!address.city && address.state) {
    address.city = address.state;
    address.state = '';
  }
  if (!address.street) {
    address.street = address.city;
    address.city = '';
  }

  return address;
}

// get list of objects with discrete address properties
var addresses = rawlist
  .filter(function(o) {
    return o.length > 0
  })
  .map(ParseAddressEsri);
$("#output").text(JSON.stringify(addresses));
console.log(addresses);

<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>
<textarea>
27488 Stanford Ave, Bowden, North Dakota
380 New York St, Redlands, CA 92373
13212 E SPRAGUE AVE, FAIR VALLEY, MD 99201
1005 N Gravenstein Highway, Sebastopol CA 95472
A. P. Croll &amp; Son 2299 Lewes-Georgetown Hwy, Georgetown, DE 19947
11522 Shawnee Road, Greenwood, DE 19950
144 Kings Highway, S.W. Dover, DE 19901
Intergrated Const. Services 2 Penns Way Suite 405, New Castle, DE 19720
Humes Realty 33 Bridle Ridge Court, Lewes, DE 19958
Nichols Excavation 2742 Pulaski Hwy, Newark, DE 19711
2284 Bryn Zion Road, Smyrna, DE 19904
VEI Dover Crossroads, LLC 1500 Serpentine Road, Suite 100 Baltimore MD 21
580 North Dupont Highway, Dover, DE 19901
P.O. Box 778, Dover, DE 19903
714 S OAK ST
714 S OAK ST, RUM TOWN, VA, 99201
3142 E SPRAGUE AVE, WHISKEY VALLEY, WA 99281
27488 Stanford Ave, Bowden, North Dakota
380 New York St, Redlands, CA 92373
</textarea>
<div id="output">
</div>

En uno de nuestros proyectos hemos utilizado el siguiente analizador de direcciones. Analiza las direcciones de la mayoría de los países del mundo con buena precisión.

Http://address-parser.net/

Está disponible como biblioteca independiente o como API en vivo.

Si desea confiar en los datos de OSM libpostal es muy potente y maneja muchas de las advertencias más comunes con entradas de direcciones.