- mkgmap-dev - The mkgmap lists

new branch nearby-POI
by Gerd Petermann 06 May '20

06 May '20

Hi all, it seems I underestimated the complexity of the new options implemented by Mikes Patch. Some errors as well as new interesting ideas came up so I decided to revert trunk (r4486 is like r4484) and and create a new branch. So, please check the bottom on http://www.mkgmap.org.uk/download/mkgmap.html for new versions of the nearby-POI branch. I've committed my latest work on the code, but documentation is not up-to-date. Unfortunately the generated docu at http://www.mkgmap.org.uk/doc/options is that for the branch. Today I don't have more time for this, so please try http://www.mkgmap.org.uk/download/mkgmap-nearby-POI-r4490.zip Please only report problems when you can reproduce them with r4490 or later. On the TODO list: - try to understand the new ideas - unit tests - docu Gerd

1 0

Commit r4486: revert changes r4485 nearby-POI handling needs more thinking
by svn commit 06 May '20

06 May '20

Version mkgmap-r4486 was committed by gerd on Wed, 06 May 2020 revert changes r4485 nearby-POI handling needs more thinking http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4486

1 0

Re: [mkgmap-dev] nearby POIs
by Gerd Petermann 06 May '20

06 May '20

Hi all, thanks for testing. I've just noticed that the jar file contained a modified points file, but I guess you all used your own style files. I thought about the possible effects on routing and found none. The new algo works like this: 1) Collect all generated POI and the corresponding nodes before adding them to the map 2) after all style rules were processed and WrongAngleFixer has moved points (and POI) to fix visible wrong angles the POI are deduplicated. This means they are - grouped by type and name - each group is processed so that + the first matching rule is applied using the given radius: Iterate as long as there are multiple POI * for each POI, build a group of all nearby POI * select the biggest group * calculate the center of that group * select the POI that is closest to the center * apply the action to the other POI of the group, maybe move the selected POI to the middle * remove all POI handled in this group Known problems: - The new implementation will not work well for the /all case because a group with different names is not detected as such - maybe identical POI are not removed with the delete-name case - Maybe there is an unwanted effect on rendering when WrongAngleFixer moves a point and the corresponding POI is not moved. This already happens sometimes and should be no big problem. If I find no solution for the first 2 problems today I'll revert trunk version and create a branch for further development. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap(a)jagit.co.uk> Gesendet: Dienstag, 5. Mai 2020 12:03 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd That got rid of my multiple benches. Just looking at the log for the few other POI it also got rid of. It would be useful for the log message to include the distance between the POIs Ticker On Tue, 2020-05-05 at 09:19 +0000, Gerd Petermann wrote: > Hi all, > > attached is a patch that seems to work. I've kept the logging as > memory is not such a big problem. > I've not yet tested special cases like duplicated barrier nodes or a > group of nodes where only some are within the tile boundary. > > Please check if your problems are solved with this version, a binary > is here: > http://files.mkgmap.org.uk/download/469/mkgmap.jar > > Gerd > > ________________________________________ > Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk> im Auftrag > von Joris Bo <jorisbo(a)hotmail.com> > Gesendet: Dienstag, 5. Mai 2020 08:32 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] nearby POIs > > Hi, > > > > I have been testing the nearby poi rules as well with 4485 > > A while I struggled thinking misconfiguration because I see nothing > happening but then after extending the ranges, an occasional poi > disappears. (toilet 0x2a0d, busstop 0x2f17, custom lift-gate 0x6905) > > > > On the cmd line > > --nearby-poi-rules=*/unnamed:100:delete-poi,*/named:100:delete-poi > > > > On my densed big city area (Antwerpen) In that case I expect maybe a > couple of thousand benches, trees and bicycle parkings disappear > which do not. > > > > Can I help testing better by increasing some logging? How could I do > that? > > > > Kind regards, joris > > > > Silo’s (0x2a19) don’t disappear / N51° 11.992' E4° 24.916' > > An occasional lift gate (0x6905) does disappear > > [cid:image001.jpg@01D622B7.BA7DE260] > > > > Bicycle stands (0x2f18): don’t disappear > > N51° 13.685' E4° 24.281' > > [cid:image002.jpg@01D622B7.BA7DE260] > > > > > > -----Oorspronkelijk bericht----- > Van: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk> Namens > Ticker Berkin > Verzonden: maandag 4 mei 2020 16:13 > Aan: mkgmap development <mkgmap-dev(a)lists.mkgmap.org.uk> > Onderwerp: Re: [mkgmap-dev] nearby POIs > > > > Hi Mike > > > > No, I just have --nearby-poi-rules=0x6605:30 > > > > Gerd has explained why I see a message from NearbyPoiHandler about a > POI for that wasn't 0x6605 - the logging of the removal of an exact > duplicate has moved from StyledConverter > > > > Ticker > > > > On Mon, 2020-05-04 at 14:35 +0100, Mike Baggaley wrote: > > > Hi Ticker, have you got a --nearby-poi-rules-config option as well? > > > > > > Cheers, > > > Mike > > > > > > -----Original Message----- > > > From: Ticker Berkin [mailto:rwb-mkgmap@jagit.co.uk] > > > Sent: 04 May 2020 11:33 > > > To: Development list for mkgmap <mkgmap-dev(a)lists.mkgmap.org.uk<mai > > lto:mkgmap-dev@lists.mkgmap.org.uk>> > > > Subject: Re: [mkgmap-dev] nearby POIs > > > > > > OK, looking up the # as a way instead gives a polygon that matches > > the > > > description and would generate a typ code as per the message > > > > > > I was more worried about it logging messages about POI with typ > > codes > > > that I hadn't mentioned in rules and not saying anything about the > > one > > > I had. > > > > > > I get the same behaviour with just --nearby-poi-rules=0x6605:30 > > > > > > Ticker > > > > > > On Mon, 2020-05-04 at 10:14 +0000, Gerd Petermann wrote: > > > > Hi Ticker, > > > > > > > > the new option doesn't work well, Mike and I are working on it. > > > See > > > > http://gis.19327.n8.nabble.com/nearby-POIs-tp5962630p5964759.html > > > > The log messages are for POIs generated from areas, so the > > > > "generated from" ids are either ways or multipolygon relations. > > > > > > > > Gerd > > > > > > > > > > > > ________________________________________ > > > > Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk<mailto: > > > mkgmap-dev-bounces(a)lists.mkgmap.org.uk>> im Auftrag > > > > von Ticker Berkin <rwb-mkgmap(a)jagit.co.uk<mailto: > > > rwb-mkgmap(a)jagit.co.uk>> > > > > Gesendet: Montag, 4. Mai 2020 12:04 > > > > An: mkgmap development > > > > Betreff: [mkgmap-dev] nearby POIs > > > > > > > > Hi Mike & Gerd > > > > > > > > I'm trying --nearby-poi-rules=0x6605:30:merge-at-mid-point > > > > > > > > with, in points: > > > > > > > > amenity=bench [0x6605 resolution 24 continue] > > > > > > > > and the resultant map is showing benches close to each other (< > > > 10 > > > > m) > > > > > > > > and, in the log file I'm getting messages like: > > > > > > > > INFO: uk.me.parabola.mkgmap.osmstyle.NearbyPoiHandler > > > > ../mapHants/74210001.osm.pbf: Removed duplicate POI with type > > > > 0x2d02 > > > > The Dungeon for element generated from 159255400 > > > > INFO: uk.me.parabola.mkgmap.osmstyle.NearbyPoiHandler > > > > ../mapHants/74210001.osm.pbf: Removed duplicate POI with type > > > > 0x2a07 > > > > Wah Ying for element generated from 468906008 > > > > > > > > The "generated from" number doesn't seem to correspond to a > > > relevant > > > > OSM node and the message doesn't have the trailing "and moved..." > > > > that > > > > I would have expected. > > > > > > > > Ticker > > > > _______________________________________________ > > > > mkgmap-dev mailing list > > > > mkgmap-dev(a)lists.mkgmap.org.uk<mailto: > > > mkgmap-dev(a)lists.mkgmap.org.uk> > > > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > _______________________________________________ > > > > mkgmap-dev mailing list > > > > mkgmap-dev(a)lists.mkgmap.org.uk<mailto: > > > mkgmap-dev(a)lists.mkgmap.org.uk> > > > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > > > _______________________________________________ > > mkgmap-dev mailing list > > mkgmap-dev(a)lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev(a)lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

3 3

nearby POIs
by Ticker Berkin 05 May '20

05 May '20

Hi Mike & Gerd I'm trying --nearby-poi-rules=0x6605:30:merge-at-mid-point with, in points: amenity=bench [0x6605 resolution 24 continue] and the resultant map is showing benches close to each other (< 10 m) and, in the log file I'm getting messages like: INFO: uk.me.parabola.mkgmap.osmstyle.NearbyPoiHandler ../mapHants/74210001.osm.pbf: Removed duplicate POI with type 0x2d02 The Dungeon for element generated from 159255400 INFO: uk.me.parabola.mkgmap.osmstyle.NearbyPoiHandler ../mapHants/74210001.osm.pbf: Removed duplicate POI with type 0x2a07 Wah Ying for element generated from 468906008 The "generated from" number doesn't seem to correspond to a relevant OSM node and the message doesn't have the trailing "and moved..." that I would have expected. Ticker

5 14

nearby POIs
by Mike Baggaley 04 May '20

04 May '20

Hi Gerd, please find attached a patch for handling the removal of duplicate POIs that are near to each other but not coincident. The existing code handles the removal of coincident duplicates, but leaves other duplicates in place. It is very common in OSM for buildings to be tagged as amenities with a single node also being tagged as the same amenity. If using --add-pois-to-areas, this can lead to a lot of duplication. The patch provides a new command line option with the following syntax: --nearby-poi-rules=type[/all|/named|/unnamed]:max-distance[:delete-poi|delet e-name|merge-at-mid-point][,...] This defines a set of rules to follow when a POI is near to another of the same type. Each rule consists of three parts separated by colons. The first two parts must be provided; the last part can be defaulted. The first part of the rule is the Garmin POI type code with an optional suffix; it determines when the rule is triggered. The type code may be specified in decimal or hexadecimal (e.g. 0x2c0b). A rule is triggered when processing a POI if the type code of the POI matches the rule type, providing there is also a match in the POI name and the first part suffix. If the suffix is '/all' (the default) then the match is only made on the type. If the suffix is '/named' then the rule is only triggered if the POI has a name. If the suffix is '/unnamed' then the rule is only triggered if the POI has no name. A wildcard of an asterisk character may be used to match any type code. The wildcard may also be combined with a suffix to allow separate processing of named and unnamed POIs. The second part of the rule is the distance in metres which an already processed POI must be within for it to be considered to be nearby and hence trigger the action part of the rule. The third part of the rule is the action part and provides three options: ::delete-poi - the POIS are considered to be duplicates and the duplicate is deleted. This is the default. ::delete-name - the POIS are not duplicates, but only a single name needs to be displayed. ::merge-at-mid-point - the POIS are considered to be duplicates but the location of the existing point is moved to a point midway between the two points. Wildcard rules are only applied if no other rule is applicable. For example: : --nearby-poi-rules=*/named:50,*/unnamed:25,0x2f1f/named:50:delete-name,0x2f1 f:3,0x641d:400:merge-at-mid-point This has the following effect: : If no other rule applies, a POI with the same name and type and within 50m of one already processed will be deleted If no other rule applies, a POI having no name and of the same type and within 25m of one already processed will be deleted A POI of type 0x2f1f that is within 50m of another POI with the same name and type will have its name deleted A POI of type 0x2f1f that is within 3m of another POI with the same type will be deleted A POI of type 0x641d that is within 400m of another POI with the same type will be deleted and the existing point moved Note: a POI that matches another in type, name and exact location is always considered a duplicate and deleted. Regards, Mike

