- mkgmap-dev - The mkgmap lists

Re: [mkgmap-dev] new branch low-res-opt to test improvements for filters
by Thomas Morgenstern 05 May '21

05 May '21

Hi all, I see this completly different : many people use osm data for routing. Routing is the main purpose for using OSM. If routing [ /quote] : //it will look a bit strange [end quote] /is not akzeptable. Thomas Quote :............. So yes with very high DP values and lots of simplification if you plan a car route over highways, at some point it will look a bit strange. But again, very few people use Garmin maps for car routing nowadays, and even less car routing based on OSM data. ...... On Wed, 5 May 2021 at 14:29, Gerd Petermann <gpetermann_muenchen(a)hotmail.com <mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix, I don't think that it only depends on the typ file. Programs like GpsMapEdit also show wrong merges. Reg. roads: Seems RoadMerger also doesn't reverse points, I didn't notice that before. So, I have two methods to improve. It's quite difficult to understand the effects because we - merge roads with equal attributes - possibly split those roads again to avoid loops or too long roads or too complex roads (too many connections) or other limits in IMG format (this is needed for routable maps, maybe not for others) - possibly merge again at levels > 0 I have to think about this again. Maybe there is no problem with the NET file changes when this last step is done. The NET file contains "pointers" to the RGN file for each level in which the road is rendered. So, if a road is rendered at level 1 the data in NET allows to show all the road labels. Maybe that's all and there is no further effect (esp. not on routing), but maybe the info is also used when you create route in Basecamp. I guess it's not. I have no idea what Garmin software does when a road has pointers to lines at levels 0, 1, and 3 but not at level 2. I found no such case in Garmin demo maps. I think that could happen when I don't add code to prevent it. Probably it doesn't matter much when RoadMerger is allowed to reverse so that we have fewer parts which could be merged later. Gerd

7 8

new branch low-res-opt to test improvements for filters
by Gerd Petermann 05 May '21

05 May '21

