- mkgmap-dev - The mkgmap lists

How to display highway shields with numbers only
by Mark Bradley 03 Jan '15

03 Jan '15

Thanks for responding Gerd. Yes, I experimented with the Substring filter, just as you suggested. But because the number of characters in the ref tag varies, I could not figure out how to make it work for all cases. I'll keep working on it. Mark ________________________________________ Hi Mark, this simple change in default/lines seems to work for me (in MapSource): ref=* {set my_ref='${ref | substring:2}''} highway=motorway { name '${my_ref|highway-symbol:hbox} ${name}' | '${my_ref|highway-symbol:hbox}' | '${name}' } Without it I see "A1", with it I see just "1" in the shield. There is more to do catch all cases for different types of highways and those without a ref. Gerd ________________________________________ From: ethnicfoodisgreat(a)gmail.com To: mkgmap-dev(a)lists.mkgmap.org.uk Date: Thu, 1 Jan 2015 08:49:01 -0500 Subject: [mkgmap-dev] How to display highway shields with numbers only Hi list members, A few weeks ago I proposed the following problem. I did not receive any help, so I will ask again, in case any of you can shed some light. Table 4.4 in the Conversion Style Manual shows highway shields displaying numbers only, which is what I would like to achieve. In Table 4.3 (the list of substitution filters), the description for the highway-symbol filter says that the filer "Prepares the value as a highway reference such as 'A21' 'I-80' and so on. A code is added to the front of the string so that a highway shield is displayed, spaces are removed and the text is truncated so as not to overflow the symbol." The description does not explain (from what I can tell) how to remove the alphabetic characters, leaving only the numbers. I've tried several possibilities of the filter without success. Where I live, there's a motorway called Interstate 70 which is labeled "I70" in OSM. I would like to create shields with only the number in the shields, similar to the example in Table 4.4. How do I do this? To add a little more information: The description in Table 4.4 for each of the first three symbols says "digits only." If I apply the substitution filter to the ref values as is, the symbols on the resulting map do NOT contain digits only, they also include the alpha characters in front of the numbers that describe what type of highway the highway is, such as "I" for interstate or "SR" for state road. Based on this, I have to conclude that it is up to the mapper to strip off these alpha characters first, before applying the highway symbol filter. Again, I have tried numerous combinations of the style filters and commands without success. The problem is that the number of alpha characters preceding the digits can vary. Sometimes there are no alpha characters at all. I know how to add "dummy" spaces to the ref tag for those features that don't have a ref value at all, but how to strip the alpha characters when the number of characters can vary, and the separator character is a space? I would've thought this would be a common desire for users in the U. S. and that it would've been solved a long time ago. Maybe not? Mark

3 2

africa map
by Steve Sgalowski 03 Jan '15

03 Jan '15

not shure what has happened to the africa map but just downloaded a 750 mb pbf file , to find out the map size is only 4 mb in size and only 2 areas . but nothing has changed from the same rules and setup in the one i do for australia any ideas on this ? stephen

2 2

How to display highway shields with numbers only
by Mark Bradley 02 Jan '15

02 Jan '15

Hi list members, A few weeks ago I proposed the following problem. I did not receive any help, so I will ask again, in case any of you can shed some light. Table 4.4 in the Conversion Style Manual shows highway shields displaying numbers only, which is what I would like to achieve. In Table 4.3 (the list of substitution filters), the description for the highway-symbol filter says that the filer "Prepares the value as a highway reference such as 'A21' 'I-80' and so on. A code is added to the front of the string so that a highway shield is displayed, spaces are removed and the text is truncated so as not to overflow the symbol." The description does not explain (from what I can tell) how to remove the alphabetic characters, leaving only the numbers. I've tried several possibilities of the filter without success. Where I live, there's a motorway called Interstate 70 which is labeled "I70" in OSM. I would like to create shields with only the number in the shields, similar to the example in Table 4.4. How do I do this? To add a little more information: The description in Table 4.4 for each of the first three symbols says "digits only." If I apply the substitution filter to the ref values as is, the symbols on the resulting map do NOT contain digits only, they also include the alpha characters in front of the numbers that describe what type of highway the highway is, such as "I" for interstate or "SR" for state road. Based on this, I have to conclude that it is up to the mapper to strip off these alpha characters first, before applying the highway symbol filter. Again, I have tried numerous combinations of the style filters and commands without success. The problem is that the number of alpha characters preceding the digits can vary. Sometimes there are no alpha characters at all. I know how to add "dummy" spaces to the ref tag for those features that don't have a ref value at all, but how to strip the alpha characters when the number of characters can vary, and the separator character is a space? I would've thought this would be a common desire for users in the U. S. and that it would've been solved a long time ago. Maybe not? Mark

2 1

Issues with barrier=*
by Helge Olav Helgesen 31 Dec '14

31 Dec '14

Hi I am using the latest mkgmap (and have tried some older versions as well). What I see is that barrier=* tags with either motor_vehicle=no or motorcar=no still creates a route through the barrier. I noticed this when my GPS sent me through this node: https://www.openstreetmap.org/node/1276408049 My GPS is a Nüvi 3597 with the latest software from Garmin. I am using mkgmap with the default style. I have also tried to work with the default style from the extras folder. I added a handler for motor_vehicle as it was not there from before. (Added to the points file: barrier=* & motor_vehicle=* { set mkgmap:car='${motor_vehicle|subst:private=>no}' }) Not sure how to solve this, any ideas? ... Helge

3 8

A few thoughts on non-rectangular tiles
by Steve Ratcliffe 29 Dec '14

29 Dec '14

Hi Here are a few thoughts on non-rectangular tiles. The main problem is knowing where to start really. The Files --------- I looked into this a few years ago and I don't think that there is anything fundamentally different about producing non-rectangular tiles. It is normal to split tiles at land based country borders, so that the tile follows the border exactly. For countries separated by sea, such as Sweden and Finland straight lines can often be used without regard to the alignment that we currently use. - You just create a tile with an arbitrary shape, the background polygon if any follows the shape. - The TRE section still records the bounding box of the tile. - the TDB file still contains those rectangular bounding boxes and so they will, in general, overlap. - You add add the actual shape of the tile as a 'map selection area' to the overview map. So we need to allow an arbitrary polygon as background in mkgmap. Splitting --------- The majority of tiles would remain rectangular as they at present. Tiles that would contain a land border need to be further split along that border. This could be done 1. Directly by splitter 2. By running mkgmap once for each country. 3. Some intermediate process. I believe it would be best in the long term for splitter to make the split, but perhaps the other strategies could be used temporarily in order to concentrate on other parts of the process. I think that the bounds file (or some similar purpose built file) should be used. There is no need to split along coastal boundaries. Only if a tile would reach to another country does it need to be split. When splitter creates the tiles, the actual boundary of a tile needs to be communicated to mkgmap in some way. Implementation -------------- Currently we have restrictions on the alignment of tile boundaries, these can all go, as this is a constraint to make things easier for us and not a feature of the format. There will probably be a few things to fix up so that the tiles still meet and route without gaps. I would suggest starting out with one tile cut in two with a sloping line. If we can get that to work without routing problems or visible gaps across all zoom levels, then most of the problems should be sorted out before putting in the work to support completely arbitrary boundaries. Then we add a more complex background polygon. ..Steve

6 9

elevation data
by Mike Baggaley 29 Dec '14

29 Dec '14

Hi, I've built a map containing contour data, using line styles 0x21 and 0x22. These are displayed in BaseCamp with the correct elevations. However, if I open a route and try to display the Graph tab, it says, "The current map does not contain any elevation data on the selected route(s)." The route crosses contour lines, so I surmise that the map needs further information. Can anyone tell me what I need to do? Thanks, Mike

2 1

Small improvements for house numbers
by Gerd Petermann 24 Dec '14

24 Dec '14

Hi all, the corrections in r3392 improves the house number code. In some cases a house number was added to the wrong part of a road, sometimes even the wrong side. Possible effect: When you search for a specific number in a street in a specific town in some cases, MapSource shows multiple possible places. Besides wrong OSM data there are many other possible reasons for that, I fixed only one of them until now. The rest is work in progress... Gerd

1 0

Commit: r3392: HousenumberGenerator: use same correction as in r3391 for Coord.shortestDistToLineSegment
by svn commit 24 Dec '14

24 Dec '14

Version mkgmap-r3392 was committed by gerd on Wed, 24 Dec 2014 HousenumberGenerator: use same correction as in r3391 for Coord.shortestDistToLineSegment Effect of the error: Some house numbers were added to the wrong sides of the street or a wrong part. E.g. when the road contains a 90 degree turn

1 0

Commit: r3391: correction: Coord.shortestDistToLineSegment sometimes returned
by svn commit 24 Dec '14

24 Dec '14

Version mkgmap-r3391 was committed by gerd on Wed, 24 Dec 2014 correction: Coord.shortestDistToLineSegment sometimes returned too large values, esp. for points far from the equator. Expected effect of the change: Small improvements in the DouglasPeuckerFilter as it is more likely keeping the right points.

1 0

Error in distance calculations
by Gerd Petermann 24 Dec '14

24 Dec '14

Hi programmers, we are using a formular to calculate the shortest distance between a point P and a line segment A-B (A,B, and P are coordinates) The result is either the distance between P and A or P and B or the perpendicular distance between the closest point on the line A-B and P. In the current code that we use to find out what case we have we are using the deltas of the garmin lat/lon values. This formular completely ignores the fact that we have coordinaties on a sphere (well, nearly a sphere). The distance between two points with the same deltaLat and deltaLong is very different depending on the position on the earth, the farer away from the equator the longer the distance. The effect of the error is that HousenumberGenerator sometimes fails to find the right road segment for a housenumber, and probably the DouglasPeuckerFilter sometimes removes the wrong points. The algos I am talking about: HousenumberGenerator.getFrac() HousenumberGenerator.distanceToSegment() and Coord.shortestDistToLineSegment() which is more or less a copy of the above. Up to now I found only one computation that seems to work: http://stackoverflow.com/questions/1299567/how-to-calculate-distance-from-a… and esp. parts of the code from here: https://github.com/Epsidon/PhoneGapExperiments/blob/master/Data/src/Distanc… The problem: This algo uses a lot of trigonometric functions to calculate the result (convert to and from cartesian coordinates) , so it is ~30 times slower. We do this computation very often in HousenumberGenerator and DouglasPeuckerFilter. Is anybody aware of a better compromise between calculation speed and error? Gerd

2 3