opentrep

• The build system is now based on CMake, replacing the GNU Autotools.

• Added pragmas to have the code compatible with the new SOCI v3.1.0 version.
• Removed any reference to ExtraCC

• The search and indexation pieces of algorithm have been completely revamped.
  • Every multi-word string now gives birth to a new C++ structure, namely StringPartition, made of all its partitions in an exhaustive manner. All those string partitions are indexed by Xapian.
  • An independant search is performed on every one of those string partitions.
  • A global match, made of the combination from several match-based pieces of algorithm, is then assigned to every string partition.
  • The best matching string partition is then selected.
  • That new search algorithm allows, among other things, to combine several independent matching methods, including heuristic ones.

• The MySQL database is no longer needed.
• The OPTD-maintained list of POR (points of reference) is now parsed, thanks to Boost.Spirit. A copy of that file is kept under the data/por/ sub-directory.

• Updated the source code to the newest format of the ORI-maintained list of POR.
• Added the Geonames-derived feature names (e.g., "nce city" now returns the POR for the city of Nice, France).

The new slice and dice algorithm seems to work now. More thorough tests are needed.

Fixed a bug hindering the new slice and dice algorithm to fully work. That latter now seems to fully work.

• Issue #1 (http://github.com/trep/opentrep/issues/1): the search algorithm is now modular.
• Issues #3 (https://github.com/trep/opentrep/issues/3) and #5 (https://github.com/trep/opentrep/issues/5): POR are now indexed with their associated PageRank value (equal to 0.1% when there is no PageRank vallue).
• Latest ORI POR data: http://github.com/opentraveldata/optd/blob/trunk/refdata/ORI/ori_por_public.csv

• The SQL database layer has been re-written.
  • A new program, namely opentrep-dbmgr, can now create, update and query the SQL database, which can be SQLite3 or MySQL/MariaDB.
  • There is still some work to do to use the SQL database when only codes are detected within the search string.
• Issue #6 (http://github.com/trep/opentrep/issues/6):
  • Many POR are also indexed with collateral types. For instance, air bases are also indexed as airports.
• Issue #7 (http://github.com/trep/opentrep/issues/7):
  • The punctuation characters are removed. Note that, as the Unicode normalisation procedure is used, there is still an issue when called from Django (for reasons unknown yet).
• Issues #4 (http://github.com/trep/opentrep/issues/4) and #8 (http://github.com/trep/opentrep/issues/8):
  • Fixed the ORI (former name of OPTD) POR data file (now optd_por_public.csv).

• The POR (points of reference) data file has been renamed, from ORI to OPTD, the latter standing for Open Travel Data, i.e., the name of the project maintaining that file. The new location is now https://github.com/opentraveldata/opentraveldata/tree/master/opentraveldata and the file is named optd_por_public.csv.
• When only (IATA, ICAO) codes are used in the query string, the POR are retrieved from the underlying database, when existing (and from the classical free-text search when no database is available).
• The US DOT (Department of Transportation) World Area Codes (WAC) have been added to the POR data file, and is now retrieved by OpenTREP.

The Python libraries are now installed into standard directory

• Support of several deployment stages, allowing staging new versions before activating them in production when cleared by Quality Assurance (QA)
• Full support of MacOS
• Full revamping of the options for the opentrep-{indexer,dbmgr,searcher} command-line programs, supporting server-side deployments
• Full support of the new OpenTravelData (OPTD) data files, which also reference non-IATA POR (points of reference). Hence, ICAO- and UN/LOCODE-referenced POR may now be indexed

Updated the code for the new OpenTravelData (OPTD) data format (Geonames coordinates
have been added)