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

[Marko Mäkelä]

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
of the roundabout belongs to a bus route relation.  Here is the changeset,
which has already been reverted according to user Daeron:
http://www.openstreetmap.org/browse/changeset/2026393

Juhe writes that he got his map from
, but he has since then
compiled a map with mkgmap based on my scripts
.

Would it be possible to merge such roundabouts in mkgmap or in a preprocessing
script?  I guess that this would require a style rule plugin that would merge
ways based on a condition.

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

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

[David]

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.
> # multiples of 200m
> contour=elevation & ele ~ '\d*[02468]00'
>   { name '${ele|conv:m=>ft}'; }
>   [0x22 resolution 18]
> # multiples of 50m
> contour=elevation & ele ~ '\d+[05]0'
>   { name '${ele|conv:m=>ft}'; }
>   [0x21 resolution 21]
> contour=elevation
>   { name '${ele|conv:m=>ft}'; }
>   [0x20 resolution 23]
>
> You could use '\d+[27]5' for your purpose.
>
> Best wishes
> Christian



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

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

[Felix Hartmann]

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 code directly from the style itself.  It also
> pretty much pre-dated routing so that the fact that you can
> have two separate names for a road (say a name and a reference when
> both exist) cannot be implemented.
>
> 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?
>
> Then I need to work out if the main problem is that actions are, in
> effect, run in a random order.  Would guaranteeing that actions were
> run in the order that they occurred in the file help?  It would
> certainly make it possible to work out what a set of rules did.
> I probably shouldn't have allowed stand alone actions on rules without
> a type, without also making them ordered.


To me this would be enough. Best make sure that it is also possible to run
several actions against the same road.

I think the most difficult is getting the name of a road right, other things
are much easier, as there are not many possibilities. Only in case we have
the extended types completely covered, it might become a bit more complex,
but nothing I can imagine that I couldn't do right now.

The other big thing missing for me (other than the extended types) is making
corners rounder but that has nothing to do with the style-file. As very
sharp corners for bicycle/pedestrian impose a too heavy time toll.

One thing I have noticed on Garmin Swiss topo maps, is that the calculated
length of some ways that curl down mountains is underrated by up to 30%,
maybe they do this on purpose to improve the chance of the ways being chosen
for autorouting. Off course having the big disadvantage that those roads
will not calculate the proper distance anymore. Maybe one could make the
autorouting data to believe the road is straight but longer, I don't know
whether that is possible.


>
>
> I think it can be done without a large performance overhead (at least
> if you make minimal use of actions), but if it is not going to
> help any power stylers then it is not worth doing and we should
> do something else instead.
>
> > implement all those nifty new tricks I'd like to have a plug-in
> > interface in mkgmap to add my own Java routines. That could be plug-in
> > at compile time, no need to make it too complicated. It would be a
> > start to sort through all the classes and provide some documented
> > hooks to plug-in your own routines. Then in the style files one could
> > "invoke" the plug-ins that one would like to use.
>
> I remember thinking that a style could have a classes directory
> probably for type resolvers although I forget exactly why.  It
> would certainly be possible, although I would like to see if
> can make the current system work better for people.
>
> ..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] Append Name with general rules via style-file

[Felix Hartmann]

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}' }



This is because you can only set the name once.  If ${name} is set
then the name will be set in the first rule and so the only
way that the second rule can be used is if ${name1} is set and ${name}
is not set.

You could fix that by doing everything together, if that is
the effect you want:

highway=* {
name '${name} (${ref})'
| '${ref}'
| '${name} ${name1}'
| '${name1}'
| '${name}'
}

..Steve
  
The problem ist that generating a list that does everything together 
will become to complex, say you have to write down all combination for 
10 keys. Or am I missing something? The problem is that if I write 
everything into one line, and one key listed there is not present on 
highway=* it will fail.


highway=* {
name '${name} (${ref})'
| '${ref}'
| '${name} ${name1}'
| '${name1}'
| '${name}'
}

