Streets not found

[aerostitch]

Issue migrated from trac ticket # 1219

component: mapdrivers/OSM | priority: critical

2014-06-24 07:07:32: [email protected] created the issue

---

Hi,

in the actual svn - version on android at search

• the village D-54526 Niederkail was not found.
• the street Friedhofstraße in the same village was not found in D-54526 Landscheid

Tested with data from https://jff-webhosting.net/daten/osm/

[aerostitch]

2014-06-25 09:20:30: tryagain commented

---

I don't know what copy of osm data and which maptool version that site uses. So can you please verify with data downloaded from maps.navit-project.org?

Please also note that we treat German municipalities (osm admin level 8) as town/city for search purposes. Suburbs boundaries with osm admin level above 8 (like villages merged to towns) are not counted as separate populated places.

Our limitation is that we can't find two streets having equal names in one municipality. We find only one in such a case.

[aerostitch]

2014-06-27 14:05:30: @sleske commented

---

I just tested this with a fresh Navit and a fresh map download from http://maps.navit-project.org/ .

• "Niederkail" is indeed not found by the town search. Also, it is not displayed as a label on the map.

• However, searching inside town "Landscheid", the search does correctly find the street "Friedhofstraße" - so I cannot reproduce the second part of this bug.

Note: There appears to be only one "Friedhofstraße" in or near Landscheid, so the remark about Navit not finding two streets of the same name in one town, while correct, is not relevant.

[aerostitch]

2014-06-27 14:36:09: @sleske commented

---

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

Please also note that we treat German municipalities (osm admin level 8) as town/city for search purposes. Suburbs boundaries with osm admin level above 8 (like villages merged to towns) are not counted as separate populated places.

Yes, that is probably the reason Niederkail is not found. Niederkail exists as a place:village and as a relation with admin_level:11.

Is there a reason we do not consider places with admin_level 9-11? As this example shows, it would be useful for finding small villages. And BTW, where in the code is the admin_level evaluated? I could not find it with a brief scan of the code.

[aerostitch]

2014-06-27 23:36:20: [email protected] commented

---

Hi,

so I have tested under android:

Germany from maps.navit-project.org -> Friedhofstraße found
Germany from jff-webhosting -> Friedhofstraße found
europe_south_west from jff-webhosting -> Friedhofstraße not found

The size of europe_south_west is 3,70 GB. Can it be that the file is too big for android?

[aerostitch]

2014-06-27 23:36:20: [email protected]

[aerostitch]

2014-06-28 00:29:00: [email protected] commented

---

Now I have tested under Linux with the same result.

[aerostitch]

2014-06-30 12:02:56: tryagain commented

---

jörg frings-fürst,

Please add place=village node for the Niederkail, and it will become findable.

Place node seems to be made optional by misunderstanding wiki editor, see https://wiki.openstreetmap.org/w/index.php?title=Key:place&diff=874017&oldid=830353 . Now it's fixed: https://wiki.openstreetmap.org/w/index.php?title=Key:place&diff=1057304&oldid=1000734

I agree with following post: gravitystorm/openstreetmap-carto#546 (comment) that place node and place boundary are different entities.

As for europe_south_west problem, I guess it's because that map is based on a broken osm extract, which does not contain the whole DE boundary. In this case we can't apply per-country admin_level processing rules.

We can increase our robustness by processing places without place node, but I'd count this idea as a minor feature request, if acceptable at all because of processing and map size overhead.
'''
sebastian leske,'''

admin level per country rules are coded in osm.c. Look at "345c7M" in country_table. It means skip 3,4,5,7 admin levels and use 6 for county, 8 for municipality.

These spells are processed by osm_process_town_by_boundary of osm.c.

Add: We actually accept place=village/town/city/etc polygons (including relations) to get town boundary, country independent. Parsing country-specific admin_level relations to get place boundaries looks more like a workaround for countries which ignore place=* polygons.

[aerostitch]

2014-06-30 12:02:56: tryagain

[aerostitch]

2014-06-30 12:02:56: tryagain

[aerostitch]

2014-06-30 15:03:50: @sleske commented

---

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

Please add place=village node for the Niederkail, and it will become findable.
[...]
I agree with following post [...] that place node and place boundary are different entities.

Hm, tagging both a place node and an area violates the "One feature, one OSM element" rule, and means extra work (and potentially extra errors) matching up the node and the area.

I agree that both area and center node are important, but it would probably be better to handle this using relations - like the "admin_centre" role for a relation:boundary. But that's for the tagging mailing list to discuss...

We can increase our robustness by processing places without place node, but I'd count this idea as a minor feature request, if acceptable at all because of processing and map size overhead.

I think ideally we should be able to handle all three cases: node only, area only, both. At the moment we handle "node only" and "both", but not "area only", correct? Should I file a bug about this?

admin level per country rules are coded in osm.c. Look at "345c7M" in country_table. It means skip 3,4,5,7 admin levels and use 6 for county, 8 for municipality.

Ah, thanks for the hint. I didn't see that, because most countries do not have that "level list".

Add: We actually accept place=village/town/city/etc polygons (including relations) to get town boundary, country independent. Parsing country-specific admin_level relations to get place boundaries looks more like a workaround for countries which ignore place=* polygons.

Well, actually I think if there is both an admin_level relations and a place=* polygon, we should prefer the admin_level relation: It is typically larger, and usually corresponds to the area used for addressing.

So to find every street that has "TownX" in its address, you'd probably need the relation for TownX, not just the place polygon, which might exclude non-built-up areas which officially belong to TownX (and possible still have the odd street or two). But again, that's probably something that needs to be investigated...

[aerostitch]

2014-07-01 10:19:53: tryagain commented

---

