So an adresse like "PARC D ACTIVITE DE SAUMATY 26 AV ANDRE ROUSSIN 13016 MARSEILLE 16" will no be extracted (av => avenue).

Phonem algo is guilty.

La question " 2719 route de neufchatel 76230 Bois-guillaume " retourne une réponse housenumber
La question " 2909 route de neufchatel 76230 Bois-guillaume " ne retourne rien

A défaut de connaitre le 2909 addok ne devrait-il pas retourner la rue ?

Merci

HP

Le géocodage du 15 route de Saint Romain 76430 La Cerlangue propose

1. Route de la Cerlangue 76430 Saint-Romain-de-Colbosc 💣

2. Route de Saint-Romain 76430 La Cerlangue

   😰

http://api.adresse.data.gouv.fr/search
/?q=15%20route%20de%20saint%20romain%2076430%20La%20Cerlangue&limit=3

"21 RUE CLEF 34 RUE DAUBENTON" matches "21 rue Daubenton"
http://api.adresse.data.gouv.fr/search/?q=21%20RUE%20CLEF%2034%20RUE%20DAUBENTON,%2075005,%20Paris,%20France&limit=1

I think detecting only matching one of the two addresses would return a correct result. The tricky part is going to separate both addresses I guess... Not sure there is a proper solution, considering street names may contain numbers.

Tested on http://adresse.data.gouv.fr/map/ :
'Y' in the input search gives 0 suggestion and pressing 'Enter' does not trigger anything.
Expected result : http://www.openstreetmap.org/relation/909020

If there is a line with no data, nothing happend, and no error is raised.
test with :

NOM;NUM;RUE;CODE POSTAL;VILLE
;;;;

if there is a something in a column, it's working, unless you don't select this column:

NOM;NUM;RUE;CODE POSTAL;VILLE
XXX;;;;

• select all columns : it work
• don't select column NOM: it didn't work

For example "Les Cotes 74 Seyssel".

We expect "64 allée de bercy" to be found, but "barcy" results are given priority.

Le lien vers nominatim dans le README est cassé !

D'ailleurs si vous pouviez m'expliquer : Nomitatim étant l'API d'openstreetmap, et bano étant composé des données d'OSM + cadastre (+ autre sources ? ) a quoi ça sert d'importer la base nominatim ?
Car si j'ai bien compris BANO est sensé être plus complet qu'osm .

Merci

This is a problematic use case I have in my radar from the beginning, but let's put an issue to track it.

Searching for "rue de" takes ages, and this is why:

• "rue" and "de" are two of the most common tokens of the index (rue: 593 129 documents, de: 2 012 949 documents), so Redis needs to loop over all documents to issue the intersection (and SUM the score), because it order results by score (SUM of all score from all set being intersected)
• when in autocomplete mode, we can't fallback to autocomplete because we only autocomplete starting at 3 chars
• when giving a center to the search, that helps, but our geohash are a bit too small and so often they do not contain enough results

The fact is that "rue de" is the start of many many roads names in French speaking countries, and so it's a very common use case in autocomplete mode.

There are some possible options to improve the situation:

• have bigger geohash (we are at level 8, move to level 7), but this will only work in some situations
• have some "bigram" index, a relation word1 + word2 => document id; in this case Redis will only need to take the x documents with the better score, so this will be very very fast; but in the same time, it will make the index much much bigger; and this will not solve the "rue de saint" issue, which si roughly the same case but with one more common terms
• start autocompleting at 2 instead of 3 chars, but this also means a bigger index, given that we also need to index edge ngrams starting at 2 instead of 3
• do not issue search with only common terms if no center is given; very user unfriendly

What should be a pragmatic approach would be to find a way to ask redis not to score the results while intersecting and to return the first x matchs, but at the moment I don't know how to issue such a query. Maybe Lua can come to the rescue here. Or we can issue a manual scan in the hope we will find very quickly results.

Maybe a base image and an image with already the data.

Bonjour,

si je cherche
api.adresse.data.gouv.fr/search/?q=30%20bis%20rue%20brisout%20de%20barneville%2076000%20Rouen&limit=1

j'obtiens

"label": "30bis Rue Brisout de Barneville 76000 Rouen",
"score": 0.896...,
"query": "30 bis rue brisout de barneville 76000 Rouen"

si je cherche avec la forme suggérée par la réponse
api.adresse.data.gouv.fr/search/?q=30bis%20rue%20brisout%20de%20barneville%2076000%20Rouen&limit=1

j'obtiens paradoxalement un score plus faible

"label": "30bis Rue Brisout de Barneville 76000 Rouen",
"score": 0.867...,,
"query": "30bis rue brisout de barneville 76000 Rouen",