would become for one more value

highway=* {
name| '${ref} ${name} ${name1} ${name2}'
| '${name} ${name1} ${name2}'
| '${ref} ${name1} ${name2}'
| '${ref} ${name} ${name2}'
| '${ref} ${name} ${name}1'
| '${ref} ${name}
| '${ref} ${name1}
| '${ref} ${name2}
| '${name} ${name1}
| '${name} ${name2}
		| '${name1} ${name2} 
		| '${name}'

| '${name1}'
| '${name2}'
| '${ref}'

}

Adding one more and it gets even worse... but adding 10 more keys and this 
list will grow into eternity.

Now the problem is that I don't want to have the value of the key in the name itself each time, but on presence of a key I wan't to have another value inside. 


so if route=mtb is present I want to have mtbrt in the name, or for 
route=bicycle I would like to have cyrt and so on. So I have to run some tests 
whether values are present or not, which would make the task to put everything 
into on line even more difficult...



___
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] [PATCH v2] - styling for the power user

[Apollinaris Schoell]

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 think of a style to accomplish merging the 2  
relation refs to a list


--
apo




On Aug 7, 2009, at 6:17 AM, Steve Ratcliffe wrote:

>
> 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 also
> pretty much pre-dated routing so that the fact that you can
> have two separate names for a road (say a name and a reference when
> both exist) cannot be implemented.
>
> 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?
>
> Then I need to work out if the main problem is that actions are, in
> effect, run in a random order.  Would guaranteeing that actions were
> run in the order that they occurred in the file help?  It would
> certainly make it possible to work out what a set of rules did.
> I probably shouldn't have allowed stand alone actions on rules without
> a type, without also making them ordered.
>
> I think it can be done without a large performance overhead (at least
> if you make minimal use of actions), but if it is not going to
> help any power stylers then it is not worth doing and we should
> do something else instead.
>
>> implement all those nifty new tricks I'd like to have a plug-in
>> interface in mkgmap to add my own Java routines. That could be plug- 
>> in
>> at compile time, no need to make it too complicated. It would be a
>> start to sort through all the classes and provide some documented
>> hooks to plug-in your own routines. Then in the style files one could
>> "invoke" the plug-ins that one would like to use.
>
> I remember thinking that a style could have a classes directory
> probably for type resolvers although I forget exactly why.  It
> would certainly be possible, although I would like to see if
> can make the current system work better for people.
>
> ..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] Memory limits for mkgmap and splitter

[Chris Miller]

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 .bz2 
vs .osm showed that .bz2 splitting takes ~6 times longer than an uncompressed 
.osm file. As for gz - it is quite a lot faster to deal with than bz2 though 
I haven't done any benchmarking with it as far as the splitter is concerned. 
My guess is that uncompressed will still win out unless you have fairly slow 
disks and a very fast CPU.

Interestingly, it's theoretically possible to parallelise bz2 
compression/decompression 
algorithm to give an almost linear performance improvements per core. 
Implementing 
this would be a big job but on a 4+ core machine would make a pretty 
significant 
difference. It's on my todo list but please don't hold your breath!

Chris


> Just out of interest, what performance gains (or disadvantages) would
> there be to working with uncompressed files, instead of bz2 and gz
> files?
> 
> Would this be faster for those of us with copious amounts of disk
> space, or would the extra IO negate any CPU-related performance gains?
> 
> I know that Osmosis performance on multi-core systems can apparently
> be improved by piping the OSM file through a decompression program,
> but I assume that would not be practical for Splitter which must make
> several passes through the file.
> 
> Cheers.




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

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

[Torsten Leistikow]

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 with previous versions I tried the
following processing:

1. I wanted to to set all surface values to either paved or unpaved. So
on top of my lines-file I entered rules like

surface=sand {set surface=unpaved}
surface=concrete {set surface=paved}
...

Later I changed the rules to

