Dear Clinton,
No Luck. I tried several combinations:
python gmapi-builder.py -v -t for_mapsource/4001.tdb -b
for_mapsource/4001.img -s for_mapsource/MINIMAL.TYP -i
for_mapsource/4001.mdx -m for_mapsource/4001_mdr.img
for_mapsource/63*.img
Unknown Block: 54, length: 20,
'\x00\x00\
Now this is getting interesting. The problems seems to come from the
waterways.
If I filter out the waterways from the input file using osmosis, routing is
fine. Similarly if I remove the waterway lines from my the default style
file, routing in file.
Oppositely if using osmosis I generate an inp
0> In article <1be1dc8a-93b8-48bb-857a-7598d2f85...@gmail.com>,
0> Stuart Poulton mailto:webw...@gmail.com> ("Stuart") wrote:
Stuart> Has anyone got a quick recipe for STRM contours to garmin for
Stuart> the UK, preferably on Linux ?
You might prefer Ordnance Survey OpenData contours (if you're h
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,
>>
>> 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 Stree
Interestingly enough if I just keep the highways then the routing issues are
gone. Are there any other objects besides the highway=* ones that would
generate routable data and be the cause of the issue?
On Thu, Jun 2, 2011 at 9:10 AM, Steve Ratcliffe wrote:
>
> [This post was too big, I've reduce
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-ta
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
Ma
Hi maning,
I'm pretty sure that there is an error in your command line. I was able to
compile the map properly with the following:
python gmapi-builder.py -v -t for_mapsource/4001.tdb -b
for_mapsource/4001.img -s for_mapsource/MINIMAL.TYP -i
for_mapsource/4001.mdx -m for_mapsource/
On 01/06/11 20:36, Peter Lerner wrote:
> Steve,
>
> I tested the greek_index patch patch only. I assumed it was an
> alternative to the translit_first patch. Was it? Or should it accumulate?
No, greek_index is a simple patch, which although it seemed to help
doesn't really deal with the major pro
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 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.
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
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
"""
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
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 neve
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 se
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 metho
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
El 27/05/11 19:26, WanMil escribió:
> Am 21.05.2011 19:45, schrieb Carlos Dávila:
>> El 20/05/11 11:06, Carlos Dávila escribió:
>>> El 20/05/11 00:07, Carlos Dávila escribió:
El 19/05/11 23:15, WanMil escribió:
>> El 19/05/11 22:12, WanMil escribió:
El 19/05/11 21:29, WanMil escri
20 matches
Mail list logo
