Hi,
I think this is an error:
If I use a command like this:
java -jar mkgmap.jar --style-file=f:\osm\tk-osm\basemap\style --nsis
--output-dir=c:\xyz e:\bremen\*.o5m f:\osm\tk-osm\basemap\basemap.TYP
I get an *.nsi script in c:\xyz that searches for a file xbasemap.TYP, but this
file is
Am 29.05.2013 23:41, schrieb GerdP:
Hello
no, Gerd, this is a problem with some maps build with mkgmap, but it is
not seen on every Oregon. It also happened, if the maps are installed on
the SD-card.
I have never seen this with my Oregon.
On the Garmin-Forum there are a lot of threads with
There is a workaround for the activity routing, which means you have to use
carpool avoidance in the car profile.
This avoids all roads tagged with either access=no OR motorcar=no (dont know
what happens with motorcar=yes access=no).
It really depends now how you use your map. Is it for car
Hi,
I tried to remove the name from motorway_links and other _links.
My first approach was simple:
highway=motorway_link { delete name }
This changed nothing! Mmmh, I looked into the source code and observed
that the action
{ name 'abc' }
is different to
{ set name='abc' }
After using { name
Hi Wanmil,
On the osm forum someone noticed that housenumbers were not found along
secondary and tertiary roads:
http://forum.openstreetmap.org/viewtopic.php?pid=337308#p337308
Could this be also related to the internal ref handling (ref is added to the
name tag?).
I agree the ref handling
Hi Christian,
I experienced the memory full error on my Oregon 400t some time ago. It
seems that it was caused by a broken map, since never did it occur again
after replacing that one map with a newer version.
Kind regards,
Bernhard
Am 29.05.2013 23:17, schrieb Christian H. Bruhn:
Hi!
I've
Hi
Wild guess by me: Oregons like the 62 have, beside the internal,
accessible memory, another, hidden internal memory, where it seems
they store index and other informations about the installed maps and
gpx files.
I would agree that the new units seem to store or cache some details
of the
Hi Thorsten,
if you say, that changing the version which every update prevents the
problem, then maybe --product-version should be set by default to
mmdd (date of generation) and not to 1.
Henning
Am 30.05.2013 12:59, schrieb Thorsten Kukuk:
On Thu, May 30, Bernd Weigelt wrote:
Am
Hi
If there is a name-field and a ref-field in Garmin-format, then I would
suggest to fill them with mkgmap:ref and mkgmap:name, if these tags are
not set or empty, use name and ref. Everything else should be handled in
style-file.
Also { name 'abc' } should be equal to { set name='abc'}.
the latest overview2 branch (snapshot taken 24 hours ago) runs through
fine for me. No more errors on australia-oceania.
(because I can't find the thread right now - I do need more than 8
levels. So please keep the behavior of the overview maps restarting at
level 0, and not continue-ing -
Version 2630 was committed by gerd on Fri, 31 May 2013
merge overview2 branch
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Version 2631 was committed by gerd on Fri, 31 May 2013
update help file
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
12 matches
Mail list logo
