[mkgmap-dev] Merging roundabouts that are split because of bus route relations

In the Finnish forum , user Juhe noticed that the Nüvi 205 gave directions as if a roundabout were a series of junctions (as far as I understood). But his fix was wrong: it is not OK to merge the roundabout in the OSM source, because only part

[mkgmap-dev] Styling for the power user: filtering contour lines

To Christian Gawron Thank you for your tip. I will try to use it for the next release of my map. David > Hi Daniel, > > you can use regular expressions to filter contour lines by elevation > - here is what I do in my style file: > > # Contours take their name from the elevation setting. > #

Re: [mkgmap-dev] [PATCH v2] - styling for the power user

2009/8/7 Steve Ratcliffe > > Hi > > > "macro/programming language". As you say, the style files were never > > intended to be able to do the things we want them to do now. So what > > can we do about that? > > The style system was designed to do the little things that were > hardwired into the co

Re: [mkgmap-dev] Append Name with general rules via style-file

Steve Ratcliffe wrote: With these two rules, even if they are run in same order as they are written, the second one could never have an effect if ${name} is defined. highway=* { name '${name} (${ref})' | '${ref}' | '${name}' } highway=* { name '${name} ${name1}' | '${name1}' | '${name}' }

Re: [mkgmap-dev] [PATCH v2] - styling for the power user

Hi Steve, combining tags from multiple relations and the way tags itself should be possible. example some motorways portions share multiple route refs. this can be tagged as ref=ref1;ref2 but since relations are available most add 2 relations and add the same way to both. currently I can't

Re: [mkgmap-dev] Memory limits for mkgmap and splitter

bz2 is *very* slow to decompress, so yes if you have the space I'd recommend decompressing the osm first before running the splitter (since the splitter has to make a minimum of two passes over the file, thus also decompressing it at least twice). The (limited and simple) benchmarks I tried with

Re: [mkgmap-dev] [PATCH v2] - styling for the power user

Moin, Steve Ratcliffe schrieb: > I would like to know what people want to do that is not possible. > Is anyone other than Felix doing something that is difficult with > the current system? I haven't tried your latest modification, which allows to change the items from the condition match, but wit

Re: [mkgmap-dev] Memory limits for mkgmap and splitter

Before patches I gained about 5% by extrackting witz 7z unpacker on commandline, before running the splitter (however compiled 10 days ago, so excluding the lates changes). 2009/8/7 Clinton Gladstone > On Fri, Aug 7, 2009 at 2:56 PM, Chris Miller > wrote: > > > I've got 4 cores (8 with hyperthre

[mkgmap-dev] Commit: r1123: Add a test for style rules.

Version 1123 was commited by steve on 2009-08-07 15:26:00 +0100 (Fri, 07 Aug 2009) Add a test for style rules. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Memory limits for mkgmap and splitter

On Fri, Aug 7, 2009 at 2:56 PM, Chris Miller wrote: > I've got 4 cores (8 with hyperthreading) so this is something I'm acutely > aware of. Watching my PC churn away at only 12.5% CPU for a few hours isn't > my idea or resources well spent! Unfortunately there's no quick win because > the XML pars

Re: [mkgmap-dev] Append Name with general rules via style-file

With these two rules, even if they are run in same order as they are written, the second one could never have an effect if ${name} is defined. > highway=* { name '${name} (${ref})' | '${ref}' | '${name}' } > highway=* { name '${name} ${name1}' | '${name1}' | '${name}' } This is because you can o

Re: [mkgmap-dev] Append Name with general rules via style-file

Hi Felix, I am trying to work out what doesn't work here. In general anything that relies on the order that actions are run in will not work reliably (see my previous post). I will put each question/comment in a separate post to keep things clear and separate. The following part of the file c

Re: [mkgmap-dev] [PATCH v2] - styling for the power user

Hi > "macro/programming language". As you say, the style files were never > intended to be able to do the things we want them to do now. So what > can we do about that? The style system was designed to do the little things that were hardwired into the code directly from the style itself. It als

