Re: [mkgmap-dev] mkgmap r1160 Exception when facing multiple splitted files

2009-09-01 Thread Gianmario Mengozzi
2009/8/31 Mark Burton ma...@ordern.com


  This is reporting a bug in the fixed error reporting (introduced
  in rev 1153). I have committed a fixed fix but even if that does the
  right thing, you will still get an exception reported because there
  must be something else going wrong for there to be an exception that
  needs reporting!. So please try 1161 and let us know what it says.

 Err, please try 1162, instead.



hi Mark,

r1162 fixed it !   :D

thx a lot for your support


Gianmario
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Splitter --cache parameter

2009-09-01 Thread Lambertus
Chris Miller wrote:
 Something else I probably should have mentioned. Enabling the disk cache 
 does NOT reduce the memory required to perform the split, though it does 
 make multiple passes during the second stage much quicker, and the more 
 passes 
 that are used (via smaller --max-areas values) the less memory required 
 during 
 that stage.
 
 I'm still looking into the best way to reduce the memory required during 
 the first (area subdivision) stage, since this is the one thing still 
 preventing 
 people from splitting the planet on a 32 bit VM.
 
I don't know what change made it possible, but I finally succeeded to 
process all of North/South America with the latest splitter and 3.9 GB 
heap space. I used the cache option and max-node=1.2 million. I've tried 
this a few times before with older splitter versions, but this is the 
first time the split finished without fatal errors. So I finally have 
correct tiles for North America (at least the ones that got rendered by 
Mkgmap successfully!): http://garmin.na1400.info/routable.php

I guess it's time for me to start hacking on a areas.kml editing tool to 
get rid of all those red tiles :-) Or is the node density code already 
functional?
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] Splitter --cache parameter

2009-09-01 Thread Chris Miller
L I don't know what change made it possible, but I finally succeeded to
L process all of North/South America with the latest splitter and 3.9
L GB heap space. I used the cache option and max-node=1.2 million. I've
L tried this a few times before with older splitter versions, but this
L is the first time the split finished without fatal errors. So I
L finally have correct tiles for North America (at least the ones that
L got rendered by Mkgmap successfully!):
L http://garmin.na1400.info/routable.php

That's great news. I've made various small changes to the splitter over the 
past couple of weeks in an attempt to squeeze as much performance while using 
as little memory as possible, but nothing too significant so perhaps it's 
just a combination of everything that has just got you under the threshold.

L I guess it's time for me to start hacking on a areas.kml editing tool
L to get rid of all those red tiles :-) Or is the node density code
L already functional?

Have you tried the .kml import? I checked this in a few days ago - you can 
just pass in a .kml file instead of areas.list, and everything should behave 
as it would with the areas.list file.

The node density stuff isn't done yet, but yesterday I found time to do some 
fairly big internal refactorings of the splitter in preparation for this. 
It hopefully won't take me too much longer to get the density map working, 
albeit with nodes only initially. This 'nodes only' approach will still split 
in exactly the same way as the current splitter, the big advantage it that 
it will require much much less memory to do so without any performance cost. 
Once I have the nodes only approach working I'll start to look at calculating 
densities for the ways and relations too. At this stage I can't see how to 
avoid having to make some big performance/memory tradeoffs to get that working 
though, so I'll probably keep it optional.

Chris



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] Maximum map resolutions people use

2009-09-01 Thread Felix Hartmann


Chris Miller wrote:
 I've just chatted to Steve about this and it turns out my description below 
 is incorrect. What really matters is the resolution of the overview map, 
 NOT the resolution of the lowest zoom level you're using.
   
overview map is at 15 AFAIK, are you sure it's 16?

