On Mon, Jan 09, 2012 at 09:09:25AM +0200, Marko Mäkelä wrote:

I am not sure if this is related. I do not seem to find any streets that I tried, in the map tile of the current location. For example, if I search for Kisatie, I get several occurrences in Finland, but not the nearest one (3km away).

I tried again with Steve's friedrichstrasse.patch. This time, I tried both "Finland" and "Suomi". There was exactly one street in Vantaa, Finland and all the rest seem to be in Vantaa, Suomi. Shouldn't these two names be mapped together, like resources/LocatorConfig.xml says? I extracted all place=* nodes from my map extract, but did not see anything obviously wrong. Apparently, the country information of location-autofill=nearest must be coming from is_in:country and addr:country. Marko

On Tue, Jan 10, 2012 at 12:38:21PM +0200, Marko Mäkelä wrote:

Or would it fail to convert some is_in=Finland keys or the --country-name option to Suomi?

It seems that --country-name=Finland will not get translated into Suomi (the primary name of the country in the location configuration file). If I compile with --country-name=Suomi and combine the map tiles of a single family-id to --index --gmapsupp, it works: I get "Suomi" and "Russian Federation" (a few place=village nodes from Russia are included). If I try to combine multiple family-id to --index --gmapsupp, then the search will break: I get countries "Suomi" and "Aara" (no idea what that is) and no streets in either country. My other layers would be unrouteable (route relations, generated with various --style=routes-*). Best regards, Marko

Hi, I done some tests. You can find the results here: http://snailrun.de/all_tests.zip First I downloaded a tile which contain only the Friedrichstraße in Berlin: http://overpass.osm.rambler.ru/cgi/xapi?way[name=Friedrichstraße][bbox=13.227,52.163,13.580,53.042][@meta] Then I build mkgmap from trunk and build a map using the --gmapsupp-option (only_fs.zip). When I search for the Friedrichstraße, I didn't fine any Friedrichstraße. So I added a further street (Rheinhardtstraße) to the osm-file. And now I can find every Friedrichstraße on the tile (with_other_only_fs.zip). So I downloaded a further tile: overpass.osm.rambler.ru/cgi/xapi?way[name=Friedrichstraße][bbox=6.506,48.991,7.628,49.743][@meta] When I now build the map with the first tile (w/o Reinhardtstraße) I also couldn't find the Friedrichstraße, but the other Friedrichstraße in the other cities. (two_only_fs.zip) If I use the tile with Rheinhardtstraße I can find the Friedrichstraße also in Berlin. (with_other_with_other.zip) For all tests I used my Oregon, I don't have Mapsource or Basecamp here (I'm using Ubuntu). For the streetsearch I entered the City. If I leave it out, I can find the Friedrichstraße every time in Berlin. Also if I find the Friedrichstraße now, if I build more tiles it's not possible to find the Friedrichstraße (I forgot to mention that the Friedrichstraße is just an example, there are more streets, which couldn't be found). Cheers, Martin Am 2012-01-09 00:08, schrieb Steve Ratcliffe:

Hi

...

today I updated and rebuild my maps with mkgmap r2164. Adress search works without going through MapSource, but the problem with Friedrichstr. in Berlin is even worse: Now only one incarnation of the street is found in Berlin, even in MapSource. In mapsource too? I am going to need to see an example. In my map I see the same number of Friedrichstrasse streets in either version. The mapsource index changed very little between the versions.

As far as I know the only differences are in:

- cities and how they are allocated to regions. - streets with highway shields may now be marked as having the same name if they differ only in the shield.

..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

On Mon, Jan 09, Martin wrote:

For all tests I used my Oregon, I don't have Mapsource or Basecamp here (I'm using Ubuntu). For the streetsearch I entered the City. If I leave it out, I can find the Friedrichstraße every time in Berlin. Also if I find the Friedrichstraße now, if I build more tiles it's not possible to find the Friedrichstraße (I forgot to mention that the Friedrichstraße is just an example, there are more streets, which couldn't be found).