Re: [mkgmap-dev] Memory limits for mkgmap and splitter

Great, I'll keep an impatient eye at the mailinglist ;-) Chris Miller wrote: >> While you're on it, dare I ask to check if it's easy to do some stuff >> in different threads? I notice that one core is at 100% almost >> constantly while the harddisk is still far from being maxed-out. There >> shoul

Re: [mkgmap-dev] Memory limits for mkgmap and splitter

> While you're on it, dare I ask to check if it's easy to do some stuff > in different threads? I notice that one core is at 100% almost > constantly while the harddisk is still far from being maxed-out. There > should be room to further speed things up a bit. I've got 4 cores (8 with hyperthreadi

Re: [mkgmap-dev] [PATCH] reduce highway=service resolution

Marko Mäkelä writes: > When the resolution of highway=residential was reduced, highway=service > should have been reduced as well. It looks odd to see highway=service > but not the highway=residential that they are connected to. > > highway=residential | highway=living_street [0x06 road_class=

Re: [mkgmap-dev] Memory limits for mkgmap and splitter

Chris Miller wrote: > Thanks for the info. Sounds like you've found about the same limit I have > with --max-nodes and -Xmx4000m. This weekend I'm going to add a --max-areas > parameter. Setting this to a number < 255 should allow for higher a > --max-nodes > value with the same heap size. In y

Re: [mkgmap-dev] [PATCH v2] - styling for the power user

Marko Mäkelä wrote: > Can we have the best of both worlds? I think we already have both possibilities. We can use any preprocessing we like and then use a selfmade style which uses fantasy tags. Or make a preprocessor which outputs the well-known tags. This works best if everything is kept in

Re: [mkgmap-dev] [PATCH v2] - styling for the power user

Hi Marko, > Hi Mark, Thilo, list, > > > The problem here is that in the end you cannot separate the styling > > from the map conversion process. When I started using mkgmap I also > > used preprocessing. But then I found that my preprocessor had to > > duplicate a lot of the functionality

Re: [mkgmap-dev] Memory limits for mkgmap and splitter

>> Just an thought from reading the thread: >> Multiple parsing runs with an bz2 zipped file could do worse to the >> performance. It would mean multiple decompressing of the input files. >> And in my experience decompressing bz2 costs a lot of resources. >> >> (In my case I'm directly using the

[mkgmap-dev] [PATCH] reduce highway=service resolution

When the resolution of highway=residential was reduced, highway=service should have been reduced as well. It looks odd to see highway=service but not the highway=residential that they are connected to. Please apply this patch. The resolution of highway=track looks a bit high too, but displaying

Re: [mkgmap-dev] [PATCH v2] - styling for the power user

Hi Mark, Thilo, list, > The problem here is that in the end you cannot separate the styling > from the map conversion process. When I started using mkgmap I also > used preprocessing. But then I found that my preprocessor had to > duplicate a lot of the functionality of mkgmap to "do it righ

Re: [mkgmap-dev] Memory limits for mkgmap and splitter

Thanks for the info. Sounds like you've found about the same limit I have with --max-nodes and -Xmx4000m. This weekend I'm going to add a --max-areas parameter. Setting this to a number < 255 should allow for higher a --max-nodes value with the same heap size. In your case with 367 areas, settin

Re: [mkgmap-dev] Styling for the power user: filtering contour lines

Hi Daniel, you can use regular expressions to filter contour lines by elevation - here is what I do in my style file: # Contours take their name from the elevation setting. # multiples of 200m contour=elevation & ele ~ '\d*[02468]00' { name '${ele|conv:m=>ft}'; } [0x22 resolution 18] # m

Re: [mkgmap-dev] Memory limits for mkgmap and splitter

Tested this latest version on my American extract with -Xmx4000m: With 1.2 million nodes the Java VM crashed due to lack of memory. Using 1 million nodes the split succeeded with 367 areas in 3:20 hours. Some swapping was noticed (bad for speed). Although I'd rather use the 1.2 million settin