Anyhow we would really need not an empty overview map but overview map 
with say all objects inside of the last map level. Say you specify down 
to 16, then everything at 16 should be put into the overview map (say 
huge cities/capitals, national boardes, motorways) and the map 
themselves start at 17 or 18. This would give a good performance 
improvement when panning far out on GPS. Currently even having only very 
basic info in say level 16 will be quite slow.
If I were creating maps for myself only I would only go down to 18, and 
use basemap on GPS from 17 down as it is more suitable at those 
resolutions, however then in Mapsource orientation gets more difficult 
(as our overviewmap is empty).
 Given that mkgmap is currently hard-coded to use a resolution of 14 for the 
 overview map, there's no need for anyone to be changing the --resolution 
 parameter in the splitter just yet. This is also good news for the density 
 map code I'm working on, it means I don't have to worry too much about the 
 amount of memory it will require.

 Chris

 L I never used the --resolution parameter as I don't know what it
 L means and does to the output/maps. Maybe I missed a discussion about
 L it earlier, but can you explain again?
 L 
 CM Oh... I was about to point you to the documentation on the website
 CM but you've just made me realise that there isn't any documentation
 CM for that parameter yet! Whoops, I'll add it...
 CM 
 CM I think (but am not 100% sure - SteveR, can you please comment?) it
 CM should be described something like this:
 CM 
 CM --resolution=13
 CM Rounds the split areas off so they are suitably aligned to use with
 CM mkgmap
 CM at the specified resolution. The resolution value you supply should
 CM be less
 CM than or equal to the lowest resolution value you plan to use in
 CM mkgmap. For
 CM example, if you are using --levels=0:24,1:22,2:20 in mkgmap, the
 CM resolution
 CM you supply here must be 20 or less.
 L As you probably know, I split two files that to be able to cover the
 L whole world: A North/South America file and one that contains the
 L rest (I call it Eurasia).  The max-nodes is set to 1.200.000 and
 L problem areas are divided further by hand. Hope this info helps.
 L 
 CM Thanks. If you're splitting even the whole planet using the default
 CM resolution of 13 then there won't be a problem with the density map
 CM at all.
 CM 
 CM Chris



 ___
 mkgmap-dev mailing list
 mkgmap-dev@lists.mkgmap.org.uk
 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
   
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] Splitter --cache parameter

2009-09-01 Thread Lambertus
Chris Miller wrote:
 Have you tried the .kml import? I checked this in a few days ago - you can 
 just pass in a .kml file instead of areas.list, and everything should behave 
 as it would with the areas.list file.
 
Not yet, but I certainly will and report back any success or failure.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] R: [PATCH v3] - beware of the bollards!

2009-09-01 Thread Martin Simon
2009/7/8 Mark Burton ma...@ordern.com:

 Marco,

 I still do not see the reason to make 2 unaccessible arcs on both sides 
 instead of one.

 Imagine that you have only one restricted arc that is on one side of
 the bollard. Now if you are within that region and try to route to a
 point that is on the other side of the bollard, it will route straight
 through the bollard because you are leaving the restricted area and not
 entering it. If you have two restricted areas, one each side of the
 bollard and your starting point is within one of the areas, it will now
 not route through the bollard if the destination is outside of the
 restricted area on the other side of the bollard.

 As previously mentioned, the case where both start and destination are
 within the restricted area does not work right and, currently, I don't
 have a plan for fixing this. I can't see how that can be achieved.

Hi Mark!

Is there any chance for this patch to get committed in the near
future? I think it would be very helpful for routing (also with
barrier=cycle_barrier/gate/lift_gate etc) and the case of target
and/or destination being too close to the barrier is not that common.

Thank you for any info!

-Martin
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


[mkgmap-dev] Commit: r1163: Fix style listing for the case when the styles are on the classpath.

2009-09-01 Thread svn commit

Version 1163 was commited by steve on 2009-09-01 15:18:37 +0100 (Tue, 01 Sep 
2009) 

Fix style listing for the case when the styles are on the classpath.

The version, short and long descriptions would be taken from the first style
discovered and not from the appropriate style.

Other cases would alread list OK.

Also rename test so that it gets run by the build process and fix it up.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] list-styles

2009-09-01 Thread Steve Ratcliffe

Hi

On 31/08/09 14:51, frmas wrote:
 The following styles are available:
 arvernes   1.0: Style for OSM Maps
 contours   1.0: Style for OSM Maps
 default1.0: Style for OSM Maps
 noname 1.0: Style for OSM Maps
 perso  1.0: Style for OSM Maps
 test   1.0: Style for OSM Maps

 It seems it takes the summary line of the first style info file and
 apply it for all of them.

Thanks for reporting this.  I believe I have fixed this now.

Regards,

..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


[mkgmap-dev] Spotlight files makes Garmin crash

2009-09-01 Thread Morten Kjeldgaard
Hi,

I've just discovered that a directory called .Spotlight-V100/ on the microSD
card makes my Garmin Legend Cx crash when I switch it off.

The crash leads to a continuous beeping sound, and the only way to stop it
is to remove the batteries (and external power if connected to USB.)