highway=* & surface=sand {set surface=unpaved}
highway=* & surface=concrete {set surface=paved}

Right now I do not know, whether the later change was necessary at all,
and whether the rules are working as expected. But I haven't noticed any
errors.

2. I wanted to evaluate the access-tags, replace them with my own flags,
and delete the access-tags:
highway=* & bicycle=yes {set mkgmap_routing=yes; set bicycle=''}
highway=* & bicycle=designated {set mkgmap_routing=yes; set bicycle=''}
highway=* & bicycle=* {set mkgmap_routing=false; set bicycle=''}
highway=footway & mkgmap_routing!=* {set mkgmap_routing=false}
highway=track & mkgmap_routing!=* {set mkgmap_routing=false}
...

I did not manage to get such a scheme working. As a workaround I create
a single rule for each access condition and each highway type, so that
the action part was done together with the conversion. Although it does
work in the end, it needs much larger style files and is much harder to
maintain.


And since you are asking, what I would like to do with styles:
For lines and polygons I would like to have the following action rules:
- create_start_point -> creates an additional point at the position of
the first point of the OSM way with the same tags as the OSM way. This
point shall afterwards be processed like all the other OSM points.
- create_centre_point -> the same as above but at the position of the
geometric centre of the OSM way
- create_last_point -> the same as above but at the position of the last
point of the OSM way

With such rules, you could control via the style file, which areas get
an additional POI/icon and which not.
Or you could mark some highways with additional icons, e.g.
speed_limits, or graphic symbols for special hiking routes.

Regarding mkgmap and styles: I would like to see as many features as
possible controlled via the style and not hardcoded in mkgmap. For my
taste most of the latest additions to the mkgmap parameters would be
better realised as action rules in the style rather than general program
parameters (e.g. make_cycleways, road-name-pois, add-pois-to-areas), so
that the user has more control, when the action shall be applied and
when not.

Gruss
Torsten
___
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

[Felix Hartmann]

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 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 parsing is very linear, but I have already been considering
> various
> > options and certainly plan to give them a try at some point. I've got
> quite
> > a few other improvements planned that'll come first though.
>
> Just out of interest, what performance gains (or disadvantages) would
> there be to working with uncompressed files, instead of bz2 and gz
> files?
>
> Would this be faster for those of us with copious amounts of disk
> space, or would the extra IO negate any CPU-related performance gains?
>
> I know that Osmosis performance on multi-core systems can apparently
> be improved by piping the OSM file through a decompression program,
> but I assume that would not be practical for Splitter which must make
> several passes through the file.
>
> Cheers.
> ___
> 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] Commit: r1123: Add a test for style rules.

[svn commit]

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

[Clinton Gladstone]

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 parsing is very linear, but I have already been considering various
> options and certainly plan to give them a try at some point. I've got quite
> a few other improvements planned that'll come first though.

Just out of interest, what performance gains (or disadvantages) would
there be to working with uncompressed files, instead of bz2 and gz
files?

Would this be faster for those of us with copious amounts of disk
space, or would the extra IO negate any CPU-related performance gains?

I know that Osmosis performance on multi-core systems can apparently
be improved by piping the OSM file through a decompression program,
but I assume that would not be practical for Splitter which must make
several passes through the file.

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

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

[Steve Ratcliffe]

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 only set the name once.  If ${name} is set
then the name will be set in the first rule and so the only
way that the second rule can be used is if ${name1} is set and ${name}
is not set.

You could fix that by doing everything together, if that is
the effect you want:

highway=* {
name '${name} (${ref})'
| '${ref}'
| '${name} ${name1}'
| '${name1}'
| '${name}'
}

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

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

[Steve Ratcliffe]

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 could be much reduced:

