- mkgmap-dev - The mkgmap lists

Re: [mkgmap-dev] Sorry, Google is being restrictive. Try 2 with the files.
by Ticker Berkin 31 Jul '20

31 Jul '20

Hi Randolph I think your test.txt TYP file might be exceeding various device limitations and have a few other problems. I've just converted it with mkgmap and then using TYPViewer to examine the resultant .typ file, firstly it takes a couple of mins to open the file, then it seems to be missing some entries. I'd recommend: Don't have [end][_point] on same line Stick to Types in range 0x01 .. 0x7f. Be consistent with Type= and Subtype=; I think you have entries that resolve to the same thing. If Type >= 0x100, the bottom 8 bits are the sub-type and the rest is the type. Don't have sub-types for cities (ie 0x01 .. 0x0d). Anyway, test-map doesn't generate them which is why you see the single line of icons to the left of the big block. Have sub-types (up to 0x1f) for the ranges where they have definite significance, ie: 0x2a..0x30 and 0x64..0x66 There are a few other places where subtype also have meaning but this is manifest in the default icon. Ticker

1 0

Re: [mkgmap-dev] [Fwd: Re: Changes that I made in a recent set of default style files and the reason I have for making those changes.]
by Ticker Berkin 30 Jul '20

30 Jul '20

Hi Randolph It is best to do city... / population test in the way it is done in the default style. If, after the "place & population > xxx" rules you try place=city & population!=* [...] it will fail if, for instance, the tag was [population=unknown] The current default style doesn't conflate pizza with italian; each has and uses the obvious Garmin type. Some conflations are there because there is a limited and strange set of Garmin cuisine types, including fast_food. There is no perfect (or even good) solution. If you search for "American" cuisine, what would you expect to find? Should burgers be here or under "Barbeque" or "Fast Food"? BaseCamp and my 2 eTrexes don't find 0x2c1e or 0x2c1f when searching for "Places of Worship". They also don't appear in you list of TYP codes. My older eTrex doesn't find 0x2c0d .. 0x2c10 either. My preference for handling this situation is to add rules for types only supported by newer devices commented out, before the generic one. Then, if someone has a device that supports them they can un-comment. It is also good documentation to show which types to avoid for other purposes. Older devices tended to find types off the end of known values with, say, Find > Attractions > Other, and this is why there are problems like the one you noticed where 0x2c0d was used for an unspecified tourism=*. So, it is a bad idea to try and invent meanings for any POI in the searchable ranges, rather use the closest meaning subtype or subtype 0. There was a thread a short while ago about type codes and their meanings. Here are links to 2 parts of the thread where lists are attached, but it is worth checking the whole thread. http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q2/030945.html http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q2/030969.html You can generate a test map with something like: $ java -jar mkgmap-rVVVV/mkgmap.jar \ --verbose \ --order-by-decreasing-area \ test-map:all-elements \ mkgmap-rVVVV/resources/typ-files/sameOrder.txt + --gmapsupp or --gmapi or whatever Source is: {svn repos}/src/uk/me/parabola/mkgmap/reader/test/AllElements.java Ticker

2 1

Changes that I made in a recent set of default style files and the reason I have for making those changes.
by Randolph J. Herber 29 Jul '20

29 Jul '20

In case that I grabbed points and polygons files that I had already modified, I included both before and after versions as well as a patch file for each. I never really liked the cities, towns, villages, suburbs, and hamlets handling. Now, they are by size only. In the USA, the difference has more to do with legal privileges than anything else. There are such entities with populations over 20 million: Shanghai, Beijing and Lagos and there are extant entities with names and no recorded population. They are often called ghost towns. In some states, they even have legal protection. I wanted to break out places of worship by religion for at least some of the major religions. I can supply icons for them. Making icons is easy for me. amenity=place_of_worship & religion=christian [0x2c0e resolution 24] amenity=place_of_worship & religion=muslim [0x2c0d resolution 24] amenity=place_of_worship & religion=jewish [0x2c10 resolution 24] amenity=place_of_worship & religion=buddhist [0x2c0f resolution 24] amenity=place_of_worship & religion=hindu [0x2c1f resolution 24] amenity=place_of_worship & religion=bahai [0x2c1e resolution 24] amenity=place_of_worship [0x2c0b resolution 24] Therefore, I changed the code in this line to move that item out of the block of codes that I am using. tourism=* & tourism!=no & tmp:stopMopUp!=yes [0x2f00 resolution 24] I used Wolfram Mathematica (mostly, just because it was convenient) to process the style files and some lists from the Maps Tool Kit to see what codes are available and which mkgmap style files were using. I attached that file as well in case it may be of use to you. I separated prisons and military areas in both points and polygons.

