- mkgmap-dev - The mkgmap lists

[Patch v2] mprove filters to reduce artifacts in shapes and unconnected ways at lower resolutions
by Gerd Petermann 30 Jul '16

30 Jul '16

Hi all, see also http://gis.19327.n5.nabble.com/Patch-v1-improve-filters-to-reduce-artifacts… here is the 2nd version of the patch. Major differences to v1: 1) The start and end points of lines are marked as preserved 2) The Douglas-Peucker-Filter now recognizes "preserved" points in lines and shapes, not only shapes The positive effect of this is that the connecting point of T junctions is preserved and therefore not eliminated from either way. The negative effect is a small increase in img size (~ 1%) because more points are kept A binary is here: http://files.mkgmap.org.uk/download/304/mkgmap.jar If I hear no complains I'll commit this version on thursday. Gerd

2 2

[Patch v1] improve filters to reduce artifacts in shapes at lower resolutions
by Gerd Petermann 30 Jul '16

30 Jul '16

Hi all, attached is a patch that addresses the following problem: When you use e.g. GPSMapEdit to look at the polygons produced by mkgmap for resolutions < 24, you may notice e.g. white triangles in the ocean where there should be water. I am not sure if they are visible in Basecamp or MapSource or a Garmin device, but they are not intended and they sometimes "confuse" the optimization filters. They are produced when the Douglas-Peucker-Filter removes points which are somehow important. Important points are 1) Those that lie on the bounding box of the polygon 2) Points which connect a hole with the outline Another problem was The patch changes the code so that these points are preserved before line simplification is applied. It also makes sure that the result doesn't depend on the order in which the shapes are processed. You may see small changes in img size, sometimes size is decreased, sometimes increased (more likely). If you see changes > 10 kB on a single img file compared to r3683, please post a link to the corresponding input file. If I hear no complains I'll commit this patch next Monday. A binary for testing is here: http://files.mkgmap.org.uk/download/303/mkgmap.jar Gerd

2 4

render landuse=orchard
by Minko 29 Jul '16

29 Jul '16

landuse=orchard is missing in styles/default/inc/landuse_polygons they can be rendered the same as farms, vineyards etc: landuse=orchard [0x4e resolution 20] Reported on http://forum.openstreetmap.org/viewtopic.php?pid=602085#p602085

4 6

Commit r3686: improve MultiPolygonRelation code
by svn commit 29 Jul '16

29 Jul '16

Version mkgmap-r3686 was committed by gerd on Fri, 29 Jul 2016 improve MultiPolygonRelation code Use high precision coordinates when checking for intersections. The old code sometimes reported overlapping inner/outer ways for correct multipolygons because the rounded values were used for tests. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3686

1 0

Commit r3685: add landuse=orchard to default style, it is rendered like landuse=vineyard
by svn commit 29 Jul '16

29 Jul '16

Version mkgmap-r3685 was committed by gerd on Fri, 29 Jul 2016 add landuse=orchard to default style, it is rendered like landuse=vineyard http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3685

1 0

Re: [mkgmap-dev] Problems with routing on Etrek 20 with latest firmware
by ael 28 Jul '16

28 Jul '16

On Thu, Jul 28, 2016 at 12:36:03PM -0400, Greg Troxel wrote: > > do you have pointers to older firmware, and can you roll back to 4.20? Garmin seem to do their best to make it difficult to get their firmware images. Anyway, I seem to remember reading that it was not possible to roll back to older versions. But maybe my memory is wrong. But I don't want to risk bricking my Etrek. It is possible that I still have the older firmware somewhere. > I have an etrex 30 with 2.80, which basically works. Yes, I am pretty sure I was on 2.80 before, and had no problems. I suppose a conspiracy theory would be that Garmin changed something to bread mkgmap, but I guess it is more likely that the reverse engineering of the map format is imperfect, and this new bug may be the opportunity to track down such imperfections. Which is why I thought the developers' list was the right place to post. If I can find the old firmware image, and am sure that reverting won't brick the unit, I will give it a try. I may also try some of the other maps suggested, although I am currently away from home with limited internet bandwidth, so large maps might be a problem ATM. Thanks for the suggestions. ael

1 0

Commit r3684: Increase size limit for polyons from 0x7fff to 0xfff.
by svn commit 28 Jul '16

28 Jul '16

Version mkgmap-r3684 was committed by gerd on Thu, 28 Jul 2016 Increase size limit for polyons from 0x7fff to 0xfff. This results in fewer splits of large polygons, the effect is a smaller img size, esp. for maps with large sea areas. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3684

1 0

Possible bug in index creation
by Carlos Dávila 28 Jul '16

28 Jul '16

In my style I have two extra lines to set mkgmap:city in Spain before default one: mkgmap:country=ESP & mkgmap:city!=* & is_in:city=* { set mkgmap:city='${is_in:city}' } mkgmap:country=ESP & mkgmap:city!=* & addr:city=* { set mkgmap:city='${addr:city}' } mkgmap:country=ESP & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } The presence of any of those lines causes that when you search for an address in device and are promted for a city, some cities appear twice. If you select one of them no street is found and if you select the other one streets are found normally. Test file: http://mapas.alternativaslibres.es/extremadura.o5m Searching for an address in Cáceres city shows "Cáceres, provincia de Cáceres" twice.

2 3

compat_lines
by Dave Swarthout 26 Jul '16

26 Jul '16

I'm working on trying to add the maxspeed tag value to my highways by creating or modifying style directives. In my investigations I noticed that the file compat_lines is not being called by any of my style files. Also, the default styles don't seem to use or call it either. Why is it present then? Or am I just missing a call that includes it somewhere else? Thanks, Dave -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com

2 1

tagging/rendering ways with multiple relations
by 987654321＠use.startmail.com 25 Jul '16

25 Jul '16

Hi I have been learning OSM mapping now for a while and struggle with best practices for name tagging ways. As an example please view the 1779 Trail on which I have worked which is shared in part by the 1777W Trail, the Timp Torne Trail links included below. What I have done here is * created a relation for each of the individual trails adding the name of the trail to the relation name. * leave the name tag on the way blank. However a problem arises: On waymarked trails this portion of the trail is rendered as follows: http://hiking.waymarkedtrails.org/#route?id=6292324&map=18!41.3237!-73.9884 showing symbols for the 3 trails that the way. On openstreetmap.org it is rendered as follows: https://www.openstreetmap.org/#map=19/41.32387/-73.98884 showing neither the symbols or the 3 associated trailnames. I am wondering 2 things * What is the best practice in dealing with such a situation? * Should I be adding the contents of every relation tag associated with a way, to the name tag of the way? This seems like it would be very cumbersome. * Would it make sense to have the default openstreetmap.org page render the name tag of each associated relation and if there are no relations then render the name tag of the way itself? Bill

2 1