[mkgmap-dev] Address search issues
Hi, I'm having a hard time getting the address search to work. I have split the area of Germany from the planet pbf file. Then I build the Garmin IMGs with this commandline: /usr/java/jdk1.6.0_24/bin/java -enableassertions -Xmx2048m -jar /data/gps/mkgmap-r2294/mkgmap.jar and this mkgmap config file: ### description=OSM_Germany_Alps country-name=Germany country-abbr=DE region-name=Germany region-abbr=DE name-tag-list="name:mkgmap,name:de,int_name,name:en,name" overview-mapname=OSM_Germany_Alps overview-mapnumber=1000 latin1 reduce-point-density=4 merge-lines=yes family-id=1331 product-id=1 series-name=OSM_SRTM_Germany_Alps family-name=OSM_Germany area-name=Germany index style-file=/data/gps/mkgmap-style-toponew_test120611/ tdbfile=no route=yes road-name-pois=0x640a add-pois-to-areas make-opposite-cycleways=yes remove-short-arcs adjust-turn-headings link-pois-to-ways bounds=/data/gps/boundary/bounds/ location-autofill=bounds,is_in,nearest generate-sea=extend-sea-sectors,multipolygon,close-gaps=1000,floodblocker,fbgap=200,fbthres=20,fbratio=0.5 mapname: 1001 description: FR-Besancon input-file: 1001.osm.gz ... [more mapname/description/input-file lines] ### The directory /data/gps/boundary/bounds/ contains the unzipped file http://www.navmaps.eu/wanmil/bounds_20120401.zip The "lines", "points" and "polygons" files in my style contain the top lines from the default style which set the location tags AFAIK. I make the mapsource files afterwards: ### description=OSM_SRTM_Germany country-name=Germany country-abbr=DE region-name=Germany region-abbr=DE name-tag-list="name:mkgmap,name:de,int_name,name:en,name" overview-mapname=OSM_SRTM_Germany overview-mapnumber=1000 latin1 series-name=OSM_SRTM_Germany area-name=Test family-id=1331 product-id=1 family-name=OSM_Germany index tdbfile=yes input-file: 1001.img ... [more tile files] ### When I try the address search in mapsource I get this: City search for "Berlin": Berlin is found, but mapsource displays "Berlin, NOT_SET, DEU". When I search for a street in Berlin (say, Alexanderstrasse, I can see the POI on the map) I cannot enter "Berlin" in the City field. As soon as I enter the "i" mapsource deletes it again. When I enter the postcode (10178 for Alexanderstrasse, Berlin) the street is found. Mapsource displays "Alexanderstrasse, Not_Set, NOT_SET, DEU". I tried this for various cities and streets. When I build a gmapsupp.img it behaves rather the same in my eTrex Legend HCx. Any ideas? Is there anything wrong with the bounds data or the style files? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Address search issues
Hi list I am trying to get address search going. It is almost working but not quite. I have updated mkgmap to the newest trunk and am invoking it with: java -ea -Xmx1536m -jar ../../mkgmap.jar \ --gmapsupp \ --description="Italia 19.03.2011" \ --countryname=Italia \ --country-abbr=ITA \ --latin1 \ --family-name="$country $date" \ --max-jobs \ --route \ --remove-short-arcs \ --adjust-turn-headings \ --add-pois-to-areas \ --generate-sea=multipolygon \ --index \ --nsis \ --make-all-cycleways \ --link-pois-to-ways \ --tdbfile \ torino.osm The OSM file used for testing is just the city center of Turin, Italy, downloaded via JOSM. After mkgmap has built the map, I am generating an NSIS installer, installing it in Windows XP running under VirtualBox and uploading to my Vista HCX. During address search, everything works as expected first. The Vista lets me select "Italia" for the country and "Torino, ITA" for the city (no other country or city is shown). I can enter an arbitrary house number. When I select the street name field, I get a complete alphabetical list. Entering *any* letter makes the device show "Not found". If, instead, I scroll down the list to the street I am looking for and select that, it is found correctly on the map. In MapSource, address search suffers a very similar problem. Here, too, starting to type a street name does not narrow down my choices as it should. Instead, it has unpredictable effects. For example, typing the single letter "D", instead of reducing the list to streets with "D" in their name, scrolls down to the first street starting with "F". Something seems to be off with the index. I would appreciate any tips on what to try. - Bartosz ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search issues
On Thu, Jun 14, Ralf kleineisel wrote:
> When I try the address search in mapsource I get this:
>
> City search for "Berlin":
> Berlin is found, but mapsource displays "Berlin, NOT_SET, DEU".
Looks like somebody played with the admin boarder of Berlin :(
I guess you need now:
mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level4=Hamburg { set
mkgmap:city='${mkgmap:admin_level4}' }
mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level4=Berlin { set
mkgmap:city='${mkgmap:admin_level4}' }
Before the "mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level8=*"
rules.
Haven't tried it yet, but the problem sounds the same as we had
for Hamburg.
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)
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search issues
On 06/14/2012 10:10 PM, Thorsten Kukuk wrote:
> On Thu, Jun 14, Ralf kleineisel wrote:
>
>> When I try the address search in mapsource I get this:
>>
>> City search for "Berlin":
>> Berlin is found, but mapsource displays "Berlin, NOT_SET, DEU".
>
> Looks like somebody played with the admin boarder of Berlin :(
>
> I guess you need now:
> mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level4=Hamburg { set
> mkgmap:city='${mkgmap:admin_level4}' }
> mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level4=Berlin { set
> mkgmap:city='${mkgmap:admin_level4}' }
This didn't help.
To find the correct values I tried this:
highway=* { set mkgmap:city='${mkgmap:admin_level2}' }
as the first line in the "lines" file.
This gives me "DEU, NOT_SET_, DEU" for a street in Berlin.
Then I tried the same for all admin_level values from 3 up to 11. For
all of them I get: "Not_set, NOT_SET_, DEU"
Seems mkgmap doesn't find any bounds except the level2 one. How can I
debug this a bit more?
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search issues
> On 06/14/2012 10:10 PM, Thorsten Kukuk wrote:
>> On Thu, Jun 14, Ralf kleineisel wrote:
>>
>>> When I try the address search in mapsource I get this:
>>>
>>> City search for "Berlin":
>>> Berlin is found, but mapsource displays "Berlin, NOT_SET, DEU".
>>
>> Looks like somebody played with the admin boarder of Berlin :(
>>
>> I guess you need now:
>> mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level4=Hamburg { set
>> mkgmap:city='${mkgmap:admin_level4}' }
>> mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level4=Berlin { set
>> mkgmap:city='${mkgmap:admin_level4}' }
>
> This didn't help.
>
> To find the correct values I tried this:
>
> highway=* { set mkgmap:city='${mkgmap:admin_level2}' }
>
> as the first line in the "lines" file.
>
> This gives me "DEU, NOT_SET_, DEU" for a street in Berlin.
>
> Then I tried the same for all admin_level values from 3 up to 11. For
> all of them I get: "Not_set, NOT_SET_, DEU"
>
> Seems mkgmap doesn't find any bounds except the level2 one. How can I
> debug this a bit more?
>
Hi Ralf,
first of all you should have a look at the error messages in the mkgmap
log file. To get a logfile you have to configure the logging system as
described in
http://wiki.openstreetmap.org/wiki/Mkgmap/dev#Enabling_Debugging
After the first tile has been processed maybe you see a message like
"LocationHook is disabled because ...". In this case there is a problem
with the bounds directory or files. Just post the error message and we
will see.
If you don't see such a message you might enable a brute force logging.
Add the line
uk.me.parabola.mkgmap.reader.osm.LocationHook.results.level=FINE
to your logging.properties file and start mkgmap with a tile of Berlin
again. Your log file will contain the boundary assignments of all OSM
elements. This info is only the data of the bounds directory and not of
the is_in and neareast algorithm. But these two algorithms should not
play a big role in a well mapped region like Berlin.
Hopefully you get an idea what's wrong. If not post a small part of the
logfile so that I can have a look on it.
WanMil
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search issues
> Hi, > > I'm having a hard time getting the address search to work. > > I have split the area of Germany from the planet pbf file. > > Then I build the Garmin IMGs with this commandline: > > /usr/java/jdk1.6.0_24/bin/java -enableassertions -Xmx2048m -jar > /data/gps/mkgmap-r2294/mkgmap.jar > > and this mkgmap config file: > > ### > description=OSM_Germany_Alps > country-name=Germany > country-abbr=DE > region-name=Germany > region-abbr=DE > name-tag-list="name:mkgmap,name:de,int_name,name:en,name" > overview-mapname=OSM_Germany_Alps > overview-mapnumber=1000 > latin1 > reduce-point-density=4 > merge-lines=yes > family-id=1331 > product-id=1 > series-name=OSM_SRTM_Germany_Alps > family-name=OSM_Germany > area-name=Germany > index > style-file=/data/gps/mkgmap-style-toponew_test120611/ > tdbfile=no > route=yes > road-name-pois=0x640a > add-pois-to-areas > make-opposite-cycleways=yes > remove-short-arcs > adjust-turn-headings > link-pois-to-ways > bounds=/data/gps/boundary/bounds/ > location-autofill=bounds,is_in,nearest > generate-sea=extend-sea-sectors,multipolygon,close-gaps=1000,floodblocker,fbgap=200,fbthres=20,fbratio=0.5 > mapname: 1001 > description: FR-Besancon > input-file: 1001.osm.gz > ... [more mapname/description/input-file lines] > ### > > The directory /data/gps/boundary/bounds/ contains the unzipped file > http://www.navmaps.eu/wanmil/bounds_20120401.zip > > The "lines", "points" and "polygons" files in my style contain the top > lines from the default style which set the location tags AFAIK. > > I make the mapsource files afterwards: > > ### > description=OSM_SRTM_Germany > country-name=Germany > country-abbr=DE > region-name=Germany > region-abbr=DE > name-tag-list="name:mkgmap,name:de,int_name,name:en,name" > overview-mapname=OSM_SRTM_Germany > overview-mapnumber=1000 > latin1 > series-name=OSM_SRTM_Germany > area-name=Test > family-id=1331 > product-id=1 > family-name=OSM_Germany > index > tdbfile=yes > input-file: 1001.img > ... [more tile files] > ### > > When I try the address search in mapsource I get this: > > City search for "Berlin": > Berlin is found, but mapsource displays "Berlin, NOT_SET, DEU". > > When I search for a street in Berlin (say, Alexanderstrasse, I can see > the POI on the map) I cannot enter "Berlin" in the City field. As soon > as I enter the "i" mapsource deletes it again. > > When I enter the postcode (10178 for Alexanderstrasse, Berlin) the > street is found. Mapsource displays "Alexanderstrasse, Not_Set, NOT_SET, > DEU". > > I tried this for various cities and streets. > > When I build a gmapsupp.img it behaves rather the same in my eTrex > Legend HCx. > > Any ideas? Is there anything wrong with the bounds data or the style files? > Hi Ralf, I have a second idea after having a look at your mkgmap parameters. Please try to run both mkgmap calls with tdbfile. I am not sure if the tdbfile=no in the first run has an effect or not. WanMil P.S.: By the way: I recommend to use the precompiled sea data. This compiles much quicker than the previous methods and the results regarding flooding problems are much better. You can enable it using the parameter precomp-sea= instead of generate-sea. You can download the sea tile from http://www.navmaps.eu/wanmil/sea_20120614.zip ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search issues
Hi Wanmil, i have a question regarding the precompiled sea tiles: I normally use the generate-sea-options in conjunction with a coastline-file. If i use the precompiled sea files instead, do i still need the coastline-file? Regards, UliBär ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search issues
> Hi Wanmil, > > i have a question regarding the precompiled sea tiles: > I normally use the generate-sea-options in conjunction with a coastline-file. > If i use the precompiled sea files instead, do i still need the > coastline-file? > > Regards, UliBär > Hi UliBär, when using the precomp-sea option the coastline-file is ignored. So you don't need it any more. For details please have a look at the mkgmap help java -jar mkgmap.jar --help=precomp-sea WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search issues
On 07/08/2012 10:37 PM, WanMil wrote:
> first of all you should have a look at the error messages in the mkgmap
> log file. To get a logfile you have to configure the logging system as
> described in
> http://wiki.openstreetmap.org/wiki/Mkgmap/dev#Enabling_Debugging
Thanks, now I could start debugging this.
It seems that the problem is this line in my config;
name-tag-list="name:de,int_name,name:en,name"
Without it everything looks good.
Any ideas?
Originally I had
"name-tag-list="name:mkgmap,name:de,int_name,name:en,name", and the
name:mkgmap was set in the style like this;
aerialway=* & is_in ~ '.*(Deutschland|Germany|Österreich|Austria).*'
{add name:mkgmap = '${name}'}
This was meant to prefer "name" to "int_name" for elements in
german-speaking countries and in non.german-speaking countries prefer
the "int_name". But it doesn't matter which of the "name-tag-list" lines
I use, it breaks the index.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search issues
On Fri, Jul 13, Ralf kleineisel wrote: > On 07/08/2012 10:37 PM, WanMil wrote: > > > first of all you should have a look at the error messages in the mkgmap > > log file. To get a logfile you have to configure the logging system as > > described in > > http://wiki.openstreetmap.org/wiki/Mkgmap/dev#Enabling_Debugging > > Thanks, now I could start debugging this. > > It seems that the problem is this line in my config; > > name-tag-list="name:de,int_name,name:en,name" > > Without it everything looks good. > > Any ideas? Besides that I run into and reported the same problem already right at the beginning, no. But I can confirm that choosing anything else beside "name" as first entry in name-tag-list will most likely break the search index. I had the feeling that name-tag-list is not used in all places, or there is a problem if only some objects supports the other name, but not all in that area. 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) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search issues
> On 07/08/2012 10:37 PM, WanMil wrote:
> AU
>> first of all you should have a look at the error messages in the mkgmap
>> log file. To get a logfile you have to configure the logging system as
>> described in
>> http://wiki.openstreetmap.org/wiki/Mkgmap/dev#Enabling_Debugging
>
> Thanks, now I could start debugging this.
>
> It seems that the problem is this line in my config;
>
> name-tag-list="name:de,int_name,name:en,name"
>
> Without it everything looks good.
>
> Any ideas?
>
> Originally I had
> "name-tag-list="name:mkgmap,name:de,int_name,name:en,name", and the
> name:mkgmap was set in the style like this;
> aerialway=* & is_in ~ '.*(Deutschland|Germany|Österreich|Austria).*'
> {add name:mkgmap = '${name}'}
I propose to use the following rule after the country assignment:
arialway=* & mkgmap:country ~ '(DEU|AUT|CHE)' ...
The is_in tag is not very reliable.
>
> This was meant to prefer "name" to "int_name" for elements in
> german-speaking countries and in non.german-speaking countries prefer
> the "int_name". But it doesn't matter which of the "name-tag-list" lines
> I use, it breaks the index.
>
Please be a bit more specific. What do you mean with "it breaks the
index" and "is working" or "is not working". Please post your complete
style files, your option file and your mkgmap call. If possible give a
concrete example, e.g. a specific POI and/or a specific street and write
what you see and what you expect.
Otherwise I fear that there will be some misunderstandings what you mean.
Thanks
WanMil
P.S.: I am busy at the moment so probably I cannot give you an answer
within the next 4 weeks but I will check that when I have time again!
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search issues
> On 07/08/2012 10:37 PM, WanMil wrote:
>
>> first of all you should have a look at the error messages in the mkgmap
>> log file. To get a logfile you have to configure the logging system as
>> described in
>> http://wiki.openstreetmap.org/wiki/Mkgmap/dev#Enabling_Debugging
>
> Thanks, now I could start debugging this.
>
> It seems that the problem is this line in my config;
>
> name-tag-list="name:de,int_name,name:en,name"
Please remove the " if you put the option in a config file.
name-tag-list=name:de,int_name,name:en,name
works for me which means the map contains city, region and country names
for all POIs and streets.
WanMil
>
> Without it everything looks good.
>
> Any ideas?
>
> Originally I had
> "name-tag-list="name:mkgmap,name:de,int_name,name:en,name", and the
> name:mkgmap was set in the style like this;
> aerialway=* & is_in ~ '.*(Deutschland|Germany|Österreich|Austria).*'
> {add name:mkgmap = '${name}'}
>
> This was meant to prefer "name" to "int_name" for elements in
> german-speaking countries and in non.german-speaking countries prefer
> the "int_name". But it doesn't matter which of the "name-tag-list" lines
> I use, it breaks the index.
>
> ___
> 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
Re: [mkgmap-dev] Address search issues
> On 07/08/2012 10:37 PM, WanMil wrote:
>
>> first of all you should have a look at the error messages in the mkgmap
>> log file. To get a logfile you have to configure the logging system as
>> described in
>> http://wiki.openstreetmap.org/wiki/Mkgmap/dev#Enabling_Debugging
>
> Thanks, now I could start debugging this.
>
> It seems that the problem is this line in my config;
>
> name-tag-list="name:de,int_name,name:en,name"
>
> Without it everything looks good.
>
> Any ideas?
>
> Originally I had
> "name-tag-list="name:mkgmap,name:de,int_name,name:en,name", and the
> name:mkgmap was set in the style like this;
> aerialway=* & is_in ~ '.*(Deutschland|Germany|Österreich|Austria).*'
> {add name:mkgmap = '${name}'}
>
> This was meant to prefer "name" to "int_name" for elements in
> german-speaking countries and in non.german-speaking countries prefer
> the "int_name". But it doesn't matter which of the "name-tag-list" lines
> I use, it breaks the index.
>
Ralf,
is this problem still present or did the removal of " in the
name-tag-list option solve your problem?
WanMil
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search issues
On 07/29/2012 05:59 PM, WanMil wrote: > is this problem still present or did the removal of " in the > name-tag-list option solve your problem? The removal of the name-tag-list optionse solved it for me. I adapted my style files to get the same result. I haven't had time to track the issue further down. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search issues
To follow up on my earlier post, I have tried running mkgmap again on a full Geofabrik extract of Italy, split using splitter.jar with default settings. Address search still fails: I can select a country on my Vista and I do get proper behavior when typing a city. But when I start typing a street, either I get "no results" after a single letter or the streets are filtered to a nonsensical subset. The alphabetic index definitely is off somehow. Is there anything I can try to debug this? - Bartosz ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search issues
Refering to your last email you are using the "--link-pois-to-ways" option. On my oregon I had the same problems you are describing here. Try it without and it should work. Maybe you should also use the locator branch with modified style files. Am 21.03.2011 um 17:46 schrieb Bartosz Fabianowski: > To follow up on my earlier post, I have tried running mkgmap again > on a > full Geofabrik extract of Italy, split using splitter.jar with default > settings. Address search still fails: > > I can select a country on my Vista and I do get proper behavior when > typing a city. But when I start typing a street, either I get "no > results" after a single letter or the streets are filtered to a > nonsensical subset. The alphabetic index definitely is off somehow. > > Is there anything I can try to debug this? > > - 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
Re: [mkgmap-dev] Address search issues
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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search issues
Have you tried to find roads in mapsource/basecamp? How they look like? Have you installed your map with the mapinstaller from garmin? Am 21.03.2011 um 19:40 schrieb Bartosz Fabianowski: > 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 > ___ > 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
Re: [mkgmap-dev] Address search issues
> 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search issues
Hello Bartosz, I've make a map and uploaded the tile arround Torino. www.snailrun.de/images/gmapsupp.img.zip Download it, unzip it and copy it to your Garmin. For me it works on my Oregon. I can find many streets within Torino. What have I done: -Downloaded italy.osm.pbf -Splittet the file into tiles (max 100 nodes) - Downloaded mkgmap from trunk and created the map with: java -Xmx1024M -jar mkgmap/dist/mkgmap.jar --latin1 --series- name=MkgmapIndex --family-name=MkgmapTest --remove-short-arcs --index --net --route --tdbfile --nsis --merge-lines --location-autofill=0 -- country-name=Italia --country-abbr=ITA --area-name=ITA ./tiles_italy/ *.osm.gz - Merged all files with gmapi-builder and installed the map with Garmin MapInstaller - Installed the Map on my Oregon Am 21.03.2011 um 20:43 schrieb Martin: > Have you tried to find roads in mapsource/basecamp? > How they look like? > Have you installed your map with the mapinstaller from garmin? > Am 21.03.2011 um 19:40 schrieb Bartosz Fabianowski: > >> 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 >> ___ >> 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 > ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search issues
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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search issues
OFFTOPIC: I suggest to download the pbf-files. They are smaller and the splitter works faster with them. Anyways, strange thing, because I made a also a German Map for a friend and it also works on an Etrex Vista HCx and my Oregon Greetings Martin Am 21.03.2011 um 22:55 schrieb Bartosz Fabianowski: > 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 > ___ > 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
Re: [mkgmap-dev] Address search issues
> 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search issues
Hi > So, how should we go about debugging this? Could you upload the broken map somewhere please. You can use http://files.mkgmap.org.uk or anywhere else suitable that you have. Thanks ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search issues
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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search issues
On 22/03/11 00:44, Bartosz Fabianowski wrote:
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:
Thanks, I have seen some strangeness with it, although not clear if it
is quite what you are seeing. I have a Legend, which I believe is very
similar to the Vista.
From your first message, it seemed like you had problems with just a
single tile. If so it would be to have that or indeed the smallest map
that shows the problem.
I have an idea what it might be, could you try the attached patch?
..Steve
Index: src/uk/me/parabola/imgfmt/app/net/NETFile.java
===
--- src/uk/me/parabola/imgfmt/app/net/NETFile.java (revision 1870)
+++ src/uk/me/parabola/imgfmt/app/net/NETFile.java (revision )
@@ -71,8 +71,7 @@
Label[] l = rd.getLabels();
for(int i = 0; i < l.length && l[i] != null; ++i) {
if(l[i].getLength() != 0) {
- String cleanName = l[i].getTextSansGarminCodes();
- SortKey sortKey = sort.createSortKey(new LabeledRoadDef(l[i], rd), cleanName);
+ SortKey sortKey = sort.createSortKey(new LabeledRoadDef(l[i], rd), l[i].getText());
sortKeys.add(sortKey);
}
}
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search issues
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
Re: [mkgmap-dev] Address search issues
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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search issues
Hi > 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". Thanks for the very good example! I haven't forgotten about this although I don't have an answer. I initially believed that it was to do with the shield symbol that gets inserted before the 'S6'. This makes it sort earlier than 'Demo' if it is counted in the sort, and later if not. The purpose of the previous patch I posted was to investigate that, although when it made no difference that seemed to rule out that reason. I shall try with this test file more things with this test file. > 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. 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). It may take a while to figure it out. Thanks, ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search issues
> 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search issues
I have some further data points: 1. Changing ref="S6" to ref="A6" *does* make search work again. So if the ref comes before the street name alphabetically, all is good. 2. I made a corresponding minimal extract of Dublin, Ireland. I found that the same thing happens: If the single street has a ref that comes after its name, things break. If the ref comes before the name alphabetically, all is good. 3. I tested a map of all of Ireland. This contains many streets with names in the entire A-Z range and, at minimum, refs starting with L, N, R. Search seems to work for the entire alphabet, including names at the very end of the alphabet. I remain puzzled. - Bartosz ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search issues
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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search issues
> * 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. Argh, I got these two the wrong way around :(. The correct statements are: * ref before name works * ref after name fails ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search issues
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
Index: src/uk/me/parabola/imgfmt/app/Label.java
===
--- src/uk/me/parabola/imgfmt/app/Label.java (revision 1650)
+++ src/uk/me/parabola/imgfmt/app/Label.java (revision )
@@ -56,10 +56,6 @@
return text;
}
- public String getTextSansGarminCodes() {
- return stripGarminCodes(text);
- }
-
// highway shields and "thin" separators
private final static Pattern SHIELDS = Pattern.compile("[\u0001-\u0006\u001b-\u001c]");
Index: src/uk/me/parabola/imgfmt/app/srt/Sort.java
===
--- src/uk/me/parabola/imgfmt/app/srt/Sort.java (revision 1873)
+++ src/uk/me/parabola/imgfmt/app/srt/Sort.java (revision )
@@ -94,21 +94,29 @@
byte[] bval = out.array();
byte[] key = new byte[bval.length * 3 + 3];
int length = bval.length;
- for (int i = 0; i < length; i++) {
-int b = bval[i] & 0xff;
-key[i] = primary[b];
-key[length + 1 + i] = secondary[b];
-key[2*length + 2 + i] = tertiary[b];
- }
- key[length] = 0;
- key[2 * length + 1] = 0;
- key[3 * length + 2] = 0;
+
+ int start = fillKey(primary, bval, key, 0);
+ start = fillKey(secondary, bval, key, start);
+ fillKey(tertiary, bval, key, start);
+
return new SrtSortKey(object, key, second);
} catch (CharacterCodingException e) {
return new SrtSortKey(object, ZERO_KEY);
}
}
+ private int fillKey(byte[] sortMap, byte[] input, byte[] outKey, int start) {
+ int index = start;
+ for (byte inb : input) {
+ int b = inb & 0xff;
+ if (sortMap[b] != 0)
+outKey[index++] = sortMap[b];
+ }
+
+ outKey[index++] = '\0';
+ return index;
+ }
+
public SortKey createSortKey(T object, String s) {
return createSortKey(object, s, 0);
}
Index: src/uk/me/parabola/imgfmt/app/net/NETFile.java
===
--- src/uk/me/parabola/imgfmt/app/net/NETFile.java (revision 1870)
+++ src/uk/me/parabola/imgfmt/app/net/NETFile.java (revision )
@@ -71,8 +71,7 @@
Label[] l = rd.getLabels();
for(int i = 0; i < l.length && l[i] != null; ++i) {
if(l[i].getLength() != 0) {
- String cleanName = l[i].getTextSansGarminCodes();
- SortKey sortKey = sort.createSortKey(new LabeledRoadDef(l[i], rd), cleanName);
+ SortKey sortKey = sort.createSortKey(new LabeledRoadDef(l[i], rd), l[i].getText());
sortKeys.add(sortKey);
}
}
@@ -107,7 +106,7 @@
List out = new ArrayList(in.size());
while(!in.isEmpty()) {
LabeledRoadDef firstLabeledRoadDef = in.get(0).getObject();
- String name0 = firstLabeledRoadDef.label.getTextSansGarminCodes();
+ String name0 = firstLabeledRoadDef.label.getText();
RoadDef road0 = firstLabeledRoadDef.roadDef;
City city0 = road0.getCity();
@@ -119,7 +118,7 @@
// firstly determine the entries whose name and city match
// name0 and city0
for(n = 0; (n < in.size() &&
- name0.equalsIgnoreCase(in.get(n).getObject().label.getTextSansGarminCodes()) &&
+ name0.equalsIgnoreCase(in.get(n).getObject().label.getText()) &&
city0 == in.get(n).getObject().roadDef.getCity()); ++n) {
// relax
}
Index: src/uk/me/parabola/imgfmt/app/mdr/MDRFile.java
===
--- src/uk/me/parabola/imgfmt/app/mdr/MDRFile.java (revision 1870)
+++ src/uk/me/parabola/imgfmt/app/mdr/MDRFile.java (revision )
@@ -203,7 +203,8 @@
String cleanName = cleanUpName(name);
int strOff = createString(cleanName);
- // XXX not sure: we sort on the dirty name (ie with the Garmin shield codes).
+ // We sort on the dirty name (ie with the Garmin shield codes) although those codes do not
+ // affect the sort order. The string for mdr15 does not include the shield codes.
mdr7.addStreet(currentMap, name, lab.getOffset(), strOff, mdrCity);
}
}
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search issues
Yes, your patch works! I just went through the test cases that used to break. All work now. I then rebuilt a map of all of Italy. Address search works in that map as well. It looks like the bug is fixed. Thanks a lot. - Bartosz ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search issues
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= --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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search issues
On 30/03/11 22:41, Dermot McNally wrote:
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)
Thanks for trying out the patch. That is indeed a problem, please try
the updated patch attached.
Best wishes
..Steve
Index: src/uk/me/parabola/imgfmt/app/Label.java
===
--- src/uk/me/parabola/imgfmt/app/Label.java (revision 1650)
+++ src/uk/me/parabola/imgfmt/app/Label.java (revision )
@@ -56,10 +56,6 @@
return text;
}
- public String getTextSansGarminCodes() {
- return stripGarminCodes(text);
- }
-
// highway shields and "thin" separators
private final static Pattern SHIELDS = Pattern.compile("[\u0001-\u0006\u001b-\u001c]");
Index: test/uk/me/parabola/imgfmt/app/srt/SortTest.java
===
--- test/uk/me/parabola/imgfmt/app/srt/SortTest.java (revision 1873)
+++ test/uk/me/parabola/imgfmt/app/srt/SortTest.java (revision )
@@ -47,7 +47,7 @@
@Test
public void testDifferentLengths() {
- SortKey k1 = sort.createSortKey(null, "aabb");
+ SortKey k1 = sort.createSortKey(null, "aa");
SortKey k2 = sort.createSortKey(null, "aab");
assertEquals(1, k1.compareTo(k2));
@@ -158,6 +158,11 @@
assertEquals(-1, collator.compare("AA", "AAA"));
}
+ @Test
+ public void testIgnorableCharacters() {
+ checkOrder("aa", "\004aa");
+ }
+
private void checkOrder(int i1, int i2) {
String s = "aaa";
SortKey k1 = sort.createSortKey(null, s, i1);
Index: src/uk/me/parabola/imgfmt/app/srt/Sort.java
===
--- src/uk/me/parabola/imgfmt/app/srt/Sort.java (revision 1873)
+++ src/uk/me/parabola/imgfmt/app/srt/Sort.java (revision )
@@ -93,22 +93,42 @@
ByteBuffer out = encoder.encode(inb);
byte[] bval = out.array();
byte[] key = new byte[bval.length * 3 + 3];
- int length = bval.length;
- for (int i = 0; i < length; i++) {
-int b = bval[i] & 0xff;
-key[i] = primary[b];
-key[length + 1 + i] = secondary[b];
-key[2*length + 2 + i] = tertiary[b];
- }
- key[length] = 0;
- key[2 * length + 1] = 0;
- key[3 * length + 2] = 0;
+
+ int start = fillKey(primary, bval, key, 0);
+ start = fillKey(secondary, bval, key, start);
+ fillKey(tertiary, bval, key, start);
+
return new SrtSortKey(object, key, second);
} catch (CharacterCodingException e) {
return new SrtSortKey(object, ZERO_KEY);
}
}
+ /**
+ * Fill in the output key for a given strength.
+ *
+ * @param sortPositions An array giving the sort position for each of the 256 characters.
+ * @param input The input string in a particular 8 bit codepage.
+ * @param outKey The output sort key.
+ * @param start The index into the output key to start at.
+ * @return The next position in the output key.
+ */
+ private int fillKey(byte[] sortPositions, byte[] input, byte[] outKey, int start) {
+ int index = start;
+ for (byte inb : input) {
+ int b = inb & 0xff;
+
+ // I am guessing that a sort position of 0 means that the character is ignorable at this
+ // strength. In other words it is as if it is not present in the string. This appears to
+ // be true for shield symbols, but perhaps not for other kinds of control characters.
+ if (sortPositions[b] != 0)
+outKey[index++] = sortPositions[b];
+ }
+
+ outKey[index++] = '\0';
+ return index;
+ }
+
public SortKey createSortKey(T object, String s) {
return createSortKey(object, s, 0);
}
Index: src/uk/me/parabola/imgfmt/app/net/NETFile.java
===
--- src/uk/me/parabola/imgfmt/app/net/NETFile.java (revision 1870)
+++ src/uk/me/parabola/imgfmt/app/net/NETFile.java (revision )
@@ -71,8 +71,7 @@
Label[] l = rd.getLabels();
for(int i = 0; i < l.length && l[i] != null; ++i) {
if(l[i].getLength() != 0) {
- String cleanName = l[i].getTextSansGarminCodes();
- SortKey sortKey = sort.createSortKey(new LabeledRoadDef(l[i], rd), cleanName);
+ SortKey sortKey = sort.createSortKey(new LabeledRoadDef(l[i], rd), l[i].getText());
sortKeys.add(sortKey);
}
}
@@ -107,7 +106,7 @@
List out = new ArrayList(in.size());
while(!in.isEmpty()) {
LabeledRoadDef firstLabeledRoadDef = in.get(0).getObject();
- String name0 = firstLabeledRoadDef.label.getTextSansGarminCodes();
+ String name0 = firstLabeledRoadDef.label.getText();
RoadDef road0 = firstLabeledRoadDef.roadDef;
City city0 = road0.getCity();
@@ -119,7 +118,7 @@
// firstly determine the entries whose name and city match
// name0 and city0
for(n = 0; (n < in.size() &&
- name0.equalsIgno
Re: [mkgmap-dev] Address search issues
On 31 March 2011 08:21, Steve Ratcliffe 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search issues
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 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). 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
Re: [mkgmap-dev] Address search issues
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=280
--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
Re: [mkgmap-dev] Address search issues
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
Re: [mkgmap-dev] Address search issues
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
>
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search issues
> So two questions: > Are you planning to fix this problem in the splitter (maybe as an option). I hope someone will fix that. I have no time to implement that, so I appeal to anyone to post such a patch. > 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). Before merging the locator branch to trunk some things should/must be fixed: * Performance * The splitter problem *must* be fixed otherwise we'll get tons of complaints and error reports that will eat up lots of our development resources. * Maybe it should be possible to turn off the new locator mechanism? At least it should not run when the index option is not set. WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search issues
This patch seems to work well, at least as far as Dermot and myself can tell. Before the patch is forgotten and bitrots away, maybe it could be committed? - Bartosz ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
