only old version of mkgmap on download page
Hi Steve, please check: since a few hours http://www.mkgmap.org.uk/download/mkgmap.html shows r2370 as the latest trunk version. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/only-old-version-of-mkgmap-on-download-page-t... Sent from the Mkgmap Development mailing list archive at Nabble.com.
On 13/01/13 21:03, GerdP wrote:
please check: since a few hours http://www.mkgmap.org.uk/download/mkgmap.html shows r2370 as the latest trunk version.
I have halted the builds and removed all versions after 9 Nov 2012 until we have solved the regression that Felix reported in the index. In fact I think it may be worse, I am seeing a problem back to between 2334 and 2345. Then it does get worse at 2384 which is after 9 Nov. Hoped to get it fixed quickly, but it is turning out to be slow work. ..Steve
I need some time for the feedback. Want to upload some files first. Actually the problem is that mkgmap does some things inconsistently. I might have triggered it accidentally. I think previously I was okay, because the input files had DIFFERENT Codepage. It's actually not a regression but an old bug triggered quite surprisingly... But I was not able to really test 233? or earlier as it somehow crashed on me. - but I suppose I would have had to downgrade my style-file and some other input files too, in order to run pre September versions of mkgmap for testing. Actually took me ages to figure out how to trigger that behaviour because I first thought it's based on mkgmap (I didn't change things regarding address search in my style). Hope to get the files all up tomorrow midday... On 13.01.2013 22:34, Steve Ratcliffe wrote:
On 13/01/13 21:03, GerdP wrote:
please check: since a few hours http://www.mkgmap.org.uk/download/mkgmap.html shows r2370 as the latest trunk version. I have halted the builds and removed all versions after 9 Nov 2012 until we have solved the regression that Felix reported in the index.
In fact I think it may be worse, I am seeing a problem back to between 2334 and 2345. Then it does get worse at 2384 which is after 9 Nov.
Hoped to get it fixed quickly, but it is turning out to be slow work.
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org
Hi Felix I have now narrowed down the problem to 2335, which is confusingly the first change *after* the last one that directly touched the MDR index code. There is a very obvious problem in that the sections MDR 20, 22 are a fraction of the size that they should be. It might be that I don't know how to use the --bounds option which changed at that point. The problem is in the tiles which have far fewer streets with cities allocated to them. It has nothing to do with index creation itself. This problem appears in both the MapSource generated gmapsupp and the mkgmap gmapsupp. I did see a mapsource/mkgmap difference in November when I didn't even get the menu option to enter an address, it may not be related. I was hit by a problem where the GPS appears to cache something which I think I've come across before but can't remember the details. I ended up recreating the map before transferring it to the device. ..Steve On 13/01/13 21:57, Felix Hartmann wrote:
I need some time for the feedback. Want to upload some files first.
Actually the problem is that mkgmap does some things inconsistently. I might have triggered it accidentally.
I think previously I was okay, because the input files had DIFFERENT Codepage. It's actually not a regression but an old bug triggered quite surprisingly...
But I was not able to really test 233? or earlier as it somehow crashed on me. - but I suppose I would have had to downgrade my style-file and some other input files too, in order to run pre September versions of mkgmap for testing. Actually took me ages to figure out how to trigger that behaviour because I first thought it's based on mkgmap (I didn't change things regarding address search in my style).
Hope to get the files all up tomorrow midday...
Good work on fixing it. Geoff Steve Ratcliffe <steve@parabola.me.uk> wrote:
Hi Felix
I have now narrowed down the problem to 2335, which is confusingly the first change *after* the last one that directly touched the MDR index code.
There is a very obvious problem in that the sections MDR 20, 22 are a fraction of the size that they should be. It might be that I don't know how to use the --bounds option which changed at that point. The problem is in the tiles which have far fewer streets with cities allocated to them. It has nothing to do with index creation itself.
This problem appears in both the MapSource generated gmapsupp and the mkgmap gmapsupp. I did see a mapsource/mkgmap difference in November when I didn't even get the menu option to enter an address, it may not be related.
I was hit by a problem where the GPS appears to cache something which I think I've come across before but can't remember the details. I ended up recreating the map before transferring it to the device.
..Steve
On 13/01/13 21:57, Felix Hartmann wrote:
I need some time for the feedback. Want to upload some files first.
Actually the problem is that mkgmap does some things inconsistently. I might have triggered it accidentally.
I think previously I was okay, because the input files had DIFFERENT Codepage. It's actually not a regression but an old bug triggered quite surprisingly...
But I was not able to really test 233? or earlier as it somehow crashed on me. - but I suppose I would have had to downgrade my style-file and some other input files too, in order to run pre September versions of mkgmap for testing. Actually took me ages to figure out how to trigger that behaviour because I first thought it's based on mkgmap (I didn't change things regarding address search in my style).
Hope to get the files all up tomorrow midday...
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Steve Ratcliffe wrote
I have now narrowed down the problem to 2335, which is confusingly the first change *after* the last one that directly touched the MDR index code.
There is a very obvious problem in that the sections MDR 20, 22 are a fraction of the size that they should be. It might be that I don't know how to use the --bounds option which changed at that point. The problem is in the tiles which have far fewer streets with cities allocated to them. It has nothing to do with index creation itself.
Maybe the problem is caused by this change in MapBuilder: if (cityName == null && (cityCountryName != null || cityRegionName != null)) { // if city name is unknown and region and/or country is known // use empty name for the city cityName = UNKNOWN_CITY_NAME; } Ciao, Gerd -- View this message in context: http://gis.19327.n5.nabble.com/only-old-version-of-mkgmap-on-download-page-t... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi I am now sure that the difference in 2335 is simply that the "nearest" sub-option to --location-autofill was no longer the default in that version. So it was a red-herring. I am now back to focusing on 2384 and previous versions. ..Steve
Steve Ratcliffe wrote
I have now narrowed down the problem to 2335, which is confusingly the first change *after* the last one that directly touched the MDR index code.
There is a very obvious problem in that the sections MDR 20, 22 are a fraction of the size that they should be. It might be that I don't know how to use the --bounds option which changed at that point. The problem is in the tiles which have far fewer streets with cities allocated to them. It has nothing to do with index creation itself.
Maybe the problem is caused by this change in MapBuilder: if (cityName == null && (cityCountryName != null || cityRegionName != null)) { // if city name is unknown and region and/or country is known // use empty name for the city cityName = UNKNOWN_CITY_NAME; } Ciao, Gerd
Maybe. That means that "" is assigned to any unknown city name. There have been some doubts if that's working. But I committed it because nobody could reproduce. WanMil
participants (5)
-
Felix Hartmann -
Geoff Sherlock -
GerdP -
Steve Ratcliffe -
WanMil