Plus étonnant encore, si je cherche
api.adresse.data.gouv.fr/search/?q=30bis%20rue%20brisout%20de%20barneville%2076100%20Rouen&limit=1
le score remonte alors que selon les termes de la réponse je m'en suis éloigné en demandant le ZIP 76100 dans la question.

"label": "30bis Rue Brisout de Barneville 76000 Rouen"
"score": 0.875

Partagez-vous la suite de mon étonnement si je demande
api.adresse.data.gouv.fr/search/?q=30%20bis%20rue%20brisout%20de%20barneville%2076100%20Rouen&limit=1
et que je constate

"label": "30bis Rue Brisout de Barneville 76000 Rouen"
"score": 0.820

Synthèse

Nota :

Dans tous les cas, le ZIP de la réponse est faux.

Questions

1. Pourquoi la question la plus proche du label de réponse n'a-t-elle pas le score le plus élevé ?
2. Pourquoi demander 30bis / 76100 est mieux noté que 30bis/76000 ?
3. Pourquoi un tel écart entre 30 bis / 76000 et 30 bis / 76100 ?
4. Pourquoi le score plafonne-t-il à 0.90 ? Même avec un lon/lat on gagne peu très peu.

Hypothèse :

dans le jeu de données initial le ZIP associé à la voie est erroné:
Dans le json de BANO on trouve 76000 semble-t-il. Pas trouvé ce qui explique le score relatif du 76100 !

Bien cordialement, HP

Bonjour,

