search

aerostitch / testnavit

0 stars 0 forks source link

Navit finds street with correct name, but in wrong city #170

Open aerostitch opened 11 years ago

aerostitch commented 11 years ago

Issue migrated from trac ticket # 1097

component: core | priority: major | keywords: address, search, names, boundaries

2013-02-18 05:05:06: grrosminet@gmail.com created the issue

Hello, I'm trying navit svn for android with french translation. For some adresses it doesn't give me the good location but I cannot determine why

Scenario :

I want to go to my work at "26 rue Henri Barbusse, 37000 TOURS, FRANCE" so I do :

  • tap on the map
  • Actions
  • "Ville" (city ?)
  • type Tours
  • select 37000 Tours
  • tap on "Rues" (streets ?)
  • type "barbu"
  • select "Rue Henri Barbusse"
  • tap on "Définir comme destination" (set as destination ?)

It calcultates itinerary and when I look at destination it is "Rue Henri Barbusse, 37700 Saint-Pierre-des-Corps" (~4km from the real destination) :-(

As my real destination didn't provide street numbers, I have added the 26 on OSM then waited 3 days and updated the maps. the "26" is well displayed on map, but still not available when entering destination. And the itinerary is still to 37700 Saint-Pierre-des-Corps, not 37000 Tours :'(

I dont understand what can do that, so I think it's a bug :-(

aerostitch commented 11 years ago

2013-02-28 16:58:07: @sleske commented

I'm afraid this is a well-known problem. Navit does not currently handle multiple streets with the same name in one city (or sometimes in adjacent cities). See e.g. #794 and #1005.

aerostitch commented 11 years ago

2013-03-25 18:04:40: @sleske commented

This is still reproducible with rev. 5419. So the fix that corrected #794 apparently did not fix this problem.

More information: There are actually three "rue Henri Barbusse" near Tours:

  • one in Tours itself
  • one in Saint-Pierre-des-Corps (the one that Navit finds)
  • one in Joué-lès-Tours (south of Tours)

There are "boundary=administrative" relations for all three cities in OSM data, and they look correct. So apparently Navit does not correctly process these relations.

Also, oddly enough, searching for "rue Henri Barbusse" in the cities of Saint-Pierre-des-Corps or Joué-lès-Tours does lead to the right street. It's just searching in Tours that does not work correctly.

aerostitch commented 11 years ago

2013-03-25 18:06:28: @sleske changed title from mis matching street to Navit finds street with correct name, but in wrong city

aerostitch commented 11 years ago

2013-03-26 10:46:09: tryagain commented

Hi!

I see it's quite uncommon to have place=city/town/village/* marked polygons or myltipolygon relations in osm. Rather than that, it seems to be common practice to tag city boundary with some admin_level=n boundary, where n is changing from country to country.

I don't know exact reasons why not tag each city boundary with place=city and so on, but navit should attempt to work in these cases too.

Also, some admin_levels used in each country may carry official divisions which are not of common use when specifying an address.

If you could specify for France, which admin_level's would you like to see as different country level divisions, I can make navit know them.

What I need, is per-country correspondence of admin_level values to the following divisions:

  • state
  • county
  • municipality
  • town
  • town subdivision like suburb or district

Also you may specify boundary of which admin_level defines a city/town/village boundary.

Some of above divisions may be skipped, if they are not applicable to a given country.

tryagain

aerostitch commented 11 years ago

2013-04-07 04:27:01: tryagain changed status from new to closed

aerostitch commented 11 years ago

2013-04-07 04:27:01: tryagain changed resolution from * to fixed*

aerostitch commented 11 years ago

2013-04-07 04:27:01: tryagain commented

Hi!

I consider this issue to be fixed with 5427, 5428.

To get right search results, you have to use a recent svn navit build and a fresh binfile map (built at April, 07 or later).

tryagain

aerostitch commented 11 years ago

2013-07-21 07:27:50: @sleske changed priority from blocker to major

aerostitch commented 11 years ago

2013-07-21 07:27:50: @sleske changed status from closed to reopened

aerostitch commented 11 years ago

2013-07-21 07:27:50: @sleske changed resolution from fixed to **

aerostitch commented 11 years ago

2013-07-21 07:27:50: @sleske commented

Unfortunately, the problem still occurs: Navit still finds the rue Henri Barbusse in 37700 Saint-Pierre-des-Corps. Tested with a map from maps.navit-project.org from today, and SVN rev. 5549. So reopening.

Looking a bit closer at the map, the problem may be related to the fact that there are two areas "Tours" in OSM: The city of Tours (OSM relation for the city) and the "arrondissement" (district) of Tours (OSM relation for the arrondissement). All three streets are in the arrondissement, but only one is also inside the city. Maybe this is confusing Navit?

aerostitch commented 11 years ago

2013-07-21 08:36:21: tryagain commented

Hm...

I'm sure it was working for me. Maptool uses admin level 8 boundaries in france to get city boundaries. Can you please verify with josm that relation 76306 is correct (boundary has no gaps). When there's no good relation or polygon, we use population-dependent radius to get town area.

tryagain

aerostitch commented 11 years ago

2013-07-21 13:13:16: @sleske commented

Strange. For me it definitely did not work. I'll try to look into this. Maybe I can grab the original OSM data, process it with maptool to make sure the map is current, then debug the search process.

aerostitch commented 11 years ago

2013-07-24 02:17:32: tryagain commented

We should trace down the people removing the iso tags from the country boundaries. Few days ago it was Norway, today France... What will be next?

http://www.openstreetmap.org/browse/relation/1403916

I consider this osm data issue unless there's some agrement.

aerostitch commented 11 years ago

2013-07-24 14:28:35: @sleske commented

Well, there is some logic behind removing the ISO code. The relation above is only for the French mainland, without the ex-colonies etc. There is another relation for the whole of France. This relation contains sub-relations (in two or three levels, I think) which together cover France.

This is explained in the OSM Wiki: France boundary pyramidal construction. It looks like we should use that relation for Navit. However, I'm not sure if we can process such a nested relation.

And BTW, there is also a relation for Norway with ISO tag. This one is not even nested :-).

aerostitch commented 11 years ago

2013-07-24 14:28:35: @sleske

aerostitch commented 11 years ago

2013-07-25 05:54:17: tryagain commented

Thete's another one, but it's buggy too http://www.openstreetmap.org/browse/relation/2202162

That is the one which navit attempts to use.

aerostitch commented 11 years ago

2013-07-25 13:17:03: @sleske commented

Replying to [comment:11 https://wiki.navit-project.org/index.php/user:tryagain]:

Thete's another one, but it's buggy too http://www.openstreetmap.org/browse/relation/2202162

Why is it buggy? It is nested, that's true, but apparently in OSM this is not considered incorrect. So maybe we'll have to learn to work with these?

aerostitch commented 11 years ago

2013-07-26 00:40:17: tryagain commented

Your [ http://trac.navit-project.org/ticket/1097?action=comment-diff&cnum=10&version=1 changes] made after my comment have sched some more light on the subject.

The old-style norway relation you are referring to is a fix by xenos.

It looks like cascaded relations feature has not been discussed yet besides an idea to keep the old style relations.

It also looks like nominatim does not support them. It works for continental france only because it does not need iso country code.

We cant workaround this in nominatim way as we're stuck to country list having iso codes, and cant treat any string as country name.

So there are two ways: follow immature specification and be the first software supporting it or create parallel old style relation and attempt to distinguish these.

At present, I would vote for second way, but like to listen to osm veterans opinion.

aerostitch commented 11 years ago

2013-07-26 06:09:29: usul

aerostitch commented 11 years ago

2013-07-26 06:09:29: usul commented

Thank you all for working on this bug. I will schedule it for the next hotfix.

aerostitch commented 11 years ago

2013-07-26 12:58:34: @sleske commented

Replying to [comment:13 https://wiki.navit-project.org/index.php/user:tryagain]:

It looks like cascaded relations feature has not been discussed yet besides an idea to keep the old style relations.

I googled a bit, and there's a fair amount of discussion about them. Googling is a bit tricky, because there are different names for them: cascading relations, super-& sub-relations, nested relations. For example, they are apparently used alot for routes (hiking routes, bus routes etc.): Creating super-relations for routes.

So there are two ways: follow immature specification and be the first software supporting it or create parallel old style relation and attempt to distinguish these.

At present, I would vote for second way, but like to listen to osm veterans opinion.

Hm, I would really, really like to avoid having to maintain our own relations in the OSM database. It would be a lot of work. Also, it might be deleted at some point, because an important OSM principle is One feature, one OSM element, which is violated by having two relations for France.

I'm afraid we'll have to find a way to handle the present situation.

Can't we drill down into the the super-relation and collect all ways? All we really need is a list of ways, and that way we get it.

As an interim solution we could even hardcode the right sub-relation for countries where it's necessary. Not nice, but would probably work, as these relations are long-lived (they are all already several years old).

aerostitch commented 11 years ago

2013-07-27 00:14:58: tryagain commented

Drilling into the cascaded admin_boundary relations is not so big problem, we already collect them into the memory.

Also we should start loading http://wiki.openstreetmap.org/wiki/Relations/Proposed/boundary_segment

Then collecting the whole way set for the given boundary is not too hard, programmatically.

I'm far from the idea to keep separate relation kind solely for navit.

My attempt to discuss this at #osm showed that these changes are silently accepted by the community.

So we probably have no way besides implementing this feature together with consistency checking and reporting logic.

aerostitch commented 11 years ago

2013-09-02 11:11:46: tryagain commented

I have implemented a workaround with 5620.

Rue Henry Barbusse seems to be found in the right city now.

Approach used is not very nice, as I have used country name in int_name attribute and admin_level=2 to distinguish the needed relation.

Other existing France relations are skipped with 5619 as not having any outer ways defined.