One user reported that lane assist works on my mkgmap generated map.
I don't know what lane assist do and not so sure if it works with
mkgmap. Anybody here can confirm that this works for newer garmin
nuvis?
--
cheers,
maning
--
Freedom is
Hi Maning,
One user reported that lane assist works on my mkgmap generated map.
I don't know what lane assist do and not so sure if it works with
mkgmap. Anybody here can confirm that this works for newer garmin
nuvis?
I have a brand new Nuvi 255 and it doesn't have lane assist but it
Mark Burton wrote:
Hi Maning,
One user reported that lane assist works on my mkgmap generated map.
I don't know what lane assist do and not so sure if it works with
mkgmap. Anybody here can confirm that this works for newer garmin
nuvis?
I have a brand new Nuvi 255 and it doesn't
As a result of some suggestions from Steve, I've checked in some changes
to the splitter (r87) that mean tiles are now trimmed of any extraneous empty
space around their borders. Empty tiles are now thrown away completely. Also,
no tiles extend past about +/-85 degrees latitude to prevent some
Mark Burton schreef:
The fact that other routing services choose to do that does not make me
any more enthusiastic about the idea.
IMHO, if people want specific changes to their OSM data before rendering
a map, it's pretty easy to do so. Merging different nodes on basis of
some rule (the rule
Hi, Felix,
Felix wrote:
Yes, very often. Due to some changes in code of mkmgap (I had written
about this earlier) the draw priority compared to non mkgmap maps, or
older mkgmap maps (before rev 10??) will always show in front (at least
on vista hcx).
So mkgmap maps will usually always show in
Steve Ratcliffe wrote:
The first term in a rule has to have an equals sign (or the rule
can be rearranged so that is the case).
So the following should work:
highway=* maxspeed 78 maxspeed 82 {set mcssl=50}
Sorry about the error message, it is clearly useless and I will change
Hi,
when I try to split a OSM file which contains only contour lines made
with srtm2osm (1.8.14.10) I get this error:
[splitter-r83]$java -Xmx2048M -jar splitter.jar --mapid=2101
--mixed=yes --cache=./cache/ --max-nodes=5 srtm_test.osm
Time started: Tue Sep 08 20:03:15 CEST 2009
mapid =
It looks like there is a latitude value in your file that contains a large
number of significant figures (far more than is actually required) and the
parsing is failing on it. I just checked in a change that will hopefully
solve the problem for you (r88) however I'd be interested in seeing the
Chris Miller wrote:
It looks like there is a latitude value in your file that contains a large
number of significant figures (far more than is actually required) and the
parsing is failing on it. I just checked in a change that will hopefully
solve the problem for you (r88) however I'd be
I've battled trying to narrow this down for a couple of days.
I have a lines style file that contains:
highway=* maxspeed=40mph {set mcssl=40}
highway=primary mcssl=40 [0x04 resolution 19]
highway=* mcssl=40 [0x04 resolution 22]
I'm then running a stripped down (in JSOM) set of OSM data
Thanks Paul, that would explain it for sure. The problem Ralf hit was
definitely
a bug in the splitter though, I had made one too many assumptions in some
custom code for parsing floating point numbers (Java's double parsing is
very slow). I figured if the code could parse the planet file it
Mapsource only uses even resolution. Only gps uses uneven. So as you did
not set 20, that might be the reason to go straight up to 22. Try with
even resolution only.
MarkS wrote:
I've battled trying to narrow this down for a couple of days.
I have a lines style file that contains:
CM As you can see the tiles are now quite a bit more compact,
CM especially around densely mapped coastlines, and unmapped ocean
CM areas are often not tiled at all. The only unusual thing I can see
CM is tile 63240007 off the west coast of Mexico which contains just a
CM single node. The node is
14 matches
Mail list logo