> mtb:scale=0 & mtb:scale:uphill=0 & route=mtb { name 'mtbrt00 ${name}' |
> 'mtbrt00' }
> mtb:scale=0 & mtb:scale:uphill=1 & route=mtb { name 'mtbrt01 ${name}' |
> 'mtbrt01' }
> mtb:scale=0 & mtb:scale:uphill=2 & route=mtb { name 'mtbrt02 ${name}' |
> 'mtbrt02' }
> mtb:scale=0 & mtb:scale:uphill=3 & route=mtb { name 'mtbrt03 ${name}' |
> 'mtbrt03' }
> mtb:scale=0 & mtb:scale:uphill=4 & route=mtb { name 'mtbrt04 ${name}' |
> 'mtbrt04' }
> mtb:scale=0 & mtb:scale:uphill=5 & route=mtb { name 'mtbrt05 ${name}' |
> 'mtbrt05' }
> mtb:scale=1 & mtb:scale:uphill=1 & route=mtb { name 'mtbrt11 ${name}' |
> 'mtbrt11' }
> mtb:scale=1 & mtb:scale:uphill=2 & route=mtb { name 'mtbrt12 ${name}' |
> 'mtbrt12' }
> mtb:scale=1 & mtb:scale:uphill=3 & route=mtb { name 'mtbrt13 ${name}' |
> 'mtbrt13' }
> mtb:scale=1 & mtb:scale:uphill=4 & route=mtb { name 'mtbrt14 ${name}' |
> 'mtbrt14' }
> mtb:scale=1 & mtb:scale:uphill=5 & route=mtb { name 'mtbrt15 ${name}' |
> 'mtbrt15' }
> mtb:scale=2 & mtb:scale:uphill=2 & route=mtb { name 'mtbrt22 ${name}' |
> 'mtbrt22' }
> mtb:scale=2 & mtb:scale:uphill=3 & route=mtb { name 'mtbrt23 ${name}' |
> 'mtbrt23' }
> mtb:scale=2 & mtb:scale:uphill=4 & route=mtb { name 'mtbrt24 ${name}' |
> 'mtbrt24' }
> mtb:scale=2 & mtb:scale:uphill=5 & route=mtb { name 'mtbrt25 ${name}' |
> 'mtbrt25' }
> mtb:scale=3 & mtb:scale:uphill=3 & route=mtb { name 'mtbrt33 ${name}' |
> 'mtbrt33' }
> mtb:scale=3 & mtb:scale:uphill=4 & route=mtb { name 'mtbrt34 ${name}' |
> 'mtbrt34' }
> mtb:scale=3 & mtb:scale:uphill=5 & route=mtb { name 'mtbrt35 ${name}' |
> 'mtbrt35' }
> mtb:scale=4 & mtb:scale:uphill=4 & route=mtb { name 'mtbrt44 ${name}' |
> 'mtbrt44' }
> mtb:scale=4 & mtb:scale:uphill=5 & route=mtb { name 'mtbrt45 ${name}' |
> 'mtbrt45' }
> mtb:scale=5 & mtb:scale:uphill=5 & route=mtb { name 'mtbrt55 ${name}' |
> 'mtbrt55' }
>
> mtb:scale:uphill=0 & route=mtb { name 'mtbrt.0 ${name}' | 'mtbrt.0' }
> mtb:scale:uphill=1 & route=mtb { name 'mtbrt.1 ${name}' | 'mtbrt.1' }
> mtb:scale:uphill=2 & route=mtb { name 'mtbrt.2 ${name}' | 'mtbrt.2' }
> mtb:scale:uphill=3 & route=mtb { name 'mtbrt.3 ${name}' | 'mtbrt.3' }
> mtb:scale:uphill=4 & route=mtb { name 'mtbrt.4 ${name}' | 'mtbrt.4' }
> mtb:scale:uphill=5 & route=mtb { name 'mtbrt.5 ${name}' | 'mtbrt.5' }
>
> mtb:scale=0 & route=mtb { name 'mtbrt0. ${name}' | 'mtbrt0.' }
> mtb:scale=1 & route=mtb { name 'mtbrt1. ${name}' | 'mtbrt1.' }
> mtb:scale=2 & route=mtb { name 'mtbrt2. ${name}' | 'mtbrt2.' }
> mtb:scale=3 & route=mtb { name 'mtbrt3. ${name}' | 'mtbrt3.' }
> mtb:scale=4 & route=mtb { name 'mtbrt4. ${name}' | 'mtbrt4.' }
> mtb:scale=5 & route=mtb { name 'mtbrt5. ${name}' | 'mtbrt5.' }
>
> mtb:scale=0 & mtb:scale:uphill=0 { name 'mtb00 ${name}' | 'mtb00' }
> mtb:scale=0 & mtb:scale:uphill=1 { name 'mtb01 ${name}' | 'mtb01' }
> mtb:scale=0 & mtb:scale:uphill=2 { name 'mtb02 ${name}' | 'mtb02' }
> mtb:scale=0 & mtb:scale:uphill=3 { name 'mtb03 ${name}' | 'mtb03' }
> mtb:scale=0 & mtb:scale:uphill=4 { name 'mtb04 ${name}' | 'mtb04' }
> mtb:scale=0 & mtb:scale:uphill=5 { name 'mtb05 ${name}' | 'mtb05' }
> mtb:scale=1 & mtb:scale:uphill=1 { name 'mtb11 ${name}' | 'mtb11' }
> mtb:scale=1 & mtb:scale:uphill=2 { name 'mtb12 ${name}' | 'mtb12' }
> mtb:scale=1 & mtb:scale:uphill=3 { name 'mtb13 ${name}' | 'mtb13' }
> mtb:scale=1 & mtb:scale:uphill=4 { name 'mtb14 ${name}' | 'mtb14' }
> mtb:scale=1 & mtb:scale:uphill=5 { name 'mtb15 ${name}' | 'mtb15' }
> mtb:scale=2 & mtb:scale:uphill=2 { name 'mtb22 ${name}' | 'mtb22' }
> mtb:scale=2 & mtb:scale:uphill=3 { name 'mtb23 ${name}' | 'mtb23' }
> mtb:scale=2 & mtb:scale:uphill=4 { name 'mtb24 ${name}' | 'mtb24' }
> mtb:scale=2 & mtb:scale:uphill=5 { name 'mtb25 ${name}' | 'mtb25' }
> mtb:scale=3 & mtb:scale:uphill=3 { name 'mtb33 ${name}' | 'mtb33' }
> mtb:scale=3 & mtb:scale:uphill=4 { name 'mtb34 ${name}' | 'mtb34' }
> mtb:scale=3 & mtb:scale:uphill=5 { name 'mtb35 ${name}' | 'mtb35' }
> mtb:scale=4 & mtb:scale:uphill=4 { name 'mtb44 ${name}' | 'mtb44' }
> mtb:scale=4 & mtb:scale:uphill=5 { name 'mtb45 ${name}' | 'mtb45' }
> mtb:scale=5 & mtb:scale:uphill=5 { name 'mtb55 ${name}' | 'mtb55' }
>
> mtb:scale:uphill=0 { name 'mtb.0 ${name}' | 'mtb.0' }
> mtb:scale:uphill=1 { name 'mtb.1 ${name}' | 'mtb.1' }
> mtb:scale:uphill=2 { name 'mtb.2 ${name}' | 'mtb.2' }
> mtb:scale:uphill=3 { name 'mtb.3 ${name}' | 'mtb.3' }
> mtb:scale:uphill=4 { name 'mtb.4 ${name}' | 'mtb.4' }
> mtb:scale:uphill=5 { name 'mtb.5 ${name}' | 'mtb.5' }
>
> mtb:scale=0 { name 'mtb0. ${name}' | 'mtb0.' }
> mtb:scale=1 { name 'mtb1. ${name}' | 'mtb1.' }
> mtb:scale=2 { name 'mtb2. ${name}' | 'mtb2.' }
> mtb:scale=3 { name 'mtb3. ${name}' | 'mtb3

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

[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 code directly from the style itself.  It also
pretty much pre-dated routing so that the fact that you can
have two separate names for a road (say a name and a reference when
both exist) cannot be implemented.

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?

Then I need to work out if the main problem is that actions are, in
effect, run in a random order.  Would guaranteeing that actions were
run in the order that they occurred in the file help?  It would
certainly make it possible to work out what a set of rules did.
I probably shouldn't have allowed stand alone actions on rules without
a type, without also making them ordered.

I think it can be done without a large performance overhead (at least
if you make minimal use of actions), but if it is not going to
help any power stylers then it is not worth doing and we should
do something else instead.

> implement all those nifty new tricks I'd like to have a plug-in
> interface in mkgmap to add my own Java routines. That could be plug-in
> at compile time, no need to make it too complicated. It would be a
> start to sort through all the classes and provide some documented
> hooks to plug-in your own routines. Then in the style files one could
> "invoke" the plug-ins that one would like to use.

I remember thinking that a style could have a classes directory
probably for type resolvers although I forget exactly why.  It
would certainly be possible, although I would like to see if
can make the current system work better for people.

..Steve
___
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

[Lambertus]

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
>> should be room to further speed things up a bit.
> 
> 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 parsing is very linear, but I have already been considering various 
> options and certainly plan to give them a try at some point. I've got quite 
> a few other improvements planned that'll come first though.
> 
> 
> 
> ___
> 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] Memory limits for mkgmap and splitter

[Chris Miller]

> 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 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 parsing is very linear, but I have already been considering various 
options and certainly plan to give them a try at some point. I've got quite 
a few other improvements planned that'll come first though.



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

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

[Greg Troxel]

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=0 road_speed=2 
> resolution 23]