2 4

check-roundabout-flares
by Mike Baggaley 28 Jul '20

28 Jul '20

Dear all, I have been working on improvements to the --check-roundabout-flares option to provide better decisions as to what should be considered a flare and have managed to greatly reduce the number of messages that relate to roads that are not flares. Of course it is not possible to discard all unwanted messages without discarding the odd message this is relevant, hence the rules need to be configurable to suit the circumstances in the area being mapped. I propose to deprecate the --check-roundabout-flares and --max-flare-length-ratio options, with the former moving into the --check-roundabouts option and the latter into a new set of rules. The --check-roundabouts option would be extended to accept the following list of values [all|loop|direction[:fix]|junctions|flares,...] where: * all applies all the checks and fixes. * loop checks that roundabouts are formed from a single loop with no forks or gaps. * direction checks that the one way direction is in the expected direction for the side of the road on which traffic drives. If the fix suffix is supplied then roundabouts failing this check have their direction reversed. * junctions checks that no more than one connecting highway joins at each node. * flares checks that roundabout flare roads are one-way, point in the correct direction, and don't extend beyond the flare. This gives more flexibility over which checks are applied whilst reducing the number of command line options. For backwards compatibility, specifying the option with no value would be the same as --check-roundabouts=loop,direction:fix,junctions, and the default would be to not check anything. Specifying --check-roundabout-flares would set --check-roundabouts=flares and display an error message saying the option had been deprecated. For the flare processing, I have used a set of rules and am considering the best way to allow users to specify the rules that are to be applied in the decision making process. I don't want to add them as individual options as this complicates the interface too much. The choice therefore seems to be between a separate rules file and a command line option with a list of rule names and values. The rules I have are as follows: max-flare-length-multiple=NUM - Discard candidates where the length of one of the possible flares is greater than NUM times the length of the other. Default is 3. Set to 0 to disable. max-flare-to-separation-multiple=NUM - Discard candidates where the length of both of the possible flares are greater than NUM times the distance between the nodes on the roundabout that the flare roads connect to. Default is 7. Set to 0 to disable. (This is equivalent to the existing --max-flare-length-ratio option) max-flare-angle=NUM - Discard candidates where the angle subtended between the two possible flares is greater than NUM. Default is 90. Set to 0 to disable. max-flare-bearing=NUM - Discard candidates where the angle between the initial bearing of a possible flare road and the centre of the roundabout is greater than NUM. Default is 90. Set to 0 to disable. max-entry-angle=NUM - Discard candidates where the angle subtended from the centre of the roundabout to the two roundabout junction nodes is greater then NUM. Default is 145. Set to 0 to disable. both-flares-extend=[=yes|no] - Discard candidates where both roads extend beyond the point where they meet. more-roads-meet-roundabout=[=yes|no] - Discard candidates where the point where the roads meet contains more roads directly connecting to the roundabout. Default yes. multiple-flares=[=yes|no] - Discard candidates where the next node of a continuation of one of the roads has a road leading directly to the roundabout, forming a bigger flare. Commonly encountered where adjacent flares cross. Default yes. different-names=[=yes|no] - Discard candidates where the two roads have different names and neither name is a substring of the other. Default yes. Specifying -- max-flare-length-ratio would set the max-flare-to-separation-multiple value and display an error message saying the option had been deprecated. At the moment I have all the rules hard coded to the default values mentioned above. I am asking for feedback on whether the rules would be better placed in a rules file, or in a command line option, i.e. either --roundabout-flare-rules=LIST-OF-RULES or --roundabout-flare-rules-file=FILENAME. Also, if you have any ideas for more rules that could be used to remove unwanted flare candidates then I could look at including them. Ideally, I would like to compare the Garmin type code of the two roads, but I can't see how to get to it from a RoadDef. Perhaps you can suggest how this can be achieved? When a candidate is discarded, a message is logged, so it is also possible to use those messages to identify errors in the OSM data (I found and corrected a few name typos by looking at the roads discarded because of having different names). If you think any of the keywords could be improved, please let me know. I realise that some of the rules really need pictures to describe how they operate! Regards, Mike

2 2

192GB recommended
by Andrzej Popowski 28 Jul '20

28 Jul '20