From my tests today I got some surprising results:

MapSource is able to find all Friedrichstr. in Berlin. Putting the mkgmap created map on my 62s: I can only find one Friedrichstr. in Berlin. Exporting the map from MapSource (where I can find all streets) to my 62s: I still can only find one Friedrichstr. in Berlin. If I search for Friedrichstr. without City, I cannot find any Friedrichstr. in Berlin. It's very surprising to me that MapSource can find Streets while the 62s cannot find them on the MapSource exported map. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)

Hello Steve, thanks for the fast patch. I will give it a try. Another bug(?): When I build a map with --gmapsupp and --index I couldn't search for addresses. When I add --route I can search for addresses. Cheers, Martin Am 2012-01-09 19:33, schrieb Steve Ratcliffe:

On 09/01/12 11:19, Martin wrote:

...

Hi,

I done some tests. You can find the results here: http://snailrun.de/all_tests.zip

Thanks again for the excellent test cases. There is so much data in a normal tile is is very useful to trim it down like this.

As a result I quickly saw a problem in the 'only_fs' files. I'm not sure if it is the same problem you were seeing earlier though -- as I think it will only happen if a city has just the one street, which is why it is found again in 'with_other_only_fs'.

But in any case a patch that fixes this is attached and pre-built mkgmap.jar can be found at: http://files.mkgmap.org.uk/download/47/mkgmap.jar

With this patch I could find all 4 Friedrichstrasse streets in Berlin on my Legend.

..Steve

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi

Now I started using the index on the main layer and it works great - as long as I don't try to combine all layers to a single gmapsupp.img, which I always do by calling mkgmap with all sublayer gmapsupps as input files:

java -jar mkgmap/mkgmap.jar --gmapsupp --nsis --description="OSM-Topo-DE" --overview-mapname=topo-gesamt deutschland/gelaende/gmapsupp.img deutschland/landuse/gmapsupp.img deutschland/topo/gmapsupp.img deutschland/maxspeed/gmapsupp.img deutschland/isohypsen/gmapsupp.img deutschland/isohypsen2/gmapsupp.img deutschland/wanderwege/gmapsupp.img deutschland/lit/gmapsupp.img

When doing so now, the resulting gmapsupp.img is lacking the complete main layer, but no error message is given.

Is that something that worked in earlier versions? There is nothing that I can think of that might have altered that.

When I add --index to the command line, I get the following error message immediadely:

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: -1 at java.util.ArrayList.get(ArrayList.java:324) at uk.me.parabola.imgfmt.app.mdr.Mdr29.preWriteImpl(Mdr29.java:62)

OK, it is a bug that an error is thrown like that, but in any case the indexing code will not work if given gmapsupp files rather than individual tiles. It would be possible to make it work, but it is not a simple change. ..Steve

OK, I now also tried to modify the command line, feeding mkgmap individual tiles, plus the overview-map.img of each layer, too. Now all layers are present in the gmapsupp.img, but I lost all layer names, .TYP files and the search index.

You should include just the individual tiles and the typ files, but not the overview files or the mdx,mdr files. The --index option will create the index. ..Steve

On Thu, Jan 12, 2012 at 03:30:57PM +0100, Martin Simon wrote:

2012/1/11 Steve Ratcliffe <steve@parabola.me.uk>:

...

...

OK, I now also tried to modify the command line, feeding mkgmap individual tiles, plus the overview-map.img of each layer, too. Now all layers are present in the gmapsupp.img, but I lost all layer names, .TYP files and the search index.

You should include just the individual tiles and the typ files, but not the overview files or the mdx,mdr files.

The --index option will create the index.

That doesn't work - no index seems to be created, the search function on the device doesn't work.

Are you sure that mkgmap builds the index when the input files are .img? I tried again with fewer tile, and other options, but nothing seems to have an effect.