> -highway=service [0x07 road_class=0 road_speed=1 resolution 22]
> +highway=service [0x07 road_class=0 road_speed=1 resolution 23]

+1

> Please apply this patch.  The resolution of highway=track looks a bit high
> too, but displaying highway=track at low zoom levels could be useful in
> sparsely built areas.

This is really a problem with the tagging scheme; physical properties of
a road do not correlate all that well with the appropriate zoom levels.
The problem is even more acute with footway and path.  I can see two
approaches:

  change tagging to have an importance level separate from physical, to
  be able to mark tracks etc. that should show up more prominently.
  This is likely to be so contentious that I'm going to ignore it

  Somehow have mkgmap (and other renderers) figure out importance from
  topology and context, either

if there wouldn't be much else on the map in the neighborhood, bump
up the zoom level at which the track is shown.  (sensible, probably
hard, and computationally scary)

have rules that look at the length of the way/relation and use that
to determine zoom.  A track that is 3 miles long is interesting at
higher zoom levels than one only 100m long.  This is also true for
footpaths, which is my main motivation (short city paths vs long
trails in forests)


So if mkgmap calculated the length of the object and one could use that
in style rules, I bet that would go a long way to getting the
appropriate zoom level.  Perhaps 'wlength' and 'rlength', with the
caveat that it's only the part within this tile and associated overlap
areas that is counted.