The .Spotlight-V100/ directory is created if you mount the micro-SD card on
a Mac; apparently spotlight carries on to index the files on the card,
thereby creating the directory. I have not investigated if you can turn this
behaviour off.

By mounting I mean setting the Garmin device in USB-mode. The
.Spotligt-V100 directory is _not_ created if you connect the device to the
Mac and use Garmins programs (such as RoadTrip) to communicate with it.

If I delete the directory in question, the very annoying crashing behaviour
stops, and the Garmin switches off with the normal two-note beep.

Cheers,
Morten

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] Spotlight files makes Garmin crash

2009-09-01 Thread Clinton Gladstone
On Tue, Sep 1, 2009 at 4:57 PM, Morten Kjeldgaardm...@bioxray.au.dk wrote:

 I've just discovered that a directory called .Spotlight-V100/ on the microSD
 card makes my Garmin Legend Cx crash when I switch it off.

This is not really mkgmap related, but the latest Legend/Vista updates
are supposed to address this problem:

cx: http://www8.garmin.com/support/download_details.jsp?id=1417

hcx: http://www8.garmin.com/support/download_details.jsp?id=3643
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] Spotlight files makes Garmin crash

2009-09-01 Thread Apollinaris Schoell
But don't try to use Webupdater on MAC to install this.
this is known to break your device.



On 1 Sep 2009, at 8:12 , Clinton Gladstone wrote:

 On Tue, Sep 1, 2009 at 4:57 PM, Morten Kjeldgaardm...@bioxray.au.dk  
 wrote:

 I've just discovered that a directory called .Spotlight-V100/ on  
 the microSD
 card makes my Garmin Legend Cx crash when I switch it off.

 This is not really mkgmap related, but the latest Legend/Vista updates
 are supposed to address this problem:

 cx: http://www8.garmin.com/support/download_details.jsp?id=1417

 hcx: http://www8.garmin.com/support/download_details.jsp?id=3643
 ___
 mkgmap-dev mailing list
 mkgmap-dev@lists.mkgmap.org.uk
 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


[mkgmap-dev] [PATCH V2] stop/continue scheme extended to style-rules without conversion

2009-09-01 Thread Torsten Leistikow
Moin,

I have to admit, that I have didn't quite understand the processing of
the action part of the style rules, when I made the first verwion of the
patch. And I also have to admit, that I still do not really understand
it. But nevertheless the new version of the patch seems to work for me
under certain conditions.

The style syntax ist still the same as in the first version, e.g.:

highway=*  surface=concrete   {set surface=deleted; set
mkgmap_surface=paved}   [continue]

My patch now works in such a way, that this line will create a normal
rule (with priority), but will not create an element in the output
during the conversion.
The stop/continue extension will loop through the conversion, until no
more output types are found (including the empty outputs). During each
iteration of the loop the pre and postprocessing is done.

The problem now is, that I do not understand, how this processing works,
i.e. how the single actions are choosen.

This does not seem to matter, if the following condition is obeserved in
the preprocessing rules: Each action rule must modify the tags of the
element in such a way, that the condition is not fullfilled any more,
when the rule is checked again. In the above example the action set
surface=deleted takes care of this, afterwards the condition
surface=concrete will not be true any more.

So with the patch I was able to preprocess the osm-data with the
following rules, to generate a road map, which only differs between
paved and unpaved surface and is limited to roads, where motor cars ar e
allowed (see preproccessing rules below).

Gruss
Torsten

# Set highway names to include the reference if there is one
highway=*  mkmap_name_fixed!=* {name '${name} (${ref})' | '${ref}' |
'${name}' ; set mkmap_name_fixed=yes} [continue]

