- mkgmap-dev - The mkgmap lists

Question about ovm-work-files
by Carlos Dávila 22 Nov '16

22 Nov '16

mkgmap keeps ovm files unless --remove-ovm-work-files=true is specified. What are these files useful for once overview map is created? Can they be reused afterwards, for example if you create two or more img from the same input tiles or if you combine previously created img in a later step?

3 3

txt to typ with mkgmap
by Arndt Röhrig 21 Nov '16

21 Nov '16

4 4

splitter r440 released
by Gerd Petermann 17 Nov '16

17 Nov '16

Hi all, I've fixed a major bug in splitter which results in wrong output files when you pass a --split-file which contains overlapping areas. See also http://www.mkgmap.org.uk/websvn/revision.php?repname=splitter&rev=440 Splitter doesn't generate such a file, but one can create such a file in an editor (intended or accidentially) I am not sure what happens when you create a gmapsupp with overlapping tiles, I'd expect problems with routing at the tile boundaries. So, I think splitter should stop when overlaps between tiles with the same mapid prefix are found, e.g. overlapping tiles 63240010 and 63240013 are not allowed, while overlapping tiles 12340001 and 43210001 would be considered okay. I've not yet implemented this test, what do you think about it? Gerd -- View this message in context: http://gis.19327.n8.nabble.com/splitter-r440-released-tp5885986.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

5 6

mkgmap:drawLevel and --order-by-decreasing-area
by Ticker Berkin 17 Nov '16

17 Nov '16

Here is a patch that implements mkgmap:drawLevel It is used in conjunction with --order-by-decreasing-area and overrides the natural polygon area that is used for output sorting, hence influencing which polygons are rendered over others. The higher the value, the later the polygon is written and hence should show over other areas. Values range from 1 to 100, 1..50 will be larger than any natural area and so output earlier. 51..100 will be smaller and written later. So, if you wanted the standard sea polygons to show, rather than any mapped area beyond the coastline, could have: natural=sea { add mkgmap:skipSizeFilter=true; set mkgmap:drawLevel=99 } [0x32 resolution 10] The default for sea is drawLevel=2 (drawLevel 1 might be needed for the map background / 0x4b). Nothing else has a default and so behaves as if between 50 and 51. The Garmin device will still respect any in-build or TYP specified _draworder. With --order-by-decreasing-area it works best if everything has the same _draworder. If your Garmin device has strange rules, like not showing City (0x01..0x03) or having green areas (0x14..0x21) at a lower _draworder than most other things, consider a TYP file giving 0x01..0x55 the same value (1) except 0x4b with a lower value (0). Ticker

4 7

Buildings in default style
by Jakob Mühldorfer 17 Nov '16

17 Nov '16