pgpSma8WosU3Y.pgp
Description: PGP signature
___
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

[Lambertus]

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 your case with 367 areas, setting 
> --max-areas=184 
> should allow for a higher max-nodes setting without any extra passes required.
> 
Yes, that's a welcome addition.

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.

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

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

[Ralf Kleineisel]

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 the style system and next to nothing is hardcoded 
in the mkgmap code, because changing a style file is not a big deal, but 
fiddling with the java code isn't for everyone. For the newcomer user 
mkgmap always should produce a sensible map out-of-the-box.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Mark Burton]

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 of mkgmap to "do it right". For  
> > example finding all the ways that belong to a relation. It was much  
> > easier to patch mkgmap to get the same results, because all that  
> > information is already accessible there. But of course one could argue  
> > if this "convenience" is a reason in itself not to separate styling  
> > and map conversion.
> 
> For what it is worth, I agree with Thilo here.  The Unix philosophy of
> combining simple tools is preferrable when it works, but OSM is huge, and
> all of the graph has to be kept in memory during the processing.  Command
> pipelines and scripts work nicely when working with simple text files, when
> linear access to the data is enough.  But I wouldn't want to load and dump
> large volumes of data even more times than currently (bzip2 decompression,
> splitter, mkgmap).

I agree, performance could be an issue although not a show-stopper
due to the cheapness of multi-core CPUs and RAM.
 
