November 2019 - mkgmap-dev - The mkgmap lists

Commit r4376: code cleanup using hints from sonarlint, no change in output expected
by svn commit 25 Nov '19

25 Nov '19

Version mkgmap-r4376 was committed by gerd on Mon, 25 Nov 2019 code cleanup using hints from sonarlint, no change in output expected - improve check of --polygon-size-limits, stop if an error is found instead of writing errors to stderr - use log.error() instead of system.err.println() - use more lambdas and computeIfAbsent - merge nested if-then clauses - improve formatting - remove some TODO http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4376

1 0

Commit r4375: Document possible routing problems in BaseCamp when option --check-routing-island-len=INTEGER is used.
by svn commit 25 Nov '19

25 Nov '19

Version mkgmap-r4375 was committed by gerd on Mon, 25 Nov 2019 Document possible routing problems in BaseCamp when option --check-routing-island-len=INTEGER is used. It seems that the routing problems occur only in Basecamp. My current understanding is that BaseCamp uses a different way to read the *.IMG data compared to devices or Mapsource. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4375

1 0

Commit r4374: Correct calculation of special nodes
by svn commit 25 Nov '19

25 Nov '19

Version mkgmap-r4374 was committed by gerd on Mon, 25 Nov 2019 Correct calculation of special nodes We have to make sure that island detection is done before we calculate the flags for special nodes, else values may be wrong, so call RoadNetwork.getCenters() which does the island detection before writing RGN data. Unfortunately this doesn't fix routing errors in Basecamp seen with the --check-routing-island-len=INTEGER option. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4374

1 0

Building map with Hebrew characters
by Carlos Dávila 18 Nov '19

18 Nov '19

I'm trying to build a map of Israel with Hebrew characters, but using --code-page=1255 a get the following assertion: at uk.me.parabola.imgfmt.app.srt.SRTFile.writeWeights(SRTFile.java:117) at uk.me.parabola.imgfmt.app.srt.SRTFile.writeSrt4Chars(SRTFile.java:99) at uk.me.parabola.imgfmt.app.srt.SRTFile.write(SRTFile.java:63) at uk.me.parabola.mkgmap.combiners.MdrBuilder.init(MdrBuilder.java:117) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:605) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:128) at uk.me.parabola.mkgmap.main.Main.mainStart(Main.java:143) at uk.me.parabola.mkgmap.main.Main.main(Main.java:114) With --unicode I also get an assertion: Exception in thread "main" java.lang.AssertionError: -125 at uk.me.parabola.imgfmt.app.BufferedImgFileWriter.put1u(BufferedImgFileWriter.java:154) at uk.me.parabola.imgfmt.app.SectionWriter.put1u(SectionWriter.java:78) at uk.me.parabola.imgfmt.app.srt.SRTFile.writeWeights(SRTFile.java:113) at uk.me.parabola.imgfmt.app.srt.SRTFile.writeSrt8(SRTFile.java:166) at uk.me.parabola.imgfmt.app.srt.SRTFile.write(SRTFile.java:68) at uk.me.parabola.mkgmap.combiners.MdrBuilder.init(MdrBuilder.java:117) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:605) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:128) at uk.me.parabola.mkgmap.main.Main.mainStart(Main.java:143) at uk.me.parabola.mkgmap.main.Main.main(Main.java:114) Probably I'm missing something obvious, but I always used --code-page=1251 and have no idea what it may be

5 12

precompiled sea files download
by thesurveyor＠wolke7.net 17 Nov '19

17 Nov '19

4 3

Commit r4373: code cleanup using hints from sonarlint, no change in output expected
by svn commit 17 Nov '19

17 Nov '19

Version mkgmap-r4373 was committed by gerd on Sun, 17 Nov 2019 code cleanup using hints from sonarlint, no change in output expected - use more lambdas and computeIfAbsent - merge nested if-then clauses - improve formatting - remove OsmReadingHooksAdaptor, add defaults to interface OsmReadingHooks http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4373

1 0

Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only
by Felix Hartmann 15 Nov '19

15 Nov '19

