Gathering detailed insights and metrics for pelias-parser
Gathering detailed insights and metrics for pelias-parser
Gathering detailed insights and metrics for pelias-parser
Gathering detailed insights and metrics for pelias-parser
npm install pelias-parser
Module System
Min. Node Version
Typescript Support
Node Version
NPM Version
55 Stars
268 Commits
28 Forks
11 Watching
10 Branches
21 Contributors
Updated on 26 Nov 2024
JavaScript (97.78%)
HTML (1.91%)
Shell (0.21%)
Dockerfile (0.09%)
Cumulative downloads
Total Downloads
Last day
130%
46
Compared to previous day
Last week
40.2%
129
Compared to previous week
Last month
-0.9%
426
Compared to previous month
Last year
23.5%
10,647
Compared to previous year
Pelias is a geocoder powered completely by open data, available freely to everyone.
Local Installation · Cloud Webservice · Documentation · Community Chat
A natural language classification engine for geocoding.
This library contains primitive 'building blocks' which can be composed together to produce a powerful and flexible natural language parser.
The project was designed and built to work with the Pelias geocoder, so it comes bundled with a parser called AddressParser
which can be included in other npm project independent of Pelias.
It is also possible to modify the configuration of AddressParser
, the dictionaries or the semantics. You can also easily create a completely new parser to suit your own domain.
30 w 26 st nyc 10010
(0.95) ➜ [
{ housenumber: '30' },
{ street: 'w 26 st' },
{ locality: 'nyc' },
{ postcode: '10010' }
]
You can access the library via three different interfaces:
javascript
via npm
command line
via the node bin/cli.js
scriptweb service
via the node server/http.js
scriptthe web service provides an interactive demo at the URL
/parser/parse
A quick and easy way to get started with the library is to use the command-line interface:
node bin/cli.js West 26th Street, New York, NYC, 10010
Please refer to the CLI screenshot above for a visual reference.
Tokenization is the process of splitting text into individual words.
The splitting process used by the engine maintains token positions, so it's able to 'remember' where each character was in the original input text.
Tokenization is coloured
blue
on the command-line.
The most primitive element is called a span
, this is essentially just a single string of text with some metadata attached.
The terms word
, phrase
and section
(explained below) are all just ways of using a span
.
Some parsers like libpostal ignore characters such as comma
, tab
, newline
and quote
.
While it's unrealistic to expect commas always being present, it's very useful to record their positions when they are.
These boundary positions help to avoid parsing errors for queries such as Main St, East Village
being parsed as Main St East
in Village
.
Once sections are established there is no 'bleeding' of information between sections, avoiding the issue above.
Each section is then split in to individual words
, by default this simply considers whitespace as a word boundary.
As per the section
, the original token positions are maintained.
May terms such as 'New York City' span multiple words, these multi-word tokens are called phrases
.
In order to be able to classify phrase
terms, permutations of adjacent words are generated.
Phrase generation is performed per-section, so it will not generate a phrase
which contains words from more than one section
.
Phrase generation is controlled by a configuration which specifies things like the minimum & maximum amount of words allowed in a phrase
.
A graph is used to associate word
, phrase
and section
elements to each other.
The graph is free-form, so it's easy to add a new relationship between terms in the future, as required.
Graph Example:
1// find the next word in this section 2word.findOne('next') 3 4// find all words in this phrase 5phrase.findAll('child')
Classification is the process of establishing that a word
or phrase
represents a 'concept' (such as a street name).
Classification can be based on:
Classification is coloured
green
andred
on the command-line.
The library comes with three generic classifiers which can be extended in order to create a new classifier
:
The library comes bundled with a range of classifiers out-of-the box.
You can find them in the /classifier
directory, dictionary-based classifiers usually store their data in the /resources
directory.
Example of some of the included classifiers:
1// word classifiers 2HouseNumberClassifier 3PostcodeClassifier 4StreetPrefixClassifier 5StreetSuffixClassifier 6CompoundStreetClassifier 7DirectionalClassifier 8OrdinalClassifier 9StopWordClassifier 10 11// phrase classifiers 12IntersectionClassifier 13PersonClassifier 14GivenNameClassifier 15SurnameClassifier 16PersonalSuffixClassifier 17PersonalTitleClassifier 18ChainClassifier 19PlaceClassifier 20WhosOnFirstClassifier
Solving is the final process, where solutions
are generated based on all the classifications that have been made.
Each parse can contain multiple solutions
, each is provided with a confidence
score and is displayed sorted from highest scoring solution to lowest scoring.
The core of this process is the ExclusiveCartesianSolver
module.
This solver
generates all the possible permutations of the different classifications while taking care to:
span
position is not used more than onceclassification
is not used more than once.After the ExclusiveCartesianSolver
has run there are additional solvers which can:
solutions
to remove inconsistenciessolutions
to provide additional functionality (such as intersections)It is possible to produce a simple mask
for any generated solution, this is useful for comparing the solution
to the original text:
1VVV VVVV NN SSSSSSS AAAAAA PPPPP 2Foo Cafe 10 Main St London 10010 Earth
Please fork and pull request against upstream master on a feature branch. Pretty please; provide unit tests.
You can run the unit test suite using the command:
1$ npm test
CI tests every release against all supported Node.js versions.
We rely on semantic-release and Greenkeeper to maintain our module and dependency versions.
No vulnerabilities found.
Reason
no dangerous workflow patterns detected
Reason
no binaries found in the repo
Reason
0 existing vulnerabilities detected
Reason
license file detected
Details
Reason
Found 15/24 approved changesets -- score normalized to 6
Reason
0 commit(s) and 3 issue activity found in the last 90 days -- score normalized to 2
Reason
detected GitHub workflow tokens with excessive permissions
Details
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
project is not fuzzed
Details
Reason
security policy file not detected
Details
Reason
dependency not pinned by hash detected -- score normalized to 0
Details
Reason
SAST tool is not run on all commits -- score normalized to 0
Details
Score
Last Scanned on 2024-11-18
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More