Steve,
Done. Its at: http://files.mkgmap.org.uk/download/33/mkgmap.jar
I think locator + city-region-index branches (2) is a milestone!
This is a strong +1 from my side to commit the changes as soon as
possible and try to base a stable mkgmap release v1.0(?) on this version.
For a long time
WanMil,
there were some changes on the boundaries around Stuttgart (suburbs were tagged
with admin-level=8), so that you get Stuttgart-Nord instead of Stuttgart.
You can also give me the osmosis-command -line(s), so I can try it myself. I
think it's also good to update the wiki ;)
Cheers,
Martin,
read this:
http://wiki.openstreetmap.org/wiki/Mkgmap/help/usage#Addressindex_with_locator-branch
WanMil
WanMil,
there were some changes on the boundaries around Stuttgart (suburbs were
tagged with admin-level=8), so that you get Stuttgart-Nord instead of
Stuttgart.
You can also
Just to add another observation.
Under the address search, you are prompted to spell a city. In my
previous mkgmap compile, you can only find a city if it is within the
tile of your current location. With city-region-index I can now
select all cities in my map and search streetnames.
On Thu,
Martin
I've tried to merge the locator-branch with your city-region-branch, but I
get a few errors and he failed to build the jar. Could you please merge it
for me?
I've tried:
Done. Its at: http://files.mkgmap.org.uk/download/33/mkgmap.jar
..Steve
Thank you SteveWanMil,
after testing the new city-region-locator-branch I have to say: You've done a
great job. Now I can find more cities, for e.g. Neustadt in Brandenburg, in
Schleswig-Holstein, in Sachsen etc... Fantastic.
So, few more things I've seen. Zip-search still not work. If I use
And now a special request to WanMil:
Could you please update the boundary-files?
Martin,
at the moment Luxembourg is broken so it makes no sense for me to update
the bounds files.
Johan want to correct that within the next days.
WanMil
___
Thanks, that was very helpful. I can probably work on a fix for that now.
It looks like the city search, only uses the POI section of the index.
Therefore I need to try making the same change to the POI section and
retain multiple city POIs that have different region/country's.
..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
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:
cdlocator-branch
svn merge --record-only
Thanks will wait and test.
On Mon, Jul 11, 2011 at 4:51 PM, Steve Ratcliffe st...@parabola.me.uk wrote:
Thanks, that was very helpful. I can probably work on a fix for that now.
It looks like the city search, only uses the POI section of the index.
Therefore I need to try making the same
On 11/07/11 15:26, maning sambale wrote:
Thanks will wait and test.
You need wait no longer!
The current city-region-index branch version has the changes. Please let
me know what you think.
..Steve
___
mkgmap-dev mailing list
Steve,
I've tried to merge the locator-branch with your city-region-branch, but I get
a few errors and he failed to build the jar. Could you please merge it for me?
I've tried:
svn co http://svn.parabola.me.uk/mkgmap/branches/locator mkgmap-locator
cd mkgmap-locator
svn merge
Initial results:
Compiled with mkgmap-city-region-index-r1992 tested on nuvi 255w.
All my San Fernandos are searcheable both in the address search and
city search. Streets are searchable as well. I also noticed a great
improvement in the street results which may have sole another bug
reported
works on nuvi 1310 city search and address search
On Tue, Jul 12, 2011 at 9:49 AM, maning sambale
emmanuel.samb...@gmail.com wrote:
Initial results:
Compiled with mkgmap-city-region-index-r1992 tested on nuvi 255w.
All my San Fernandos are searcheable both in the address search and
city
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
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
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
On 11/07/2011 04:51, maning sambale wrote:
Dear steve,
Here's a bit of explanation from one of our colleagues.
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
Yes, although minimal. --location-autofill=0
On Mon, Jul 11, 2011 at 12:53 PM, Charlie Ferrero char...@cferrero.net wrote:
--location-autofill
--
cheers,
maning
--
Freedom is still the most radical idea of all -N.Branden
wiki:
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
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 Fernandos that are in a separate tile. The other
San Fernandos within one tile is not included in the search results.
So can you explain exactly
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
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
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
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
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
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
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
Hi,
how can I merge them?!
Thx
Martin
Am 07.07.2011 um 09:50 schrieb Steve Ratcliffe st...@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.
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
Got it!
On Thu, Jul 7, 2011 at 3:58 PM, maning sambale
emmanuel.samb...@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
Testing this version,
Uploading via mac mapinstall is a bit longer but not too long
I only get two San Fernandos that are in a separate tile. The other
San Fernandos within one tile is not included in the search results.
args.list:
code-page=1252
tdbfile
latin1
country-abbr=PHL
@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
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
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
Hi
is this problem already fixed and I missed some emails?
The problem in Feb was fixed, there is currently a problem in the latest
svn version with similar symptoms that is not fixed.
..Steve
___
mkgmap-dev mailing list
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
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
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
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
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:
I can confirm this.
I've attached the error-message.
Cheers
?xml version=1.0 encoding=UTF-8 standalone=no ?
ErrorReport xmlns=http://www.garmin.com/xmlschemas/ApplicationErrors/v1;
Error
Exception
SourceCodeLocation
SourceFileNameMDR_TRIM_ADDR.CXX/SourceFileName
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
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 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
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 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.
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
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
Hi
can you commit the patch or do you have some more ideas you want to
implement and test first?
Sure, sorry, I thought that I had already done so. Thanks for reminding me.
..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
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
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
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
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
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
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
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
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
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
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
#!/usr/bin/python
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
On Jun 2, 2011, at 16:12, Martin wrote:
I couldn't find any version in the file, so I attached the file.
Thanks, I'll take a look and see if I can find anything. Right now I'm
comparing the output produced by Garmin's MapConvert with that of gmapi-builder.
Cheers.
On 02/06/11 15:13, WanMil wrote:
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
Index: src/uk/me/parabola/imgfmt/app/mdr/Mdr5.java
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
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
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
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!
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
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
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
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
Hi
I've just tried with an up-to-date version of mapsource and I see the
same thing. Back to the drawing board then!
The attached patch seems to work better.
..Steve
Index: src/uk/me/parabola/imgfmt/app/mdr/Mdr5.java
===
---
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
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
Index: src/uk/me/parabola/imgfmt/app/mdr/Mdr5.java
===
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
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
77 matches
Mail list logo
