- mkgmap-dev - The mkgmap lists

variable contained with variable test
by Mike Baggaley 11 Feb '15

11 Feb '15

Hi, I've been struggling to find out whether a style rule can look to see if one variable is contained within another. For example, to see whether the name contains the ref, something like: name~'.*${ref}.*' Is there a syntax for doing this, or is it not supported? Thanks, Mike

1 0

Commit: r3447: don't draw railway lines around polygons with railway=station & building=yes
by svn commit 11 Feb '15

11 Feb '15

Version mkgmap-r3447 was committed by gerd on Tue, 10 Feb 2015 don't draw railway lines around polygons with railway=station & building=yes - Adrian

2 1

Error in style: Error: X3:NOT
by Stéphane MARTIN 10 Feb '15

10 Feb '15

Hi all, - mkgmap-r3447 - java version "1.8.0_31" Java(TM) SE Runtime Environment (build 1.8.0_31-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode) I got an error « Error in style: Error: X3:NOT » with « !(tunnel=yes) » in lines file, and the process stops. No problem with « tunnel!=yes ». Steph

3 5

Railway tracks drawn around station buildings
by A drian 09 Feb '15

09 Feb '15

This way https://www.openstreetmap.org/way/72614628 is tagged building=yes and railway=station. In the generated map (r3436 and default style), it appears as a railway track following the outline of the building. At resolution 24, the building is not rendered. The tag railway=station was originally on a node on the track representing the stopping-point of trains. The tag was moved to the station building by another user (Christian Quest, no less, president of the board of OSM France). I would not have tagged it in that way, but it is one of several possibilities allowed for in the wiki. There are about 500 stations in France tagged in the same way (half of which have been edited by cquest). The railway track comes from line 166 of the lines style file railway=* & !(tunnel=yes) [0x14 resolution 22] Many values of the railway tag are in use, so I am not sure what is the best way to prevent railway lines being drawn round buildings. Some possibilities: A whitelist (railway=rail | railway=tram | railway=disused | railway=subway | railway=narrow_gauge | railway=light_rail | railway=preserved) & !(tunnel=yes) [0x14 resolution 22] A blacklist railway=* & railway!=station & railway!=construction & railway!=razed & railway!=dismantled & !(tunnel=yes) [0x14 resolution 22] (The whitelist and blacklist are based on the frequency of tags according to taginfo https://taginfo.openstreetmap.org/keys/railway?filter=ways#values ) Test for buildings railway=* & !(tunnel=yes) & building!=* [0x14 resolution 22] I prefer the whitelist because it gives you better control: you know exactly which tags are going to be rendered. Any thoughts? Adrian

7 17

Commit: r3445: change public transport labels
by svn commit 09 Feb '15

09 Feb '15

Version mkgmap-r3445 was committed by gerd on Mon, 09 Feb 2015 change public transport labels - by Adrian: Change the POI labels for railway stations and halts, and bus and tram stops. The name would come first and the operator would come last. This is the reverse of the current situation. I think public_transport=platform should be added to the list of tags in my proposal, for the same reason as it was added to the four rules in the points style. i.e. bus stops tagged according to the new public transport schema would have this tag, and not the tag highway=bus_stop.

1 0

java error - UnknownFormatConversionException: Conversion = '''
by Bernd Weigelt 08 Feb '15

08 Feb '15

Hi a few days ago i started to use TYPwiz4 instead of TYPviewer, because of the IMHO better UI. But files created by TYPwiz are completly different as from TYPviewer, TYPviewer uses per default spaces for transparent pixel. This isn't the problem now, it make the buildprocess only a little more complicate ;-) My Problem If i save changes in TYPwiz as TXT, i got this error messages at the end of the buildprocess II: building basemap Time started: Sun Feb 08 10:36:20 CET 2015 java.util.UnknownFormatConversionException: Conversion = ''' at java.util.Formatter.checkText(Formatter.java:2547) at java.util.Formatter.parse(Formatter.java:2533) at java.util.Formatter.format(Formatter.java:2469) at java.util.Formatter.format(Formatter.java:2423) at uk.me.parabola.mkgmap.scan.SyntaxException.getMessage(SyntaxException.java:50) at uk.me.parabola.mkgmap.main.TypCompiler.makeMap(TypCompiler.java:73) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:253) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:249) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Number of MapFailedExceptions: 0 Number of ExitExceptions: 0 Time finished: Sun Feb 08 10:39:09 CET 2015 Total time taken: 169075ms If i open this TXT in TYPwiz and save it as TYP, everthing seems to be ok. For me the TXT looks correct, is there any error, i've not seen? both files are in the attached zip Bernd

2 3

Commit: r3444: Add format specifier when printing error message.
by svn commit 08 Feb '15

08 Feb '15

Version mkgmap-r3444 was committed by steve on Sun, 08 Feb 2015 Add format specifier when printing error message. A format() call was missing a "%s" format specifier, so that if the string to be printed contained a '%' it would fail.

1 0

patches
by GerdP 08 Feb '15

08 Feb '15

Hi Steve, again and again users report that they don't know what to do with patches. Do you think it would be possible to implement a service on http://www.mkgmap.org.uk/ which allows to upload a patch to get a binary? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/patches-tp5831932.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

4 3

Commit: r3442: no-dup
by svn commit 07 Feb '15

07 Feb '15

Version mkgmap-r3442 was committed by steve on Sat, 07 Feb 2015 no-dup

2 1

[Patch v1] avoid duplicate evaluation of rules
by Gerd Petermann 07 Feb '15

07 Feb '15

Hi all, as A drian pointed out here: http://gis.19327.n5.nabble.com/Bug-in-handling-of-bus-stops-tp5832099.html we have a bug in the style evaluation system. The attached patch makes sure that each rule is only evaluated once for one element. If I got it right the problem occurs with rules that combine two "or" expressions, like (a | b) & ( c | d) { do something } A binary based on r3436 is here: http://files.mkgmap.org.uk/download/244/mkgmap.jar @Steve: Please review, I've added a new field "matched" to WatchableTypeResult but I think the field "found" was already intended for this? Maybe you find a better place to fix this? Gerd

3 6