5 37

Commit r4485: Implement and document new options --nearby-poi-rules and --nearby-poi-rules-config
by svn commit 30 Apr '20

30 Apr '20

Version mkgmap-r4485 was committed by gerd on Thu, 30 Apr 2020 Implement and document new options --nearby-poi-rules and --nearby-poi-rules-config Patch nearbyPOI8.patch by Mike Baggaley http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4485

1 0

Commit r4484: improve/correct example roadNameConfig.txt (patches by Ticker Berkin and Mike Baggaley)
by svn commit 27 Apr '20

27 Apr '20

Version mkgmap-r4484 was committed by gerd on Mon, 27 Apr 2020 improve/correct example roadNameConfig.txt (patches by Ticker Berkin and Mike Baggaley) http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4484

1 0

[Fwd: Re: Suggestions for roadNameConfig.txt]
by Ticker Berkin 27 Apr '20

27 Apr '20

Hi Gerd Could you consider this change to roadNameConfig.txt for GBR I've attached an updated version based current trunk.o1 Thank you Ticker -------- Forwarded Message -------- From: Ticker Berkin <rwb-mkgmap(a)jagit.co.uk> Reply-to: Development list for mkgmap <mkgmap-dev(a)lists.mkgmap.org.uk> To: Development list for mkgmap <mkgmap-dev(a)lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] Suggestions for roadNameConfig.txt Date: Thu, 23 Jan 2020 16:56:17 +0000 Hi Gerd I've just been going through some old mails/patches. I think the updated contents of roadNameConfig.txt is correct and better than the previous version. The fact that it doesn't work consistently across devices and, on some, is misleading shouldn't stop the file being available as an example in the distribution. The user has the choice about how to use it and it contains some comments and a link relating to these problems. I've attached an updated patch with UTF-8 encoding markers, a different section for UK road names and improved some comments. This file has always been read by mkgmap as UTF-8. The function of the markers is to make editors aware of this; it contains characters outside the 7-bit ascii range. Ticker On Mon, 2019-12-16 at 11:30 +0000, Gerd Petermann wrote: > Hi Ticker, > > reg. search: You are probably right, address search works very > different on the Garmin devices. On the Oregon, I have several > dialogs, first to chose country, next to chose city or "all", next to > type house number, last one asking for road name. In this dialog > there is no autocompletion, I just have to type characters. Sometimes > the device switches automatically to a result list while I am typing, > sometimes it doesn't. When I press OK I get a list of matching roads. > So, for the Oregon it works fine. Maybe it doesn't for those devices > with auto-completion. Cannot test this right now. I tried it once > with a Nüvi and it seemed to work well, but I don't own one. > > Reg. combination of --road-name-config and --split-name-index: Yes, > this gives confusing results. Not sure if it worked better in the > past. > I tried with Essex extract: > java -jar d:\mkgmap\dist\mkgmap.jar --bounds=f:\osm\bounds.zip - > -gmapi --net --index --road-name > -config=d:\mkgmap\resources\roadNameConfig.txt --gmapsupp --split > -name-index f:\dwnload\temp\essex-latest.osm.pbf > > > According to Mapsource a search for "Mace" without giving a city name > should list "John Mace Road", "Mace Avenue", "Mace Court", and "Mace > Walk", maybe in a different order. > Without your patch I get a list showing "Mace Road", "Mace Avenue", > and "Mace Walk", so "Mace Court" is missing and when I select "Mace > Road" the device shows the "John Mace Road". > With your patch this gets worse: The list shows only "Mace Road", > when I select that entry I get a new list containing > ",Thurrock","Braintree,Essex","Chelmsford,Essex", and "Colchester, > Essex". Each of them points to just one of the expected roads. > > Results look much better when I specify a city name. > Result also looks very different without the --split-name-option. > I have to do more tests, I think it worked better in the past. Maybe > sorting is broken. > > Gerd

4 12

Extending metadata mkgmap default logging output
by Joris Bo 25 Apr '20

25 Apr '20

Hello, Is there a way to get the mkgmap version number in the logfile? I know it is possible to use the -version option but this means an extra execution of mkgmap. There is already a default output like this: Time started: Thu Apr 23 07:56:43 CEST 2020 Found one style in ..\..\Dropbox\Garmin\Build\Style - Jbm finished check-styles Number of MapFailedExceptions: 0 Number of ExitExceptions: 0 Time finished: Thu Apr 23 07:57:17 CEST 2020 Total time taken: 33 seconds Could the mkgmap version number be part of this metadata? Kind regards, Joris

3 3

"Small" SRTM1 files and DEM maps
by Carlos Dávila 21 Apr '20

21 Apr '20

I use phyghtmap to build contour lines and also to download hgt data that I then use to build DEM maps with mkgmap. For a long time, SRTM1 files (and also VFP1) have all been ~24.7 MB in size, but lately (I don't remember since when) SRTM1 are also served as 12.4 MB files. phyghtmap is able to generate contour lines from those small files, as they seem to contain the same information but with a different compression ratio, but mkgmap fails to read them, and report them as missing. Would it be possible to get support for such files in mkgmap?

5 11