January 2013 - mkgmap-dev - The mkgmap lists

shapes with holes
by GerdP 29 Jan '13

29 Jan '13

Hi WanMil, WanMil wrote > 1. RoundCoordsFilter creates an invalid polygon with hole > 2. PolygonSplitterFilter might split the polygon because it is too > large. It converts the polygon to a java.awt.geom.Area object, splits it > into two halves and converts it back in the method > PolygonSplitterBase.areaToShapes(..) method. This method does not check > the orientation of the returned polygons and therefore converts the hole > to same type the polygon has - in other words the hole is removed. I thought about this again and I think it might be the solution for the mp-cut problem: We don't have to cut out inner polygons, instead we can connect each inner polygon with the outer one. We have to find two points: p1, a point on the outer way that is close to a point of the inner polygon, which is then called p2. Now, we have to split the outer way at p1, draw a line to p2, add the points of the inner polygon, and draw a way back from p2 to p1. It works (QLandkarte shows the polygon with a hole), but only when none of the filters destroys the added ways between p1 and p2. I don't know yet how multiple nested polygons look like, but I think it is a promising approach. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/shapes-with-holes-tp5745424.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

4 14

Commit: r2468: Merge from the numbering branch.
by svn commit 29 Jan '13

29 Jan '13

Version 2468 was committed by steve on Tue, 29 Jan 2013 Merge from the numbering branch. Implements house numbers. The will display on the map and can also be used in address searches. Catch is that it only works with input files in the Polish format. Making it work with OSM data directly is much more difficult!

1 0

Merging branches
by Steve Ratcliffe 29 Jan '13

29 Jan '13

Hi I am planning to merge the numbering and functions branches soon. The numbering branch is for house numbers and only has any effect for Polish input files. The functions branch should have no effect on anything, it simply integrates WanMil's style functions more deeply into the style system code. ..Steve

2 1

Commit: r2461: Merge the mkgmap_exits branch
by svn commit 28 Jan '13

28 Jan '13

Version 2461 was committed by wanmil on Wed, 23 Jan 2013 Merge the mkgmap_exits branch The new motorway exit processing can be activated with the --process-exits option.

4 9

Commit: r2466: Documentation building changes.
by svn commit 27 Jan '13

27 Jan '13

Version 2466 was committed by steve on Sun, 27 Jan 2013 Documentation building changes. Add a documentation index for web site here. Create directory and introduction to the tutorial.

1 0

unwanted node tags from relation
by Minko 27 Jan '13

27 Jan '13

Hi, When I use place=country or place=state in my place style file, I notice that mkgmap sometimes creates unwanted nodes at the borders with the same tags, so that on my map the country or state name is rendered several times instead of just one. For instance I want to render the state name of Scotland, which is just one place=state node: http://www.openstreetmap.org/browse/node/470649732 It is part of a relation which has the same tag, place=state: http://www.openstreetmap.org/browse/relation/58446 Mkgmap creates 2 other nodes around the borders on my map with 'Scotland' as label but I want only one in the center. I see the same effect in Switzerland, several unwanted place=country nodes of 'Schweiz' are rendered at the borders. Is there a mkgmap tag created with those artificial nodes so I can distinguish them from the real OSM place nodes? I tried (place=country | place=state) & boundary=administrative but this makes no sense because node 470649732 gets this tag too because it is part of a relation.

1 1

Commit: r2465: Documentation: complete section on including files in a style.
by svn commit 27 Jan '13

27 Jan '13

Version 2465 was committed by steve on Sun, 27 Jan 2013 Documentation: complete section on including files in a style.

1 0

Commit: r2464: Beginning adding the documentation to the build.
by svn commit 26 Jan '13

26 Jan '13

Version 2464 was committed by steve on Sat, 26 Jan 2013 Beginning adding the documentation to the build.

1 0

Marine style
by gbbickerton 25 Jan '13

25 Jan '13

Is it possible to render seamarks eg lighthouses with sectors shown as per open sea map with mkgmap if so is there a style file available -- View this message in context: http://gis.19327.n5.nabble.com/Marine-style-tp5743401.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

4 6

Upper / lower case names
by Wolfgang Hammel 22 Jan '13

22 Jan '13

Hi, I was observing that that capitalized names on eg. buildings like "VW" etc. show up in upper and lower case on my Oregon 550. So I played around and tried some different combinations of upper / lower case names. Here is the outcome on the Oregon: "name" "name" in OSM -> on Oregon 550 "ABC" -> "Abc" "ABC D" -> "Abc D" "ABCd" -> "ABCd" "ABC De" -> "ABC De" "ABC d" -> "ABC d" "ABC DE" -> "Abc De" "ABC dE" -> "ABC dE" So it seems as if when there were only upper case letters in a name, the name shown on the GPS device is modified such that only the first letter of each word stays uppercase. If there is a least one lower case letter in the name it is shown as it was originally in the OSM-data. Is this a firmware "feature" of the Oregon or is this depending on the map-generation via mkgmap? Command line for mkgmap was java -Xmx1300M -ea -jar mkgmap.jar --latin1 --lower-case ... however, omitting the --lower-case option doesn't change the outcome. Anyhow, mkgmap is a great software, Thanks. Wolfgang

3 2