For me, mkgmap --index --gmapsupp will generate a working index out of individual *.img tiles, but only if they belong to a single family-id, generated from splitter output using the default style. If I try to combine multiple map layers (the other layers cover the whole Finland, for various route relations using the route-* styles), I get a non-working index (no streets found). To be more specific, if I edit the osm2img.sh script at http://www.polkupyoraily.net/osm/ so that I just add --index before --gmapsupp, it will not work. If I only pass the 63240*.img to the command, it will work. By the way, --index is very useful for data validation. I already corrected a few name=?, name=xx and name=fix* and some typos in non-Finnish street names, searching for names starting with b, c, d, f, g, q, w, x, z. Marko

My observation is maybe related to Martins post, I can find only streetnames if those lines are routable (which make sense). If a road is not routable in my cyclemap (highways that are forbidden for bicycles) I give them a non routable line and as a consquence those roads are not findable in the search index. ---------- "Martin" wrote thanks for the fast patch. I will give it a try. Another bug(?): When I build a map with --gmapsupp and --index I couldn't search for addresses. When I add --route I can search for addresses.

Bad&good news. Good news: If I build a map which just contain different Friedrichstraßen in the same city I can find now all. But when building a map with surrounding tiles I still find one Friedrichstraße. And I confirm, that it depends on the splitted area. When I tried it in the office with a other max-node-size I found the Friedrichstraße for 3 times in Berlin... Any ideas? Cheers, Martin Am 09.01.2012 um 19:33 schrieb Steve Ratcliffe:

On 09/01/12 11:19, Martin wrote:

...

Hi,

I done some tests. You can find the results here: http://snailrun.de/all_tests.zip

Thanks again for the excellent test cases. There is so much data in a normal tile is is very useful to trim it down like this.

As a result I quickly saw a problem in the 'only_fs' files. I'm not sure if it is the same problem you were seeing earlier though -- as I think it will only happen if a city has just the one street, which is why it is found again in 'with_other_only_fs'.

But in any case a patch that fixes this is attached and pre-built mkgmap.jar can be found at: http://files.mkgmap.org.uk/download/47/mkgmap.jar

With this patch I could find all 4 Friedrichstrasse streets in Berlin on my Legend.

..Steve <friedrichstrasse.patch>_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

No, in the previous given files I've tested if it depend on just the name of the street (Thats why I downloaded only the way with the name Friedrichstraße) . Now I used complete tiles which surround the Berlin-tile. Here are the tiles where I can still find on Friedrichstraße: 63240348: 2430976,546816 to 2471936,616448 # : 52.163086,11.733398 to 53.041992,13.227539 63240364: 2471936,546816 to 2504704,681984 # : 53.041992,11.733398 to 53.745117,14.633789 63240376: 2385920,624640 to 2430976,702464 # : 51.196289,13.403320 to 52.163086,15.073242 63240380: 2430976,632832 to 2471936,702464 # : 52.163086,13.579102 to 53.041992,15.073242 63240412: 2430976,616448 to 2471936,632832 # : 52.163086,13.227539 to 53.041992,13.579102 Berlin-Tile 63240416: 2381824,571392 to 2430976,624640 # : 51.108398,12.260742 to 52.163086,13.403320 After this I made a new map, with tile with a maximum 500000 nodes. So Berlin is now divided in more parts and I can find the Friedrichstraße for 3 times. 63240364: 2435072,579584 to 2471936,612352 # : 52.250977,12.436523 to 53.041992,13.139648 63240396: 2435072,612352 to 2443264,628736 # : 52.250977,13.139648 to 52.426758,13.491211 63240460: 2435072,628736 to 2443264,686080 # : 52.250977,13.491211 to 52.426758,14.721680 63240492: 2447360,612352 to 2451456,628736 # : 52.514648,13.139648 to 52.602539,13.491211 63240556: 2451456,612352 to 2471936,628736 # : 52.602539,13.139648 to 53.041992,13.491211 63240588: 2443264,628736 to 2471936,641024 # : 52.426758,13.491211 to 53.041992,13.754883 63240604: 2443264,612352 to 2447360,628736 # : 52.426758,13.139648 to 52.514648,13.491211 You can download the splitted tiles here: http://snailrun.de/Found_one.zip http://snailrun.de/Find_three.zip Maybe somebody can go deeper into detail, but I have to go to bed now... Cheers, Martin Am 10.01.2012 um 22:21 schrieb Steve Ratcliffe:

On 10/01/12 19:26, Martin wrote:

...

But when building a map with surrounding tiles I still find one Friedrichstraße. And I confirm, that it depends on the splitted area. When I tried it in the office with a other max-node-size I

Is this problem seen on any of the files that you previously provided? If not could you provide a set of files that doesn't work, including .osm files.

Thanks. Steve

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi Steve, your patch works great ;) Thank you! I made a map and now I can find the Friedrichstraße for 5 times (one I find for two times). Currently I'm uploading the map to my server. I hope some other people will test the map. If I/they didn't found other problems I would suggest to commit this patch. Afterwards we should identify how to enable housenumber and zip-code-search ;) Cheers Martin Am 2012-01-12 01:08, schrieb Steve Ratcliffe:

Hi Martin

...

You can download the splitted tiles here: http://snailrun.de/Found_one.zip http://snailrun.de/Find_three.zip

Thanks, this is very helpful.

I think the problem is that I am missing the case where the same street is in different map tiles when creating mdr20.

I attach a new version of the patch, afraid I will not have time to do any testing or changes to it over the next few days, although I do have high hope of it being an improvement.

Pre-built jar file at: http://files.mkgmap.org.uk/download/49/mkgmap.jar

..Steve

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

On Thu, Jan 12, 2012 at 12:08:18AM +0000, Steve Ratcliffe wrote:

I attach a new version of the patch, afraid I will not have time to do any testing or changes to it over the next few days, although I do have high hope of it being an improvement.

I have not observed any problems related to this patch. Not that I observed the initial problem either. The next major improvements would be an option to specify the family-id for which to build the index, and to make house number search work. Marko

Hi In case anyone didn't notice, the patch was commited, so street search should work fairly well in gmapsupp indexes now.

The next major improvements would be an option to specify the family-id

It looks like you need a separate index for each family in the gmapsupp.img. So, while not a small change, that should be easy enough to do.

for which to build the index, and to make house number search work.

This could be possible with a team effort. First we need to be able to associate house numbers from OSM with the nodes in the road. This has to be done for each side of the street. Its quite possible that there is code somewhere that does this. ..Steve

Hi

Do you think it would be good to create a synthetic relation that provides such a mapping?

It seems to me that once you have enough information to link the address to the correct node to create a relation, then you have solved the problem and wouldn't need the relation.

...

Its quite possible that there is code somewhere that does this.

Any ideas where to search for that?

No idea, I thought that maybe one of the navigation programs that deals in street addresses might already do something useful, but it is quite possible that they work in a completely different way. ..Steve

I don't know if this helps: http://www.andnav.org/index.php/en/component/content/article/37-about-andnav... It's OpenSource and is hosted on http://code.google.com/p/andnav/ Cheers Martin Am 20.01.2012 um 23:40 schrieb WanMil:

...

Hi

...

Do you think it would be good to create a synthetic relation that provides such a mapping?

It seems to me that once you have enough information to link the address to the correct node to create a relation, then you have solved the problem and wouldn't need the relation.

Ok, you are right. I change my question. What do you think: Where should we put the code to link addresses to the correct node? I am more familar with OSM code using tags etc (all before the style system) so synthetic relations were my first idea to create a data structure that can be used later on.

WanMil _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi,

Date: Sat, 21 Jan 2012 21:52:14 +0000 From: steve@parabola.me.uk To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] gmapsupp + index and Berlin/Friedrichstr.

...

Ok, you are right. I change my question. What do you think: Where should we put the code to link addresses to the correct node? I am more familar with OSM code using tags etc (all before the style system) so synthetic

Right, it might be better to this after or during the roads being created in StyledConverter. I believe (not 100% sure) that numbers can only be attached to the nodes in a way, so it might be best to step down the way and find the nearest housenumber rather than look at all the housenumbers and try to match them to a road.

