Housenumber search behaves strange

[jandegr]

Hi, map : OSM related to :Search for my town works, but I can't find my street on the Navit wiki ​http://wiki.navit-project.org/index.php/OpenStreetMap Since admin_level in Belgium is similar to the situation in Germany, ​http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Boundaries it would be nice if someone makes the small change needed in maptool/osm.c Now sometimes :

• street in city is not found
• street is found in adjacent city. if multiple results for street search turn up, Navit seems clever enough to select the most probable (closest to city center ?), - but when searching for housenumbers, results from the rejected streets show up among the found housenumbers.

I think it is related to the suffix like "345c7M" in maptool/osm.c but I don't have a clue on how to code or decode it.

This would mean a significant increase in usability of Navit.

Thanks, Jan

[jandegr]

Hi, After some more investigating I built a maptool with "345c7M" appended to Belgium, (line 150 in trunk/navit/navit/maptool/osm.c), and then processed a map. It solves both "street in city is not found" and "street is found in adjacent city". It also adds the province name to the results shown in the search menu's, which is nice. It does not solve the issue when proceeding to search for housenumbers. I built a maptool with 345c7m instead of 345c7M, but that did not solve anything. So I will search for someone on IRC to change line 150 and I put the focus of this ticket to the housenumber issue. To repeat the housenumber issue : search in Belgium, town = Deinze, street is Kortrijksesteenweg, with a map from any maptool version (before or after the 345c7M mod) Then move on to the housenumber search, tap 1 and see a number of results show up. All those higher than 1000 are in another city (there are more false entries in the results)and are shown in the result list with city=9800 DEINZE, but they are in fact Sint-Martens-Latem, Sint-Denijs-Westrem and Gent. The false results are on the same road, and same streetname, but in each city the numbering starts over, so those results should be rejected.

regards, Jan

[jandegr]

List of countries with custom boundery handling in osm.c up to now : France, Germany, Russian federation, Spain, Switzerland, Ukraine, United Kingdom and USA

[kazer]

Fix applied in r5878, thank Jan!

Please test and report!

[jandegr]

KaZeR: Thanks for making the change in the sourcecode. The list of countries now includes Belgium and the Netherlands.

Remains to be investigated : the housenumber search issue

[jandegr]

Hi, Even with the new maps the housenumbersearch issue still exists. Tryagain could reproduce it and confirms the issue. I include a screenshot if you tap 1 in the housenumbersearch, select the first suggestion and then proceed to "show the results on the map" Those in the lower left corner (n° 124 and 185) are actually in Deinze. All the other results are in two different cities.

regrds, Jan

[jandegr]

In the first test we started searching in Deinze and we got results in Sint-Martens-Latem, Gent and it's suburd Sint-Denijs Westrem as well. I thought if we start in the middle (Sint-Martens-Latem), it would extend both ways up to Deinze in the bottom left and Gent in top-right, but id does not !

Start a search in Sint-Martens-Latem (zipcode 9830) same street Kortrijksesteenweg and tap 1 as well. Now it only extends to Gent, not in the direction Deinze.

regards, Jan

[jandegr]

Hi, I propose a change to limit the housenumbersearch to the area in the town boudaries when available. It falls back to a normal search when no boundaries are available.

diff attached.

Can be further improved by : -limiting the initial search range to a rectangle enclosing the street, now it can get a little slow in dense area's with lots of housenumbertags. -A maximal growth of the search range can be imposed for the normal search without town boundaries.

regards, Jan

[jandegr]

searc housenumbers in town boundaries

[jandegr]

Hi, Further investigating the issue I also found that housenumbers from an interpolation will appear once + the number of times the search restarted because of search range extension. Probable cause : only housenumbers are checked for duplicate, interpolation items are not.

regards, Jan

[jandegr]

Hi, I post a working version to inform about progress and receive comments

Even if town boundaries are available, the search is done as before but the range extending is limited to the boundaries and housenumber results are checked to be within the boundaries. If no boundaries are available the range extending is limited to only once and also limited in the amount it can grow. It is not neat to store 'extendable' in map_priv as well, but put it there anyway to not spread things to remember to different places, untill a better and more universal solution for 'search memory & history' exists.

Also contains a check for duplicate interpolations, but the code suggests there is a possibility to do an indexed search, but the duplicate check as it is now will probably break indexed search.

The only time I still found a duplicate is when a discrete housenumber exists in the range of an interpolation, but that is more an OSM related issue.

Remaining issue °1 : I don't trust item_inside_poly_list, for a roadsegment it should return true if any coordinate is in the boundaries, not only if the middle point is within boundaries. Did not change it yet not to break anything and needs further testing to confirm the suspected, the very last piece of a road crossing the town boundaries might get cut out of the search.

Remaining issue °2 : on long roads with housenumbers going to n° 1000 and more, search for n°1, the resultlist now gets flooded with results and wipe out n° 1 or any in the ten's.

Has now been tested on Android (with 0.5.0 5889) as well, breaks nothing and works very well.

regards, Jan

[jandegr]

interim version

[kazer]

Nice job jandegr. We will probably need an automated way to ensure that there is no regressions with this change tho.

[tryagain]

Replying to http://wiki.navit-project.org/index.php/user:jandegr:

Even if town boundaries are available, the search is done as before but the range extending is limited to the boundaries and housenumber results are checked to be within the boundaries. If no boundaries are available the range extending is limited to only once and also limited in the amount it can grow.

1600 meters would be too hard limit unless we have a really small populated place. What if you create estimate boundaries (based on town population) when actual boundary is not found? Put four points to make a square boundary, or use 6-10 points placed on a circle around town centre.

Also contains a check for duplicate interpolations, but the code suggests there is a possibility to do an indexed search, but the duplicate check as it is now will probably break indexed search.

The only time I still found a duplicate is when a discrete housenumber exists in the range of an interpolation, but that is more an OSM related issue.

I agree, we can go with it. At least until somebody comes with a real life example where it looks really ugly.

Remaining issue °1 : I don't trust item_inside_poly_list, for a roadsegment it should return true if any coordinate is in the boundaries, not only if the middle point is within boundaries. Did not change it yet not to break anything and needs further testing to confirm the suspected, the very last piece of a road crossing the town boundaries might get cut out of the search.

My first version of that function was actually checking each coordinate and were very resource hungry. But navit anyway splits every osm way into separate binfile items on each node belonging to more than one way. Also, I believe it's common in osm to make such nodes where a road leaves the town boundary. So checking any road item point (not counting its ends) should be enough.

Remaining issue °2 : on long roads with housenumbers going to n° 1000 and more, search for n°1, the resultlist now gets flooded with results and wipe out n° 1 or any in the ten's.

Town search (unsure about street and housenumbers) in internal gui is ordered in such a way that complete matches are always on the top. I'd suggest populating this ordering to housenumber searches.

Has now been tested on Android (with 0.5.0 5889) as well, breaks nothing and works very well.

Not yet compiled it.

[jandegr]

Hi, version 3 :

• still includes the duplicate check
• if no boundaries are avalaible, estimated boundaries are used with the same size as the estimate for the street search.
• nothing changed to item_inside_poly_list, some day some place it will cause some housenumbers to be missed but I decided not to change it untill some sample use cases turn up

regards, Jan

[tryagain]

Commited housenumbersearch3.diff​ in 5919 with slight fixes.

[jandegr]

thanks for the review and the commit Jan