Replying to [comment:7 sebastian leske]:

Please add place=village node for the Niederkail, and it will become findable.
[...]
I agree with following post [...] that place node and place boundary are different entities.

Hm, tagging both a place node and an area violates the "One feature, one OSM element" rule, and means extra work (and potentially extra errors) matching up the node and the area.

This seems to be common practice, which was a documented way to go for quite a while. And we have here two different features to tag: place itself, described by polygon, and place centre of interest, mapped as a node. So two features, two osm elements.

I agree that both area and center node are important, but it would probably be better to handle this using relations - like the "admin_centre" role for a relation:boundary. But that's for the tagging mailing list to discuss...

It's a tradeoff to decide when to stop database normalization...

I think ideally we should be able to handle all three cases: node only, area only, both. At the moment we handle "node only" and "both", but not "area only", correct? Should I file a bug about this?

1. Yes. 2. You MAY :)

Actually, making navit to support place (admin level) polygons without central node would probably resolve a problem with Estonian search we were discussing with xenos1984. Estonians tag different name= values on place/admin boundary and place node. Difference is in some status words they always include in the name attribute. So, for any Estonian place, navit never find a matching boundary.

Well, actually I think if there is both an admin_level relations and a place=* polygon, we should prefer the admin_level relation: It is typically larger, and usually corresponds to the area used for addressing.

So to find every street that has "TownX" in its address, you'd probably need the relation for TownX, not just the place polygon, which might exclude non-built-up areas which officially belong to TownX (and possible still have the odd street or two). But again, that's probably something that needs to be investigated...

I expect this to be country dependent. At least for Russia, it's said to be de-facto standard to use place= polygons rather than admin_level ones for addressing purposes.

[aerostitch]

2014-07-02 14:24:22: @sleske commented

---

Thanks for all that interesting information.

About handling place areas w/o a place node: For the time being, we don't need a new ticket, as that is just the problem that this ticket is about (the problem with the missing street appears to have been a faulty map file). If we decide a new ticket is better, we can always create one.

[aerostitch]

2014-07-09 22:35:39: [email protected] commented

---

Hi,

I have tested with a build from a new planet-file.

And I have the same errors described in comment 4 & 5.

So I think thats not a prob with a broken osm extract.

Jörg

[aerostitch]

2014-07-10 10:11:51: @sleske commented

---

Replying to [comment:10 jörg frings-fürst]:

I have tested with a build from a new planet-file.
And I have the same errors described in comment 4 & 5.
So I think thats not a prob with a broken osm extract.

As explained above, the fact that Niederkail is not found is a known problem - that's why this ticket is still open.

About the street Friedhofstraße: As it only occurs with certain maps, it looks like a problem with map creation.

Please describe the exact steps to reproduce the problem. In particular, how did you create the map where the street is not found? What OSM did you use - can you provide a download? And did you use any special options to maptool?

[aerostitch]

2014-07-10 11:16:53: [email protected] uploaded file Screenshot_2014-07-10-20-06-48.png (100.4 KiB)

Error: Search Landsch: Postcode missing

[aerostitch]

2014-07-10 11:17:40: [email protected] uploaded file Screenshot_2014-07-10-20-07-10.png (99.8 KiB)

Error: Search Streets "F" in Landscheid

[aerostitch]

2014-07-10 11:18:13: [email protected] uploaded file Screenshot_2014-07-10-20-07-21.png (102.5 KiB)

Error: Search Streets "T" in Landscheid

[aerostitch]

2014-07-10 11:18:47: [email protected] uploaded file Screenshot_2014-07-10-20-19-13.png (123.9 KiB)

Ok: Search Landsch

[aerostitch]

2014-07-10 11:19:13: [email protected] uploaded file Screenshot_2014-07-10-20-19-32.png (121.1 KiB)

OK: Search Streets "F" in Landscheid

[aerostitch]

2014-07-10 11:19:35: [email protected] uploaded file Screenshot_2014-07-10-20-19-48.png (127.1 KiB)

Ok: Search Streets "T" in Landscheid

[aerostitch]

2014-07-10 11:32:03: [email protected] commented

---

Hi,

I have attach some Screenshots:

The 3 "Error" was from https://jff-webhosting.net/daten/osm/navit/navitmap_osm_europe_south_west.bin.

The 3 Ok was from https://jff-webhosting.net/daten/osm/navit/europe/navitmap_osm_DE.bin.

Both based on the same osm-extract.

The maptool - Version is from svn downloaded at last sunday.

The europe_south_west - commandline is

${MAPTOOL} -S 5000000000 -P -i europe_south_west.osm.${TS}.pbf navitmap_osm_europe_south_west.${TS}.bin >>${PROGLOG} 2>&1

and for DE:

${MAPTOOL} -P -i ../$1 ../$2 >${PROGLOG} 2>&1

Jörg

[aerostitch]

2014-07-17 15:01:32: @sleske commented

---

Replying to [comment:12 jörg frings-fürst]:

I have attach some Screenshots:

Thanks for the additional information.

The 3 "Error" was from https://jff-webhosting.net/daten/osm/navit/navitmap_osm_europe_south_west.bin.
The 3 Ok was from https://jff-webhosting.net/daten/osm/navit/europe/navitmap_osm_DE.bin.

Both based on the same osm-extract.

How can they be based on the same OSM extract, if they contain different regions?
Did you split the OSM input file first?

At any rate, if the problem is only reproducible with the full map of south-west Europe, I will probably not be able to help. My computer is not powerful enough to process maps of that size :-/.

If you can reproduce the problem with a smaller map, it should be possible to fix it.

[aerostitch]

2017-11-04 09:58:29: @pgrandin commented

---

Jörg any update? Thanks!