périphérique henri wallon 76800 Saint-etienne-du-rouvray est une voie connue dans OSM ( http://www.openstreetmap.org/#map=18/49.39412/1.07099 )

On note que cette voie ne comporte pas de numéro de voies.

Dans addok, la recherche périphérique henri wallon 76800 Saint-etienne-du-rouvray ne retourne rien. Est-ce un soucis d'alimentation d'addok ?

La question de pouvoir interroger tour tourmalet périphérique henri wallon 76800 Saint-etienne-du-rouvray semble se poser, faute de numéro dans la voie.

Est-il techniquement possible de faire d'un bâtiment un pseudo point de voie ?

Qu'en pensez-vous ?
Merci

HP

The CSV returned as no name, we want to keep the original one, plus a suffix, like "_geocoded".

"epinal, france" doesn't get "Epinal" as first result, because Epinal document doesn't contain "France".

We have two options:

• index country name for each document (bigger index)
• add a special case for handling "france" in search algo (hackish)

I'm in favour of option 1.

40 rue lafayette 76 rouen

76 Rue Lafayette 76000 Rouen (765404610R | 0.7994805194805195)

At the moment we are using the token order which is by frequency.

Going totally out of road:

> EXPLAIN rue de la répub
[5.003] Taken tokens []
[5.028] Common tokens [<Token ru>, <Token la>, <Token de>]
[5.039] Not found tokens [<Token repub>]
[5.052] ** STEP_ONLY_COMMONS **
[5.063] ** STEP_NO_MEANINGFUL_BUT_COMMON_TRY_AUTOCOMPLETE **
[5.071] Only commons, trying autocomplete
[5.081] Autocompleting repub
[5.275] Found tokens to autocomplete {b'republik', b'republikain'}
[5.293] Trying to extend bucket. Autocomplete w|republik
[5.304] Adding to bucket with keys ['w|ru', 'w|la', 'w|de', 'w|republik']
[9.774] 100 ids in bucket so far
[9.794] Trying to extend bucket. Autocomplete w|republikain
[9.807] Adding to bucket with keys ['w|ru', 'w|la', 'w|de', 'w|republikain']
[10.04] 100 ids in bucket so far
[10.05] ** STEP_BUCKET_WITH_MEANINGFUL **
[10.07] Adding to bucket with keys ['w|ru', 'w|la']
[665.1] 200 ids in bucket so far
[665.1] ** STEP_REDUCE_WITH_OTHER_COMMONS **
[665.1] Now considering also common token de
[665.1] New bucket with keys ['w|ru', 'w|la', 'w|de'] and limit 0
[1356.] 100 ids in bucket so far
[1356.] ** STEP_ENSURE_GEOHASH_RESULTS_ARE_INCLUDED_IF_CENTER_IS_GIVEN **
[1356.] ** STEP_AUTOCOMPLETE **
[1356.] ** STEP_CHECK_BUCKET_FULL **
[1356.] ** STEP_CHECK_CREAM **
[1356.] ** STEP_FUZZY **
[1356.] ** STEP_EXTEND_RESULTS_REDUCING_TOKENS **
[1356.] Computing results
[1380.] Done computing results

The type field returned as always set to 'street' when it should be 'housenumber'

Rend un résultat à la rue, alors que le 86 est bien présent dans les données BAN (à tester sur devban).

J-B => two tokens not found
Maybe we can have a step removing all token of only one char.

> vernou
Vernou 37130 Langeais (37123B283J | 0.9328818181818181)
Vernou 77670 Vernou-la-Celle-sur-Seine (77494B121P | 0.9142272727272726)
Vernou 41600 Chaumont-sur-Tharonne (41046B158V | 0.9121090909090909)
Vernou 79200 Gourgé (79135B205K | 0.9117181818181818)
Vernou 37120 Razines (37191B115F | 0.9098636363636363)
Vernoux 49370 Bécon-les-Granits (49026C361N | 0.8233181818181818)
Vernoux 79200 Le Tallud (79322B095C | 0.8225545454545454)
Vernoux (01433 | 0.8196545454545454)
Rue Vernoux 26000 Valence (263628740S | 0.6735545454545454)
Habitation Vernou 97170 Petit-Bourg (97118B406W | 0.6629818181818181)

This has two causes:

• string distance score is very low
• score for relation "vernou" => "Vernou-la-Celle-sur-Seine" is low (it is ranked 166)

> INDEX 77494
vernou 0.801506 166

I'm not sure how to fix that, and I'm not even totally sure we want to.

Two arguments could incite us to do so:

• while autocompleting, exact match and startswith could be considered of same weight, so a user typing "Vernou" would consider both "Vernou" and "Vernou-la-Celle-sur-Seine" results as 100% match
• Vernou could be considered an alias of "Vernou-la-Celle-sur-Seine"; I guess people living there use "Vernou" to refer to the city

So if we go this way, we'd need two fix:

• while in autocomplete mode, to consider both exact match and startswith with the same score; not sure which kind of side effects we could expect
• in any case, because its rank is > 166 "Vernou-la-Celle-sur-Seine" will never be in the bucket, so we need a way to have a greater relation score; this could be done the data side, adding a sort of "alias" that would be considered as important as the "official name"; or we can have an "autocomplete" strategy, scoring every first word of every city name with full name score (4.0), instead of dividing score by length of name;

La recherche " neuville les dieppe 15 route de bonne nouvelle 76370 Dieppe " ne fournit aucun résultat

La recherche "15 route de bonne nouvelle 76370 Dieppe " fournit le 15 route de bonne nouvelle 76370 Dieppe

neuville les dieppe est d'une certaine façon un synonyme du 76370 puisqu'il s'agit d'une commune fusionnée de longue date avec Dieppe qui devenue quartier de Dieppe a conservé son code postal.

La formulation telle que vient d'une source tierce (annuaire opérateur). Considérez-vous qu'il faudrait retraiter en amont d'addok la donnée source ? ou bien qu'addok ne devrait pas faire chou blanc.

Merci !

On me propose une adresse 580 le baillage 76170 Ecrainville 0️⃣ addok est KO

Si je tente le baillage 76170 Ecrainville 0️⃣ addok est toujours KO

Après avoir consulté http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#17/49.65028/0.31096 je tente le bailliage 76170 Ecrainville 👍 addok est OK

Du coup je tente 580 le bailliage 76170 Ecrainville et là 0️⃣ addok est KO.

Q1: baillage et bailliage ne peuvent-ils être équivalents ?
Q2 : la dernière tentative ne devrait pas faire planter ?!
Merci

Some config is related to French language, some others to France address format.

Après import, il apparaît que quasiment aucune (aucune a priori) adresse
avec housenumber n'est importée, puisque pour qu'elle le soit, il faut
que row['class'] == 'highway' (def extend_row(self, row)). Aucune
adresse n'est de ce type. Les "class" concernées sont place, shop,
amenity, tourism et le nom de la rue n'est pas dans "name" mais dans
"street" ce qui bloque dans l'ajout puisque la condition "if not
row['name'] or not row['postcode']" est utilisée, et que contrairement à
la France, les postcodes ici ne sont que très peu souvent connus.

Bonjour j'ai noté la forme

http://api-adresse.data.gouv.fr/search/?q=8 bd du port&postcode=44380

Peut-on imaginer d'avoir une forme ?

http://api-adresse.data.gouv.fr/search/?q=12 rue jeanne d'arc&codeinsee=76540

Ca serait super !

J'ai un soucis avec une requête en particulier :

 - - [03/Feb/2015 13:47:57] "GET /search/?q=1%20route%20express%2071300%20montceau%20les%20mines HTTP/1.1" 500 -
Traceback (most recent call last):
  File "/home/kevin/addok/addok/server.py", line 41, in app
    response = on_search(request)
  File "/home/kevin/addok/addok/server.py", line 73, in on_search
    return serve_results(results, query=query)
  File "/home/kevin/addok/addok/server.py", line 94, in serve_results
    "features": [r.to_geojson() for r in results]
  File "/home/kevin/addok/addok/server.py", line 94, in <listcomp>
    "features": [r.to_geojson() for r in results]
  File "/home/kevin/addok/addok/core.py", line 120, in to_geojson
    properties['name'])
