Index and equally named cities
Hi, there have been some reports on the list that there are problems searching for streets in cities with the same name but with different regions. I can confirm that and have created a very simple testcase to show that problem. Attached osm file contains two streets: 1: name=Hauptstrasse, city=Testcity, region=Region 1, country=DEU 2: name=Hauptstrasse, city=Testcity, region=Region 2, country=DEU So both streets differ only in the position and the region they contain to. The testfile should be compiled with the locator branch (parameter --index must be set). It's more easy to assign the city/region/country name I want to have with locator branch but with a modified testcase it should also work with the trunk. Now I can search for the street Hauptstrasse and get both streets as result (search1.png). When I add Testcity to my search I only get the street of Region 1 in my result although both streets should match the search. The testcase might be modified using two different streetnames (Hauptstrasse1 for street 1 and Hauptstrasse2 for street2). Entering a search for Hauptstrasse2 with city=Testcity will not find any result. Steve, do you have any idea where the problem might be located? WanMil
Hi
Steve, do you have any idea where the problem might be located?
Well it might be that there should be separate city entries for each region, as in attached patch. The patch works for the given example, although I wouldn't be surprised if it caused another problem somewhere else - but give it a go see what happens! ..Steve
Hi
Steve, do you have any idea where the problem might be located?
Well it might be that there should be separate city entries for each region, as in attached patch.
The patch works for the given example, although I wouldn't be surprised if it caused another problem somewhere else - but give it a go see what happens!
..Steve
Hi, with the patch I get the street from Region 2 only when I search for "Hauptstrasse" and "Testcity". It seems as if the city "Testcity" in the search box is linked to the city in Region 2 using the patch and to the city in Region 1 without this patch. Searching for "Hauptstrasse / Region1" and "Hauptstrasse / Region2" without the cityname works fine. WanMil
Hi
with the patch I get the street from Region 2 only when I search for "Hauptstrasse" and "Testcity". It seems as if the city "Testcity" in the search box is linked to the city in Region 2 using the patch and to the city in Region 1 without this patch.
I've just tried with an up-to-date version of mapsource and I see the same thing. Back to the drawing board then! ..Steve
On May 30, 2011, at 23:23, Steve Ratcliffe wrote:
The attached patch seems to work better.
..Steve <city_region2.patch>
This patch appears to be identical to the first one, with the exception of an empty src/uk/me/parabola/imgfmt/app/mdr/Mdr20.java patch. Did something happen to the patch file, or am I missing something? Cheers.
Hello, how can I patch a precompiled jar-file? I would like to test this patch with the locator-branch to see if this fix some problems I've found. Or is it already included in the locator-branch? Thanks Martin Am 30.05.2011 um 23:56 schrieb Steve Ratcliffe:
Hi
Did something happen to the patch file, or am I missing something?
Yes something weird happened to the patch file. There was a change to Mdr20. Trying again...
..Steve <city_region3.patch>_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 01/06/11 09:24, Martin wrote:
Hello,
how can I patch a precompiled jar-file? I would like to test this patch with the locator-branch to see if this fix some problems I've found. Or is it already included in the locator-branch?
Its not included in the branch yet. Here is a jar with the patch applied. URL: http://files.mkgmap.org.uk/download/23/mkgmap.jar Description: mkgmap from locator branch with city_region3.patch applied. ..Steve
Hello Steve, thank you for your fast reply. My problems with not findable streets still exist. If a town is devided into 2 or more pieces, only streets could be find on the tile which contains the place-tag. Tested on Basecamp for Mac and my Garmin Oregon. On Mapsource it seems to work. I don't know how the index is generated (tile by tile or all-in-one), but I hope this helps you to find the problem. When I copy the place-tag into this tile then I can find all that streets. Testcase: Tile: 63240403: 2250752,378880 to 2271232,403456 # : 48.295898,8.129883 to 48.735352,8.657227 Streets that are not findable: e.g Schafblumenhalde (City: Horb am Neckar) Generated with locator-branch and your patched jar-file. Cheers Martin Am 01.06.2011 um 12:52 schrieb Steve Ratcliffe:
On 01/06/11 09:24, Martin wrote:
Hello,
how can I patch a precompiled jar-file? I would like to test this patch with the locator-branch to see if this fix some problems I've found. Or is it already included in the locator-branch?
Its not included in the branch yet.
Here is a jar with the patch applied.
URL: http://files.mkgmap.org.uk/download/23/mkgmap.jar
Description: mkgmap from locator branch with city_region3.patch applied.
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Martin, Steve, compiling only the given tile I cannot reproduce the problem. MapSource search is ok and searching on the Oregon finds Schafblumenhalde too. Anyhow I have reviewed some relevant source code parts and have a question Steve maybe can answer. The class PlacesFile contains the methods: City createCity(Country country, String name, boolean unique) City createCity(Region region, String name, boolean unique) They are called when creating a city from a place tag (unique=true) and when creating a road (unique=false). I don't understand in detail what the unique parameter should do. WanMil
Hello Steve,
thank you for your fast reply. My problems with not findable streets still exist. If a town is devided into 2 or more pieces, only streets could be find on the tile which contains the place-tag. Tested on Basecamp for Mac and my Garmin Oregon. On Mapsource it seems to work. I don't know how the index is generated (tile by tile or all-in-one), but I hope this helps you to find the problem. When I copy the place-tag into this tile then I can find all that streets.
Testcase: Tile: 63240403: 2250752,378880 to 2271232,403456 # : 48.295898,8.129883 to 48.735352,8.657227
Streets that are not findable: e.g Schafblumenhalde (City: Horb am Neckar)
Generated with locator-branch and your patched jar-file.
Cheers Martin
Am 01.06.2011 um 12:52 schrieb Steve Ratcliffe:
On 01/06/11 09:24, Martin wrote:
Hello,
how can I patch a precompiled jar-file? I would like to test this patch with the locator-branch to see if this fix some problems I've found. Or is it already included in the locator-branch?
Its not included in the branch yet.
Here is a jar with the patch applied.
URL: http://files.mkgmap.org.uk/download/23/mkgmap.jar
Description: mkgmap from locator branch with city_region3.patch applied.
..Steve _______________________________________________ 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
Hallo WanMil, could you please give me your settings for the splitter and mkgmap. Maybe something goes wrong with gmapi.py?! Thanks Martin Am 02.06.2011 um 14:36 schrieb WanMil:
Martin, Steve,
compiling only the given tile I cannot reproduce the problem. MapSource search is ok and searching on the Oregon finds Schafblumenhalde too.
Anyhow I have reviewed some relevant source code parts and have a question Steve maybe can answer.
The class PlacesFile contains the methods: City createCity(Country country, String name, boolean unique) City createCity(Region region, String name, boolean unique)
They are called when creating a city from a place tag (unique=true) and when creating a road (unique=false). I don't understand in detail what the unique parameter should do.
WanMil
Hello Steve,
thank you for your fast reply. My problems with not findable streets still exist. If a town is devided into 2 or more pieces, only streets could be find on the tile which contains the place-tag. Tested on Basecamp for Mac and my Garmin Oregon. On Mapsource it seems to work. I don't know how the index is generated (tile by tile or all-in-one), but I hope this helps you to find the problem. When I copy the place-tag into this tile then I can find all that streets.
Testcase: Tile: 63240403: 2250752,378880 to 2271232,403456 # : 48.295898,8.129883 to 48.735352,8.657227
Streets that are not findable: e.g Schafblumenhalde (City: Horb am Neckar)
Generated with locator-branch and your patched jar-file.
Cheers Martin
Am 01.06.2011 um 12:52 schrieb Steve Ratcliffe:
On 01/06/11 09:24, Martin wrote:
Hello,
how can I patch a precompiled jar-file? I would like to test this patch with the locator-branch to see if this fix some problems I've found. Or is it already included in the locator-branch?
Its not included in the branch yet.
Here is a jar with the patch applied.
URL: http://files.mkgmap.org.uk/download/23/mkgmap.jar
Description: mkgmap from locator branch with city_region3.patch applied.
..Steve _______________________________________________ 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
So.... I've made a map on a Windows-Machine, using the same files I used on my Macbook and the nsis-compiler... And now it works... Damn... So the problem comes from the gmapi-builder. Anyone here who understand python to fix this problem?! And sorry for bothering you with this problem. I've never expected that the problem comes from gmapi. Cheers Martin Am 02.06.2011 um 14:59 schrieb Martin:
Hallo WanMil,
could you please give me your settings for the splitter and mkgmap. Maybe something goes wrong with gmapi.py?!
Thanks Martin
Am 02.06.2011 um 14:36 schrieb WanMil:
Martin, Steve,
compiling only the given tile I cannot reproduce the problem. MapSource search is ok and searching on the Oregon finds Schafblumenhalde too.
Anyhow I have reviewed some relevant source code parts and have a question Steve maybe can answer.
The class PlacesFile contains the methods: City createCity(Country country, String name, boolean unique) City createCity(Region region, String name, boolean unique)
They are called when creating a city from a place tag (unique=true) and when creating a road (unique=false). I don't understand in detail what the unique parameter should do.
WanMil
Hello Steve,
thank you for your fast reply. My problems with not findable streets still exist. If a town is devided into 2 or more pieces, only streets could be find on the tile which contains the place-tag. Tested on Basecamp for Mac and my Garmin Oregon. On Mapsource it seems to work. I don't know how the index is generated (tile by tile or all-in-one), but I hope this helps you to find the problem. When I copy the place-tag into this tile then I can find all that streets.
Testcase: Tile: 63240403: 2250752,378880 to 2271232,403456 # : 48.295898,8.129883 to 48.735352,8.657227
Streets that are not findable: e.g Schafblumenhalde (City: Horb am Neckar)
Generated with locator-branch and your patched jar-file.
Cheers Martin
Am 01.06.2011 um 12:52 schrieb Steve Ratcliffe:
On 01/06/11 09:24, Martin wrote:
Hello,
how can I patch a precompiled jar-file? I would like to test this patch with the locator-branch to see if this fix some problems I've found. Or is it already included in the locator-branch?
Its not included in the branch yet.
Here is a jar with the patch applied.
URL: http://files.mkgmap.org.uk/download/23/mkgmap.jar
Description: mkgmap from locator branch with city_region3.patch applied.
..Steve _______________________________________________ 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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On Jun 2, 2011, at 15:49, Martin wrote:
I've made a map on a Windows-Machine, using the same files I used on my Macbook and the nsis-compiler... And now it works... Damn... So the problem comes from the gmapi-builder. Anyone here who understand python to fix this problem?! And sorry for bothering you with this problem. I've never expected that the problem comes from gmapi.
Which version of gmapi-builder are you using? Please also send the command lines you use. Cheers.
Hello Clinton, I couldn't find any version in the file, so I attached the file. I use the following commands: python gmapi-builder.py -t osmmap.tdb -b osmmap.img -s ./master/basemap.TYP -i osmmap.mdx -m osmmap_mdr.img osmmap.img 63240*.img osmmap_mdr.img Thanks Martin Am 02.06.2011 um 15:56 schrieb Clinton Gladstone:
On Jun 2, 2011, at 15:49, Martin wrote:
I've made a map on a Windows-Machine, using the same files I used on my Macbook and the nsis-compiler... And now it works... Damn... So the problem comes from the gmapi-builder. Anyone here who understand python to fix this problem?! And sorry for bothering you with this problem. I've never expected that the problem comes from gmapi.
Which version of gmapi-builder are you using?
Please also send the command lines you use.
Cheers. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On Jun 2, 2011, at 16:12, Martin wrote:
I use the following commands: python gmapi-builder.py -t osmmap.tdb -b osmmap.img -s ./master/basemap.TYP -i osmmap.mdx -m osmmap_mdr.img osmmap.img 63240*.img osmmap_mdr.img
I compared the output from gmapi-builder with that produced by Garmin's MapConverter program: they appear to be identical. Perhaps you could do the following to help isolate the problem: - Run Garmin's MapConverter on the map which you created on your Windows machine. - Install the resulting gmapi map on your Mac OS machine. - Does the problem still occur? If so, it may be a general problem with converting maps to gmapi format, or (perhaps more likely) it could be a problem in Garmin's Mac OS programs (MapInstall, Basecamp, etc.). - Which versions of MapInstall and Basecamp do you have on your Mac? Cheers.
You are right... I've converted the map, produced on the windows machine, to the Mac-Format, and the same behavior: I couldn't find the streets nor the city, which is outside of the tile. I didn't think this is an error from the Garmin-Software, I think there is a difference between the index-table produced with mkgmap and a original Garmin-Map. Maybe a character or something like this. Cheers Martin Am 02.06.2011 um 18:24 schrieb Clinton Gladstone:
On Jun 2, 2011, at 16:12, Martin wrote:
I use the following commands: python gmapi-builder.py -t osmmap.tdb -b osmmap.img -s ./master/basemap.TYP -i osmmap.mdx -m osmmap_mdr.img osmmap.img 63240*.img osmmap_mdr.img
I compared the output from gmapi-builder with that produced by Garmin's MapConverter program: they appear to be identical.
Perhaps you could do the following to help isolate the problem:
- Run Garmin's MapConverter on the map which you created on your Windows machine.
- Install the resulting gmapi map on your Mac OS machine.
- Does the problem still occur?
If so, it may be a general problem with converting maps to gmapi format, or (perhaps more likely) it could be a problem in Garmin's Mac OS programs (MapInstall, Basecamp, etc.).
- Which versions of MapInstall and Basecamp do you have on your Mac?
Cheers. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Okay, I've made a new map of Germany on a Windows-machine. On Mapsource I can find a few more streets, which I couldn't found before. But, on my Garmin, I still couldn't find the streets like Schafblumenhalde in Horb. If I leave out the City, I can find the street, but when I click on it, the Garmin says, that it couldn't found this street. When I make just the tile containing the Schafblumenhalde, I can find it on Mapsource, my Garmin but not in Basecamp (used Gmapi-Builder and the Garmin Map Converter). Strange things... Am 02.06.2011 um 19:51 schrieb Martin:
You are right... I've converted the map, produced on the windows machine, to the Mac-Format, and the same behavior: I couldn't find the streets nor the city, which is outside of the tile. I didn't think this is an error from the Garmin-Software, I think there is a difference between the index-table produced with mkgmap and a original Garmin-Map. Maybe a character or something like this.
Cheers Martin
Am 02.06.2011 um 18:24 schrieb Clinton Gladstone:
On Jun 2, 2011, at 16:12, Martin wrote:
I use the following commands: python gmapi-builder.py -t osmmap.tdb -b osmmap.img -s ./master/basemap.TYP -i osmmap.mdx -m osmmap_mdr.img osmmap.img 63240*.img osmmap_mdr.img
I compared the output from gmapi-builder with that produced by Garmin's MapConverter program: they appear to be identical.
Perhaps you could do the following to help isolate the problem:
- Run Garmin's MapConverter on the map which you created on your Windows machine.
- Install the resulting gmapi map on your Mac OS machine.
- Does the problem still occur?
If so, it may be a general problem with converting maps to gmapi format, or (perhaps more likely) it could be a problem in Garmin's Mac OS programs (MapInstall, Basecamp, etc.).
- Which versions of MapInstall and Basecamp do you have on your Mac?
Cheers. _______________________________________________ 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
Looks good to me. There is one crude thing left but hopefully you can fix that too. I have modified the testcase (attached). It contains now one street with each permutation of name=Street1 / Street2 city=City1 / City2 region=Region / Region2 Performing some searches gives the following results: * Searching for street only gives the expected 4 results * Searching for a street/city combination gives the expected 2 results * Searching for a street/region combination gives the expected 2 results * Adding a country to the searches is working too (might have to add another permutation with a 2nd country) * Searching for street, city and region gives one expected result only when searching for Street1/City2/Region1 or Street2/City2/Region1. All other combinations return two results with both regions. WanMil
Hi
Did something happen to the patch file, or am I missing something?
Yes something weird happened to the patch file. There was a change to Mdr20. Trying again...
..Steve
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Steve, no matter if there are some minor issues left your patch is a big improvement and is worth being committed. WanMil P.S.: I forgot to mention that I have done my tests in combination with the translit_first.patch.
Looks good to me. There is one crude thing left but hopefully you can fix that too.
I have modified the testcase (attached). It contains now one street with each permutation of name=Street1 / Street2 city=City1 / City2 region=Region / Region2
Performing some searches gives the following results: * Searching for street only gives the expected 4 results * Searching for a street/city combination gives the expected 2 results * Searching for a street/region combination gives the expected 2 results * Adding a country to the searches is working too (might have to add another permutation with a 2nd country)
* Searching for street, city and region gives one expected result only when searching for Street1/City2/Region1 or Street2/City2/Region1. All other combinations return two results with both regions.
WanMil
Hi
Did something happen to the patch file, or am I missing something?
Yes something weird happened to the patch file. There was a change to Mdr20. Trying again...
..Steve
_______________________________________________ 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
Steve,
no matter if there are some minor issues left your patch is a big improvement and is worth being committed.
OK thanks, but I now have a patch that works with your new example.
Attached.
..Steve
That's one further step :-) Now I get one result when searching for StreetX/CityX/Region1 which is good. When using Region2 I always get two results when searching for the StreetX/CityX/Region2 combination. WanMil
Hi WanMil
Now I get one result when searching for StreetX/CityX/Region1 which is good. When using Region2 I always get two results when searching for the StreetX/CityX/Region2 combination.
Weird, I see that on my up-to-date mapsource but not on the older version. I'll have another think! ..Steve
Hi
Now I get one result when searching for StreetX/CityX/Region1 which is good. When using Region2 I always get two results when searching for the StreetX/CityX/Region2 combination.
I tried with region 2 and 4 too. I found that if you search for street+city+region you always get Region1 as am extra (incorrect) result. But never any other region, so for example if the street+city combination is not in region1 then you just get the correct item and not any of the other regions instead. So with lots of regions in a real map it is probably not much of a problem. Anyway, I cannot see any way to fix it - it may even be a mapsource bug, you never know. So I will just commit the previous patches which fix the main problems. ..Steve
Hi
Now I get one result when searching for StreetX/CityX/Region1 which is good. When using Region2 I always get two results when searching for the StreetX/CityX/Region2 combination.
I tried with region 2 and 4 too.
I found that if you search for street+city+region you always get Region1 as am extra (incorrect) result. But never any other region, so for example if the street+city combination is not in region1 then you just get the correct item and not any of the other regions instead.
So with lots of regions in a real map it is probably not much of a problem. Anyway, I cannot see any way to fix it - it may even be a mapsource bug, you never know.
So I will just commit the previous patches which fix the main problems.
Yep, that's fine! I think this fix will bring the index generation a big step forward. WanMil
..Steve
Hi Steve, can you commit the patch or do you have some more ideas you want to implement and test first? WanMil
Hi
Now I get one result when searching for StreetX/CityX/Region1 which is good. When using Region2 I always get two results when searching for the StreetX/CityX/Region2 combination.
I tried with region 2 and 4 too.
I found that if you search for street+city+region you always get Region1 as am extra (incorrect) result. But never any other region, so for example if the street+city combination is not in region1 then you just get the correct item and not any of the other regions instead.
So with lots of regions in a real map it is probably not much of a problem. Anyway, I cannot see any way to fix it - it may even be a mapsource bug, you never know.
So I will just commit the previous patches which fix the main problems.
..Steve
However, for the first time (ever in my short mkgmap map making life) I get an error when Mapsource builds the index. Everything was fine till locator version 1969. Locator version 1977 gives a MDR_TRIM_ADDR.CXX-440.6.16.3.0 error code. I'll try another test run tomorrow Cheers, Johan On Thu, 23 Jun 2011 15:17:47 +0200, WanMil wrote:
Hi Steve,
can you commit the patch or do you have some more ideas you want to implement and test first?
WanMil
Hi
Now I get one result when searching for StreetX/CityX/Region1 which is good. When using Region2 I always get two results when searching for the StreetX/CityX/Region2 combination.
I tried with region 2 and 4 too.
I found that if you search for street+city+region you always get Region1 as am extra (incorrect) result. But never any other region, so for example if the street+city combination is not in region1 then you just get the correct item and not any of the other regions instead.
So with lots of regions in a real map it is probably not much of a problem. Anyway, I cannot see any way to fix it - it may even be a mapsource bug, you never know.
So I will just commit the previous patches which fix the main problems.
..Steve
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
My 2nd attempt, running mkgmap again, also failed and produced the same error message. Index building on smaller sized maps (< 100 Mb) is ok. Yet, I suppose that somehow a bug has been introduced between locator 1969 and locator 1977 Johan On Thu, 23 Jun 2011 23:45:06 +0200, navmaps wrote:
However, for the first time (ever in my short mkgmap map making life) I get an error when Mapsource builds the index. Everything was fine till locator version 1969. Locator version 1977 gives a MDR_TRIM_ADDR.CXX-440.6.16.3.0 error code.
I'll try another test run tomorrow
Cheers, Johan
On Thu, 23 Jun 2011 15:17:47 +0200, WanMil wrote:
Hi Steve,
can you commit the patch or do you have some more ideas you want to implement and test first?
WanMil
Hi
Now I get one result when searching for StreetX/CityX/Region1 which is good. When using Region2 I always get two results when searching for the StreetX/CityX/Region2 combination.
I tried with region 2 and 4 too.
I found that if you search for street+city+region you always get Region1 as am extra (incorrect) result. But never any other region, so for example if the street+city combination is not in region1 then you just get the correct item and not any of the other regions instead.
So with lots of regions in a real map it is probably not much of a problem. Anyway, I cannot see any way to fix it - it may even be a mapsource bug, you never know.
So I will just commit the previous patches which fix the main problems.
..Steve
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
I can confirm this. I've attached the error-message. Cheers Am 24.06.2011 um 08:55 schrieb navmaps:
My 2nd attempt, running mkgmap again, also failed and produced the same error message. Index building on smaller sized maps (< 100 Mb) is ok. Yet, I suppose that somehow a bug has been introduced between locator 1969 and locator 1977
Johan
On Thu, 23 Jun 2011 23:45:06 +0200, navmaps wrote:
However, for the first time (ever in my short mkgmap map making life) I get an error when Mapsource builds the index. Everything was fine till locator version 1969. Locator version 1977 gives a MDR_TRIM_ADDR.CXX-440.6.16.3.0 error code.
I'll try another test run tomorrow
Cheers, Johan
On Thu, 23 Jun 2011 15:17:47 +0200, WanMil wrote:
Hi Steve,
can you commit the patch or do you have some more ideas you want to implement and test first?
WanMil
Hi
Now I get one result when searching for StreetX/CityX/Region1 which is good. When using Region2 I always get two results when searching for the StreetX/CityX/Region2 combination.
I tried with region 2 and 4 too.
I found that if you search for street+city+region you always get Region1 as am extra (incorrect) result. But never any other region, so for example if the street+city combination is not in region1 then you just get the correct item and not any of the other regions instead.
So with lots of regions in a real map it is probably not much of a problem. Anyway, I cannot see any way to fix it - it may even be a mapsource bug, you never know.
So I will just commit the previous patches which fix the main problems.
..Steve
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
I tried to reproduce and got the same problem with the trunk r1973. So the problem must have been introduced with r1971/2/3 and is not locator specific. @Steve: any ideas? WanMil
I can confirm this. I've attached the error-message.
Cheers
Am 24.06.2011 um 08:55 schrieb navmaps:
My 2nd attempt, running mkgmap again, also failed and produced the same error message. Index building on smaller sized maps (< 100 Mb) is ok. Yet, I suppose that somehow a bug has been introduced between locator 1969 and locator 1977
Johan
On Thu, 23 Jun 2011 23:45:06 +0200, navmaps wrote:
However, for the first time (ever in my short mkgmap map making life) I get an error when Mapsource builds the index. Everything was fine till locator version 1969. Locator version 1977 gives a MDR_TRIM_ADDR.CXX-440.6.16.3.0 error code.
I'll try another test run tomorrow
Cheers, Johan
On Thu, 23 Jun 2011 15:17:47 +0200, WanMil wrote:
Hi Steve,
can you commit the patch or do you have some more ideas you want to implement and test first?
WanMil
Hi
Now I get one result when searching for StreetX/CityX/Region1 which is good. When using Region2 I always get two results when searching for the StreetX/CityX/Region2 combination.
I tried with region 2 and 4 too.
I found that if you search for street+city+region you always get Region1 as am extra (incorrect) result. But never any other region, so for example if the street+city combination is not in region1 then you just get the correct item and not any of the other regions instead.
So with lots of regions in a real map it is probably not much of a problem. Anyway, I cannot see any way to fix it - it may even be a mapsource bug, you never know.
So I will just commit the previous patches which fix the main problems.
..Steve
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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 24/06/11 14:13, WanMil wrote:
I tried to reproduce and got the same problem with the trunk r1973. So the problem must have been introduced with r1971/2/3 and is not locator specific.
@Steve: any ideas?
Yes, it is bound to be on trunk, I've just seen something that might be a problem, so it may be easy to fix after all. I'll look into it. ..Steve
I tried to reproduce and got the same problem with the trunk r1973. So the problem must have been introduced with r1971/2/3 and is not locator specific.
@Steve: any ideas?
Yes, it is bound to be on trunk, I've just seen something that might be a problem, so it may be easy to fix after all. I'll look into it.
..Steve
Great! FYI: r1972 crashes too. Will continue to try r1971. WanMil
I tried to reproduce and got the same problem with the trunk r1973. So the problem must have been introduced with r1971/2/3 and is not locator specific.
@Steve: any ideas?
Yes, it is bound to be on trunk, I've just seen something that might be a problem, so it may be easy to fix after all. I'll look into it.
..Steve
Great! FYI: r1972 crashes too. Will continue to try r1971.
WanMil
r1971 also crashes. I wonder if r1970 does not... WanMil
Am 24.06.2011 17:14, schrieb WanMil:
I tried to reproduce and got the same problem with the trunk r1973. So the problem must have been introduced with r1971/2/3 and is not locator specific.
@Steve: any ideas?
Yes, it is bound to be on trunk, I've just seen something that might be a problem, so it may be easy to fix after all. I'll look into it.
..Steve
Great! FYI: r1972 crashes too. Will continue to try r1971.
WanMil
r1971 also crashes. I wonder if r1970 does not... WanMil
r1970 is ok and works. WanMil
Hi
r1971 also crashes. I wonder if r1970 does not...
r1970 is ok and works.
I am not surprised ;) I have managed to reproduce this with two tiles, each one by itself transfers fine, but together they fail. I know that there was a bug like this a long time ago but I cannot find the email exchanges where it was discussed. It would probably be very helpful to know what I did to fix it then. Can anyone remember of find the problem in the list? ..Steve
Hi
r1971 also crashes. I wonder if r1970 does not...
r1970 is ok and works.
I am not surprised ;)
I have managed to reproduce this with two tiles, each one by itself transfers fine, but together they fail.
I know that there was a bug like this a long time ago but I cannot find the email exchanges where it was discussed. It would probably be very helpful to know what I did to fix it then.
Can anyone remember of find the problem in the list?
..Steve
Do you mean: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2011q2/011612.html ? WanMil
Hi Ahh, I remembered a keyword that helped me find it. I had no idea it was just Feb this year, thought is was years ago, so not looking in the right place at all! It was this thread I was thinking of: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2011q1/010163.html ..Steve
Hi, is this problem already fixed and I missed some emails? Cheers, Martin Am 2011-06-26 14:56, schrieb Steve Ratcliffe:
Hi
Ahh, I remembered a keyword that helped me find it. I had no idea it was just Feb this year, thought is was years ago, so not looking in the right place at all!
It was this thread I was thinking of: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2011q1/010163.html
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 24/06/11 07:55, navmaps wrote:
My 2nd attempt, running mkgmap again, also failed and produced the same error message. Index building on smaller sized maps (< 100 Mb) is ok. Yet, I suppose that somehow a bug has been introduced between locator 1969 and locator 1977
There were several fixes on trunk between those revisions that were merged in with 1977. It would be good to know which one it was. Unfortunately the error message means nothing to me, you get a similar message when there is anything it thinks is wrong. I will only be able to fix it if you can give me a way of reproducing it, preferably with a small example. ..Steve
On 24/06/11 07:55, navmaps wrote:
My 2nd attempt, running mkgmap again, also failed and produced the same error message. Index building on smaller sized maps (< 100 Mb) is ok. Yet, I suppose that somehow a bug has been introduced between locator 1969 and locator 1977
I'm going to check in a patch to fix this since trunk is broken anyway, that largely goes back to how it was before the change that broke it. It will re-introduce a problem that this thread is about, but I have seen that mdr27 does not look right, so I will then see if that makes any difference with the original problem. ..Steve
Today I've found the mkgmap-city-region-index-r1984.jar-branch on the snapshot-site. Sound interesting, but the bounds-options didn't work. "Invalid option: 'boundsdirectory'" Or has something changed in the options? Cheers Martin Am 30.06.2011 um 16:03 schrieb Steve Ratcliffe:
On 24/06/11 07:55, navmaps wrote:
My 2nd attempt, running mkgmap again, also failed and produced the same error message. Index building on smaller sized maps (< 100 Mb) is ok. Yet, I suppose that somehow a bug has been introduced between locator 1969 and locator 1977
I'm going to check in a patch to fix this since trunk is broken anyway, that largely goes back to how it was before the change that broke it.
It will re-introduce a problem that this thread is about, but I have seen that mdr27 does not look right, so I will then see if that makes any difference with the original problem.
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 06/07/11 06:42, Martin wrote:
Today I've found the mkgmap-city-region-index-r1984.jar-branch on the snapshot-site. Sound interesting, but the bounds-options didn't work. "Invalid option: 'boundsdirectory'" Or has something changed in the options?
boundsdirectory is an option that is in the locator branch. You would have to merge the two branches together to get both sets of changes. ..Steve
Hi, how can I merge them?! Thx Martin Am 07.07.2011 um 09:50 schrieb Steve Ratcliffe <steve@parabola.me.uk>:
On 06/07/11 06:42, Martin wrote:
Today I've found the mkgmap-city-region-index-r1984.jar-branch on the snapshot-site. Sound interesting, but the bounds-options didn't work. "Invalid option: 'boundsdirectory'" Or has something changed in the options?
boundsdirectory is an option that is in the locator branch.
You would have to merge the two branches together to get both sets of changes.
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi I am away this week so didn't have time to mention it, but I created a branch (city-region-index) to fix the city/region bug since it turned out to be quite a complex change. It is now working as far as I can tell. Upload to a device works without mapsource crashes and giving both city and region in the search box works. ..Steve
Where to download your branch? This is also a long standing issue for our PH maps. See issue report here: https://github.com/maning/osmphgps/issues/9 Basically, we have 6 "San Fernando" cities and city/address search only works for this case when using mkgmap r1867. On Thu, Jul 7, 2011 at 3:55 PM, Steve Ratcliffe <steve@parabola.me.uk> wrote:
Hi
I am away this week so didn't have time to mention it, but I created a branch (city-region-index) to fix the city/region bug since it turned out to be quite a complex change.
It is now working as far as I can tell. Upload to a device works without mapsource crashes and giving both city and region in the search box works.
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------
Got it! On Thu, Jul 7, 2011 at 3:58 PM, maning sambale <emmanuel.sambale@gmail.com> wrote:
Where to download your branch?
This is also a long standing issue for our PH maps. See issue report here: https://github.com/maning/osmphgps/issues/9
Basically, we have 6 "San Fernando" cities and city/address search only works for this case when using mkgmap r1867.
On Thu, Jul 7, 2011 at 3:55 PM, Steve Ratcliffe <steve@parabola.me.uk> wrote:
Hi
I am away this week so didn't have time to mention it, but I created a branch (city-region-index) to fix the city/region bug since it turned out to be quite a complex change.
It is now working as far as I can tell. Upload to a device works without mapsource crashes and giving both city and region in the search box works.
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------
-- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------
Testing this version, Uploading via mac mapinstall is a bit longer but not too long I only get two "San Fernando"s that are in a separate tile. The other "San Fernando"s within one tile is not included in the search results. args.list: code-page=1252 tdbfile latin1 country-abbr=PHL country-name=PHILIPPINES remove-short-arcs=5 route add-pois-to-areas family-id=639 family-name=OSM_PHIL overview-mapname=40000001 series-name=OSM_PHIL description=OSM Philippines style-file=/home/maning/osm/routable_garmin/git/osmphgps/styles/default generate-sea=polygons,extend-sea-sectors,close-gaps=1000 index adjust-turn-headings check-roundabouts drive-on-right check-roundabout-flares report-dead-ends ignore-maxspeeds link-pois-to-ways location-autofill=0 styles: https://github.com/maning/osmphgps/tree/master/styles/default On Thu, Jul 7, 2011 at 4:01 PM, maning sambale <emmanuel.sambale@gmail.com> wrote:
Got it!
On Thu, Jul 7, 2011 at 3:58 PM, maning sambale <emmanuel.sambale@gmail.com> wrote:
Where to download your branch?
This is also a long standing issue for our PH maps. See issue report here: https://github.com/maning/osmphgps/issues/9
Basically, we have 6 "San Fernando" cities and city/address search only works for this case when using mkgmap r1867.
On Thu, Jul 7, 2011 at 3:55 PM, Steve Ratcliffe <steve@parabola.me.uk> wrote:
Hi
I am away this week so didn't have time to mention it, but I created a branch (city-region-index) to fix the city/region bug since it turned out to be quite a complex change.
It is now working as far as I can tell. Upload to a device works without mapsource crashes and giving both city and region in the search box works.
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------
-- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------
-- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------
@WanMil: could you please merge the locator-branch with the last city-region-branch from Steve?! I have no idea, how can I make this. THX Martin Am 07.07.2011 um 10:35 schrieb maning sambale:
Testing this version, Uploading via mac mapinstall is a bit longer but not too long
I only get two "San Fernando"s that are in a separate tile. The other "San Fernando"s within one tile is not included in the search results.
args.list:
code-page=1252 tdbfile latin1 country-abbr=PHL country-name=PHILIPPINES remove-short-arcs=5 route add-pois-to-areas family-id=639 family-name=OSM_PHIL overview-mapname=40000001 series-name=OSM_PHIL description=OSM Philippines style-file=/home/maning/osm/routable_garmin/git/osmphgps/styles/default generate-sea=polygons,extend-sea-sectors,close-gaps=1000 index adjust-turn-headings check-roundabouts drive-on-right check-roundabout-flares report-dead-ends ignore-maxspeeds link-pois-to-ways location-autofill=0
styles: https://github.com/maning/osmphgps/tree/master/styles/default
On Thu, Jul 7, 2011 at 4:01 PM, maning sambale <emmanuel.sambale@gmail.com> wrote:
Got it!
On Thu, Jul 7, 2011 at 3:58 PM, maning sambale <emmanuel.sambale@gmail.com> wrote:
Where to download your branch?
This is also a long standing issue for our PH maps. See issue report here: https://github.com/maning/osmphgps/issues/9
Basically, we have 6 "San Fernando" cities and city/address search only works for this case when using mkgmap r1867.
On Thu, Jul 7, 2011 at 3:55 PM, Steve Ratcliffe <steve@parabola.me.uk> wrote:
Hi
I am away this week so didn't have time to mention it, but I created a branch (city-region-index) to fix the city/region bug since it turned out to be quite a complex change.
It is now working as far as I can tell. Upload to a device works without mapsource crashes and giving both city and region in the search box works.
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------
-- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------
-- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------ _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Martin, I don't want to merge changes from one branch to another branch. The advantage of the branch is that one can concentrate on the development of a few specific things only (better assignment of city/region/country information in the locator branch). Merging unfinished developments from another branch might introduce new problems. Of course once the changes from the city-region branch are merged back to the trunk I will apply the changes to the locator branch soon. At the moment you can do that yourself: * Create a patch between the city-region branch and r1973 * Apply this patch to the locator branch WanMil
@WanMil: could you please merge the locator-branch with the last city-region-branch from Steve?! I have no idea, how can I make this.
THX Martin
Am 07.07.2011 um 10:35 schrieb maning sambale:
Testing this version, Uploading via mac mapinstall is a bit longer but not too long
I only get two "San Fernando"s that are in a separate tile. The other "San Fernando"s within one tile is not included in the search results.
args.list:
code-page=1252 tdbfile latin1 country-abbr=PHL country-name=PHILIPPINES remove-short-arcs=5 route add-pois-to-areas family-id=639 family-name=OSM_PHIL overview-mapname=40000001 series-name=OSM_PHIL description=OSM Philippines style-file=/home/maning/osm/routable_garmin/git/osmphgps/styles/default generate-sea=polygons,extend-sea-sectors,close-gaps=1000 index adjust-turn-headings check-roundabouts drive-on-right check-roundabout-flares report-dead-ends ignore-maxspeeds link-pois-to-ways location-autofill=0
styles: https://github.com/maning/osmphgps/tree/master/styles/default
On Thu, Jul 7, 2011 at 4:01 PM, maning sambale <emmanuel.sambale@gmail.com> wrote:
Got it!
On Thu, Jul 7, 2011 at 3:58 PM, maning sambale <emmanuel.sambale@gmail.com> wrote:
Where to download your branch?
This is also a long standing issue for our PH maps. See issue report here: https://github.com/maning/osmphgps/issues/9
Basically, we have 6 "San Fernando" cities and city/address search only works for this case when using mkgmap r1867.
On Thu, Jul 7, 2011 at 3:55 PM, Steve Ratcliffe<steve@parabola.me.uk> wrote:
Hi
I am away this week so didn't have time to mention it, but I created a branch (city-region-index) to fix the city/region bug since it turned out to be quite a complex change.
It is now working as far as I can tell. Upload to a device works without mapsource crashes and giving both city and region in the search box works.
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------
-- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------
-- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------ _______________________________________________ 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
WanMil, you are right. My fault, I didn't want you to merge this two branches for public. I have no idea how I can download the city-region- & location-branch and the r1973. I also didn't know how to patch this both files and apply this patch to the locator branch. I think you know how to do this. So if you find some time, it would be nice if you can provide me this "special branch". I think you can upload it to: http://files.mkgmap.org.uk/download Thank you in advance. Martin Am 2011-07-08 13:16, schrieb WanMil:
Martin,
I don't want to merge changes from one branch to another branch. The advantage of the branch is that one can concentrate on the development of a few specific things only (better assignment of city/region/country information in the locator branch). Merging unfinished developments from another branch might introduce new problems.
Of course once the changes from the city-region branch are merged back to the trunk I will apply the changes to the locator branch soon.
At the moment you can do that yourself: * Create a patch between the city-region branch and r1973 * Apply this patch to the locator branch
WanMil
@WanMil: could you please merge the locator-branch with the last city-region-branch from Steve?! I have no idea, how can I make this.
THX Martin
Am 07.07.2011 um 10:35 schrieb maning sambale:
Testing this version, Uploading via mac mapinstall is a bit longer but not too long
I only get two "San Fernando"s that are in a separate tile. The other "San Fernando"s within one tile is not included in the search results.
args.list:
code-page=1252 tdbfile latin1 country-abbr=PHL country-name=PHILIPPINES remove-short-arcs=5 route add-pois-to-areas family-id=639 family-name=OSM_PHIL overview-mapname=40000001 series-name=OSM_PHIL description=OSM Philippines style-file=/home/maning/osm/routable_garmin/git/osmphgps/styles/default generate-sea=polygons,extend-sea-sectors,close-gaps=1000 index adjust-turn-headings check-roundabouts drive-on-right check-roundabout-flares report-dead-ends ignore-maxspeeds link-pois-to-ways location-autofill=0
styles: https://github.com/maning/osmphgps/tree/master/styles/default
On Thu, Jul 7, 2011 at 4:01 PM, maning sambale <emmanuel.sambale@gmail.com> wrote:
Got it!
On Thu, Jul 7, 2011 at 3:58 PM, maning sambale <emmanuel.sambale@gmail.com> wrote:
Where to download your branch?
This is also a long standing issue for our PH maps. See issue report here: https://github.com/maning/osmphgps/issues/9
Basically, we have 6 "San Fernando" cities and city/address search only works for this case when using mkgmap r1867.
On Thu, Jul 7, 2011 at 3:55 PM, Steve Ratcliffe<steve@parabola.me.uk> wrote:
Hi
I am away this week so didn't have time to mention it, but I created a branch (city-region-index) to fix the city/region bug since it turned out to be quite a complex change.
It is now working as far as I can tell. Upload to a device works without mapsource crashes and giving both city and region in the search box works.
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------
-- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------
-- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------ _______________________________________________ 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
On Fri, Jul 08, 2011 at 01:42:13PM +0200, Martin wrote:
I also didn't know how to patch this both files and apply this patch to the locator branch.
Here is how it should work: svn co http://svn.parabola.me.uk/mkgmap/branches/locator mkgmap-locator cd mkgmap-locator svn log|less # see which trunk revision it is based on # The log reports for me that the svn:log of the current head (r1977) is # "Synchronize to trunk r1973". So, you will need to merge changes from # that on: svn merge http://svn.parabola.me.uk/mkgmap/trunk -r1973:HEAD . # This went without conflicts. ant dist # This gives compilation failures: "cannot find class BlockInputStream" So, it does not seem to be that simple. Best regards, Marko
Hello Marko, thanks for your help: I would like to merge locator with the city-region-branch. Using your steps, I see, that Steve made the branch from 1979, or?! r1980 | steve | 2011-07-01 15:30:57 +0200 (Fre, 01. Jul 2011) | 2 Zeilen Create branch for city/region problem fix So, now, that I know how I can download different versions (tried 1973 and 1979), I tried to make a patch with diff -r -u mkgmap-city newtrunk > patch1 When I try to patch the locator with this patch I get a lot of errors: Hunk #1 FAILED at 1. 1 out of 1 hunk FAILED -- saving rejects to file all-wcprops.rej ... So any idea what's wrong?! Cheers, Martin Am 2011-07-08 14:02, schrieb Marko Mäkelä:
On Fri, Jul 08, 2011 at 01:42:13PM +0200, Martin wrote:
I also didn't know how to patch this both files and apply this patch to the locator branch. Here is how it should work:
svn co http://svn.parabola.me.uk/mkgmap/branches/locator mkgmap-locator cd mkgmap-locator svn log|less # see which trunk revision it is based on # The log reports for me that the svn:log of the current head (r1977) is # "Synchronize to trunk r1973". So, you will need to merge changes from # that on: svn merge http://svn.parabola.me.uk/mkgmap/trunk -r1973:HEAD . # This went without conflicts. ant dist # This gives compilation failures: "cannot find class BlockInputStream"
So, it does not seem to be that simple.
Best regards,
Marko _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On Fri, Jul 08, 2011 at 02:49:17PM +0200, Martin wrote:
Hello Marko,
thanks for your help: I would like to merge locator with the city-region-branch. Using your steps, I see, that Steve made the branch from 1979, or?!
r1980 | steve | 2011-07-01 15:30:57 +0200 (Fre, 01. Jul 2011) | 2 Zeilen
Create branch for city/region problem fix
Subversion revision numbers are repository-wide. The common practice is that the repository contains subdirectories, such as "trunk" and "branches/locator".
So, now, that I know how I can download different versions (tried 1973 and 1979), I tried to make a patch with diff -r -u mkgmap-city newtrunk > patch1
"svn merge" should do that in a more intelligent way, resolving conflicts and taking into account renamed files. I took a look at the output of "svn diff", and I do not see any reference to BlockInputStream there. So, I guess that "ant dist" should fail even in the unmodified locator branch. Sure enough, I can repeat the build error after "svn revert -R ." Now I remember that I had a little tweak in my mkgmap/external.properties, replacing jars=/opt/jars with a different path. When I tweak that, the locator branch builds for me. The jars directory must contain the following: /opt/jars/osmprotobuf/osmprotobuf.jar /opt/jars/protobuf-2.3.0/protobuf.jar On my system, these point to the following files: osmosis-0.37/lib/default/osmbin-1.0-6d760534.jar osmosis-0.37/lib/default/protobuf-java-2.3.0.jar
So any idea what's wrong?!
Just follow the steps that I posted earlier, but make sure that the jar files are available. Best regards, Marko
Hi
for public. I have no idea how I can download the city-region-& location-branch and the r1973. I also didn't know how to patch this both files and apply this patch to the locator branch. I think you know how to do this. So if you find some time, it would be nice if you can provide me this "special branch".
Normally to merge a branches you would check out the locator branch and then merge the other one in like this: svn merge ^/branches/city-region-index . it doesn't work in this case, because the merge information is missing on the locator branch, probably because the merge command wasn't used to merge in the trunk changes. Anyway I fixed the merge information and created a merged tree locally and uploaded the result to: http://files.mkgmap.org.uk/download/32/mkgmap.jar I haven't tested it... ..Steve
it doesn't work in this case, because the merge information is missing on the locator branch, probably because the merge command wasn't used to merge in the trunk changes.
Oh, I wasn't aware of special svn merge information and merged changes from the trunk manually. Good to know. Will try that next time. WanMil
Hi
Oh, I wasn't aware of special svn merge information and merged changes from the trunk manually. Good to know. Will try that next time.
You can fix up the merge information for the revisions that are already merged from trunk with: cd <locator-branch> svn merge --record-only -r1891:1973 ^/trunk . svn commit Then merging from trunk can be just: svn merge ^/trunk . ..Steve
Hi
Oh, I wasn't aware of special svn merge information and merged changes from the trunk manually. Good to know. Will try that next time.
You can fix up the merge information for the revisions that are already merged from trunk with:
cd<locator-branch> svn merge --record-only -r1891:1973 ^/trunk . svn commit
Then merging from trunk can be just: svn merge ^/trunk .
..Steve
Thanks for the hints! Can you do me a favour and commit that for me? I am using the Eclipse SVN facility only and would have to try a lot how to achieve that with the special "record-only" parameter. Thanks! WanMil
Steve, thank you for merging both branches. I could make a map, but still get one city that exist in 2 different regions. When I just search for city in the city-search-function of my garmin I see both cities (Chemnitz, Sachsen and Chemnitz, Mecklenburg-Vorpommern). But when I use the address-search function I only find Chemnitz, Mecklenburg-Vorpommern. In the next menu I see all streets, which are in Chemnitz, Sachsen, but when I choose these streets, No results are found... Strange thing... Cheers, Martin Am 09.07.2011 um 23:08 schrieb Steve Ratcliffe:
Hi
for public. I have no idea how I can download the city-region-& location-branch and the r1973. I also didn't know how to patch this both files and apply this patch to the locator branch. I think you know how to do this. So if you find some time, it would be nice if you can provide me this "special branch".
Normally to merge a branches you would check out the locator branch and then merge the other one in like this:
svn merge ^/branches/city-region-index .
it doesn't work in this case, because the merge information is missing on the locator branch, probably because the merge command wasn't used to merge in the trunk changes.
Anyway I fixed the merge information and created a merged tree locally and uploaded the result to: http://files.mkgmap.org.uk/download/32/mkgmap.jar
I haven't tested it...
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hallo Martin, hast du die neue Karte schon zum download eingestellt? Ich würde mal schauen ob meine "fehlenden" Straßen auftauchen. Ich konnte mit der letzten Karte ein paar Straßen finden, aber nicht alle. Der Straßenname hat vermutlich auch kein "Doppel" das irritieren könnte... Laas mal hören wo die Karte zu laden ist - Vieri Augen mappen mehr als zwei :-) Gruß Ludwich Am 10.07.2011 um 20:02 schrieb Martin:
Steve,
thank you for merging both branches. I could make a map, but still get one city that exist in 2 different regions. When I just search for city in the city-search-function of my garmin I see both cities (Chemnitz, Sachsen and Chemnitz, Mecklenburg-Vorpommern). But when I use the address-search function I only find Chemnitz, Mecklenburg-Vorpommern. In the next menu I see all streets, which are in Chemnitz, Sachsen, but when I choose these streets, No results are found... Strange thing...
Cheers, Martin
Am 09.07.2011 um 23:08 schrieb Steve Ratcliffe:
Hi
for public. I have no idea how I can download the city-region-& location-branch and the r1973. I also didn't know how to patch this both files and apply this patch to the locator branch. I think you know how to do this. So if you find some time, it would be nice if you can provide me this "special branch".
Normally to merge a branches you would check out the locator branch and then merge the other one in like this:
svn merge ^/branches/city-region-index .
it doesn't work in this case, because the merge information is missing on the locator branch, probably because the merge command wasn't used to merge in the trunk changes.
Anyway I fixed the merge information and created a merged tree locally and uploaded the result to: http://files.mkgmap.org.uk/download/32/mkgmap.jar
I haven't tested it...
..Steve _______________________________________________ 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
On 07/07/11 09:35, maning sambale wrote:
Testing this version, Uploading via mac mapinstall is a bit longer but not too long
I only get two "San Fernando"s that are in a separate tile. The other "San Fernando"s within one tile is not included in the search results.
So can you explain exactly what is better and worse between the city-region-index branch r1867 and r1870. Do the different "San Fernando's" have different regions? If not how do you tell them apart? ..Steve
participants (9)
-
Clinton Gladstone -
Frey Jürgen -
maning sambale -
Marko Mäkelä -
Martin -
Martin -
navmaps -
Steve Ratcliffe -
WanMil