Hi, another question about the default style. Some buildings are not converted properly, because they are "caught" by other conversions first. For example a large supermarket building (like this one <https://www.openstreetmap.org/way/322291694>) is dealt with here https://github.com/openstreetmap/mkgmap/blob/master/resources/styles/defaul… And never to be seen again. Would it make sense to insert a > building=* & area!=no [0x13 resolution 24 continue] To the very beginning of the polygon file, so everything that is a building is rendered as building? Or does this have odd side-effects when something like a indoor building pitch is given two types? Regards Jakob

2 1

Warn when using invalid resolution in styles
by Jakob Mühldorfer 16 Nov '16

16 Nov '16

Hi, I just had a typo in a style using resolution "25" instead of "24". Turns out mkgmap silently drops objects appearing at invalid resolution without any warning. The "--check-styles" option also does not catch it. Maybe you could implement some kind of warning when invalid resolutions are used. Regards Jakob

2 1

Commit r3703: Improve style checks to detect resolution values > 24
by svn commit 16 Nov '16

16 Nov '16

Version mkgmap-r3703 was committed by gerd on Wed, 16 Nov 2016 Improve style checks to detect resolution values > 24 http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3703

1 0

Commit r3702: sortAreas_v5.patch: Add option --order-by-decreasing-area
by svn commit 14 Nov '16

14 Nov '16

Version mkgmap-r3702 was committed by gerd on Fri, 11 Nov 2016 sortAreas_v5.patch: Add option --order-by-decreasing-area Patch by Ticker Berkin, slightly modifed http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3702

9 14

Re: [mkgmap-dev] patch to write polygons in decreasing order
by Ticker Berkin 11 Nov '16

11 Nov '16

Hi Gerd My device shows buildings as very slightly paler than the pale background and so it is difficult to see them anyway, but I can't see any difference between with and without --order-by-decreasing-area. Is the change you are seeing relating them having an outline, and this has changed from 1 aggregate outline to an outline per defined building. The reason for the change in ShapeMergeFilter is to stop it combining areas that came from different OSM objects - it is only allowed to re -join objects that got split to expose holes in multi-polygon processing or were split because they had too many points to go into a subDivision. The rationale for this is that if two or more overlapping areas straddle a subdivision boundaries, they must be output in the same relative order in each subdivision, otherwise different areas could show 'on top' on each side of the boundary line. At the subdivision processing stage, merging areas unrelated except by typeCode would make this output ordering impossible. I was considering ShapeMergeFilter to be a pure map-space optimisation. If the difference you are seeing is related to area outlines, this has grave implication not just on what I'm trying to do, but also on the way mkgmap might chop up any polygon. Ticker On Thu, 2016-11-10 at 13:39 +0000, Gerd Petermann wrote: > Hi Ticker, > > I still don’t understand the change in ShapeMergeFilter. One of the > nice effects of this filter is that it > merges buildings or forests with the same attributes. > I would assume that this is still a good idea, but you have to > maintain the fullArea value. > Use the attached input file and compare the shapes of the buildings. > > Gerd > > Von: Ticker Berkin > Gesendet: Donnerstag, 10. November 2016 13:35 > An: Gerd Petermann > Betreff: Re: AW: [mkgmap-dev] patch to write polygons in decreasing > order > > Hi Gerd > > I hope this version of the patch will fix all the issues you have > raised with the previous ones except performance. > > Regards > Ticker Berkin > > On Tue, 2016-11-08 at 16:51 +0000, Gerd Petermann wrote: > > Reg. PrepShapesForMerge: This was only used for the overview map, > so > > Coord.equals() is the best we can get > > for that. I see no problems when you change it to use more precise > > values. > > Reg. Performance: Yes, no problem for now. > > Reg. mkgmap:skipSizeFilter: It is used to make sure that even small > > pieces are written to the map (to avoid white triangles in the > sea). > > I now think that it makes sense to keep that separate from the size > > calculation. > > > > Gerd > > > > Von: Ticker Berkin > > Gesendet: Dienstag, 8. November 2016 15:48 > > An: mkgmap-dev(a)lists.mkgmap.org.uk > > Betreff: Re: [mkgmap-dev] patch to write polygons in decreasing > order > > > > Hi Gerd > > > > 1/ > > I hadn't discovered 'ant test' - Sorry. I'll fix > > ShapeMergeFilterTest. > > > > 2/ > > To see what is happening with ShapeMergeFilter not doing anything I > > tried fixing all the equal coordinates to be identical simply by > > calling prepShapesForMerge() just before invoking ShapeMergeFilter > > each > > time. > > > > This gave some very strange behaviour - I was getting lots of: > > > > SEVE: uk.me.parabola.mkgmap.filters.ShapeMergeFilter > > mapHants/74210002.osm.pbf: ignoring shape with id 350798212 and > type > > 0x50 at resolution 24, it has 4 points and has an empty area > > > > which I fixed it by changing prepShapesForMerge() to be more like > the > > equivalent in PolygonSplitter, ie using > > it.unimi.dsi.fastutil.longs.Long2ObjectOpenHashMap<Coord> rather > than > > HashMap<Coord,Coord> > > > > Looking at Coord.hashCode() - I presume this is what the > > hashMap<Coord> > > version uses - it doesn't seem adequate to make a unique hash, so > > causing incorrect Coord instances to be plugged back into the > shape. > > I'm surprised this hasn't caused other problems. > > > > I then get a reasonable amount of shapeMerging and the img size is > > reduced slightly, but a bit bigger than the release code; I'd > expect > > this. > > > > 3/ > > The run-time also increases as expected; Can we live with this > > until it can be improved with more efficient clipping? > > > > 4/ > > Setting fullArea of all the Sea polygons is necessary for 2 > reasons: > > 1/ shapeMergeFilter won't merge shapes with different fullArea. > > 2/ it needs to be sorted/output in a consistent order with respect > to > > other shapes that might also straddle subDivisions. > > > > Setting to a large value means that, providing _draworder is the > same > > for everything, tidal areas like beaches, mud-flats etc will show > > rather than sea. It could be set to a low value instead, so that > the > > sea overwrites the inter-tidal areas. This achieves the default > look > > of > > a map on my garmin device but without relying on the inbuilt > > _draworder > > or having TYP _draworder higher for sea. > > > > I was thinking this could be made into an option or a mkgmap: tag > so > > that, for systems without TYP / _draworder, there is a way of > > flipping > > the behaviour. Maybe even a value that looks like a layer-number > > could > > be specified, giving the functionality requested by Jürgen < > > rheinskipper1000(a)gmx.de> > > > > The rationale for mkgmap:skipSizeFilter being applied to sea is > > related > > to setting sea polygons to have a large area - the sea shouldn't be > > lots of distinct polygons, just 1 big, very complicated one. > > > > Ticker > > > > On Sat, 2016-11-05 at 01:13 -0700, Gerd Petermann wrote: > > > Hi Ticker, > > > > > > I've started to run some tests. No crash until now. A few remarks > > so > > > far: > > > 1) please use ant test before producing patches. This will show > you > > > that > > > ShapeMergeFilterTest needs changes. > > > 2) You already mentioned that ShapeMergeFilter doesn't work as > you > > > would > > > expect. I think the reason is that the splitIntoAreas() method > > > replaces the > > > original Coord instances. This will produce pairs of different > > > Coord instances which are "highPrecEqual" (and may not have the > > same > > > flags > > > set). > > > The code in PolygonClipper tries to avoid this problem. The > > > ShapeMergeFilter > > > will only merge shapes which have identical Coord instances. > > > > > > Alternative would be to implement a clipper which doesn't need > > > area.intersect(). I've once coded the "Sutherland-Hodgman > > algorithm" > > > but > > > didn't use it yet as it failed with special cases like self > > > -intersecting > > > ways or concave shapes producing spikes, but I still think this > > would > > > be a > > > great improvement. See attached (out-aged) patch and the wiki > > > > https://en.wikipedia.org/wiki/Sutherland%E2%80%93Hodgman_algorithm > > > for further details. > > > > > > 3) With my test set of 10 tiles run time is much higher (r3701: > 112 > > > s, > > > patched : 164 s) > > > and img sizes are a bit higher (40 MB / 42MB) . > > > > > > 4) Reg. fullArea : I agree that AreaSizeFunction should return > the > > > value for > > > the complete multipolygon > > > but I don't yet understand the special treatment in SeaGenerator. > > If > > > I got > > > that right you try to make sure that all sea polygons are written > > > before > > > others, no matter how large they are? > > > This seems to duplicate the code for mkgmap:skipSizeFilter which > is > > > also a > > > bit dirty. Maybe > > > > > > I fully agree that the current data flow for shapes is not good, > so > > > also the > > > item "rewrite classes that hold information about map objects, > esp. > > > shapes" > > > in the to-do list. > > > > > > Gerd > > > > > > mp_suth_hodg.patch > > > < > http://gis.19327.n8.nabble.com/file/n5885381/mp_suth_hodg.patch> ; > > ;; > > > > > > Ticker Berkin wrote > > > > Hi Gerd > > > > > > > > I've fixed it and the test case now runs. I've also > incorporated > > > > your 3 > > > > other points. > > > > > > > > I've added the following comment to mkgmap/build/MapArea.java > > > > > > > > /* > > > > Failed to split! > > > > > > > > This happens easily when doing low resolution overview > > > > levels (have a high shift value) and we are insisting that > areas > > > > can only be split on boundaries that can be represented exactly > > > > with the relevant shift for the level. All the lines/shapes > that > > > > need to be put at this level are here, but represented at the > > > > highest resolution without any filtering relevant to the > > > > resolution. In the end it tries to split a single pixel > because > > > > it contains, say, 100s of bits of Sea and Coastline with > complex > > > > shapes which it thinks is too much data for a subDivision, but > > > > actually will mostly disappear when we come to write it. And > it > > > > will look meaningless - the lines/shapes should have been > > > > simplified much earlier in the process, then they could appear > as > > > > such in reasonably size subDivision. > > > > > > > > The logic of levels, lines and shape placement, simplification, > > > > filtering and splitting, subDivision splitting etc needs a > > > > re-think and re-organisation. > > > > */ > > > > > > > > I could try and explain this more fully in another thread and > > maybe > > > > it > > > > should go on the enhancement list > > > > > > > > Regards > > > > Ticker > > > > > > > > > > > > On Sat, 2016-10-22 at 14:00 +0100, Ticker Berkin wrote: > > > > > Hi Gerd > > > > > > > > > > I've reproduced the crash. > > > > > > > > > > I think the problem is that area.getEstimatedSizes() (called > > from > > > > > MapSplitter.addAreasToList) doesn't reflects what will go > into > > > > > the > > > > > area > > > > > when the option is in effect and so addAreasToList might keep > > > > > recursing. > > > > > > > > > > I need to think about this more deeply. There is a related > > issue > > > > > where > > > > > complex shapes are split earlier when there probably is no > need > > > > > because > > > > > they will be split later to scattered into lots of > > subDivisions. > > > > > > > > > > Concerning the other problems: > > > > > > > > > > It wasn't dead code - rather a function with side effects - > > I'll > > > > > re > > > > > -code it. > > > > > > > > > > Sorry about Long vs long. > > > > > > > > > > I notice ShapeMergeFilterTest in the patch. I experimented a > > bit > > > > > with > > > > > mergeShapes and was surprised it wasn't doing a bit of > merging > > > > > when > > > > > my > > > > > option was in effect - I was expecting it join bits of the > > > > > complex > > > > > shapes mentioned earlier. > > > > > > > > > > I'm away on holiday next week. I should be able to send you > > > > > something > > > > > in a couple of weeks time. > > > > > > > > > > Regards > > > > > Ticker > > > > > > > > > > > > > > > On Sat, 2016-10-22 at 01:04 -0700, Gerd Petermann wrote: > > > > > > Hi Ticker, > > > > > > > > > > > > I reviewed the patch, it looked good but the patched > version > > > > > > crashes > > > > > > in a > > > > > > recursion because of an > > > > > > java.lang.StackOverflowError. I think the problem is in the > > > > > > rounding > > > > > > in Area > > > > > > class. > > > > > > I've uploaded test data that should allow you to reproduce > > the > > > > > > problem: > > > > > > http://files.mkgmap.org.uk/download/310/test.zip > > > > > > > > > > > > Besides that I found two small problems: > > > > > > 1) The unit tests did not compile with the patch > > > > > > 2) MultPpolygonRelation.java contains dead (?) code and > uses > > > > > > Long > > > > > > instead > > > > > > of long. > > > > > > Please check my changes in the attached modified patch: > > > > > > > > > > > > sortAreas_v2.patch > > > > > > > > > > > < > > http://gis.19327.n8.nabble.com/file/n5884759/sortAreas_v2.pat > > > > > ch> ; > > > > > > ;; > > > > > > > > > > > > Ciao, > > > > > > Gerd > > > > > > > > > > > > > > > > > > Ticker Berkin wrote > > > > > > > Hi > > > > > > > > > > > > > > I have a patch that outputs polygons into the map file in > > > > > > > decreasing > > > > > > > size order, so that, assuming equal _drawOrder, the > Garmin > > > > > > > device > > > > > > > renders small details over larger areas, much like how > they > > > > > > > appear > > > > > > > on > > > > > > > OpenStreetMap.org. > > > > > > > > > > > > > > As well as sorting by size, polygons that straddle > > > > > > > subDivisions > > > > > > > are cut up and placed into their correct subdivision, > > rather > > > > > > > than > > > > > > > being > > > > > > > put into an arbirary one, which, if it isn't the one in > > > > > > > focus, > > > > > > > renders > > > > > > > over the focus subdivision. > > > > > > > > > > > > > > The original, full, area of polygons is tracked > > throug > > > > > > > h > > > > > > > a > > > > > > > ny cutting and clipping so that relative ordering is > > correct > > > > > > > across > > > > > > > subdivision and map boundaries. > > > > > > > > > > > > > > All this is controlled by the option --order-by > -decreasing > > > > > > > -area, > > > > > > > with a > > > > > > > default of false that leaves the behavior of mkgmap > > > > > > > unchanged. > > > > > > > A > > > > > > > s such, I think this patch could be applied to the trunk > > > > > > > development. > > > > > > > > > > > > > > Regards > > > > > > > Ticker Berkin > > > > > > > mk > > > > > > > > > > > > > > _______________________________________________ > > > > > > > mkgmap-dev mailing list > > > > > > > > > > > > > mkgmap-dev@.org > > > > > > > > > > > > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > > > > > > > > > sortAreas.patch (25K) > > > > > > > < > > > > > > > > > http://gis.19327.n8.nabble.com/attachment/5884038/0/sortAreas > > > > > > > .p > > > > > > > atch> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > View this message in context: > > > > > > http://gis.19327.n8.nabble.com/patch-to > > > > > > -write-polygons-in-decreasing-order-tp5884038p5884759.html > > > > > > Sent from the Mkgmap Development mailing list archive at > > > > > > Nabble.com. > > > > > > _______________________________________________ > > > > > > mkgmap-dev mailing list > > > > > > > > > > > > > mkgmap-dev@.org > > > > > > > > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > _______________________________________________ > > > > > mkgmap-dev mailing list > > > > > > > > > > > > mkgmap-dev@.org > > > > > > > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > _______________________________________________ > > > > mkgmap-dev mailing list > > > > > > > mkgmap-dev@.org > > > > > > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > > > sortAreas_v3.patch (31K) > > > > < > > http://gis.19327.n8.nabble.com/attachment/5885284/0/sortAreas_v > > > > 3.patch> > > > > > > > > > > > > > > > > > > -- > > > View this message in context: > > http://gis.19327.n8.nabble.com/patch-to > > > -write-polygons-in-decreasing-order-tp5884038p5885381.html > > > Sent from the Mkgmap Development mailing list archive at > > Nabble.com. > > > _______________________________________________ > > > 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 >

2 5

metres to fee issue with mp contour files
by nwillink 09 Nov '16

09 Nov '16

Hi Gerd I realise this has been discussed before but I certainly have been unable to convert m to ft in contour mps created by Groundtruth. It seems mkgmap ignores *Elevation=m* and presumes numerical data, ie label=50 refers to feet by default. As a result Basecamp /always / treats the resulting img as containing feet data which when converted to metric is never rounded off to the nearest 10. An example of a contour mp containic metric data can be found here <http://www.pinns.co.uk/osm/bits/12345678.mp> Its not urgent as I can use srtm2osm which works fine although it's slower. Thanks Nick -- View this message in context: http://gis.19327.n8.nabble.com/metres-to-fee-issue-with-mp-contour-files-tp… Sent from the Mkgmap Development mailing list archive at Nabble.com.

2 2