- mkgmap-dev - The mkgmap lists

BaseCamp Route from Track
by Arndt 10 Jan '15

10 Jan '15

BaseCamp makes Routes from Tracks 1:1. (Activity Car) This works only with Garmin Maps.Any Ideas to support this feature with mkgmap maps?

1 0

splitter man page
by Sebastiaan Couwenberg 10 Jan '15

10 Jan '15

Hi all, The attached patch add a man page for splitter. Both the DocBook XML source and resulting groff files are included. The man page is heavily based on doc/splitter.txt, but was manually converted to DocBook XML format. The Debian package for splitter will include a slightly modified version because there already exists a splitter binary, so a simple shell wrapper called mkgmap-splitter is used to around the java -jar splitter.jar command. Kind Regards, Bas -- GPG Key ID: 4096R/E88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1

2 2

africa mkgmap diaster
by Steve Sgalowski 09 Jan '15

09 Jan '15

mkgmap is broken , or the bounding box is sir , checking it with splitter 418 java.lang.assertion error arc segment with big bb box not split this is in mkgmap gerd stephen

3 5

random housenumbers
by Gerd Petermann 09 Jan '15

09 Jan '15

Hi Steve, how can I make sure that Garmin programs do not try to interpolate housenumbers for places where this is not wanted? Is it possible that there is another attribute besides ODD,EVEN,BOTH ? Gerd

2 7

Re: [mkgmap-dev] small issue with Way.getCofG()
by Mike Baggaley 09 Jan '15

09 Jan '15

I have a working solution for ensuring that the created point is placed within the polygon when using --add-pois-to-areas, based on drawing the polygon on to a small monochrome bitmap and then looking for the point that is furthest from the surrounding area. I used a 9x9 bitmap for polygons having a small number of points and 15x15 for longer polygons. There is however a performance penalty. My standard map takes about 1 hour 20 minutes; using this algorithm the time increases by about 50% to about 2 hours. I am not currently able to commit changes to SVN (perhaps someone can help out with that) but I have attached the code changes. I suggest that due to the performance penalty, if we adopt this, then the --add-pois-to-areas option be extended to be --add-pois-to-areas[=centre|optimised] or something similar, with the default being centre and functioning as now and the optimised option invoking the new code. Please try out the suggested change. Note I don't expect this to work properly where a polygon is formed from a multiploygon relation, but the code could quite easily be adapted for this circumstance. Regards, Mike

4 9

SVN commit problem
by Mike Baggaley 08 Jan '15

08 Jan '15

I can't seem to commit any changes, because I think Tortoise SVN is using a guest account to retrieve the data and I can't work out how to get it to use my account details instead (which I assume are the same as the email subscription details). I have the following in my Tortoise SVN servers file: [groups] group1 = *.mkgmap.org.uk [group1] # store-plaintext-passwords = no username = mike.b Can anyone help? Regards, Mike

3 2

How to display U. S. highway shields with numbers only
by Mark Bradley 08 Jan '15

08 Jan '15