#set mkgmap_surface values to either paved or unpaved
highway=*  surface=paved {set surface=deleted; set
mkgmap_surface=paved}   [continue]
highway=*  surface=unpaved   {set surface=deleted; set
mkgmap_surface=unpaved} [continue]
highway=*  surface=asphalt   {set surface=deleted; set
mkgmap_surface=paved}   [continue]
highway=*  surface=cobblestone   {set surface=deleted; set
mkgmap_surface=paved}   [continue]
highway=*  surface=concrete  {set surface=deleted; set
mkgmap_surface=paved}   [continue]
highway=*  surface=paving_stones {set surface=deleted; set
mkgmap_surface=paved}   [continue]
highway=*  surface=metal {set surface=deleted; set
mkgmap_surface=paved}   [continue]
highway=*  surface=wood  {set surface=deleted; set
mkgmap_surface=paved}   [continue]
highway=*  surface=grass_paver   {set surface=deleted; set
mkgmap_surface=unpaved} [continue]
highway=*  surface=gravel{set surface=deleted; set
mkgmap_surface=unpaved} [continue]
highway=*  surface=pebblestone   {set surface=deleted; set
mkgmap_surface=unpaved} [continue]
highway=*  surface=grass {set surface=deleted; set
mkgmap_surface=unpaved} [continue]
highway=*  surface=ground{set surface=deleted; set
mkgmap_surface=unpaved} [continue]
highway=*  surface=earth {set surface=deleted; set
mkgmap_surface=unpaved} [continue]
highway=*  surface=dirt  {set surface=deleted; set
mkgmap_surface=unpaved} [continue]
highway=*  surface=mud   {set surface=deleted; set
mkgmap_surface=unpaved} [continue]
highway=*  surface=sand  {set surface=deleted; set
mkgmap_surface=unpaved} [continue]
highway=*  surface=ice_road  {set surface=deleted; set
mkgmap_surface=unpaved} [continue]

