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 fo
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
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:
highway=*
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 co
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
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 b
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 o
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 = 2
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
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
On Tue, 2009-09-08 at 11:27 +0200, Felix Hartmann wrote:
> However it might be that maps in the back take preference for routing
> (this is a black book on which map is chosen for routing, so if people
> don't deactivate (deactivating however does not completely deactivate,
> i.e. POI search, but
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
Mark Burton wrote:
Hi Felix,
I can't believe that it works. We don't even have the data in
Openstreetmap (in general), nor anything about lanes in the style-file.
http://www.malsingmaps.com/forums/viewtopic.php?f=73&t=16364&start=0
Obviously, we don't know how to encode this stu
Hi Felix,
> I can't believe that it works. We don't even have the data in
> Openstreetmap (in general), nor anything about lanes in the style-file.
http://www.malsingmaps.com/forums/viewtopic.php?f=73&t=16364&start=0
Obviously, we don't know how to encode this stuff at the moment.
> Probab
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 e
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
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
17 matches
Mail list logo