Ok, but you have to make sure that the house number belongs to that street, else you may assign the number to multiple streets.

This would mean that you may have to keep around a lot of information around for longer than if you did the housenumber step early on. I don't know the answer of the best way to do it.

I think this is a general point. If I got this right, mkgmap is doing a lot of complex calculations more than once. At some execution point, ways are split, at other points, ways are re-combined, sometimes distances are calculated, sometimes nearest nodes are searched. Maybe it is possible to find a good data structure (e.g. the quadtree used in LocationHook) that can be kept to aid such calculations?

..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

On Fri, Jan 20, 2012 at 06:43:51PM +0100, Martin wrote:

I think most of the housenumbers are connected to a street with the Karlsruhe-Schema (via relation or normal tagging), or?

I have seen both nodes with addr:* tags and building=* ways with addr:* tags. Some mappers seem to set addr:housenumber only. I try to set addr:street, addr:postcode, addr:city, addr:country. House number interpolation lines are rare around here; I have come across one. I guess that the algorithm could be something like this: * For all polygons that carry addr:housenumber, create an imaginary address point for the centroid. Process these converted points as well as all points that carry addr:housenumber. (I would not convert every way or node with addr:housenumber node to a fully featured POI. They should only be included in the house number index.) * Do whatever is needed for processing relations or interpolation lines. Or ignore them in the initial version. * If addr:street exists, try to match it to a nearby highway=* name=${addr:street}. Complain and ignore the house number if no matching street is found nearby. Maybe try matching to name:*=${addr:street} as well, for multilingual areas. * If addr:street does not exist, attach the point to the nearest highway=* & highway!=service & name!=*. If no such way exists nearby, complain and ignore the house number. * The search distance ('nearby') should be a configuration parameter. Best regards, Marko

Am 20.01.2012 23:05, schrieb Colin Smale:

How about using building=entrance if available instead of the centroid? That's also more likely to be closer to a street and less ambiguous as to which street. The centroid of a corner building will be closer to the long side, irrespective of where the entrance is. Yes, this feature is already implemented in add-pois-to-area.

First the algorithm should take information of Karlsruhe-Schema. If there is only an adressinterpolation, then there should be a linear interpolation between the given adressinformation. If this doesn't contains informations about streets, there should be a "bruteforce" to find next street. Information about country and city shouldn't be a problem after LocationHook. Henning

On Sun, Jan 22, 2012 at 11:11:57AM +0200, Rich wrote:

i prefer setting addresses for the building ways, but that's not really feasible if one building has several housenumbers assigned, of course.

What does Garmin allow in the house number field? Does it allow numbers and letters and some separator? For example, if we have addr:housenumber=4 on a building polygon, and the polygon has several building=entrance nodes, with ref=A, ref=B, ref=C, the entrances could be 4A, 4B, 4C. If the ref were 1,2,3, then the entrances could be 4-1, 4-2, 4-3 or 4 Apt. 1, 4 Apt. 2, 4 Apt. 3. There are different numbering schemes used, even within a single country. In Finland, we could have apartments 4A1, 4A2, 4A3, 4A4, 4B5, 4B6, 4B7, 4B8 in a small two-entrance block house (4 apartments reachable from each staircase). If each apartment had its own direct entrance from outdoors, then it would be 4A, 4B, 4C, ..., 4H or 4 Apt. 1 through 4 Apt. 8. If the property was split from an originally bigger property and the multi-entrance house was assigned the "base number" of 4B, then you would replace "4" with "4B" in the above.

general osm view seems to be that city & country are not encouraged to be used as they should be possible to derive from other (border) data

Right, the city&country can be fetched from the boundary data, if it is available. The addr:postcode can be trickier. Sometimes, a postcode boundary consists of suburbs (or parts thereof) in two adjacent towns. Also, the post may assert copyright on the postcode data, and could make noise if someone defined the postcode boundaries in OSM. This probably varies a lot between countries. Marko