#set access values
highway=*  mkgmap_routing!=*  motorcar=yes
  {set mkgmap_routing=allowed;   set access=deleted; set
bicycle=deleted; set motorcar=deleted; set motor_vehicle=deleted; set
vehicle=deleted} [continue]
highway=*  mkgmap_routing!=*  motorcar=designated
  {set mkgmap_routing=allowed;   set access=deleted; set
bicycle=deleted; set motorcar=deleted; set motor_vehicle=deleted; set
vehicle=deleted} [continue]
highway=*  mkgmap_routing!=*  motor_vehicle=yes  motorcar!=*
  {set mkgmap_routing=allowed;   set access=deleted; set
bicycle=deleted; set motorcar=deleted; set motor_vehicle=deleted; set
vehicle=deleted} [continue]
highway=*  mkgmap_routing!=*  vehicle=yes  motor_vehicle!=* 
motorcar!=*  {set mkgmap_routing=allowed;   set
access=deleted; set bicycle=deleted; set motorcar=deleted; set
motor_vehicle=deleted; set vehicle=deleted} [continue]
highway=*  mkgmap_routing!=*  access=yes  vehicle!=* 
motor_vehicle!=*  motorcar!=*  {set mkgmap_routing=allowed;   set
access=deleted; set bicycle=deleted; set motorcar=deleted; set
motor_vehicle=deleted; set vehicle=deleted} [continue]
highway=*  mkgmap_routing!=*  (access=* | vehicle=* | motor_vehicle=*
| motorcar=*) {set mkgmap_routing=forbidden; set access=deleted; set
bicycle=deleted; set motorcar=deleted; set motor_vehicle=deleted; set
vehicle=deleted} [continue]
highway=*  mkgmap_routing!=*
  {set 

Re: [mkgmap-dev] [PATCH V2] stop/continue scheme extended to style-rules without conversion

2009-09-01 Thread Steve Ratcliffe

Hi

As an aside, I always planned to have lists of values which might
be useful in this case.  Eg. the following

 #set mkgmap_surface values to either paved or unpaved
 highway=*  surface=asphalt   {set mkgmap_surface=paved ...
 highway=*  surface=cobblestone   {set mkgmap_surface=paved ...
 highway=*  surface=concrete  {set mkgmap_surface=paved ...

could be represented by

   highway=*  surface=(asphalt, cobblestone, concrete, ...) {set 
mkgmap_surface=paved

(or with the keyword 'in' instead of = perhaps)

does that sound useful?

..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] [PATCH V2] stop/continue scheme extended to style-rules without conversion

2009-09-01 Thread Marko Mäkelä
On Tue, Sep 01, 2009 at 08:14:43PM +0100, Steve Ratcliffe wrote:
 
 Hi
 
 As an aside, I always planned to have lists of values which might
 be useful in this case.  Eg. the following
 
  #set mkgmap_surface values to either paved or unpaved
  highway=*  surface=asphalt   {set mkgmap_surface=paved ...
  highway=*  surface=cobblestone   {set mkgmap_surface=paved ...
  highway=*  surface=concrete  {set mkgmap_surface=paved ...
 
 could be represented by
 
highway=*  surface=(asphalt, cobblestone, concrete, ...) {set 
 mkgmap_surface=paved
 
 (or with the keyword 'in' instead of = perhaps)
 
 does that sound useful?

It would shorten some rules, such as this rule from my patch
for bus/railway/tram stop names:

(highway=bus_stop | railway=tram_stop | railway=halt | railway=station)
 (shelter=yes | covered=yes)
{ name '${name|def:} ${ref|def:}+${operator|def:}'; }

If you allowed the same syntax for keys, this rule would shorten to

(highway=bus_stop | railway={tram_stop,halt,station})  {shelter,covered}=yes

Above, I used the {,} syntax that is familiar from tcsh and bash.
The (,) or (|) syntax could be easier to implement in the grammar.

Marko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] [PATCH V2] stop/continue scheme extended to style-rules without conversion

2009-09-01 Thread Felix Hartmann



Steve Ratcliffe wrote:

On 01/09/09 17:36, Torsten Leistikow wrote:
  

Moin,

I have to admit, that I have didn't quite understand the processing of
the action part of the style rules, when I made the first verwion of the
patch. And I also have to admit, that I still do not really understand
it. But nevertheless the new version of the patch seems to work for me
under certain conditions.



They are run during matching which is why they are run in an arbitary
order.

This is a problem, but on the other hand if they are not run first,
then it is not possible to use an action to change what is matched
later on.  Everyone relies on this quite heavily it seems.

I think what we will have to do is create separate lists
of actions and rules. Create a list of all matched actions
and run them in the correct order first and then do the
type rules.
  

Yeah that would sound better.

I have not looked yet at the new patch, the thing needed desperately is 
to run the rules in several runs so that one can build up on previous 
rules, i.e have several rules that affect the name setting of the same 
street run one after another)


However we should be able to use different names for the global index 
once it's implemented. So if searching for an address the streetname ist 
just the streetname and not attributes added to it. However I know of 
course that the address index is still a long way to go...


Felix

..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
  
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Which Nuvi?

2009-09-01 Thread Thilo Hannemann
Hi Mark,

for collecting OSM tracks with your Nüvi you will want one where you  
can switch off the show on road behaviour. If you can't switch that  
off your tracks will always be exactly on top of the roads that are  
already in the map. Very much useless for OSM mapping.

With my Nüvi 255W I don't see a way to switch off that behaviour (but  
perhaps there is some hack that I don't know of). Also all the nice  
options to control the tracklogging are missing, e.g. setting the  
point density. From the tracks that my Nüvi captures it seems that the  
distance between the points is about 30 meters, that is very far apart  
for OSM mapping.

So I think at least the Nüvi 2xx series is useless for mapping. But  
using the mkgmap-generated OSM maps on them works fine. They do  
support the day and night modes (the Oregons for example doesn't),  
true color display (this is missing from the eTrex series, they only  
have 256 colors) and have an easily accessible SD-card slot (2 GB  
cards work, maybe more). I don't know about marine POIs, those are  
probably not supported well (but I don't know). Other than the Oregon  
for example it doesn't have a dedicated marine mode.

Hope that helps.

Regards
Thilo

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] Spotlight files makes Garmin crash

2009-09-01 Thread Marko Mäkelä
On Tue, Sep 01, 2009 at 04:24:10PM -0700, Apollinaris Schoell wrote:
 lucky you :)couldn't figure that out too. it wasn't a problem with older
 firmware. and since the update to 3.0 it was really annoying to remove the
 batteries all time.

Well, at least you can remove the batteries without breaking the case open.
Us poor Edge 605/705 owners do not have that luxury. :-)  The SD card is
removeable, but I guess the beep of death could be triggered by the internal
flash as well.  No, I don't have a Mac, so I don't really know if the
Edge is affected. 

BTW, a 2.90 firmware update for the Edge 605/705 was released this week.
Nothing special, and I haven't tried recording any traces with it yet.
The 2.70 badly broke the recording (it routinely corrupted the XML files).

Marko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] Which Nuvi?

2009-09-01 Thread Valentijn Sessink
Thilo Hannemann schreef:
 So I think at least the Nüvi 2xx series is useless for mapping.

My Nuvi 205T has an option to show/hide the tracklog. I bought it quite
recently, but it has an older map (2008). I'll ask a collegue, who just
got a 205, if he has the tracklog option as well.

V.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev