January 2018 - mkgmap-dev - The mkgmap lists

documentation patch
by Mike Baggaley 24 Jan '18

24 Jan '18

Hi Gerd, please find attached a patch to correct and improve the documentation of the --read-config command line argument. If it looks OK to you, please commit it. Thanks, Mike

4 9

Commit r4086: improve documentation of command line options
by svn commit 24 Jan '18

24 Jan '18

Version mkgmap-r4086 was committed by gerd on Wed, 24 Jan 2018 improve documentation of command line options Patch configdoc3.patch by Mike Baggaley http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4086

1 0

bug in r-4025
by lig fietser 24 Jan '18

24 Jan '18

Hi Gerd, Users of my Openfietsmap Germany reported a bug in my maps, one tile was missing. Normally something went wrong with splitting (tiles too big) but this one was compiled fine as img. However, it didn't render, only the overview map. I have compiled it with r-4025. When I compile it with r-4066 there is no issue, so it is probably solved but I just mention it. Are you aware of this bug? The o5m file is here: http://mijndev.openstreetmap.nl/~ligfietser/mkgmap/ Screenshot here: https://www.facebook.com/photo.php?fbid=975247545973988&set=p.9752475459739…

2 7

Re: [mkgmap-dev] mkgmap-dev Digest, Vol 114, Issue 93
by EthnicFood IsGreat 24 Jan '18

24 Jan '18

> Message: 4 > Date: Tue, 23 Jan 2018 15:15:07 +0000 > From: Gerd Petermann <gpetermann_muenchen(a)hotmail.com> > To: Development list for mkgmap <mkgmap-dev(a)lists.mkgmap.org.uk> > Subject: Re: [mkgmap-dev] Open source GIS systems and DEM > > Hi Mike, > > I have never used any GIS system. I just download zipped hgt files from e.g. > http://viewfinderpanoramas.org/Coverage%20map%20viewfinderpanoramas_org3.htm > unzip them into one dir called srtm3 and feed that to mkgmap. > > Gerd > > ________________________________________ > Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk> im Auftrag von EthnicFood IsGreat <ethnicfoodisgreat(a)gmail.com> > Gesendet: Dienstag, 23. Januar 2018 15:48:54 > An: mkgmap-dev(a)lists.mkgmap.org.uk > Betreff: [mkgmap-dev] Open source GIS systems and DEM > > Hello. For those of you that use an open source GIS system, I would > like to ask you why you chose the one you use. When developing the > DEM functionality for mkgmap, is a certain system preferred? I have > GRASS installed, but I keep hearing about QGIS. > > Mark Bradley > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > I guess I didn't make myself clear. I have already successfully created a DEM for my Garmin map. In a general sense, I was just wondering what is the preferred open source GIS system for the users of this mailing list. For example, to display the raw SRTM data directly. Mark

1 0

Open source GIS systems and DEM
by EthnicFood IsGreat 23 Jan '18

23 Jan '18

Hello. For those of you that use an open source GIS system, I would like to ask you why you chose the one you use. When developing the DEM functionality for mkgmap, is a certain system preferred? I have GRASS installed, but I keep hearing about QGIS. Mark Bradley

2 1

mkgmap r4048 seems to fix problem with hill shading
by Gerd Petermann 22 Jan '18

22 Jan '18

Hi all, I've changed the code so that when a sub tile (typically 64x64) is completely outside of the polygon (--dem-poly) is still encoded with a bit stream. This is how BuildDEMFile does it and it seems that this solves all problems reported by Andrzej. Before this I simply wrote a header that said "no bit stream, all heights are equal, highest value is invalid", but Garmin doesn't seem to like that. The change means that a few more bytes are written to DEM, maybe also runtime is a bit higher. Gerd

5 24

addresses in the United States
by Greg Troxel 22 Jan '18

22 Jan '18

(I have been using mkgmap for a really long time, and have been a little out of touch with it the last few years mostly due to using OsmAnd on my phone, although I still build maps for my Etrex 30 for hiking.) I built osm.img from Geofabrik's us-northeast. On my Nuvi 50, I find that I can find Massachusetts towns, but not towns in Rhode Island. I realized this was due to my not really understanding the address options and using them wrong/not-at-all. So I read the docs about precompiled bounds and sea and added those, using the files from mkgmap.org.uk, and rebuilt. Hence I am not asking about my earlier not-right builds. With the new osm.img, in address search, there is only "United States" vs "Canada", and no per-state option. Towns can be found in any of the states in my source file, but they show with their counties only, not the state. If you pick the right town/county combination, streets are found, and I believe housenumbers, when they exist in OSM. This is harder than you might think because we basically reuse town names and county names from England separately in each State :-) When building, I first use splitter, and I think I have not had any splitter issues in many years. Then I run mkgmap (details at end). Note that in addition to us-northeast.obf, I also add a file which has parcel boundaries in my town convreted to OSM format, and I have a style rule that shows them as marine depth contours. This has been working for many years. My style diff in lines is: +# 0x23 is depth countour - thin. Wacky but useful. 0x1c is too heavy +boundary=parcel [0x23 resolution 20] I don't think this matters, but I don't feel right leaving out the info. For no good reason, my recent build was done with r3997 | gerd | 2017-09-26 03:49:38 -0400 (Tue, 26 Sep 2017) | 1 line and I am going to update and try again, without the --region-* arguments. Other than the parcel style change my only other local changes are doc fixes that I need to check and submit some day. My questions are: 1. I have leftover --region-* arguments in my script, and I'm wondering if that's the issue. Should I remove those? Does that explain the state/county confusion? 2. I would expect the admin boundaries for state, county and town to be used from the bounds file, to fill in those address elements for roads, as well as for explicitly tagged addresses if they only have housenumber/street. Is that right? Fairly clearly the town and county boundaries are being used correctly. (Actually also county boundaries for counties that do not have admin_level=6 because of overzealous nonlocals who think it's helpful to remove those for counties that don't legally have a separate government, even though nobody who uses the map has any idea about this fine point and everyone refers to counties as a real thing. But counties are showing up, so that's not the problem.) 3. To make the best map possible for normal people to use navigating with a nuvi, without crossing into custom styles, should I be doing something different? 4. Given the goal in (3), should I be crossing into a custom style? 5. In addition to the admin hierarchy, which is what everyone thinks of in terms of addresses, there are also a lot of place names (as nodes) in OSM, with tags like village and hamlet. These are names for where there were concentrations of house long ago, and many are in use today. People use them as in "I live near Tracey's Corner" but would never put "Tracey's Corner" as a component of their address. by using is_in, I think I'm not using those, and I don't think this is related to my problem anyway. java \ -enableassertions \ -Xmx3072m \ -jar splitter.jar \ --output=pbf \ --max-nodes=${MAXNODES} \ --keep-complete=no \ $INPUT \ java \ -enableassertions \ -Xmx6144m \ -jar mkgmap.jar \ --max-jobs \ --latin1 \ --description="OSM_gdt" \ --country-abbr="US" \ --country-name="United States" \ --region-abbr="MA" \ --region-name="Massachusetts" \ --family-id=1500 \ --family-name="OSM_gdt_family" \ --product-id=13 \ --series-name="OSM_gdt_series" \ --area-name="OSM_gdt_area" \ --draw-priority=60 \ --overview-mapname=63240000 \ --tdbfile \ --precomp-sea=sea.zip \ --reduce-point-density=4 \ --reduce-point-density-polygon=8 \ --merge-lines \ --route \ --check-roundabouts \ --check-roundabout-flares \ --remove-short-arcs \ --adjust-turn-headings \ --report-similar-arcs \ --report-dead-ends=2 \ --add-pois-to-areas \ --check-styles \ --index \ --bounds=bounds.zip \ --housenumbers \ --location-autofill=is_in \ -c template.args \ --gmapsupp Thanks, Greg (osm user gdt)

2 2

r4072: slower but probably better
by Gerd Petermann 22 Jan '18

22 Jan '18

Hi all, see http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4072 I am not sure but I think it is a good idea to use 3312 for level 0 for 1'' hgt files now, and 9936 for 3''. As the values are rounded down, 3312 and 3314 will give the same result, as well as 9936 and 9942 My modifications compared to the patch are small, I've introduced constant EXTRA in DEMFile, removed unused import and adapted the unit test. I am not yet convinced that it is needed to round the dem-dist values, but Andrzej is right that this is what Garmin does and therefore it is less likely to cause problems certain devices. Maybe I'll add an option to use the exact value if that means that interpolation can be avoided. I'll also try to find faster code later. Frank is also working on a document regarding the problems adressed in the dem-align patches. Gerd

1 0

28 bit prec in DEM section header ?
by Gerd Petermann 21 Jan '18

21 Jan '18

Hi DEM experts, as Andrzej pointed out here [1] the Garmin maps seem to use 28 bit precision for some 32 bit values in DEM. I tried to find out if that means that MapSource actually ignores the lower 4 bits of the values. I've compiled two maps using --dem-dists=9942 for a tile created with split-file containing 29000000: 2291022,918105 to 2297489,946049 OSM data contains <bounds minlat="49.1599988" minlon="19.700396" maxlat="49.2987657" maxlon="20.3000093"/> One with original r4071, one with a change so that 9936 (0x26D0) instead of 9942 (0x26d6) is written to the DEM section header, If MapSource would ignore the lower 4 bits all should produce the same results, but that is not the case. Instead, the rectangle that contains DEM data is smaller with 9936, no height values are shown on the bottom and right side. The effect is clearly visible when I change the value in the header to 9000 instead of 9942, hill shading ara shrinks. Again: I only changed the value in the DEM header. I tried something similar with the location of the top left corner. The results are not that clear. I change both top and left by the same value. It seems that Garmin ignores rather small changes. -1000 : no effect -2000 : A large part of the map looks unchanged but there is a move of hill shading left from ~ E 19.75 -4000: Like with -2000 I see the same changes on the left but also a small change at the very top. -8000: all hill shading moves left and just a little bit up (!) -16000: all hill shading moves left and down , no obvious change near E 19.75 +1000 :no visible change +2000: all hill shading moves up +4000: again there is a boundary near E 19.75, data to the left moves up and maybe a little bit to the left, data on the right moves up and more to the right +8000: almost like with +4000, but small change on the bottom +16000: all hill shading moves up+right, but maybe not exactly by the same amount +32000: all hill shading moves up+right, no obvious change near E 19.75 To be continued. With very large values parts of the map have no hill shading. It is not that obvious to me how Garmin interprets the position values in the DEM header. Maybe one sees completely different results in other parts of the world or with larger maps containing more tiles. I guess that MapSources uses the position info to check if bbox of DEM data intersects bbox of tile, but there seems to be a complex rule how it determines where to place the calculated hill shading data. Maybe someone else finds a rule? [1] http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2018q1/027818.html ciao Gerd

2 1

Re: [mkgmap-dev] HGT - getElevation()
by Frank Stinner 21 Jan '18

21 Jan '18

Hi Gerd and Andrzej, > your choice of triangle is arbitrary. of course, but the version with 4 triangles isn't. > bilinear interpolation seems better Yes. It's a little bit more to calculate, but better. For our special case it is: h = h11 * (1 + y * x - x - y) + h21 * (x - y * x) + h12 * (y - y * x) + h22 * y * x (h11 is left-bottom in coordinate origin, the horizontal and vertical distance is 1) If your java-class have to much overhead, you can use this formula. By the way, i would be very defensive with interpolation in the case of missing values. The hgt values are only interpolated values from original measurments. I would not interpolate values in the near of missing values. That give us a nice but unreliably picture. Frank

6 57