KeyError: 'name'

Sinon pas de soucis avec cette nouvelle api, bien plus réactif que bano-geocode, et les résultats m'ont l'air plus pertinent a priori.

http://redis.io/topics/mass-insert

Il serait preferable que la reponse comporte un entete "Content-Type:
application/json; charset=UTF-8", ce qui permettrait une integration plus facile par les differents clients... httpie y compris.

Hello URL en échec
http://api.adresse.data.gouv.fr/search/?q=283%20rue%20saint%20exupery%2076170%20Lillebonne&lon=.537546682886993&lat=49.5209623388051&limit=3

Concerne donc 76170 Lillebonne

Merci

Since addok is datasource-agnostic, it may be a good idea in my opinion to include attribution and possibly the license into the result JSON. I'm thinking that if you find an addok instance in the wild, or even parallel instances of addok with different data for various needs (FANTOIR...), it ensures you know the origin and how to handle it. Maybe it could even be included in the GeocodeJSON spec.

Maybe something as trivial as two optional keys in the config file is enough; then we'd add them at the root of the JSON result.

Erreur courante de saisie d'adresse : mettre le code postal de la commune/arrondissement d'en face !
Ou plus simplement se tromper de code postal.

Même si cela ne pose pas trop de problème en saisie intéractive, la validation en masse en souffre beaucoup.

Ex: lors de la saisie de "24 bd hopital 75013 paris", le résultat "24 bd hopital 75005 paris" est attendu, et non pas "bd hopital 75 paris".
Avec "24 bd hopital 75006 paris", c'est pire, la "rue d'assas" est proposée en premier résultat.

11b rue de Clamart 92100 Boulogne-Billancourt
ne trouve pas le 11bis (qui existe)

un post-traitement pour les b/t/q/c/s serait utile pour les retrouver quelle que soit l'adresse en entrée.

Exemple: 5 chemin du caribouillé, sarrigny 89110 poilly sur tholon (BAN)

Pas trouvé par addok dans BAN à cause du nom du lieu dit (Sarrigny)
Si on le retire, l'adresse est trouvée.

Identique pour:
9 chemin du ravillon, auvergne 89110 poilly sur tholon

Regarding importing data, the README links to https://github.com/etalab/addok/blob/master/bano.openstreetmap.fr/data/full.sjson.gz but it seems there is nothing here anymore. I'd have fixed myself but I can't find where it's gone :)

We need a deindex command.

Dans la présentation addok il est indiqué que le score est entre 0 et 1.
Si on cherche le 41 rue d Iena 76600 Le Havre, le score est 1.3096363636363635 !
Sans doute l'effet du Grand Paris 😆 ?

http://api.adresse.data.gouv.fr/search/?q=41%20%20rue%20d%20iena%2076600%20Le%20Havre

PS : autant de décimales dans le score ne parait pas utile.

http://tavendo.com/blog/post/going-asynchronous-from-flask-to-twisted-klein/

Geohash preference is only used when we have only common tokens.

So in the case we have not only common tokens, but we have an overflown bucket anyway, we may lose a result that would in reality be in the geohash.

Note that boost by geodistance is applied in any case, not only with only common tokens.

http://api.adresse.data.gouv.fr/search/?q=24%20BD%20POISSONNIERE,%20Paris&limit=1

Oddly enough, it works if I specify France: http://api.adresse.data.gouv.fr/search/?q=24%20BD%20POISSONNIERE,%20Paris,%20France&limit=1

Je viens d'essayer le géocodeur CSV avec quelques données test : celui-ci a très bien fonctionné, sauf lorsque les adresses contenaient des accents.
Par exemple, les "è" sont devenus des "�", et le géocodage n'a donc donné aucun résultat.
J'ai essayé depuis un CSV, un TXT, même problème.
Certainement un problème de gestion de l'encodage.

Bravo pour ce super outil en perspective !

Sylvain M.

Toutes les tentatives qui finissent par un "h" seul retournent HTTP 500.

Je précise qu'il n'existe bien sûr pas de telles voies ...

C'est la seule lettre qui semble avoir ce problème.

The phonem algo cut the final g or h.

Salut,

J'ai forké le projet et fait un petit commit pour que l'import marche !
Ca par contre je suis pas sur de ça :

 chunk.append(json.loads(json.dumps(row)))

J'ai regardé dans la doc Python, ça a l'air d'être comme ça qu'il faut faire.
Mais comme dit dans l'autre sujet j'y connais pas grand chose en Python

Bon par contre ça marche toujours pas vu qu'il y a toujours un problème sur le fichier csv !