Gerd, Thanks for the followup. Somehow I overlooked the Substitution filter that you suggest, which seems like a good idea. It looks like your idea also involves an Oracle Regex expression, with which I am not familiar. I thought about that, but the URL in the Conversion Style Manual for the Regex documentation is no longer correct. (Can someone on this mailing list see that it is corrected?) After a little searching on the Java website, I did not find the documentation, and did not want to take a lot of time looking, so I tried a different tack. After much thought, I came up with a series of commands that seems to produce the desired output. However, it looks like the idea of using the Substitution filter might produce a more elegant solution. I will probably look into that. Anyway, here is the sequence of commands I came up with that seemed to work. (I live in Indiana.) I have only included the commands that pertain to U. S. and state highways. The motorways (interstates) were more straightforward and a lot easier, because their ref values are much more consistent. The problem I had to overcome with the other highways is that the number of characters in the ref key value can vary, from none, to one or more. # Append extra characters to the end of the ref value to ensure it is more than one character in length, otherwise an error will be returned by the Substring filter later. # ("AB" are dummy characters.) highway = * & ref = * { set ref = '$(ref) AB' } # Create the letter_ref key that will determine later what type of symbol to display on the highway. highway = * & ref = * { set letter_ref = '$(ref|substring:0:2)' } # Extract the numbers only from the ref value, which will become the numbers inside the symbols. highway = * & ref = * { set number_ref = '$(ref|part:" :-2)' } #If the highway is a U. S. highway, use a shield symbol. letter_ref = 'US' {name '${number_ref|highway-symbol:shield:3} ${name}' | '${number_ref|highway-symbol:shield:3}' | '${name}'; addlabel '${name} (${ref})' } # If the highway is a state highway, use a round symbol. letter_ref = 'SR' | letter_ref = 'IN' {name '${number_ref|highway-symbol:round:3} ${name}' | '${number_ref|highway-symbol:round:3}' | '${name}'; addlabel '${name} (${ref})' } _____________________________________________ Hi Mark, okay, so your problem is not directly related to the highway symbols. What you need is a simple filter to return the part of a string which starts at the first digit. I guess this can be done with subst plus a regular expression, but I'm not sure how exactly. Something like ref=* {set my_ref = ${ref|subst:"[a-zA-Z]*~>"} Gerd

3 3

Issues with --housenumbers
by Gerd Petermann 08 Jan '15

08 Jan '15

Hi all, during the last weeks I tried to improve the --housenumber option. First of all: In most cases the existing code works quite well, but in many special cases it fails. I did not yet find a good solution, so I start to describe the problems with the existing code. 1) No support for random house numbers. In some areas there is no obvious order in house numbers. Nevertheless the current code in mkgmap always produces house number data that assumes that the numbers are either in ascending or descending order. We would need new data structures to support this, or at least ignore random housenumbers. The effect of the current code is that MapSource shows multiple possible places when you enter a road and a housenumber, and maybe none of the places is correct. 2) No plausibility check is done. The current code assigns a house (number element) to the closest road segment. It orders the houses by sorting these closest points. a) This doesn't work very well when multiple houses lie at the end of a road. As an effect, a house with number 12 maybe assigned to the left side of a road containing only odd numbers (or vice versa), or b) It also often fails when multiple houses are connected to the road with an unnamed service road. In many areas you have a group with odd numbers 1-9 followed by another group with numbers 11-17. Depending on the position of the houses, the calculated order might be 5,7,9,1,17,15,13,11 which results in an interval 5..11 instead of 1..17. The result also depends on whether the service road is in the map or not . c) In some areas, different road objects are created with the same road name, e.g. when a p-shaped road is split or the road forms some kind of grid like this a # sign. In such an area it is likely that some houses are assigned to the wrong (part of a )road. d) In some cases we might be able to detect wrong OSM data as such and print a corresponding message. Both points 1) and 2) are correlated. Without a plausibilty check we cannot detect the random house number case, so I think it is an interesting problem of pattern recognition. The human brain is very good with that, but it is difficult to find a quick and good algo for it. Gerd

4 4

prob in africa map 3
by Steve Sgalowski 08 Jan '15

08 Jan '15

here is the log file info said bb box is to big any ideas gerd and steve stephen

2 2

License of OsmosisRuntimeException.java copy in splitter source is outdated
by Sebastiaan Couwenberg 08 Jan '15

08 Jan '15

Hi all, While working on the Debian package for splitter, specifically the copyright file, I noticed that the copy of OsmosisRuntimeException.java included in the source still states that it's licensed under the GPL (without a version), whereas the recent osmosis source places it in the public domain like the rest of Osmosis. See: https://github.com/openstreetmap/osmosis/blob/master/osmosis-core/src/main/… The attached patch updates the OsmosisRuntimeException.java file included in the splitter source with the current version from the osmosis source. The only change is the license statement. Kind Regards, Bas -- GPG Key ID: 4096R/E88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1

2 1