Hi, I recently have noticed the following suggestion in mkgmap output: "To reduce the run time, consider increasing the amnount of memory available for use by mkgmap by using the Java -Xmx flag to set the memory to more than 196700 MB, providing this is less than the amount of physical memory installed." I run mkgmap to create files for PC installation - overview map, index, tdb. There is no actual compilation of any map. I guess, that condition for triggering the message is wrong in my case and maybe the calculations too. I mean this part of code in Main.java: if ((taskCount > threadCount + 1) && (maxJobs == 0) && (threadCount < runtime.availableProcessors())) { System.out.println("To reduce the run time, consider increasing the amnount of memory available for use by mkgmap by using the Java -Xmx flag to set the memory to more than " + 100* (1 + ((runtime.maxMemory() * runtime.availableProcessors()) / (threadCount * 1024 * 1024 * 100))) + " MB, providing this is less than the amount of physical memory installed."); } Is "taskCount" correct, when input files are only *.img? "threadCount" is probably forced to 1, because I see message: "Setting max-jobs to 1". Then probably there is no need to multiply memory for all processors. I'm not sure about "runtime.maxMemory()". It looks like 24GB which I have allocated with option -Xmx24G. Shouldn't it be a real memory used? Well, all is not a problem really. I just found the message funny and investigated a bit. Btw, there is a typo: "amnount". -- Best regards, Andrzej

2 2

Performance of POI search on the Device
by franco_bez 28 Jul '20

28 Jul '20

Hi all, searching for POIs on my Oregon often is very frustrating. It virtually takes forever. Yesterday I noticed that some POI types are reasonably fast, while others are 10 times slower. I assume that this is some sort of index Problem. For example using my DACH map, built with mkgmap-r4506, map size 2.7GiB on my Oregon 750t - searching for Gas Stations takes some 5 seconds - searching for Bank/ATM takes some 50 seconds - searching for Any-/All Poi types also takes some 50 seconds for the first Elements to appear in the list. If I can trust my memory, in the past, maybe some 2 years ago, searching for Gas Stations was just as slow as any other POI type. What can I do to get the POI search fast for any POI type in the map ? I tried --make-poi-index but this didn't make any noticeable difference. Ciao, Franco -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html

4 22

Re: [mkgmap-dev] mkgmap-dev Digest, Vol 144, Issue 42
by John Thorn 28 Jul '20

28 Jul '20

Just another idea.... Is it possible to make the car park a (pseudo) node that is on all the paths that connect to the car park? John Thorn On Tue, 28 Jul 2020 at 12:00, <mkgmap-dev-request(a)lists.mkgmap.org.uk> wrote: > Send mkgmap-dev mailing list submissions to > mkgmap-dev(a)lists.mkgmap.org.uk > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > or, via email, send a message with subject or body 'help' to > mkgmap-dev-request(a)lists.mkgmap.org.uk > > You can reach the person managing the list at > mkgmap-dev-owner(a)lists.mkgmap.org.uk > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of mkgmap-dev digest..." > Today's Topics: > > 1. Re: default style lines enhancements (Ticker Berkin) > 2. Virtual paths (ael) > > > > ---------- Forwarded message ---------- > From: Ticker Berkin <rwb-mkgmap(a)jagit.co.uk> > To: mkgmap development <mkgmap-dev(a)lists.mkgmap.org.uk> > Cc: > Bcc: > Date: Tue, 28 Jul 2020 10:58:30 +0100 > Subject: Re: [mkgmap-dev] default style lines enhancements > Hi all > > In some major walking areas there are networks of paths with a few car > parks around the edge, normally set 100m or so into the park/woods. The > free maps one can obtain show suggested trails and these trails often > cross multiple car parks. The maps probably don't show a path within > the car park and there is no physical manifestation of it. > > Without "paths around car park", if I try to use my device to generate > a walking route to some feature in the area (or back to the start), it > will probably generate a route that leaves the area, gets onto the > closest road, and re-enters elsewhere. Or it might give a "Route > Calculation Error" because paths closest to the start or end are not > connected to the rest of the network. > > With the data as it stands, for sensible routes in the above situation > and others as expressed in my earlier email, mkgmap needs to generate > footways that join up all ways that lead into the car park with a > footway. With the current technology this can be done with > circumference footway and mkgmap:set_{semi_/un}connected_type provide a > really good way of not doing this where the footway won't solve any > routing issue and might cause routing island problems. > > I wouldn't object if OSM mappers joined all paths and the entrance > road/parking aisles within the car park and maybe there should be a > policy to do this and then there is no problem. > > However, there is a good argument that the correct OSM mapping is to > show paths exactly as they are and not have to invent and add 'virtual' > bits of footpath just to keep routing engines working sensibly because > "mkgmap expects it like that". > > Other things that have been mentioned: > > - What about a path that runs up to or along the side of a car park but > there is no access between them, eg an enclosed car park with a road > along-side. I'd say that this is just incorrect mapping if the car park > shares a node with the road but there is a barrier between. > > - If starting within the car park, the route might tell you to walk > around the edge rather that direct to the highway. Yes and no; it will > plot a route to the closest edge and then to the best exit for the > final destination; It should be obvious to the GPS user that they can > just walk directly to the best exit. Without the change the only option > you might get is onto the road network which could be entirely wrong. > > Ticker > > > > > > ---------- Forwarded message ---------- > From: ael <witwall3(a)disroot.org> > To: mkgmap-dev(a)lists.mkgmap.org.uk > Cc: > Bcc: > Date: Tue, 28 Jul 2020 11:44:52 +0100 > Subject: [mkgmap-dev] Virtual paths > On Tue, Jul 28, 2020 at 10:58:30AM +0100, Ticker Berkin wrote: > > road/parking aisles within the car park and maybe there should be a > > policy to do this and then there is no problem. > > > > However, there is a good argument that the correct OSM mapping is to > > show paths exactly as they are and not have to invent and add 'virtual' > > bits of footpath just to keep routing engines working sensibly because > > "mkgmap expects it like that". > > Not just mkgmap. It is a general problem. Maybe OSM should introduce > a new relation "connected"? That is one or more ways and/or points could > be members implying that it is possible to navigate (perhaps directly) > between any of them. That would solve many of the problems for all > routers. This idea needs expansion: a tag on the relation would specify > the mode of transport, although I guess this would be mainly foot. > Likewise, some sort of seasonal tag would be useful. But most of those > already exist for ways, so I suppose those could be just be applied to > the relation as well. > > Just musing out loud. If it seems sensible, maybe a proposal on the > tagging list? > > ael > > > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

2 1

Unable to search for Address - GPSMAP64s
by Andrew Morris 24 Jul '20

24 Jul '20

I finally got my map conversion working and the maps load fine. I can pick a location on the map and routing works as well as ever (there were always issues over the shortest distance/fastest route with Garmins). The problem is I can't search by address, which is kind of important. Only cities on the Basemap are being found, and only a few addresses. If I zoom in on a point on the map the street being searched for is shown on the map and in fact I can pick an address by that method. So, here's what I'm doing, but I'm obviously doing something wrong: (I installed all the jar files under /opt/mkgmap) osmconvert canada-latest.osm.pbf -o=canada-latest.o5m osmfilter canada-latest.o5m \ --keep-nodes= \ --keep-ways-relations="boundary=administrative =postal_code postal_code=" \ -o=canada-latest-boundries.o5m mkdir bounds java -cp /opt/mkgmap/mkgmap.jar \ uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryPreprocessor \ canada-latest-boundries.o5m bounds mkdir work ( cd work ; java -jar /opt/mkgmap/splitter.jar ../canada-latest.osm.pbf ) ( cd work ; java -jar /opt/mkgmap/mkgmap.jar \ --route --add-pois-to-areas --preserve-element-order \ --housenumbers --process-exits --process-destination \ --split-name-index \ --bounds=../bounds --precomp-sea=../sea-latest.zip \ --series-name='Canada OSM 2020' \ --family-name='Canada OSM 2020' \ --area-name='Canada OSM 2020' \ --country-name='Canada' --country-abbr='CA' \ --description='Canada OpenStreetMap (2020)' \ --index --gmapsupp 6324*.osm.pbf ) The only thing I can think of is I'm doing something wrong with osmfilter and removing too much information... If there's some sort of check I can do on the resulting gmapsup.img file, let me know and I'll get the results. Thanks for any help you can provide!

6 13

actual style rules
by Frank Stinner 23 Jul '20

23 Jul '20

Hi Gerd, thanks for the version r4565. The option --x-keep-empty-value-tags works like expected. Perhaps it would be better, i change my classification process a little bit and generate for my "private" tags additional name tags (LINE_MOTORWAY -> LINE_MOTORWAY_NAME). That increase the osm files but anyway. Frank Stinner

2 1

Commit r4565: implement undocumented option --x-keep-empty-value-tags to disable the removal of empty tags while parsing OSM input
by svn commit 22 Jul '20

22 Jul '20

Version mkgmap-r4565 was committed by gerd on Wed, 22 Jul 2020 implement undocumented option --x-keep-empty-value-tags to disable the removal of empty tags while parsing OSM input http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4565

1 0