libpostal
Walla Walla
Libpostal est une bibliothèque C pour analyser / normaliser les adresses de rue dans le monde en utilisant la PNL statistique et les données ouvertes. L'objectif de ce projet est de comprendre les chaînes basées sur la localisation dans chaque langue, partout. Pour un aperçu plus complet de la recherche derrière Libpostal, assurez-vous de consulter les articles de blog d'introduction (longs):
?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
Les adresses et les emplacements qu'ils représentent sont essentiels pour toute demande concernant les cartes (recherche de place, transport, services à la demande / livraison, vérifications, avis). Pourtant, même les adresses les plus simples sont remplies de conventions locales, d'abréviations et de contexte, ce qui les rend difficiles à indexer / interroger efficacement avec les moteurs de recherche en texte intégral traditionnels. Cette bibliothèque aide à convertir les adresses de forme libre que les humains utilisent en formulaires normalisés propres adaptés à la comparaison des machines et à l'indexation du texte intégral. Bien que la libpostal ne soit pas elle-même un géocodeur complet, il peut être utilisé comme étape de prétraitement pour rendre n'importe quelle application géocodante plus intelligente, plus simple et plus cohérente internationale.
?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
La bibliothèque de base est écrite en liaisons linguistiques C. pure pour Python, Ruby, Go, Java, PHP et Nodejs est officiellement prise en charge et il est facile d'écrire des liaisons dans d'autres langues.
Si votre entreprise utilise Libpostal, pensez à demander à votre organisation de parrainer le projet. Interpréter ce que les humains signifient lorsqu'ils se réfèrent à des emplacements est loin d'être un problème résolu, et les parrainages nous aident à poursuivre de nouvelles frontières dans la PNL géospatiale. En tant que sponsor, le logo de votre entreprise apparaîtra en bonne place sur la page GitHub Repo ainsi qu'un lien vers votre site. Informations sur le parrainage
Les utilisateurs individuels peuvent également aider à prendre en charge les recherches sur les PNL en géo en faisant un don mensuel:
Avant d'installer, assurez-vous d'avoir les conditions préalables suivantes:
Sur Ubuntu / Debian
sudo apt-get install curl autoconf automake libtool pkg-config
Sur Centos / Rhel
sudo yum install curl autoconf automake libtool pkgconfig
Sur Mac OSX
brew install curl autoconf automake libtool pkg-config
Ensuite, pour installer la bibliothèque C:
Si vous utilisez un M1 Mac, ajoutez --disable-sse2 à la commande ./configure . Cela entraînera des performances plus faibles, mais la construction réussira.
git clone https://github.com/openvenues/libpostal
cd libpostal
./bootstrap.sh
./configure --datadir=[...some dir with a few GB of space...]
make -j4
sudo make install
# On Linux it's probably a good idea to run
sudo ldconfig
LibPostal soutient PKG-Config, vous pouvez donc utiliser le PKG-Config pour imprimer les drapeaux nécessaires pour lier votre programme contre lui:
pkg-config --cflags libpostal # print compiler flags
pkg-config --libs libpostal # print linker flags
pkg-config --cflags --libs libpostal # print both
Par exemple, si vous écrivez un programme appelé App.c, vous pouvez le compiler comme ceci:
gcc app.c `pkg-config --cflags --libs libpostal`
MSYS2 / Mingw
Pour Windows, la procédure de construction nécessite actuellement MSYS2 et MINGW. Cela peut être téléchargé à partir de http://msys2.org. Veuillez suivre les instructions sur le site Web MSYS2 pour l'installation.
Veuillez vous assurer que MSYS2 est à jour en fonctionnant:
pacman -Syu
Installez les conditions préalables suivantes:
pacman -S autoconf automake curl git make libtool gcc mingw-w64-x86_64-gcc
Ensuite, pour construire la bibliothèque C:
git clone https://github.com/openvenues/libpostal
cd libpostal
cp -rf windows/* ./
./bootstrap.sh
./configure --datadir=[...some dir with a few GB of space...]
make -j4
make install
Remarques: Lors de la définition du datadir, le lecteur C: serait entré en tant que /c . Le script de construction libpostal ajoute automatiquement libpostal à la fin du chemin, donc '/ c' deviendrait C:libpostal sur Windows.
Le .dll compilé sera dans le src/.libs/ répertoire et doit être appelé libpostal-1.dll .
Si vous avez besoin d'une bibliothèque d'importation .lib pour le relier à votre application. Vous pouvez en générer un à l'aide de l'outil Visual Studio lib.exe et du fichier de définition libpostal.def :
lib.exe /def:libpostal.def /out:libpostal.lib /machine:x64
Un autre modèle de données est disponible pour la libpostal. Il est créé par Senzing Inc. pour améliorer l'analyse des adresses américaines, du Royaume-Uni et de Singapour et de l'amélioration de la gestion de l'adresse de l'itinéraire rural américain. Pour activer ce MODEL=senzing à la ligne de conigure pendant l'installation:
./configure --datadir=[...some dir with a few GB of space...] MODEL=senzing
Les données de ce modèle sont obtenues d'OpenAddress, OpenStreetMap et les données générées par Senzing sur la base des commentaires des clients (quelques centaines d'enregistrements), soit un total d'environ 1,2 milliard d'enregistrements de données de plus de 230 pays, en plus de 100 langues. Les données d'OpenStreetMap et d'OpenAddress sont bonnes mais pas parfaites, donc l'ensemble de données a été modifié en filtrant les adresses mal formées, en corrigeant les jetons d'adresse mal classés et en supprimant les jetons qui n'appartenaient pas aux adresses, chaque fois que ces conditions étaient rencontrées.
Senzing a créé un ensemble de données de 12950 adresses de 89 pays qu'il utilise pour tester et vérifier la qualité de ses modèles. L'ensemble de données a été généré à l'aide d'adresses aléatoires à partir de l'OSM, au moins 50 par pays. Les adresses difficiles àars ont été obtenues de l'équipe de support Senzing et des clients et de la page GitHub Libpostal et ajoutée à cet ensemble. Le modèle Senzing a obtenu 4,3% de meilleurs résultats d'analyse que le modèle par défaut, en utilisant cet ensemble de tests.
La taille de ce modèle est d'environ 2,2 Go par rapport à 1,8 Go pour le modèle par défaut, alors gardez cela à l'esprit si l'espace de stockage est important.
De plus amples informations sur ce modèle de données peuvent être trouvées sur: https://github.com/senzing/libpostal-data si vous rencontrez des problèmes avec ce modèle, qu'ils aient à faire des parses, une installation ou d'autres problèmes, puis s'il vous plaît les signaler à https://github.com/senzing
L'adresse internationale de LibPostal utilise l'apprentissage automatique (champs aléatoires conditionnels) et est formé sur plus d'un milliard d'adresses dans chaque pays habité sur terre. Nous utilisons OpenStreetMap et OpenAddress comme sources d'adresses structurées, et les modèles de format d'adresse d'OpenCage à: https://github.com/opencagedata/address-formatting pour construire les données de formation, complétant les polygones contenant et générer des composants de sous-copie tels que l'appartement / les nombres d'étage et les boxes. Nous ajoutons également des abréviations, des composants abandonnés au hasard, etc. pour rendre l'analyseur aussi robuste que possible pour une entrée réelle désordonnée.
Ces exemples de résultats d'analyse sont tirés du programme Interactive Address_Parser qui construit avec LibPostal lorsque vous exécutez make . Notez que l'analyseur peut gérer les virgules vs pas de virgules ainsi que divers boîtiers et permutations de composants (si l'entrée est par exemple, la ville ou simplement la ville / code postal).
L'analyseur atteint une précision très élevée sur les données de maintien, actuellement 99,45% corrects corrects (ce qui signifie un 1 dans le numérateur pour obtenir chaque jeton dans l'adresse correcte).
Voici un exemple de l'API d'analyseur à l'aide des liaisons Python:
from postal . parser import parse_address
parse_address ( 'The Book Club 100-106 Leonard St Shoreditch London EC2A 4RH, United Kingdom' )Et un exemple avec l'API C:
#include <stdio.h>
#include <stdlib.h>
#include <libpostal/libpostal.h>
int main ( int argc , char * * argv ) {
// Setup (only called once at the beginning of your program)
if (! libpostal_setup () || ! libpostal_setup_parser ()) {
exit ( EXIT_FAILURE );
}
libpostal_address_parser_options_t options = libpostal_get_address_parser_default_options ();
libpostal_address_parser_response_t * parsed = libpostal_parse_address ( "781 Franklin Ave Crown Heights Brooklyn NYC NY 11216 USA" , options );
for ( size_t i = 0 ; i < parsed -> num_components ; i ++ ) {
printf ( "%s: %sn" , parsed -> labels [ i ], parsed -> components [ i ]);
}
// Free parse result
libpostal_address_parser_response_destroy ( parsed );
// Teardown (only called once at the end of your program)
libpostal_teardown ();
libpostal_teardown_parser ();
}L'adresse Parser peut techniquement utiliser toutes les étiquettes de chaîne définies dans les données de formation, mais ce sont celles actuellement définies, sur la base des champs définis dans la bibliothèque de format d'adresse d'OpenCage, ainsi que quelques-uns ajoutés par Libpostal pour gérer des modèles spécifiques:
L'API expand_address convertit les adresses réelles désordonnées en équivalents normalisés adaptés à l'indexation de la recherche, au hachage, etc.
Voici un exemple interactif utilisant la liaison Python:
Libpostal contient un classificateur de langue formé OSM pour détecter les langues utilisées dans une adresse donnée afin qu'elle puisse appliquer les normalisations appropriées. La seule entrée nécessaire est la chaîne d'adresse brute. Voici une courte liste de quelques normalisations moins simples dans diverses langues.
| Saisir | Sortie (peut être multiple en libpostal) |
|---|---|
| Cent vingt e 96th st | 120 East 96th Street |
| C / ocho, pi 4 | Calle 8 Polígono Industrial 4 |
| V xx setlembre, 20 | via 20 setlembre 20 |
| Quatre Vingt Douze R. De l'Église | 92 Rue de L eglise |
| ул каретный р д, д 4, строение 7 | улица каретныи ряд дом 4 строение 7 |
| ул каретный р д, д 4, строение 7 | Ulitsa Karetnyy Ryad Dom 4 Strieuiye 7 |
| Marktsstraße 14 | Markt Strasse 14 |
LibPostal prend actuellement en charge ces types de normalisations dans plus de 60 langues , et vous pouvez en ajouter plus (sans avoir à écrire de C).
Pour plus de lecture et des cas de bord d'adresse bizarre, voir: les programmeurs de mensonges croient aux adresses.
Voici un exemple utilisant les liaisons Python pour la succisses (la plupart des liaisons linguistiques de niveau supérieur sont similaires):
from postal . expand import expand_address
expansions = expand_address ( 'Quatre-vingt-douze Ave des Champs-Élysées' )
assert '92 avenue des champs-elysees' in set ( expansions )L'équivalent de l'API C est quelques lignes supplémentaires, mais toujours assez simple:
#include <stdio.h>
#include <stdlib.h>
#include <libpostal/libpostal.h>
int main ( int argc , char * * argv ) {
// Setup (only called once at the beginning of your program)
if (! libpostal_setup () || ! libpostal_setup_language_classifier ()) {
exit ( EXIT_FAILURE );
}
size_t num_expansions ;
libpostal_normalize_options_t options = libpostal_get_default_options ();
char * * expansions = libpostal_expand_address ( "Quatre-vingt-douze Ave des Champs-Élysées" , options , & num_expansions );
for ( size_t i = 0 ; i < num_expansions ; i ++ ) {
printf ( "%sn" , expansions [ i ]);
}
// Free expansions
libpostal_expansion_array_destroy ( expansions , num_expansions );
// Teardown (only called once at the end of your program)
libpostal_teardown ();
libpostal_teardown_language_classifier ();
}Après la construction de libpostal:
cd src/
./libpostal "Quatre vingt douze Ave des Champs-Élysées"
Si vous avez un fichier texte ou un flux avec une adresse par ligne, l'interface de ligne de commande accepte également les entrées de STDIN:
cat some_file | ./libpostal --json
Après la construction de libpostal:
cd src/
./address_parser
Adresse_parser est un shell interactif. Juste les adresses de type et LibPostal les analyseront et impriment le résultat.
La libpostal est conçue pour être utilisée par les langues de niveau supérieur. Si vous ne voyez pas votre langue de choix, ou si vous écrivez une liaison de la langue, faites-le nous savoir!
Liaisons linguistiques officiellement soutenues
Liaisons non officielles
Extensions de base de données
API de repos non officiel
Repos libpostal docker
Libpostal zeromq docker
Libpostal utilise le plus grand pour les tests automatisés. Pour exécuter les tests, utilisez:
make check
L'ajout de cas de test est facile, même si votre C est rouillé / inexistant, et nous aimerions les contributions. Nous utilisons principalement des tests fonctionnels vérifiant l'entrée de chaîne par rapport à la sortie de la chaîne.
Libpostal est également éprouvé périodiquement au combat à des millions d'adresses d'OSM (propre) ainsi que des requêtes anonymisées d'un géocodeur de production (pas si propre). Au cours de ce processus, nous utilisons Valgrind pour vérifier les fuites de mémoire et autres erreurs.
LibPostal doit télécharger certains fichiers de données à partir de S3. Les fichiers de base sont des représentations sur les disques des structures de données nécessaires pour effectuer une expansion. Pour l'analyse d'adresse, puisque la formation du modèle prend quelques jours, nous publions le modèle entièrement formé à S3 et le mettrons à jour automatiquement à mesure que de nouvelles adresses sont ajoutées à OSM, OpenAddress, etc. Il en va de même pour le modèle de classificateur de langue.
Les fichiers de données sont automatiquement téléchargés lorsque vous exécutez la marque. Pour vérifier et télécharger tous les nouveaux fichiers de données, vous pouvez soit exécuter make ou l'exécution:
libpostal_data download all $YOUR_DATA_DIR/libpostal
Et remplacez $ votre_data_dir par tout ce que vous avez passé pour configurer pendant l'installation.
Libpostal contient un certain nombre de dictionnaires permanents qui influencent l'expansion, le classificateur de langue et l'analyseur. Pour explorer les dictionnaires ou apporter des abréviations / phrases dans votre langue, voir les ressources / dictionnaires.
Dans l'apprentissage automatique, de grandes quantités de données de formation sont souvent essentielles pour obtenir de bons résultats. De nombreux projets d'apprentissage automatique open source ne publient que le code du modèle (résultats reproductibles si et seulement si vous êtes Google), soit un modèle pré-cuit où les conditions de formation sont inconnues.
LibPostal est un peu différent car il est formé sur des données ouvertes disponibles pour tout le monde, nous avons donc publié l'intégralité du pipeline de formation (le package Geodata dans ce repo), ainsi que les données de formation qui en résultent sur les archives Internet. Il est plus de 100 Go décompressé.
Les données de formation sont stockées sur archive.org d'ici la date à laquelle ils ont été créés. Il y a également un fichier stocké dans le répertoire principal de ce dépôt appelé current_parser_training_set qui stocke la date de l'ensemble de formation créé dernier. Pour toujours pointer les dernières données, essayez quelque chose comme: latest=$(cat current_parser_training_set) et utilisez cette variable à la place de la date.
Tous les fichiers peuvent être trouvés sur https://archive.org/download/libpostal-parser-training-data-yyymmdd/$file en tant que fichiers gzip'd tab-séparés (tsv) formaté comme: languagetcountrytaddress .
Si l'analyseur ne fonctionne pas aussi bien que vous espériez sur un type d'adresse particulier, le meilleur recours est d'utiliser Grep / awk pour parcourir les données de formation et essayer de déterminer s'il existe un modèle / style d'adresse qui n'est pas capturé.
Expansion de l'abréviation : par exemple, en expansion "rd" => "route" mais pour presque toutes les langues. LibPostal prend en charge> 50 langues et il est facile d'ajouter de nouvelles langues ou d'étendre les dictionnaires actuels. Les langues idéographiques (non séparées par les espaces par exemple chinois) sont soutenues, tout comme les langues germaniques où les types de voies sont concaténés sur la fin de la chaîne, et peuvent être éventuellement séparés, de sorte que Rosenstraße et Rosen Straße sont équivalents.
Parse d'adresse internationale : champ aléatoire conditionnel qui analyse "123 Main Street New York New York" Into {"house_number": 123, "Road": "Main Street", "City": "New York", "State": "New York"}. L'analyseur fonctionne pour une grande variété de pays et de langues, pas seulement nous / l'anglais. Le modèle est formé sur plus d'un milliard d'adresses et de chaînes de type adresse, en utilisant les modèles dans le repo de mise en forme d'adresse d'Opencage pour construire des exemples de transition formatés et étiquetés pour chaque pays habité dans le monde. De nombreux types de normalisations sont effectués pour rendre les données de formation qui ressemblent à une véritable entrée en géocodeur en désordre aussi étroitement que possible.
Classification du langage : régression logistique multinomiale formée (en utilisant la méthode FTRL-proximale pour induire la rareté) sur toutes les voies OpenStreetMap, Addr: * Tags, toponymes et adresses formatées. Les étiquettes sont dérivées à l'aide de tests ponctuels en polygone pour les pays OSM et les langues officielles / régionales pour les pays et les limites de l'administration 1 respectivement. Ainsi, par exemple, l'espagnol est la langue par défaut en Espagne, mais dans différentes régions, par exemple Catalunya, Galice, la région basque, les langues régionales respectives sont la valeur par défaut. La désambiguïsation basée sur le dictionnaire est utilisée dans les cas où la langue régionale n'est pas par exemple gallois, Breton, Occitan. Les dictionnaires sont également utilisés pour abréger les phrases canoniques comme "Calle" => "C /" (effectué à la fois sur le classificateur de langue et les ensembles de formation d'analyse d'adresse)
Analyse d'expression numérique ("Vingt premier" => 21e, "Quatre-Vingt-Douze" => 92, à nouveau en utilisant les données fournies dans CLDR), prend en charge> 30 langues. Gère les langues avec des expressions concaténées par exemple milleottocento => 1800. Normalise éventuellement des chiffres romains quelle que soit la langue (ix => 9) qui se produisent dans les noms de nombreux monarques, papes, etc.
Tokenisation / lexing rapide et précise : Courée à> 1 m de jetons / sec, implémente la spécification TR-29 pour la segmentation des mots UTF8, Tokenise les langues asiatiques de l'Est Chracter par caractère plutôt que sur un espace blanc.
Normalisation UTF8 : Décompose éventuellement le formulaire de normalisation UTF8 à NFD, les bandes accentuer les marques par exemple à => a et / ou applique la translittération latine-ASCII.
Translittération : par exemple, улица => ulica ou ulitsa. Utilise toutes les transformations CLDR, les mêmes données source exactes que celles utilisées par les soins intensifs, bien que LibPostal ne nécessite pas de tir dans toute l'USI (pourrait entrer en conflit avec la version de votre système). Remarque: Certaines langues, en particulier l'hébreu, l'arabe et le thaï, peuvent ne pas inclure de voyelles et ne correspondent donc pas souvent à une translittération faite par un humain. Il peut être possible de mettre en œuvre des translittérateurs statistiques pour certaines de ces langues.
Détection de script : détecte le script qu'une chaîne donnée utilise (peut être multiple par exemple une adresse Hong Kong ou Macao en forme libre peut utiliser les scripts Han et Latin dans la même adresse). Dans la translittération, nous pouvons utiliser tous les translittérateurs applicables pour un script Unicode donné (le grec peut par exemple être translittéré avec le grec-latin, le grec-latin-bgn et le grec-latin-punggn).
LibPostal a été créé à l'origine dans le cadre du projet OpenVENEUES pour résoudre le problème de la déducteur du lieu. Dans les OpenVENUS, nous avons un ensemble de données de millions de places dérivées de téraoctets de pages Web de la frawal commune. La rampe commune est publiée mensuellement, et donc même la fusion des résultats de deux rampes produit des doublons importants.
La déducteur est un domaine relativement bien étudié, et pour des documents texte comme les pages Web, les articles académiques, etc. Il existe des méthodes de similitude approximatives assez décentes telles que Minhash.
Cependant, pour les adresses physiques, l'utilisation fréquente des abréviations conventionnelles telles que Road == Rd, California == CA ou New York City == NYC complique un peu les choses. Même en utilisant une technique comme Minhash, qui est bien adapté aux matchs approximatifs et équivaut à la similitude Jaccard de deux ensembles, nous devons travailler avec des textes très courts et il est souvent le cas que deux adresses équivalentes, une en abrégation et une entièrement spécifiée, ne correspondra pas très étroitement en termes de N-gram settant. Dans les scripts non latins, disons une adresse russe et son équivalent translittéré, il est concevable que deux adresses se référant au même endroit ne correspondent pas même à un seul caractère.
À titre d'exemple de motivation, considérons les deux façons équivalentes suivantes d'écrire une adresse de rue Manhattan particulière avec des conventions et des degrés de verbosité variables:
Évidemment '30 W 26th ST FL # 7! = '30 West Twenty-Sixth Street Floor numéro 7 'dans un sens de comparaison de cordes, mais un humain peut grok que ces deux adresses se réfèrent au même emplacement physique.
LibPostal vise à créer des chaînes géographiques normalisées, analysées en composants, de sorte que nous pouvons raisonner plus efficacement sur la façon dont deux adresses correspondent réellement et prendre des décisions automatisées sur le serveur concernant les dupes.
Si ce qui précède ressemble beaucoup à la géocodage, c'est parce que c'est en quelque sorte, seulement dans le cas des OpenVENUS, nous devons géocoder sans interface utilisateur ou utilisateur pour sélectionner l'adresse correcte dans une liste déroulante Assommée automatique. Compte tenu d'une base de données d'adresses source telles que OpenAddress ou OpenStreetMap (ou la totalité de ce qui précède), LibPostal peut être utilisé pour implémenter des choses comme la déducteur d'adresse et le géocodage par lots côté serveur dans des paramètres tels que MapReduce ou le traitement de flux.
Maintenant, au lieu d'essayer de cuire les conventions spécifiques à l'adresse dans des moteurs de recherche de documents traditionnels comme Elasticsearch en utilisant des fichiers géants synonymes, des scripts, des analyseurs personnalisés, des tokenisers, etc., le géocodage peut ressembler à ceci:
De cette façon, LibPostal peut effectuer une correspondance d'adresse floue en temps constant par rapport à la taille de l'ensemble de données.
Libpostal est écrit en C pour trois raisons (par ordre d'importance):
Portabilité / Ubiquity : LibPostal cible les langages de niveau supérieur que les gens utilisent réellement au quotidien: Python, Go, Ruby, Nodejs, etc. La beauté de C est que presque n'importe quel langage de programmation peut se lier à elle et C compilates C est partout, alors choisissez votre préféré, écrivez un serveur séparé, et vous pouvez utiliser LibPostal directement dans votre application sans avoir à résister à un serveur séparé. Nous prenons en charge Mac / Linux (Windows n'est pas une priorité mais heureux d'accepter les correctifs), nous avons une construction standard AutoTools et un format de fichier en endostic-agnostique pour les fichiers de données. Les liaisons Python sont maintenues dans le cadre de ce référentiel car elles sont nécessaires pour construire les données d'entraînement.
Efficacité de la mémoire : Libpostal est conçu pour s'exécuter dans un paramètre MapReduce où nous pouvons être limités à <1 Go de RAM par processus en fonction de la configuration de la machine. Autant que possible, Libpostal utilise des tableaux contigus, essaie (construit sur des tableaux contigus), des filtres de floraison et des matrices clairsemées compressées pour maintenir l'utilisation de la mémoire faible. Il est possible d'utiliser Libpostal sur un appareil mobile avec des modèles formés sur un seul pays ou une poignée de pays.
Performance : c'est le dernier sur la liste pour une raison. La plupart des optimisations dans la libpostal sont destinées à l'utilisation de la mémoire plutôt qu'à des performances. La libpostal est assez rapide étant donné la quantité de travail qu'elle fait. Il peut traiter 10-30k adresses / seconde dans un seul thread / processus sur les plates-formes que nous avons testées (cela signifie traiter chaque adresse dans OSM Planet en un peu plus d'une heure). Consultez le programme de référence simple pour tester sur votre environnement et divers types d'entrée. Dans le réglage MapReduce, les performances par cœur ne sont pas aussi importantes car tout est fait en parallèle, mais il existe des applications d'ingestion en streaming à Mapzen où cela doit fonctionner en cours.
Libpostal est écrit en moderne, lisible, C99 et utilise les conventions suivantes:
Le package Geodata Python dans le repo libpostal contient le pipeline pour le prétraitement des divers ensembles de données GEO et la création de données d'entraînement pour les modèles C à utiliser. Ce package ne devrait pas être nécessaire pour la plupart des utilisateurs, mais pour ceux qui souhaitent générer de nouveaux types d'adresses ou améliorer les données de formation de LibPostal, c'est là où chercher.
Sur les données de test détenues (c'est-à-dire les analyses étiquetées que le modèle n'a jamais vues auparavant), l'analyseur d'adresse atteint une précision complète de 99,45%.
Pour certaines tâches comme la reconnaissance des entités nommées, il est préférable d'utiliser quelque chose comme un score F1 ou des variantes, principalement parce qu'il y a un problème de biais de classe (la plupart des mots sont des non-entités, et un système qui prédisait simplement la non-entité pour chaque jeton ferait en fait assez bien en termes de précision). Ce n'est pas le cas pour l'analyse d'adresse. Chaque jeton a une étiquette et il y a des millions d'exemples de chaque classe dans les données de formation, donc la précision est préférable car c'est une mesure propre, simple et intuitive des performances.
Ici, nous utilisons la précision complète de l'analyse, ce qui signifie que nous ne donnons à l'analyseur qu'un "point" dans le numérateur s'il obtient chaque jeton dans l'adresse correct. Cela devrait être une meilleure mesure que de simplement regarder si chaque jeton était correct.
Bien que l'analyseur actuel fonctionne assez bien pour la plupart des adresses standard, il y a encore de la place à l'amélioration, en particulier pour s'assurer que les données de formation que nous utilisons sont aussi proches que possible pour les adresses à l'état sauvage. Il existe deux façons principales de l'analyseur d'adresse peut être encore améliorée (par ordre de difficulté):
Les rapports de bogues, les problèmes et les demandes de traction sont les bienvenus. Veuillez lire le guide de contribution avant de soumettre votre problème, votre rapport de bogue ou votre demande de traction.
Soumettez des problèmes à: https://github.com/openvenues/libpostal/issues.
Un merci spécial à @ benk10 pour la version initiale de Windows et @aeroxuk pour l'intégrer parfaitement dans le projet et la mise en place d'une génération d'apptesure.
Le logiciel est disponible en open source en vertu des termes de la licence MIT.
