November 2019 - mkgmap-dev - The mkgmap lists

Commit r4351: code cleanup: remove parameter which was always set to true
by svn commit 06 Nov '19

06 Nov '19

Version mkgmap-r4351 was committed by gerd on Wed, 06 Nov 2019 code cleanup: remove parameter which was always set to true My understanding: The flag in the topmost bit is set when the remaining integer is a pointer to a city, else is points to a region which is written with a different method. 2nd commit, forgot to safe before committing) http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4351

1 0

Commit r4350: code cleanup: remove parameter which was always set to true
by svn commit 06 Nov '19

06 Nov '19

Version mkgmap-r4350 was committed by gerd on Wed, 06 Nov 2019 code cleanup: remove parameter which was always set to true My understanding: The flag in the topmost bit is set when the remaining integer is a pointer to a city, else is points to a region which is written with a different method. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4350

1 0

Commit r4349: Patch f:\dwnload\temp\typeSubtypeCity_v3.patch by Ticker Berkin
by svn commit 06 Nov '19

06 Nov '19

Version mkgmap-r4349 was committed by gerd on Wed, 06 Nov 2019 Patch f:\dwnload\temp\typeSubtypeCity_v3.patch by Ticker Berkin - Simplify handling of type/subtype - Change handling of POI with type 0x1100 so that they are no longer treated as a city. Maybe this value is still too high. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4349

1 0

type/subtype of points and cities
by Ticker Berkin 05 Nov '19

05 Nov '19

Hi I think the mkgmap internal handling of types/subtypes of points is obscure. In the points style file, the type code is always full, ie type << 8 | subtype, but when the points are read back from the RGN file for the MDR processing, the representation is the same provided the subtype is not zero, otherwise it is just type! Logic then decides that if the value is <= 0xff it is because the subtype is zero. It is simpler and much clearer to preserve the original representation. This also allows unambiguous use of type 0 with subtypes, and, possibly, city with subtypes. It also allows the same function to be used to test a type for being in the 'city' range, regardless of the context. mkgmap wasn't consistent the ranges for the isCity test. City POI are written in a different manner to the RGN file. The old range for this was: type >= 0x0100 && type <= 0x1100 which I've kept, except changing to: ...& type < 0x1200. A similar range was used for MDR5. However, city POI are held in group 1 of MDR 9/10. This is used in Find > City 'By Name'. The old range was: type <= 0xf, where, if the subtype was zero, type is right shifted by 8 (see above), non-zero subtypes messed up the testing. Now it uses the same range as above. Actually neither of these ranges are correct for my Garmin devices. Find > City show nearby POI with types in the range 0x0100..0x0d1f, regardless of the img RGN or MDR. The eTrex Legend labels POIs in this range as {Large/Medium/Small} City/Town and points in the range 0x0e00..0x111f as "*". Find > City 'by-name' returns POI if in group 1 of MDR 9/10. I find it a useful feature to have a POI that can be searched for but doesn't flood the list of nearby points. Generally, non-zero subtypes for cities cause problems in the RGN structure and I've added a test for this to the style validation. There is also a fix to --make-poi-index, but I can't detect any effect of this option. This patch won't make any difference to the img output unless the there are points 0x1000, 0x1100. If this patch is accepted, I'll do the equivalent to the img display system. Regards Ticker

3 13

Re: [mkgmap-dev] documentation of new option in branch
by Gerd Petermann 05 Nov '19

05 Nov '19

