Thanks for the tip. I removed "--link-pois-to-ways" and after that did not help, tried removing "--make-all-cycleways" as well. I can see that removing these options does change things as the map file becomes smaller - but search still fails in the exact same way. From what I understand about address search, the locator branch should not have any influence on the particular problem I am facing. The right streets are shown in the list - so they are assigned to the city correctly. But then the index is somehow broken so that narrowing the list down to a subset by typing a few letters does not work. Any other tips? - Bartosz

Have you tried to find roads in mapsource/basecamp?

I did try in MapSource, yes. With the map of Turin only that I had yesterday, street search in MapSource was as broken as it is on my Vista. With the full map of Italy now, street search appears to work in MapSource. Cities are auto-completed and so are street names. But it remains broken on the Vista.

How they look like?

The streets are drawn in white on a gray background. All streets are labeled with names and can be found successfully in MapSource.

Have you installed your map with the mapinstaller from garmin?

I mad a Windows installed from the NSIS script that mkgmap spit out, installed that and sent the map to my Vista through MapSource. - Bartosz

Thanks for that. I did some further investigation together with Dermot, another OSMer. Your map of Turin and my map of Italy behave in exactly the same way: Address search works on an Oregon but fails on two different Vista HCx devices. So there is something in the maps that mkgmap produces which Oregons are happy to live with but that trips up Vistas. Dermot has made a map of Ireland before that had working address search both on his Oregon and his Vista. I will download ireland.osm.bz2 now and give that a spin to check whether we have a regression. - Bartosz

OFFTOPIC: I suggest to download the pbf-files.

Yes, of course. The use of osm.bz2 files is a legacy decision. I have some mkgmap-related scripts that I wrote a long time ago and have not updated yet. So to make sure I can use my data files with these, I am sticking with osm.bz2 for now. Now, back onto topic: I just generated a map of Ireland. Identical settings, tool chain - and search works on my Vista. So this is *not* a regression but a genuine bug: Search will work on Oregon for both Italy and Ireland. It will only work on a vista for the latter of the two. Italian has more diacritical marks and these did cause trouble in the past. But Ireland has some diacritics as well - and everything is well there. So, how should we go about debugging this? - Bartosz

I made a fresh map, just to make sure there absolutely no cruft left anywhere. I used the newest italy.osm.pbf this time and the following mkgmap options: java -ea -Xmx2560m -jar ../../mkgmap.jar \ --description="Italia 21.3.2011" \ --country-name=Italia \ --country-abbr=ITA \ --latin1 \ --family-name="Italia 21.3.2011" \ --max-jobs \ --route \ --remove-short-arcs \ --adjust-turn-headings \ --add-pois-to-areas \ --generate-sea=multipolygon \ --index \ --nsis \ --tdbfile \ *.osm.gz This was then processed by MapSource and sent to my Vista. I verified that search is as broken as it was before. The resulting gmapsupp.img copied off my Vista is here: http://dev2.openstreetmap.ie/~plush/gmapsupp.img - Bartosz

First of all yes, the Legend is essentially a Vista without a barometer. So they are very similar. I applied your patch and regenerated the map of Italy. Search failed as before. I then started over with a tiny extract of central Turin. For this, search worked. I started increasing the download size and found the spot where search breaks (still using your patch). First, here are an OSM extract of Turin, the output of mkgmap for it and the gmapsupp.img that MapSource produces: http://dev2.openstreetmap.ie/~plush/torino_good.osm.bz2 http://dev2.openstreetmap.ie/~plush/torino_good.tar.bz2 http://dev2.openstreetmap.ie/~plush/gmapsupp_good.img.bz2 Second, here is the same data for a slightly larger area. With this, search on my Vista is broken: http://dev2.openstreetmap.ie/~plush/torino_bad.osm.bz2 http://dev2.openstreetmap.ie/~plush/torino_bad.tar.bz2 http://dev2.openstreetmap.ie/~plush/gmapsupp_bad.img.bz2 If you load the good gmapsupp.img onto your Legend, the initial list of streets in your Legend's search window should read: Corso Adriatico Corso Alcide de Gasperi Corso Bolzano Corso Brescia Corso Cairoli With the bad gmapsupp.img, the list I get is: Sp6 Corso Orbassano Corso Adriatico Corso Alcide de Gasperi Corso Bolzano Corso Bramante The road that is breaking alphabetical order here is tagged as name="Corso Orbassano", ref="SP6" - which seems valid. It does appear to make it into the index twice, though as "Sp6 Corso Orbassano" up in the list and then again as "Corso Orbassano (Sp6)". Let me know if there is any further data you might need. - Bartosz

El 31/03/11 23:07, Martin escribió:

