On 09/08/2009 09:21 PM, 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
Felix Hartmann wrote:
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.
I've changed the second line to
highway=primary mcssl=40 [0x04 resolution 20]
but it doesn't
On 09/09/09 11:27, MarkS wrote:
Felix Hartmann wrote:
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.
I've changed the second line to
highway=primary mcssl=40 [0x04
Currently building polygons have names in my area. How do I add the
names in the map and enable search?
--
cheers,
maning
--
Freedom is still the most radical idea of all -N.Branden
wiki: http://esambale.wikispaces.com/
blog:
Chris Miller wrote:
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
On Wed, Sep 9, 2009 at 1:24 PM, maning
sambaleemmanuel.samb...@gmail.com wrote:
Currently building polygons have names in my area. How do I add the
names in the map and enable search?
A while back I believe I posted a patch which modified the polygons
style file to add names (and house
I've just updated to the latest mkgmap from trunk and am now having
problems processing tiles that I have previously successfully processed.
The error I am receiving is
java.lang.IllegalStateException: Polygon offset too large
at
I found it somewhat annoying that my tiles always had identical
generic descriptions such as OSM Map. It made it very difficult to
recognise which tiles belonged to which areas, in particular when
attempting to select specific tiles on my GPSr. Since my maps could
have over 200 tiles, it was
Hi Paul,
I'd used Ralf's osm file as a test case to solve this problem, but seems
like even that didn't go far enough. I have no idea why but the numbers in
your file contain several digits more precision than a 64bit floating point
number can even represent. I've added another check so that
Hi Paul,
I've just updated to the latest mkgmap from trunk and am now having
problems processing tiles that I have previously successfully processed.
The error I am receiving is
java.lang.IllegalStateException: Polygon offset too large
Please try attached patch.
Cheers,
Mark
diff --git
Chris Miller wrote:
Hi Paul,
I'd used Ralf's osm file as a test case to solve this problem, but seems
like even that didn't go far enough. I have no idea why but the numbers in
your file contain several digits more precision than a 64bit floating point
number can even represent. I've
Mark Burton wrote:
Hi Paul,
I've just updated to the latest mkgmap from trunk and am now having
problems processing tiles that I have previously successfully processed.
The error I am receiving is
java.lang.IllegalStateException: Polygon offset too large
Please try attached patch.
Version 1181 was commited by markb on 2009-09-09 14:56:57 +0100 (Wed, 09 Sep
2009)
Improve estimate of size required for lines and polygons.
Was underestimating size of lines/polys that would be split due to
their number of points.
___
mkgmap-dev
Heh, you're doing a great job testing various corner-cases in the splitter
- keep up the good work :) I have to wonder quite how that osm file you
have was generated though. Are there really nodes in the osm database that
are missing lat and/or lon values? Seems a bit worrying if so.
P That
On Wed, Sep 9, 2009 at 4:02 PM, Chris Millerchris.mil...@kbcfp.com wrote:
Nice idea! I'll put that on the todo list for incorporating into the splitter,
sounds like a very useful feature to add. What might be even better is if
I use those webservices to generate a data file that can be
Well I wasn't planning on bundling the whole thing. My idea was to create
a grid that's the same resolution as the splitter's density map (typically
8192x4096), I only need to store some simple summary data (a reference to
the predominant country/city, plus perhaps a weighting based on
On Wed, Sep 9, 2009 at 5:07 PM, Chris Millerchris.mil...@kbcfp.com wrote:
Well I wasn't planning on bundling the whole thing. My idea was to create
a grid that's the same resolution as the splitter's density map (typically
8192x4096),
This would be very cool. I'm in favour! ;-)
Cheers.
Steve Ratcliffe wrote:
On 09/09/09 11:27, MarkS wrote:
The problem is definitely in the generated img and not how mapsource
displays it. I would expect that both roads would be at resolution 22
which is probably not what you wanted but that is due to the usual
issue of the action rules
Hi Thilo,
I will modify the code that the merging is applied even earlier.
Shouldn't be too hard to do.
Did you do that? I would be keen to try a version because I notice on
my first few trips with the Nuvi that sometimes it says keep
right/left when it should say turn right/left. I think
Mark Burton escribió:
Hi Thilo,
I will modify the code that the merging is applied even earlier.
Shouldn't be too hard to do.
Did you do that? I would be keen to try a version because I notice on
my first few trips with the Nuvi that sometimes it says keep
right/left when it
I have a large lake with a relation connecting all ways together. It
seems mkgmap creates a polygon for each of the ways by connecting
start and end together.
Do we have support for multipolygons. In this case 2 arms of the lake
cross the tile boundary. the 2 arms are rendered correct in the
21 matches
Mail list logo