> The mkgmap:* would be great for quick prototyping or for those who prefer
> preprocessing or prefer to work with their favourite scripting language
> instead of Java.  This brings about a question of dependences and 
> coordination.
> If people start writing preprocessor scripts in their favourite languages,
> suddenly you might need a host of runtime environments (Perl, Python, Ruby,
> ...) with all sorts of libraries, in addition to the current Java dependences.

Exactly, give people a choice.

As to the runtime requirements, what is required to be installed depends
on whatever technology is used to implement the styling filter but
unless it's seriously esoteric, you wouldn't expect it to be a
problem. These days, most of the common languages are
available for all of the major platforms at the click of a button.

> Can we have the best of both worlds?  The best preprocessing transformations
> would eventually be ported to mkgmap plugins that would be linked to mkgmap
> style rules.  Examples of such plugins include plugins for naming objects
> and for filtering or duplicating objects (lines or points, e.g., refactoring
> the current code of duplicating cycleways or transforming areas into POIs).
> We can start small; I'd be happy with the naming plugin framework for now.

Of course.

I am not for one moment suggesting that development of the
mkgmap styling engine (MSE) should be limited. As you suggest, (with the
patch) it would be possible to prototype and develop styling schemes
outside of mkgmap. If successful, those schemes could then be
incorporated into the MSE.

Remember, the zero-style patch only disables the MSE for elements
that have a mkgmap:gtype tag, so all other elements that don't
have that tag will still be styled by the MSE. This allows "selective
styling" by an external program that could be useful for testing
styling regimes without having to implement them in a prototype form
within mkgmap.

So, unless there are compelling reasons not to incorporate the patch, I
will commit it before too long as I believe in the long-run it will
prove to be useful.

Cheers,

Mark



___
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

[Johann Gail]

>> 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 osm.bz2 files from geofabrik as input.)
>> 
>
> Perhaps true, but you should have seen the runtime from running mkgmap
> on input files that needed more than 1.8G per area on a machine with 2G
> of RAM.  Redoing bz2 on the input a few times would have been fine
> compared to paging.  I realize this is tough, as the right tuning is heavily 
> dependent on how much memory is available.
>   
>   
Yes, I know it from my job.
A java process starting swapping is nearly unusable. IMO the reason for 
it is the garbage collector, which has to read in the whole virtual 
memory periodically. Therefore it sometimes help to double the size of 
the virtual memory of the java machine (-Xmx ...), because the GC has to 
run less.

But in general you are right. You should do everything to stop swapping 
of java.





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

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

[Marko Mäkelä]

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 highway=track at low zoom levels could be useful in
sparsely built areas.

Marko

Index: resources/styles/default/lines
===
--- resources/styles/default/lines  (revision 1122)
+++ resources/styles/default/lines  (working copy)
@@ -46,7 +46,7 @@ highway=primary_link [0x08 road_class=3 
 highway=residential | highway=living_street [0x06 road_class=0 road_speed=2 
resolution 23]
 highway=secondary [0x04 road_class=2 road_speed=3 resolution 20]
 highway=path {add access = no; add bicycle = yes; add foot = yes} [0x16 
road_class=0 road_speed=0 resolution 23]
-highway=service [0x07 road_class=0 road_speed=1 resolution 22]
+highway=service [0x07 road_class=0 road_speed=1 resolution 23]
 highway=steps {add access = no; add foot = yes} [0x16 road_class=0 
road_speed=0 resolution 23]
 highway=tertiary [0x05 road_class=1 road_speed=3 resolution 20]
 highway=track [0x0a road_class=0 road_speed=1 resolution 21]
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Marko Mäkelä]

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 right". For  
> example finding all the ways that belong to a relation. It was much  
> easier to patch mkgmap to get the same results, because all that  
> information is already accessible there. But of course one could argue  
> if this "convenience" is a reason in itself not to separate styling  
> and map conversion.