Hi Gerd, So you mean the only solution would be to change the style-file to the following in order to have it working? service=driveway {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} [0x13 road_class=0 road_speed=0 resolution 24 continue with_actions] service=driveway & mkgmap:set_semi_connected_type=none {delete service; delete highway; delete access} service=driveway [0x1040c resolution 24] But then I guess I would also have to change the other example to: ( service=parking_aisle | service=parkingaisle) {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} ( service=parking_aisle | service=parkingaisle) & mkgmap:set_semi_connected_type=none {delete ....} Felix On Thu, 14 Nov 2019 at 16:50, Gerd Petermann < gpetermann_muenchen(a)hotmail.com> wrote: > Hi Felix, > > sorry, I replied to you instead of the list. In my example containing the > island detection please replace "a semi-connected" with "an unconnected". > > Gerd > > ________________________________________ > Von: Gerd Petermann <gpetermann_muenchen(a)hotmail.com> > Gesendet: Donnerstag, 14. November 2019 16:46 > An: Felix Hartmann > Betreff: AW: [mkgmap-dev] mkgmap:set_unconnected_type differentiate > between connected on both sides or on one side only > > Hi Felix, > > I think the patch works fine for your examples but not in this case: > service=driveway {set mkgmap:set_semi_connected_type=none; set > mkgmap:set_unconnected_type=none} [0x13 road_class=0 road_speed=0 > resolution 24 continue with_actions] > service=driveway {set mkgmap:set_semi_connected_type=0x1040d; set > mkgmap:set_unconnected_type=0x1040e} [0x1040c resolution 24] > The overlay line will always be added with 0x1040c. I think this is not > obvious and therefore an error. > > I think the idea with a replacement type was similar to the new > island-detection: reduce img size. For example, with a single line like this > service=driveway {set mkgmap:set_semi_connected_type=0x1040c; set > mkgmap:set_unconnected_type=0x1040c} [0x13 road_class=0 road_speed=0 > resolution 24] > a semi-connected service way would still appear in the map (with 0x1040c) > but not in NET or NOD while island detection only removes it from NOD. > > Regarding the error: The problem gets worse when your style adds the same > OSM way more than 3 or more times with different values in > mkgmap:set_unconnected_type, esp. when two or more routable ways are > added. I think results are more or less unpredictable when you have both a > "none" and a replacement type. > Not sure how to handle these special cases. > > Gerd > > ________________________________________ > Von: Felix Hartmann <extremecarver(a)gmail.com> > Gesendet: Donnerstag, 14. November 2019 16:09 > An: Gerd Petermann > Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate > between connected on both sides or on one side only > > Yes I sometimes use types for unconnected - but only none for > semi_connected. > > And well the situation with continue is a bit complicated, but yes. I > changed my style so that I can adjust what happens with continue. > > e.g: > service=driveway {set mkgmap:set_semi_connected_type=none; set > mkgmap:set_unconnected_type=none} [0x13 road_class=0 road_speed=0 > resolution 24 continue with_actions] > service=driveway {set mkgmap:set_semi_connected_type=none; set > mkgmap:set_unconnected_type=none} [0x1040c resolution 24] > > here both the invisible 0x13 road and the visible 0x1040c is removed. So > semi_connected is not only valid for roads but also for simple lines. This > is a classic example as I feel that driveways clutter the map and don't > need them for routing if they are semi_connected (because Garmin will route > to destination with straight line too). > > I'm also using it as a general statement however: > ( service=parking_aisle | service=parkingaisle) {set > mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} > > This overrules later occuring roads and removes them if they are > semi_connected. And yes in this case overlay lines are supposed to be > removed to in my understanding. > > On Thu, 14 Nov 2019 at 14:19, Gerd Petermann < > gpetermann_muenchen(a)hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> > wrote: > Hi Felix, > > no idea why you would modify to code instead of using option > --min-size-polygon=14, so I agree this is not important. > > I was surprised to find that there is no documentation about > mkgmap:set_unconnected_type. I found a lot of confusing posts about the > expected behaviour, so it's very difficult to guess what it really should > do. With the additional tag mkgmap:set_semi_connected_type it get's even > more complicated. > Since you wrote that the patch worked well for you I think we should just > document what it does. > > The patch was written before option > --add-boundary-nodes-at-admin-boundaries was implemented. > A road with a node on a tile boundary is not removed when > mkgmap:set_unconnected_type=none (or mkgmap:set_semi_connected_type=none) > is found. > I think we can ignore nodes on country borders here (like we do with the > dead-end-check. > > My understanding so far, please improve: > The algorithm first finds out how often a road (one OSM way) is connected > to other roads. If there are zero connections and > mkgmap:set_unconnected_type=none is set, the way is removed (not written > to the map). If there are other (overlaying) lines for the same OSM way and > they also have mkgmap:set_unconnected_type=none they are also removed. > Similar things happen with tag mkgmap:set_semi_connected_type=none for > roads with exactly one connection to another road. > > There is also an option to specify a different type instead of none, e.g. > mkgmap:set_unconnected_type=0x10804. This type must be a non-routable line > type. The effect is that the line is not added as a road with the original > type, instead it is added as normal line with the fiven type when the road > is not connected to other roads. Similar with > mkgmap:set_semi_connected_type=0x10804. > The current patch doesn't care about overlay lines when a replacement type > is given for the road, means, they are neither removed nor changed. Looks > wrong to me. > If I got that right you only use tag values "none" and nobody else uses > this feature, so I'd prefer to remove the type change. In that case it > would be better to also rename the tags, e.g. > mkgmap:remove-unconnected=true and mkgmap:remove_semi_connected=true > > Any thoughts? > > Gerd > > > > > > > ________________________________________ > Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk<mailto: > mkgmap-dev-bounces(a)lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann < > extremecarver(a)gmail.com<mailto:extremecarver@gmail.com>> > Gesendet: Mittwoch, 13. November 2019 19:29 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate > between connected on both sides or on one side only > > Hi Gerd, > Nope that's the only one. Until yesterday I think it worked correctly. I > never really check again in the last 1 year however. And I do not use > --housenumber option so far. It's very useful to filter out private ways > which are not marked access=private - I mainly use it on > highway=footway/path/track and so on (which should not have housenumbers > anyhow). > > (well and what I hardly call a patch - + minSizePolygon = > props.getProperty("min-size-polygon", 14); > value 14 instead of 8. I think 8 is too small in > src/uk/me/parabola/mkgmap/build/MapBuilder.java > > On Wed, 13 Nov 2019 at 19:00, Gerd Petermann < > gpetermann_muenchen(a)hotmail.com<mailto:gpetermann_muenchen@hotmail.com > ><mailto:gpetermann_muenchen@hotmail.com<mailto: > gpetermann_muenchen(a)hotmail.com>>> wrote: > Hi Felix, > > I already wondered where this code has gone. :o > Hard to say if it is still useful. I probably would not want to use it in > combination with option --housenumbers. > I am able to modify the patch. Are there any other patches from me or > others that you use? > > Gerd > > ________________________________________ > Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk<mailto: > mkgmap-dev-bounces(a)lists.mkgmap.org.uk><mailto: > mkgmap-dev-bounces(a)lists.mkgmap.org.uk<mailto: > mkgmap-dev-bounces(a)lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann < > extremecarver(a)gmail.com<mailto:extremecarver@gmail.com><mailto: > extremecarver(a)gmail.com<mailto:extremecarver@gmail.com>>> > Gesendet: Mittwoch, 13. November 2019 17:12 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate > between connected on both sides or on one side only > > Could semi_con-v3.patch so the semi_connected tag be merged to trunk? It > was compatible until now and is of really good use. Unfortunately - it > conflicts with todays mkgmap update. > Sorry I forgot to answer back in 2017 confirming that it worked splendidly. > > Felix > > On Thu, 21 Sep 2017 at 15:02, Felix Hartmann <extremecarver(a)gmail.com > <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: > extremecarver(a)gmail.com>><mailto:extremecarver@gmail.com<mailto: > extremecarver(a)gmail.com><mailto:extremecarver@gmail.com<mailto: > extremecarver(a)gmail.com>>>> wrote: > Thanks for v3 - on a quick tryrout it works well now. I have not found > time (and won't until Tuesday next week) to give it a full check. > (and yes - I'm right now only using "none"). > > On 21 September 2017 at 11:56, Gerd Petermann < > GPetermann_muenchen(a)hotmail.com<mailto:GPetermann_muenchen@hotmail.com > ><mailto:GPetermann_muenchen@hotmail.com<mailto: > GPetermann_muenchen(a)hotmail.com>><mailto:GPetermann_muenchen@hotmail.com > <mailto:GPetermann_muenchen@hotmail.com><mailto: > GPetermann_muenchen(a)hotmail.com<mailto:GPetermann_muenchen@hotmail.com>>>> > wrote: > Hi Felix, > > sorry, did not search for a solution for my example, what I wanted to > point out is that the algo may produce unexpected results whenever the > style adds multiple lines for one way with conflicting > mkgmap:set_semi_connected_type values. > > In your style you can probably only use value "none". I wonder if anybody > uses the variant with a value that gives a different type. > > Gerd > > > ________________________________________ > Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk<mailto: > mkgmap-dev-bounces(a)lists.mkgmap.org.uk><mailto: > mkgmap-dev-bounces(a)lists.mkgmap.org.uk<mailto: > mkgmap-dev-bounces(a)lists.mkgmap.org.uk>><mailto: > mkgmap-dev-bounces(a)lists.mkgmap.org.uk<mailto: > mkgmap-dev-bounces(a)lists.mkgmap.org.uk><mailto: > mkgmap-dev-bounces(a)lists.mkgmap.org.uk<mailto: > mkgmap-dev-bounces(a)lists.mkgmap.org.uk>>>> im Auftrag von Felix Hartmann < > extremecarver(a)gmail.com<mailto:extremecarver@gmail.com><mailto: > extremecarver(a)gmail.com<mailto:extremecarver@gmail.com>><mailto: > extremecarver(a)gmail.com<mailto:extremecarver@gmail.com><mailto: > extremecarver(a)gmail.com<mailto:extremecarver@gmail.com>>>> > Gesendet: Donnerstag, 21. September 2017 11:16 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate > between connected on both sides or on one side only > > As for your example - yes I guess only changing first occurence to 0x* - > further occurences to none makes most sense. In general I think such a rule > should not be used. > > So good practice would be either: > highway=service & service=driveway {set > mkgmap:set_semi_connected_type=none} > highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue] > highway=service & oneway=yes [0x10106 resolution 24] > > or > highway=service & service=driveway {set > mkgmap:set_semi_connected_type=0x10806} [0x07 road_class=0 road_speed=2 > resolution 22 continue] > highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue] > highway=service & oneway=yes [0x10106 resolution 24] > > or > highway=service & service=driveway {set > mkgmap:set_semi_connected_type=0x10806} > highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue] > highway=service & service=driveway {set > mkgmap:set_semi_connected_type=0x10806} > highway=service & oneway=yes [0x10106 resolution 24] > > but not your example and also not: > highway=service & service=driveway {set > mkgmap:set_semi_connected_type=0x10806} [0x07 road_class=0 road_speed=2 > resolution 22 continue with_actions] > highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue] > highway=service & oneway=yes [0x10106 resolution 24] > > > > On 21 September 2017 at 11:10, Felix Hartmann <extremecarver(a)gmail.com > <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: > extremecarver(a)gmail.com>><mailto:extremecarver@gmail.com<mailto: > extremecarver(a)gmail.com><mailto:extremecarver@gmail.com<mailto: > extremecarver(a)gmail.com>>><mailto:extremecarver@gmail.com<mailto: > extremecarver(a)gmail.com><mailto:extremecarver@gmail.com<mailto: > extremecarver(a)gmail.com>><mailto:extremecarver@gmail.com<mailto: > extremecarver(a)gmail.com><mailto:extremecarver@gmail.com<mailto: > extremecarver(a)gmail.com>>>>> wrote: > Somthing seems to be wrong with the patch: > > java.lang.NullPointerException > at > uk.me.parabola.mkgmap.osmstyle.StyledConverter.findUnconnectedRoads(StyledConverter.java:1970) > at > uk.me.parabola.mkgmap.osmstyle.StyledConverter.end(StyledConverter.java:605) > at > uk.me.parabola.mkgmap.reader.osm.ElementSaver.convert(ElementSaver.java:243) > at > uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:157) > at > uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:154) > at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:52) > at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:263) > at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:259) > at java.util.concurrent.FutureTask.run(Unknown Source) > at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown > Source) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown > Source) > at java.lang.Thread.run(Unknown Source) > Could Not Find C:\OpenMTBMap\maps\ovm_6431*.img > > On 19 September 2017 at 15:53, Gerd Petermann < > gpetermann_muenchen(a)hotmail.com<mailto:gpetermann_muenchen@hotmail.com > ><mailto:gpetermann_muenchen@hotmail.com<mailto: > gpetermann_muenchen(a)hotmail.com>><mailto:gpetermann_muenchen@hotmail.com > <mailto:gpetermann_muenchen@hotmail.com><mailto: > gpetermann_muenchen(a)hotmail.com<mailto:gpetermann_muenchen@hotmail.com > >>><mailto:gpetermann_muenchen@hotmail.com<mailto: > gpetermann_muenchen(a)hotmail.com><mailto:gpetermann_muenchen@hotmail.com > <mailto:gpetermann_muenchen@hotmail.com>><mailto: > gpetermann_muenchen(a)hotmail.com<mailto:gpetermann_muenchen@hotmail.com > ><mailto:gpetermann_muenchen@hotmail.com<mailto: > gpetermann_muenchen(a)hotmail.com>>>>> wrote: > Attached is v2 of the patch. It implements the removal of overlay lines > when > mkgmap:set_unconnected_type=none or mkgmap:set_semi_connected_type=none was > found. > > I am still not sure what should be done if the tag has a value that gives > another type instead of none. > Assume your style uses > highway=service & service=driveway {set > mkgmap:set_semi_connected_type=0x10806} > highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue] > highway=service & oneway=yes [0x10106 resolution 24] > > What would you expect for a semi connected way? > We have 2 lines, the first is changed from 0x07 to 0x10806. It would not > make much sense to change also the 2nd from 0x10106 to 0x10806. > So, for now only the value none has an effect for the overlay line(s). > > semi_con-v2.patch > <http://gis.19327.n8.nabble.com/file/t318326/semi_con-v2.patch> > > Gerd > > > Felix Hartmann-2 wrote > > That sounds good > > > > On Sep 19, 2017 11:23 AM, "Gerd Petermann" < > > > gpetermann_muenchen@ > > > > > > wrote: > > > >> Hi Felix, > >> > >> Felix Hartmann-2 wrote > >> > Well I would like it to apply to non routable lines too - if continue > >> > with_actions is used - basically just treat routable and non routable > >> > lines > >> > the same (the initial check should only look at routable lines though > I > >> > guess). > >> > >> OK, I think I can change the code so that it stores the information > >> whether > >> or not a road > >> is connected (or "semi-connected") once for each OSM way that is at > least > >> added once as a road. > >> In a further step mkgmap would check each line for the existence of the > >> mkgmap:set_unconnected_type tag and check if the corresponding OSM way > is > >> connected or not. > > > > > > -- > Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html > _______________________________________________ > 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(a)lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk > <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: > mkgmap-dev(a)lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk > >>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: > mkgmap-dev(a)lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk > <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: > mkgmap-dev(a)lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk > ><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: > mkgmap-dev(a)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 > _______________________________________________ > 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(a)lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk > <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: > mkgmap-dev(a)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 > > > -- > 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 > -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich

2 2

Commit r4372: - Correct and document handling of internal tag mkgmap:set_unconnected_type so that it works with overlay lines
by svn commit 15 Nov '19

15 Nov '19

Version mkgmap-r4372 was committed by gerd on Fri, 15 Nov 2019 - Correct and document handling of internal tag mkgmap:set_unconnected_type so that it works with overlay lines when the road is not removed with mkgmap:set_unconnected_type=none - Add new tag mkgmap:set_semi_connected_type which works similar but matches only when the road has exactly one connection to any other road. Based on semi_con-v3.patch from September 2017 http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4372

1 0

Commit r4371: Catch invalid value for option mapname (-n) like --mapname=Zambia
by svn commit 15 Nov '19

15 Nov '19

Version mkgmap-r4371 was committed by gerd on Fri, 15 Nov 2019 Catch invalid value for option mapname (-n) like --mapname=Zambia Although the option name is mapname we expect the mapid here, an 8-digit number like 63240001 http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4371

1 0

Error Cannot calculate mapid for xxx.txt
by Dave 15 Nov '19

15 Nov '19

Hi, Since release 4336 I have been getting 'Cannot calculate mapid for xxx.txt ' error while running Mkgmap, with xxx.txt being the path and name of my typ file which was created some time ago with TYPWiz 3 and has not been edited recently. I do not have this problem with release 4323. After some investigation I realised Mkgmap was treating the txt file as an input file and not attempting to compile it as a typ file. I found by changing the order of my command options and placing the --output-dir option followed by the txt file near the beginning before the -gmapsupp option it would compile the typ file. This order did not seem to matter before. I thought I would just let you know. Rgds, Dave

3 3