-
-
Notifications
You must be signed in to change notification settings - Fork 5
/
NEWS
179 lines (151 loc) · 5.82 KB
/
NEWS
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
* 2024-03-23:
- Version 0.07.15
- Upgraded a few CMake support files
* 2023-12-02:
- Version 0.07.14
- Upgraded a few CMake support files
* 2023-05-01:
- Version 0.07.13
- Upgraded a few CMake support files
* 2022-11-30:
- Version 0.07.12
- Fixed deprecated Boost.Phoenix/Boost.Spirit header
* 2022-06-26:
- Version 0.07.11
- Added support for Python 3.11
* 2021-08-15:
- Version 0.07.10
- Fixed an Boost.Spirit issue having appeared with Boost 1.76.
There is still an issue with Boost.Python, at least on MacOS.
The support for Unicode may have been dropped.
* 2021-06-26:
- Version 0.07.9
- Upgraded a few CMake support files
* 2021-06-23:
- Version 0.07.8
- Added support for Python 3.10
* 2020-05-30:
- Version 0.07.7
- The non-Python libraries are not longer linked against Python ones
* 2020-05-16:
- Version 0.07.6
- Improved how the Python module is delivered
* 2020-03-02:
- Version 0.07.5
- Updated the code for the new OPTD data format (Geonames coordinates
have been added)
* 2019-11-10:
- Version 0.07.4
- FindBoost.cmake now supports older CMake versions
* 2019-09-28:
- Version 0.07.3
- OPENTREP_SAMPLE_DIR is now exported
* 2019-09-28:
- Version 0.07.2
- Merged the trunk and releases branches to master, so as to get
a standard setup
- The default branch is now master
- The versionning scheme follows the one on the releases branch before,
i.e., the version number is incremented just before tagging
the Git repository
* 2019-01-16:
- Version 0.07.1
- Improved the release of Python libraries and scripts (e.g.,
following Fedora packaging guidelines, and it works well
with `pipenv`)
* 2018-10-14:
- Version 0.07.0
- Support of several deployment stages (allowing staging new versions
before activating them in production when QA-cleared)
- 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 data files, which also
reference non-IATA POR (points of reference). Hence, ICAO-
and UN/LOCODE-referenced POR may now be indexed
* 2015-06-28:
- Version 0.06.6
- The Python libraries are now installed into standard directory
* 2015-04-19:
- Version 0.06.5
- The POR reference data file has been renamed, from ORI
to OPTD (standing for Open Travel Data, i.e., the name of the
project maintaining that file). The new location is now
http://bit.ly/1FXmQdl, 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 World Area Code (WAC) has been added to the POR
reference data file, and is now retrieved by OpenTREP.
* 2014-04-13:
- Version 0.06.1
- Re-wrote the SQL database layer. A new program, namely
opentrep-dbmgr, to 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 POR data file
(http://github.com/opentraveldata/optd/refdata/ORI).
* 2014-02-01:
- Version 0.06.0
- Issue #1 (http://github.com/trep/opentrep/issues/1):
The search algorithm is now modular.
- Issues #3 (http://github.com/trep/opentrep/issues/3)
and #5 (http://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
* 2013-03-10:
- Version 0.05.3
- Fixed a bug hindering the new slice and dice algorithm to fully work.
That latter now seems to fully work.
* 2013-02-16:
- Version 0.05.2
- The new slice and dice algorithm seems to work now. More thorough tests
are needed.
* 2013-02-16:
- Version 0.05.1
- 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).
* 2012-10-14:
- Version 0.05.0
- 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. And 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 independant matching methods, including heuristic ones.
- The MySQL database is no longer needed. The ORI-maintained list of POR
(points of reference) is now parsed, thanks to Boost.Spirit v2.
A copy of that file is kept under the data/por/ sub-directory.
* 2011-11-12:
- Version 0.04.1
- Added pragmas to have the code compatible with the new Soci-3.1.0 version
- Removed any reference to ExtraCC
* 2011-11-01:
- Version 0.04.0
- The build system is now based on CMake (instead of the GNU Autotools)
* 2009-03-29:
- Version 0.03.0
- Now relies on the new SOCI RPM
* 2009-03-22:
- Version 0.02.0
- RPM release for Fedora 10