Hi all, as a result of the thread about raster problems I've started this new branch. First commit implements experimental options to specify values for --reducePointError and --reducePointErrorPolygon for each resolution Options are --simplify-filter-line-errors as replacement for --reducePointError and --simplify-filter-polygon-errors as replacement for --reducePointErrorPolygon. If --simplify-filter-line-errors is given and ----simplify-filter-polygon-errors is not given the values for lines are also used for polygons. Meaning is similar to the --polygon-size-limits option, values are given in pairs <resolution,reduce-value> Note that in resolution 24 the filter is not used. Sample usage: --x-simplify-filter-line-errors=23:1.3,22:2.6,20:4,18:6 --x-simplify-filter-polygon-errors=23:1.3,22:2.6,20:4 The old options are still supported, --reducePointErrorPolygon=1.3 is treated like --x-simplify-filter-line-errors=23:1.3 If none of the options is used the default is 2.6 for all resolutions. There are a few more things to change: - simplify4.patch with special code to improve rendering of contour lines - more-merge.patch to allow merging of roads at level > 0 - Line merger could merge more lines if direction of the lines doesn't matter - maybe I find a way to merge dual-carriage ways into one line (again, if direction doesn't matter) - the --housenumber option should probably not assign numbers to trunk roads (similar to motorways), this can add lables to these roads and thus prohibit merging. None of these changes should change routing results. They can reduce img size and improve rendering. Gerd

4 9

new branch low-res-opt to test improvements for filters
by Thomas Morgenstern 05 May '21

05 May '21

before misanderstandings arise, maybee you can post here screenshot's ? by carrouting I mostly use 300 m details in cities. By using this resolution, the map should very accurat, not simplified. By very long travels 3 km details. Using 3 km, the map can bee simplified. I don't know, how this is correspondending to Levels/resolution. Can you post screenshot's #old style# vs #simplified style' ?. thomas [quote] Hi Karl, But even then you will never use the overview map. What resolution are you actually using on your device if routing on a highway? I guess 19 or 20... The thing is simply with high DP filter value that you can see the highway pretty straight, but as the route itself is not simplifed that much in Basecamp. The route will not be 1:1 visually of the map. But still very easy to see the the underlying highway. if you plan a route from Berlin to Mardrid, then zoom out and see the whole route - then it's not so beautiful anymore. But can any mkgmap created map actually route from Berlin to Madrid without via points? It's a long time that I looked at mgkmap created maps for car routing and some years ago this was not possible.[/qoute]

2 1

Please try branch check-precomp-sea
by Gerd Petermann 04 May '21

04 May '21

Hi all, I've implemented some basic checks to detect large flooded areas in the precomp-sea data in this new branch. A link to the latest binary (r4579 as of now) is a the bottom of the normal download page : http://www.mkgmap.org.uk/download/mkgmap.html - If PrecompSeaGenerator is used to calculate the sea data and the index check fails a warning is printed and the program ends with rc -1. - If mkgmap is used with a "dubious" sea.zip one or more messages about the problematic areas are written and the program stops with an ExitException unless option --x-check-precomp-sea=0 is given before the first input file. The index test is normally performed once for the whole planet, so it doesn't care about the actual tile boundaries. If e.g. only a part of Australia is flooded and you create a map for the UK you'll still see the errors. BTW: The current code (also in trunk version) doesn't support to use --precomp-sea with different values. Results are rather unpredictable. Gerd

4 4

Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution 23 raster problems
by Felix Hartmann 04 May '21

04 May '21

Well yes in that case they must. However for overhanging rocks the hgt files are incompatible. All sources we use for phyghtmap or srt2osm or other tools rely on 2D models to show the altitude. So for what we have right now - contourlines shall never cross. On Mon, 26 Apr 2021 at 18:22, Thomas Morgenstern <webmaster(a)img2ms.de> wrote: > I think , your wish, never cross contourlines, shows not the reality. In > fact there are some rocks, cliffs with 90 ° declination. For exampel: the > cliffs near Los Gigantes (tenerife) and the Baranco del Inferno > (tenerife) . In such situations, the contourlines must touch each other. > And how to procede, if the rocks hang over ? Contourlines must cross !? > thomas > > Am 26.04.2021 um 11:02 schrieb Felix Hartmann: > > I'm not fully sure of the exact location anymore - not too far away > from N47° 31.285' E12° 55.889' however. And using Basecamp map details at > lowest (this will allow you to see the problems much easier). > > On Mon, 26 Apr 2021 at 16:40, Thomas Morgenstern <webmaster(a)img2ms.de> > wrote: > >> @ Felix : please, can you post coordinates of your screenshots ?. i will >> look at my own contourlines at this position. >> thomas >> >> Am 26.04.2021 um 10:15 schrieb Felix Hartmann: >> >> yes - for contourlines it would be great if the algo could check that >> lines never cross - and if moving one direction vs the other means not >> touching vs touching - then move the other direction. So it would need to >> loop at for each line, at the next 2 lines. The big advantage would be for >> contourlines only maps (which makes most sense IMHO, as you don't need to >> update contourlines except if there is newer better data which is rare) >> that you can create them with resolution 23 as highest resolution >> instead of 24. Saving about 50% of the space. Old Garmin devices scroll >> notably slower with resolution 24 contourlines vs 23, even more of course >> if 10m equidistance instead of 20m equidistance is used. >> >> As 0x20, 0x21 and 0x22 are always contourlines - those lines could easily >> be distinguished (there is one second set of contour line types in newer >> garmin maps, I don't know if that matters, and cant remember the types >> right now). If this treatment is a lot slower - then it should have a >> command option, so whoever integrates the contourlines has the choice of >> chosing it. Because for separate contourlines even doubling or >> tripling compilation times do not matter much. >> >> On Mon, 26 Apr 2021 at 15:45, Gerd Petermann < >> gpetermann_muenchen(a)hotmail.com> wrote: >> >>> Hi all, >>> >>> the major problem with resolution 23 and lower is the rounding to garmin >>> units without looking at the distortions (WrongAngleFixer does that for res >>> 24) >>> >>> At res 23 we have to draw the lines using a "bed of nails" where the >>> nails have ~5m distance to each other. If the original line "meanders" >>> horizontally close to the nails there is no big problem, nodes are probably >>> rounded to a straight line. If the same line is moved by ~2.5 m up or down >>> we often hit the worst case scenario where one node is rounded to the north >>> and the next is rounded to the south. This produces visible zig-zagging. >>> If two or more almost parallel lines meat this worst case you see the >>> obvious errros where contour lines overlap. >>> >>> The logic in WrongAngleFixer tries to detect this and sometimes decides >>> to round to a different place to reduce zig-zagging. The problem is that >>> this has to be done looking at all lines, not just one, at least with >>> normal OSM data where we have intersections. >>> >>> For contourlines it would be best if the generator would only calculate >>> nodes which are exactly at the positions of the Garmin nails, but that is >>> probaby not easy. >>> The special case here is that it doesn't really matter where the nodes >>> are, we just need "good looking" lines and that each node is only used by >>> one contour way. >>> >>> Maybe it is possible to do this with a separate program or a special >>> method in mkgmap which just treats contour lines >>> - take generated contour data as input >>> - rerender each way with resolution 23 nodes so that the line looks >>> almost like before. This means it may add nodes somewhere and remove others. >>> - maybe re-iterate if the rerendering caused overlapping contour lines >>> where original lines where not overlapping >>> >>> Gerd >>> >>> >>> >>> ________________________________________ >>> Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk> im Auftrag von >>> Felix Hartmann <extremecarver(a)gmail.com> >>> Gesendet: Montag, 26. April 2021 08:55 >>> An: Development list for mkgmap >>> Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 >>> Resolution 23 raster problems >>> >>> Thanks Andrzej for the patch. >>> It produces better results in about 2/3 of cases, and worse in about 1/3 >>> of cases for resolution 23. So overall it's an improvement, and at least >>> for compiling contourlines I didn't notice a significant difference in >>> compile time. I could test this more in detail also against normal map data >>> if needed... >>> Using --simplifyContoursEpsilon= in phyghtmap helps a bit too, >>> especially for resolution 24. However it runs super slow. It's like 1-30 >>> times as much time, if not more (except for a value of 0.0 which is not >>> changing the maps at all, and just making the .pbf file 10% smaller). >>> >>> This doesn't solve phyghtmap not using b-spline interpolation. That >>> would improve even more (at least up to resolution 23, for resolution 22 >>> maybe this patch matters more). In general if using 20m equidistance I feel >>> in most cases it's good enough to compile contourlines only starting from >>> resolution 23, much faster, less data just of course in very steep areas >>> problematic. For 10m equidistance however it kinda means also going for >>> resolution 24, else the improvement from 20m to 10m is more of a nuisance. >>> >>> On Mon, 26 Apr 2021 at 03:41, Andrzej Popowski <popej(a)poczta.onet.pl >>> <mailto:popej@poczta.onet.pl>> wrote: >>> Hi Gerd, >>> >>> I don't observe any significant differences in compilation. But to make >>> it more optimized, we can put SizeFilter before DouglasPeuckerFilter. I >>> have attached a second patch here. >>> >>> There is a difference in results. See pictures with DouglasPeuckerFilter >>> after RoundCoordsFilter and new version with DouglasPeuckerFilter >>> before. This is for 22-bit resolution, so effects are probably more >>> clear. >>> >>> -- >>> Best regards, >>> Andrzej >>> >>> _______________________________________________ >>> mkgmap-dev mailing list >>> mkgmap-dev(a)lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> >>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >>> >>> >>> -- >>> Felix Hartman - Openmtbmap.org & VeloMap.org >>> >>> _______________________________________________ >>> mkgmap-dev mailing list >>> mkgmap-dev(a)lists.mkgmap.org.uk >>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >>> >> >> >> -- >> Felix Hartman - Openmtbmap.org & VeloMap.org >> >> >> >> _______________________________________________ >> mkgmap-dev mailing listmkgmap-dev@lists.mkgmap.org.ukhttps://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> >> >> > > -- > Felix Hartman - Openmtbmap.org & VeloMap.org > > > -- Felix Hartman - Openmtbmap.org & VeloMap.org

3 33

Commit r4693: apply linkPOI.patch (improve --link-pois-to-ways option and reporting)
by svn commit 04 May '21

04 May '21

Version mkgmap-r4693 was committed by gerd on Tue, 04 May 2021 apply linkPOI.patch (improve --link-pois-to-ways option and reporting) - introduce extra HashMap to improve the code which identifies the CoordNode that is related to the CoordPOI so that it doesn't have to guess using the position of points, removes the "found multiple points with equal coord as CoordPOI at ..." messages - add the string "link-pois-to-ways:" to messages which are related to that option - implement and use copy constructor for CoordPOI http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4693

1 0

found multiple points with equal coord.....
by Thomas Morgenstern 04 May '21

04 May '21

Hi , yesterday mkgmap r4587 gives me following message : 'found multiple points with equal coord as CoordPOI at 56.835467 37.404949....... The map seems okay. What shell I do with this message ?. Is this meassage only a hint for incorrect data ? Or what else ? thomas

3 6

Commit r4689: merge the check-precomp-sea branch to do some basic plausibilty tests on precompiled sea data.
by svn commit 02 May '21

02 May '21

Version mkgmap-r4689 was committed by gerd on Sun, 02 May 2021 merge the check-precomp-sea branch to do some basic plausibilty tests on precompiled sea data. The new file sea-check.txt contains characters s (sea), m(mixed), and l(land). Each character represents one entry in the index file that comes with precompiled sea (sea.zip) with the expected result. Tiles near the coastline have m. - If PrecompSeaGenerator is used to calculate the sea data and the index check fails a warning is printed and the program ends with rc -1. - If mkgmap is used with a "dubious" sea.zip one or more messages about the problematic areas are written and the program stops with an ExitException unless option --x-check-precomp-sea=0 is given before the first input file. The index test is normally performed once for the whole planet, so it doesn't care about the actual tile boundaries. If e.g. only a part of Australia is flooded and you create a map for the UK you'll still see the errors. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4689

1 0

Request - set --reduce-point-density= for each resolution
by Felix Hartmann 01 May '21

01 May '21

As I'm not sure everyone is following the other topic, I would like to ask to introduce the possibility to set different values for the DP filter based on resolution. Why is this important? a) maps which are produced with resolution 23 as highest resolution need to have a much lower level than subsequent resolutions. b) For resolution 23 and 22 a lower level makes sense - it is not needed as much here to speed up the gps device map drawing speed, while for lower resolutions like 18-21 a high level is really needed else map panning becomes painfully slow (usually basemap kicks in at 17). If I'm correct right now 2.6 at resolution 23 would be 5.4 at resolution 22, 10.8 at resolution 21 and so on. It's okay to keep that behaviour - but the value doubled just needs to be possible to be set for each resolution. It doesn't matter to me if we keep it like that or if we change the numbers than ourselves by resolution. Important thing is that it's possible to be set for each resolution c) maybe also introduce the possibility to set DP for resolution 24. I think a value of 0.3-0.6 could be worth it. I'm not sure if there were some problems preventing DP to be used at 24. However as by now I think mkgmap is able to produce routable maps starting at 23 instead of 24, those problems should be fixed... In general I think a map made for automotive use (car, motorcycle) would be fine using resolution 23 as a start instead of 24. Like Garmin City Navigator maps do. But then yes it's really important to not have a high DP value on resolution 23. Same as contourlines only maps which make sense at resolution 23 instead of 24. -- Felix Hartman - Openmtbmap.org & VeloMap.org

2 8

tile takes very long time to generate
by 7770 29 Apr '21

29 Apr '21

Hi. I observe a situation that one of the very first tiles (often the first or the third) that mkgmap generates takes 20 - 30 minutes to generate, wheres the others take about 30 seconds each. The map data produced by splitter is a total of around 700 files with splitter option --max-nodes=1275000. sea and bouds are used for mkgmap. At first i thought i am running low on memory but changing to max-jobs=1 (instead of the possible max of 2) did not make any change. Is mkgmap doing something specific in the beginning that can explain this long time generating one of the very first tiles? I can provide more details, let me know how i can best collect those details in case i need to set some parameters to have mkgmap to say more about what it is doing. Regards Karl

6 40