Re: [mkgmap-dev] mkgmap r1160 Exception when facing multiple splitted files
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
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
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
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
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/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.
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
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
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
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
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
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
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
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
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?
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
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?
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