For what it is worth, I agree with Thilo here.  The Unix philosophy of
combining simple tools is preferrable when it works, but OSM is huge, and
all of the graph has to be kept in memory during the processing.  Command
pipelines and scripts work nicely when working with simple text files, when
linear access to the data is enough.  But I wouldn't want to load and dump
large volumes of data even more times than currently (bzip2 decompression,
splitter, mkgmap).

The mkgmap:* would be great for quick prototyping or for those who prefer
preprocessing or prefer to work with their favourite scripting language
instead of Java.  This brings about a question of dependences and coordination.
If people start writing preprocessor scripts in their favourite languages,
suddenly you might need a host of runtime environments (Perl, Python, Ruby,
...) with all sorts of libraries, in addition to the current Java dependences.

Can we have the best of both worlds?  The best preprocessing transformations
would eventually be ported to mkgmap plugins that would be linked to mkgmap
style rules.  Examples of such plugins include plugins for naming objects
and for filtering or duplicating objects (lines or points, e.g., refactoring
the current code of duplicating cycleways or transforming areas into POIs).
We can start small; I'd be happy with the naming plugin framework for now.

Marko
___
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

[Chris Miller]

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, setting 
--max-areas=184 
should allow for a higher max-nodes setting without any extra passes required.

> 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 setting, as that is a nice
> balance between the number of failed map builds and map size
> worldwide, using 1 million now enables me to do all the work myself
> instead of relying on others. Great, thanks a million!
> 
> Next up: splitting the whole world on my laptop and process the output
> with mkgmap. See which areas need fixing manually...



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

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

[Christian Gawron]

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]
# multiples of 50m
contour=elevation & ele ~ '\d+[05]0'
{ name '${ele|conv:m=>ft}'; }
[0x21 resolution 21]
contour=elevation
{ name '${ele|conv:m=>ft}'; }
[0x20 resolution 23]

You could use '\d+[27]5' for your purpose.

Best wishes
Christian

David schrieb:
> To Mark Burton,
>
> The new features you added for styling is a great step for my map. The  
> last step is how to filter each contour line which height finishes by  
> 25 or 75 (I don't know how to do it with style rules). These contours  
> are only used for low level of details. At higher LOD, contours with a  
> step of 10m are displayed (to build such a layer I need cgpsmapper).
>
> Thank you for your work,
>
> David
>
>
>
> ___
> 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] Memory limits for mkgmap and splitter

[Lambertus]

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 setting, as that is a nice 
balance between the number of failed map builds and map size worldwide, 
using 1 million now enables me to do all the work myself instead of 
relying on others. Great, thanks a million!

Next up: splitting the whole world on my laptop and process the output 
with mkgmap. See which areas need fixing manually...

  Chris Miller wrote:
> I've built a new version that *might* be able to handle the planet OK. I 
> don't know how many areas North America breaks in to, but if you're able 
> to handle 255 areas (at 1,600,000 nodes each) with an older version of the 
> splitter, then I think this version should work for the whole planet:
> 
> http://redyeti.net/splitter.jar
> 
> If you still can't get it to work but are able to at least generate 
> areas.list, 
> then you could try reducing the number of nodes per area since that will 
> directly reduce the amount of memory required when the split files are being 
> written out.
> 
> Assuming no one finds any serious problems with this build, I'll get it 
> checked 
> in and released properly so everyone can benefit.
> 
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev