Skip to content

Releases: pelias/api

v3.1.0

05 Aug 19:17
Compare
Choose a tag to compare

<a name"3.1.0">

3.1.0 (2016-08-05)

Features

  • Add categories filter param and /nearby endpoint (c5eb71f4)

v3.0.2

03 Aug 18:36
Compare
Choose a tag to compare

<a name"3.0.2">

3.0.2 (2016-08-03)

Bug Fixes

  • URL for Gitter does not appear correctly on NPM (6cde730e)

v3.0.1

28 Jul 23:16
Compare
Choose a tag to compare

<a name"3.0.1">

3.0.1 (2016-07-28)

Bug Fixes

  • remove version from package.json (63d73f99)

Address Parsing

23 Jul 19:34
Compare
Choose a tag to compare

Address parsing is huge for an address geocoder and this release takes a first crack at it using AddressIt module. AddressIt is a freeform street address parser, that is designed to take a piece of text and convert that into a structured address that can be processed in different systems.

> var addressit = require('addressit')

> addressit('123 main st new york ny 10010 usa')
{ text: '123 main st new york ny 10010 usa',
  parts: [],
  unit: undefined,
  number: 123,
  street: 'main st',
  state: 'NY',
  country: 'USA',
  postalcode: 10010,
  regions: [ 'new york' ] }

Before the pelias API calls addressit for address parsing, it does some basic checks by parsing query to ensure that we dont slow things down drastically when unnecessary for example the following are the cases where we dont need address parsing -

  • input=a or input=au or input=aus - if the input has 3 or less characters, we could assume its not a fully formed address, in fact - we can go one step further by only targeting admin layers because if we return results such as austin, australia etc it should be relevant but more importantly fast.
  • input=boston or input=frankfurt or input=somereallybigname or input=new york - if the input is just one or even two tokens and does not contain a number - we can get away with just targeting admin and poi layers

In all other cases, we do address parsing and handle the address parts to query the ES index. Here's a sample mapping

number + street -> name.default
number -> address.number
street -> address.street
postalcode -> address.zip
state -> admin1_abbr
country -> alpha3
regions -> admin2

Sometimes, the address parser comes back empty handed

> addressit('123 chelsea, london')
{ text: '123 chelsea, london',
  parts: [],
  unit: undefined,
  state: undefined,
  country: undefined,
  postalcode: undefined,
  regions: [ '123 chelsea', 'london' ] }

In this case, we take fall back to the naive approach we implemented months ago - where we split the address based on a comma and assume everything that follows the comma is an admin part and add a match block in the should array. So, we query name.default with 123 chelsea and the should array in the query would try to match london with all the 5 admin fields

  • admin0
  • admin1
  • admin1_abbr
  • admin2
  • alpha3

All of this logic lives in helper/query_parser.js and is well documented with in-line comments. The query changes can be seen in query/search.js.

An additional 104 test cases were written to test out all the above mentioned logic and to test the query building - bringing the grand total of unit tests for the API to 708!

Deleting code is so much fun

21 Jul 14:31
Compare
Choose a tag to compare

Code cleanup - deleted all suggester related code (843 deletions) FTW!
Tech Debt - Better 408/500 error handling

Minor cleanup -> minor speedup

21 Jul 14:26
Compare
Choose a tag to compare

Minor cleanup, minor speedup and minor performance improvement - brought to you by:

  • removed exact_match script
  • increased search radius to 500kms

NGRAMS

21 Jul 14:23
Compare
Choose a tag to compare

This release is a big one, we are using ngrams to analyze/tokenize & are officially moving away from using the context suggester that is memory intensive and wasn't letting us build an autocomplete suggester on a global scale

Some major Features:

category scoring, bbox format change, fix JSONification bug

06 May 20:25
Compare
Choose a tag to compare

Minor improvements/bugfixes:

  • change the API bbox parameter format to a more conventional format (#117)
  • fix a bounding-box runtime error (#124)
  • boost records belonging to certain feature categories (#106)

Better index page and details parameter

28 Apr 15:46
Compare
Choose a tag to compare

This release includes the following improvements:

  • All endpoints support a details parameter. When details=true all available properties are returned. When details=false only id,layer, and text are returned.
  • /reverse endpoint supports a parameter called categories, which allows reverse searching for POI's of specified types. The categories feature is in ALPHA and will probably change in the near future.
  • API index page shows API documentation for all available endpoints when requested with Accepts:html header.
  • /suggest/coarse endpoint has been fixed to only use admin layers.
  • Cleaner runtime error reporting and a few other minor things.

General Enhancements and Bug fixes

09 Apr 17:45
Compare
Choose a tag to compare

This release fixes a few bugs and adds a couple of new features/ enhancements

  1. New: Ability to search/filter on localities and local_admin layers &layers=locality
  2. New: API now uses the optimized bbox query which cuts down the response times by one third.
  3. Bug Fix: Filtering by layer is now working on all endpoints (/suggest, /search, /reverse)
  4. Bug Fix: No Internal server errors when you pass in lat=0 and lon=0