Hi all, thanks for all the input. Here is my 2nd try: --check-routing-island-len=INTEGER Routing islands are small road networks which are not connected to other roads. A typical case is a footway that is not connected to the main road network, or a small set of ways on the inner courtyard of a large building These islands can cause problems if you try to calculate a route and the GPS selects a point on the island as a start. It will fail to calculate the route even if a major road is only a few steps away. If this option is specified, then mkgmap will detect these islands. If the value is set to zero, mkgmap will simply report the islands (you will need to set uk.me.parabola.imgfmt.app.net.RoadNetwork.level=INFO to activate logging of the message). If the value is greater than zero, mkgmap will mark islands with a total length less than the specified value in metres as not routable. Reasonable values are 500 or higher. The default is for the check to not take place. If any of the roads forming the island touches a tile boundary or a country border the island is ignored, as it may be connected to other roads in a different tile. See also option --add-boundary-nodes-at-admin-boundaries. As Arndt has pointed out there is a possible problem with the island detection when the input file doesn't cover the tile boundary. This is quite normal. When you split eg. germany-latest.osm.pbf you'll get lots of tiles at the country boundary. Since Geofabrik uses simplified polygons you will see many small islands next to the cutting polygon. These islands may be connected to the road network in the neighbour country without touching the country border. Of course this is also the case when you use a polygon in splitter (options --polygon-file or --polygon-desc-file). So, I would not use this test for OSM quality checks (geofabric provides this in the routing view of OSM inspector). Gerd ________________________________________ Von: Gerd Petermann <gpetermann_muenchen(a)hotmail.com> Gesendet: Montag, 4. November 2019 18:17 An: Felix Hartmann Betreff: AW: [mkgmap-dev] documentation of new option in branch Hi Felix, the number is about the total length of the roads in the island, measured in meters. Gerd ________________________________________ Von: Felix Hartmann <extremecarver(a)gmail.com> Gesendet: Montag, 4. November 2019 17:51 An: Gerd Petermann Betreff: Re: [mkgmap-dev] documentation of new option in branch Ah okay - so it should be explained that the Integer is the number of roads which form an island. e.g. 100 so anything below 200 100 segments is still an island and thereby routing disabled. That is quite interesting then and an addition (still set_unconnected_type=XXXXX is then pretty obsolete if its only about making the road unroutable). On Mon, 4 Nov 2019 at 17:40, Gerd Petermann <gpetermann_muenchen(a)hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix, mkgmap:set_unconnected_type works very different. 1) It only detects single roads not connected to other roads, the island detection also finds multiple roads which are only connected to each other 2) the island detection adds the line as a road to NET, it just doesn't add it to NOD. So address search works as usual. (I am not yet 100% sure if this is a good idea, have to do more testing here) Island detection happens after processing of mkgmap:set_unconnected_type, right before the AngleChecker is called. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <extremecarver(a)gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Montag, 4. November 2019 17:27 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] documentation of new option in branch Hi So basically this is a global: set mkgmap:set_unconnected_type=none; Or is there a difference? I've used the unconnected_type and semi_connected type basically for all routable lines in my style-file. The unconnected_type is now obsolete if you just used to disable routing by setting an unroutable type - correct? Have you tested that the global option is run after semi_connected_type and unconnected_type? Because first the style should be able to remove them or change them to unroutable type - then leftover islands should be covered with this method. Felix On Mon, 4 Nov 2019 at 17:06, Ticker Berkin <rwb-mkgmap(a)jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>>> wrote: Hi I think the default should be either: Don't check for routing islands or: Check for and remove islands of any length but I don't feel that strongly about this aspect. In the documentation, it should mention the effect of a road meeting a tile boundary or boundary nodes added at admin boundaries. I've been using this feature for a couple of weeks now and it has stopped a lot of "Route Calculation Error"s - Thanks Gerd. Ticker On Mon, 2019-11-04 at 15:37 +0000, Gerd Petermann wrote: > Hi Nick, > > as always the information is written with the logger (1). You have to > activate logging at info level with > uk.me.parabola.imgfmt.app.net<http://uk.me.parabola.imgfmt.app.net><http://uk.me.parabola.imgfmt.app.net>.RoadNetwork.level=INFO > > (1) https://wiki.openstreetmap.org/wiki/Mkgmap/dev#Enabling_Debugging > > Using a negative value for NUM means that mkgmap doesn't calculate > the islands at all, using > 0 means that it only reports the islands. If you want to remove > islands you can start with a value like > 500. The default is 0. > > Gerd > > ________________________________________ > Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag > von Pinns UK <osm(a)pinns.co.uk<mailto:osm@pinns.co.uk><mailto:osm@pinns.co.uk<mailto:osm@pinns.co.uk>>> > Gesendet: Montag, 4. November 2019 16:29 > An: mkgmap-dev(a)lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>> > Betreff: Re: [mkgmap-dev] documentation of new option in branch > > Hi Gerd > > Thanks for all you work with regards routing islands! > > a) Is there a way of finding out how many .if any. routing islands > were found given a certain length? > > b) if NUM is negative is there any point in adding --check-routing > -island-len=NUM > > Nick > > > > On 04/11/2019 13:58, Gerd Petermann wrote: > > Hi all, > > I think the work on the branch is almost done. > Attached is a patch to add documentation for the new option. > Please help to improve it: > > --check-routing-island-len=NUM > Routing islands are small road networks which are not > connected to other > roads. Typical case is a footway that is not connected to the > main road > network. These islands can cause problems if you try to > calculate a route > and Garmin selects a point on the island as a start. It will > fail to > calulate the route even if a major road is only a few steps > away. > When calculating the NOD data mkgmap detects the islands. The > option > --check-routing-island-len=NUM can be used to tell mkgmap > that islands with > a total length below NUM meters should not be written to NOD. > The effect is > that the corresponding roads are visible as usual but they > are not > routable. > A negative value for NUM means that mkgmap skips the island > check. > > ciao > Gerd > > > > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev(a)lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@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<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@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<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich

3 4

Preparing merge with trunk for branch NET-no-NOD
by Gerd Petermann 05 Nov '19

05 Nov '19

Hi all, besides the new island detection the major changes are: - reduced IMG size (NOD). The trunk version converts all road ends to so called routing nodes and also adds arcs to those nodes. Think of a +-shaped crossing where only the southern end is connected to another road. The trunk versions adds three route nodes and at least 6 arcs for the unconnected ends. I found no good reason for this. The data is probably completely ignored by Garmins routing algo, so the branch version doesn't do this. - routing and address search work with maps that use resolution 23 for level 0 (instead of 24). To use this the style must NOT add any objects with a minimal resolution of 24. More general, it must not use a minimum resolution that is higher than that given for level 0. (I did not intend to code that, I just found the error that causes a problem in the trunk version, the RoundCoordsFilter removed special nodes.) In most cases one would replace lines like (aeroway=taxiway | aeroway=taxilane) & area!=yes {name '${ref}'} [0x27 resolution 24 continue] by (aeroway=taxiway | aeroway=taxilane) & area!=yes {name '${ref}'} [0x27 level 0 continue] to use this BUT probably some objects really should not be added to such a map, e.g. buildings, so I see no good way to automate this, so mkgmap stops with an error message if the style is not adjusted like this. - improved polish format (*.mp) reader no longer ignores empty Numbers ("x,N,-1,-1,N,-1,1") as they improve the address search result. - reduced NET size when map is not routable The trunk version stores information in NET which is only needed for routable maps. If you have doubts about any of the changes please try to find a place where the branch doesn't work (better) than the trunk version. Gerd

1 0

documentation of new option in branch
by Gerd Petermann 04 Nov '19

04 Nov '19

Hi all, I think the work on the branch is almost done. Attached is a patch to add documentation for the new option. Please help to improve it: --check-routing-island-len=NUM Routing islands are small road networks which are not connected to other roads. Typical case is a footway that is not connected to the main road network. These islands can cause problems if you try to calculate a route and Garmin selects a point on the island as a start. It will fail to calulate the route even if a major road is only a few steps away. When calculating the NOD data mkgmap detects the islands. The option --check-routing-island-len=NUM can be used to tell mkgmap that islands with a total length below NUM meters should not be written to NOD. The effect is that the corresponding roads are visible as usual but they are not routable. A negative value for NUM means that mkgmap skips the island check. ciao Gerd

6 7

Re: [mkgmap-dev] [mkgmap-svn] Commit r4338: merge from trunk r4337
by Ticker Berkin 02 Nov '19

02 Nov '19

Hi Gerd I get this with r4338: java.lang.IndexOutOfBoundsException: Index: 0 at java.util.Collections$EmptyList.get(Collections.java:4454) at uk.me.parabola.imgfmt.app.net.NETFile.createSortKeysyNameAndCity(NETFil e.java:166) at uk.me.parabola.imgfmt.app.net.NETFile.deDupRoads(NETFile.java:117) at uk.me.parabola.imgfmt.app.net.NETFile.writePost(NETFile.java:88) at uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:320) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:107) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:73) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:289) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:285) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.ja va:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.j ava:617) at java.lang.Thread.run(Thread.java:745) using my options, style and test area as before (22-oct 18:24 and 24 -oct 08:35 24-oct 9:07). Options include --no-housenumbers --x-check-routing-island-len=700 I can try with latest version later tonight. Ticker On Sat, 2019-11-02 at 14:56 +0000, svn commit wrote: > Version mkgmap-r4338 was committed by gerd on Sat, 02 Nov 2019 > BRANCH: NET-no-NOD > merge from trunk r4337 > > http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4338 > _______________________________________________ > mkgmap-svn mailing list > To unsubscribe send an mail to mkgmap-svn-leave(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-svn

2 2

mapids beyond the limit
by nwillink 02 Nov '19

02 Nov '19

Hi Gerd For testing purposes I have created an arg file with mapids starting from 99999999 (8 digits) and incrementing them to 100000009 (9 digits) It created all the tiles (imgs) - I don't think it gave me a warning about most imgs having a nine digital mapid. After I installed the map onto Basecamp , Basecamp reported an error and refused to load. I'm sure this has never been an issue with anyone using mkgmap, but it might be useful to check the validity of mapids when tiles are created ? Regards Nick -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html

4 9

Commit r4339: Fix possible IndexOutOfBoundsException caused by copy+paste error
by svn commit 02 Nov '19

02 Nov '19

Version mkgmap-r4339 was committed by gerd on Sat, 02 Nov 2019 Fix possible IndexOutOfBoundsException caused by copy+paste error http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4339

1 0