Hello

I know there where some discussions about this topic before. I'm using the locator branch r1892. While the splitting-process the boundaries are broken and so some streets could not be found.

I've been generating map of Spain for some days (splitter+locator) and for me, most of boundaries are working after splitting, giving the right place-region-country matches. I have the following rules in my styles to set region: mkgmap:region!=* & is_in:province=* { set mkgmap:region='${is_in:province}' } mkgmap:region!=* & mkgmap:admin_level6=* { set mkgmap:region='${mkgmap:admin_level6}' } mkgmap:region!=* & mkgmap:admin_level4=* { set mkgmap:region='${mkgmap:admin_level4}' } mkgmap:region!=* & mkgmap:admin_level5=* { set mkgmap:region='${mkgmap:admin_level5}' } mkgmap:region!=* & mkgmap:admin_level3=* { set mkgmap:region='${mkgmap:admin_level3}' } In Spain there are 50 provinces, tagged as admin_level=6 and so MapSource drop down State/province list should show those 50 provinces, but for two of them many places are assigned to the admin_level=4 boundary, instead of the a_l=6 one. In one of them (relation id=349010) I've seen a_l=6 boundary is split in four tiles. If I extract the whole area covered by that boundary with osmosis [1] and generate the map in a single tile, places are assigned the right region from the a_l=6 boundary. Using the following command on spain.osm.pbf from Geofabrik: osmosis --rb spain.osm.pbf --tf reject-ways source='EU%sCORINE%sland%scover%s2006' --tf reject-nodes "rednap:codigoine"=* --write-pbf file="spain-filtrado.osm.pbf" omitmetadata=true java -Xmx1000M -jar splitter.jar --max-nodes=2800000 --geonames-file=cities15000.zip --mapid=55140001 spain-filtrado.osm.pbf [2] java -Xmx1500m -enableassertions -Dlog.config=logging.properties -jar mkgmap-locator.jar --max-jobs --generate-sea=polygons,extend-sea-sectors --route --latin1 --code-page=1252 --gmapsupp --country-name=ESPAÑA --country-abbr=ESP --area-name=España --family-name="OpenStreetMap España" --family-id=39 --product-id=1 --series-name="OSM-España-index" --index --ignore-maxspeeds --remove-short-arcs --add-pois-to-areas --adjust-turn-headings --report-similar-arcs --link-pois-to-ways --location-autofill=0 --drive-on-right --check-roundabouts --check-roundabout-flares --style=mio -c spain.args [3] [1] osmosis --rb spain.osm.pbf --bb left=-7.079 right=-4.728 top=43.242 bottom=42.027 completeWays=yes completeRelations=yes --write-pbf file="leon.osm.pbf" [2] Current areas.list: 55140001: 1798144,-354304 to 1904640,-137216 # : 38.583984,-7.602539 to 40.869141,-2.944336 55140002: 1730560,-34816 to 1910784,227328 # : 37.133789,-0.747070 to 41.000977,4.877930 55140003: 1904640,-256000 to 1986560,-137216 # : 40.869141,-5.493164 to 42.626953,-2.944336 55140004: 1910784,2048 to 2000896,79872 # : 41.000977,0.043945 to 42.934570,1.713867 55140005: 1675264,-354304 to 1798144,-137216 # : 35.947266,-7.602539 to 38.583984,-2.944336 55140006: 1689600,-137216 to 1910784,-34816 # : 36.254883,-2.944336 to 41.000977,-0.747070 55140007: 1904640,-440320 to 1982464,-256000 # : 40.869141,-9.448242 to 42.539063,-5.493164 55140008: 1910784,79872 to 1984512,182272 # : 41.000977,1.713867 to 42.583008,3.911133 55140009: 1986560,-256000 to 2039808,-137216 # : 42.626953,-5.493164 to 43.769531,-2.944336 55140010: 1910784,-137216 to 2037760,2048 # : 41.000977,-2.944336 to 43.725586,0.043945 55140011: 1982464,-452608 to 2056192,-256000 # : 42.539063,-9.711914 to 44.121094,-5.493164 [3] spain.args: mapname: 55140001 description: ES-Madrid input-file: 55140001.osm.gz mapname: 55140002 description: ES-Valencia input-file: 55140002.osm.gz mapname: 55140003 description: ES-Valladolid input-file: 55140003.osm.gz mapname: 55140004 description: ES-Tarragona input-file: 55140004.osm.gz mapname: 55140005 description: ES-Sevilla input-file: 55140005.osm.gz mapname: 55140006 description: ES-Murcia input-file: 55140006.osm.gz mapname: 55140007 description: ES-Vigo input-file: 55140007.osm.gz mapname: 55140008 description: ES-Barcelona input-file: 55140008.osm.gz mapname: 55140009 description: ES-Santander input-file: 55140009.osm.gz mapname: 55140010 description: ES-Zaragoza input-file: 55140010.osm.gz mapname: 55140011 description: ES-Gijon input-file: 55140011.osm.gz input-file: typ/SPAIN-14.TYP

I tried to fix this problem by opening the single tiles in JOSM, complete the boundaries, process the tiles again with the splitter and create the map. A very annoying job, but now I can find streets, which I could not found before. So two questions: Are you planning to fix this problem in the splitter (maybe as an option). And my second question: Will be the locator-option fully integrated into mkgmap permanently or not. Actually it's the only way to make street-searchable maps for Germany (with the normal version you only can find the streets in the suburb of a city).

I agree with you. Although locator is still not perfect, I get much better search functionality with it than with trunk, in spite of the problems reported above.

Cheers Martin

Am 23.03.2011 um 21:03 schrieb Bartosz Fabianowski:

...

First of all yes, the Legend is essentially a Vista without a barometer. So they are very similar.

I applied your patch and regenerated the map of Italy. Search failed as before. I then started over with a tiny extract of central Turin. For this, search worked. I started increasing the download size and found the spot where search breaks (still using your patch).

First, here are an OSM extract of Turin, the output of mkgmap for it and the gmapsupp.img that MapSource produces:

http://dev2.openstreetmap.ie/~plush/torino_good.osm.bz2 http://dev2.openstreetmap.ie/~plush/torino_good.tar.bz2 http://dev2.openstreetmap.ie/~plush/gmapsupp_good.img.bz2

Second, here is the same data for a slightly larger area. With this, search on my Vista is broken:

http://dev2.openstreetmap.ie/~plush/torino_bad.osm.bz2 http://dev2.openstreetmap.ie/~plush/torino_bad.tar.bz2 http://dev2.openstreetmap.ie/~plush/gmapsupp_bad.img.bz2

If you load the good gmapsupp.img onto your Legend, the initial list of streets in your Legend's search window should read:

Corso Adriatico Corso Alcide de Gasperi Corso Bolzano Corso Brescia Corso Cairoli

With the bad gmapsupp.img, the list I get is:

Sp6 Corso Orbassano Corso Adriatico Corso Alcide de Gasperi Corso Bolzano Corso Bramante

The road that is breaking alphabetical order here is tagged as name="Corso Orbassano", ref="SP6" - which seems valid. It does appear to make it into the index twice, though as "Sp6 Corso Orbassano" up in the list and then again as "Corso Orbassano (Sp6)".

Let me know if there is any further data you might need.

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

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

-- Por favor, no me envíe documentos con extensiones .doc, .docx, .xls, .xlsx, .ppt, .pptx, .mdb, mdbx Instale OpenOffice desde http://es.openoffice.org/programa/index.html OpenOffice es libre: se puede copiar, modificar y redistribuir libremente. Gratis y totalmente legal. OpenOffice está en continuo desarrollo y no tendrá que pagar por las nuevas versiones.

For Germany I use the following settings: mkgmap:city!=* & openGeoDB:name=* { set mkgmap:city='${openGeoDB:name}' } mkgmap:city!=* & is_in:city=* { set mkgmap:city='${is_in:city}' } mkgmap:city!=* & addr:city=* { set mkgmap:city='${addr:city}' } mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:city!=* & mkgmap:admin_level6=* { set mkgmap:city='${mkgmap:admin_level6}' } mkgmap:city!=* & mkgmap:admin_level7=* { set mkgmap:city='${mkgmap:admin_level7}' } mkgmap:city!=* & mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' } mkgmap:city!=* & mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' } Maybe I will try the new locator branch but the most problems come from the splitting-process. Try to find streets within boundaries, which where splitted. I wask asking, because maybe we can fix this with a perl-script, but this will take me some time/days ;) Maybe someone has already done this or there is a solution in development, I can wait... Cheers Martin Am 01.04.2011 um 09:07 schrieb Minko:

For generating the Benelux cycling maps of openfietsmap.nl, I've been using mkgmap-locator-r1901.jar. Since there are 5 different countries in my map, and the country assignment doesn't work very well (multipolygon relation too big?), I skipped them in my styles. This shows an empty button in the which country menu, http://img21.imageshack.us/img21/4263/adressearch.png

For the regions (Provinces) the same problems with assignment occur so I rahter skip them too. I use these settings, which works very well as far as I have tested with streets in the Netherlands:

mkgmap:city!=* & openGeoDB:name=* { set mkgmap:city='${openGeoDB:name}' } mkgmap:city!=* & is_in:city=* { set mkgmap:city='${is_in:city}' } mkgmap:city!=* & addr:city=* { set mkgmap:city='${addr:city}' }

mkgmap:city!=* & mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' } mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:city!=* & mkgmap:admin_level6=* { set mkgmap:city='${mkgmap:admin_level6}' }

Admin_level=10 is the most important level for assigning streetnames to placenames, and this works much better with the locator.jar than the default mkgmap.jar

I'm not sure what the best settings are for Germany, maybe someone can have a look at my map since it contains a wide German border area too. See http://www.openfietsmap.nl

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

I have further reduced the problematic map down to a tiny testcase. All that is left is: * A single city node providing location information to mkgmap * A single road with two nodes The road is called "Demo Street" and has a ref of "S6". If I build a map out of this data file and install it on my Vista via MapSource, search does not work. The street shows up three times in the list, as "S6 Demo Street", "Demo Street (S6)" and "S6". Typing "D" should narrow down the list to "Demo Street (S6)" only. Instead, I get "None Found". Typing "S" instead should probably yield both "S6 Demo Street" and "S6". I get the latter one only. Changing the ref from "S6" to "6" seems to fix the issue. Removing the ref altogether fixes it as well. None of this makes any sense to me. There are plenty of streets with bot a name and a ref all over the world - and these work fine. There is something very specific going on here that I do not understand. My mkgmap knowledge does not reach far enough to fix this issue myself. Any help would be much appreciated. - Bartosz

Perhaps its because in many countries refs begin with 'A' or 'B' and so sort early anyway. (Not true in the USA though, so can't be the whole reason).

I have done a lot of testing to try and isolate the bug as best as possible. I was unable to break routing in Ireland - and there, refs start with "L", "N" and "R". So it is something more complicated, just as you said. - Bartosz

Sorry to be providing insights piecemeal... but I just found another thing: In Ireland, search actually fails on a street-by-street basis: * If a street has no ref, it can be found * If a street has a ref that comes after its name, alphabetically, it can be found * If a street has a ref that comes *before* its name, alphabetically, the street is *not* found. So, in Ireland, the sort order seems to break individual streets. In Italy, I found that search was totally broken once a single street exhibiting the above problem was present in the map. I cannot explain the difference... but either way, the above points to a bug that should affect many countries (probably all countries). - Bartosz

Hi Thanks for your work on this. I now believe that the shield code should not strongly affect the sort order, whereas before I thought they did. Could you try the attached patch please. ..Steve

It looks like we may not be out of the woods yet on this one - with the latest patch, trying to build a map of Ireland (from the Geofabrik extract) fails, where it had succeeded before. Single tile, no splitting: java.lang.ArrayIndexOutOfBoundsException: 36 at uk.me.parabola.imgfmt.app.srt.SrtSortKey.compareTo(SrtSortKey.java:41) at uk.me.parabola.imgfmt.app.srt.SrtSortKey.compareTo(SrtSortKey.java:22) at java.util.Arrays.mergeSort(Arrays.java:1167) at java.util.Arrays.mergeSort(Arrays.java:1155) at java.util.Arrays.mergeSort(Arrays.java:1155) at java.util.Arrays.sort(Arrays.java:1079) at java.util.Collections.sort(Collections.java:117) at uk.me.parabola.imgfmt.app.net.NETFile.writePost(NETFile.java:82) at uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:228) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:101) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:65) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:224) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:221) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:680) Exiting - if you want to carry on regardless, use the --keep-going option Command line is: java -Xms2g -Xmx2g -Dlog.config=svn/mkgmap/logging.properties -jar svn/mkgmap/dist/mkgmap.jar --family-id=333 --mapname=55555555 --family-name='OSM Ireland' --series-name='OSM Ireland' --description='OSM Ireland' --country-name='IRELAND' --country-abbr='IRL' --latin1 --gmapsupp --net --route --index --tdbfile --add-pois-to-areas --remove-short-arcs --check-roundabouts --generate-sea=multipolygon --check-roundabout-flares ireland.osm dermot3.TYP Worth knowing about in case the same problem doesn't get spotted in other tests. Cheers, Dermot -- -------------------------------------- Igaühel on siin oma laul ja ma oma ei leiagi üles

On 31 March 2011 08:21, Steve Ratcliffe <steve@parabola.me.uk> wrote:

Thanks for trying out the patch. That is indeed a problem, please try the updated patch attached.

Hi Steve, That compiles just fine, thanks for the fix. I'll do some testing to make sure searching works well. Dermot -- -------------------------------------- Igaühel on siin oma laul ja ma oma ei leiagi üles