Re: [mkgmap-dev] Tiles pruned in DEM map
Hi Ticker, there is a typo in the patch, overview-dem-dists instead of overview-dem-dist. My rather small overview map got 20MB instead of 181K ;) I also didn't like the idea that the overview map is recognized by the name. That can lead to strange effects with test maps, so I added a parameter. With the corrections the size increases by only by 5K, but I have no idea how these 5K improve the map. I see one small difference where a label of a lake (1) is placed a bit of the center. The "patched" map contains two polygons for this lake, I assume the Garmin software avoids to render its name twice but uses a different algo to calculate the position. These are the results for my own style, a variant of Minkos OpenFietsMap Light style. Will try again with default style and type file sameOrder.txt. Gerd (1) https://www.openstreetmap.org/relation/3582977#map=14/53.5815/11.1991 Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Dienstag, 5. Januar 2021 10:58 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map Hi Gerd shapeMergeFilter.merge() sorts the shapes according to typ, skipSize, fullArea and name. For --order-by to work for the overview, this must not happen; the order in the ovm_ files must be used. This is the same idea as when the more than 1 detail tiles are displayed on a device. The size of osmmap.img for my test area, with the patch, is: 9216 --no-order-by-decreasing-area throughout 10752 --order-by-decreasing-area throughout 9219 --order-by-decreasing-area at start, --no-order-by-decreasing-area for the combiners So, there is a slight increase, as expected, it really isn't of any significance. --order-by-decreasing-area needs to be applied to both phases for it to work correctly. If applied to the tile phase only, the overview map will render polygons in order of the results of the the shapeMergeFilter. If applied to the overview phase only, probably similar; the order of the shapeMergeFilter governed ordering in the ovm_ .img Ticker On Mon, 2021-01-04 at 18:52 +, Gerd Petermann wrote: > Hi Ticker, > > thanks for the patch. I'll have a closer look during the next days. I > don't yet understand why shapes aren't always merged. > What is the impact on the size of the overview map? What happens for > those users who create the overview map in an extra step that doesn't > have the --order-by-decreasing-area option? What happens when it's > the other way around, no --order-by-decreasing-area option for the > tiles but --order-by-decreasing-area for the overview map? > > Gerd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev overview-v2.patch Description: overview-v2.patch ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Embedding raster maps
Hi Steve, that was really helpful. I managed to get my map listed. However the raster layer did not show up :( Well I didn't really expect it. ;) > > I believe that the byte at 0x40 is the start block of the FAT so in > test.img it should be 2. Patching that byte did not make it load > though. Indeed, it seems to be an offset in number of 0x200 blocks. In all my example maps it's set to 8 and FAT starts at 0x1000. In your map it's set to 2 and FAT starts at 0x400. Another mystery solved. I guess the next step is to get a rectangular extended polygon without the raster data to show up. The polygon type for the raster map tiles used is 0x10613. Usually it only contains a single point as the extended data referencing the jpeg tile has the four boundaries coded as 32 bit integers. My goal is to remove the extended data and to code all 4 corner coordinates. This should give me a matrix of all rectangles. Again this raises the question about the minimum effort necessary to add a single polygon. In my naive point of view it would be just encoding it into the extended polygon section of the RGN file. Of course I tried it and it does not work. So I am missing something, or have a couple of more bugs in my code. Would it be possible to code another file with a single polygon QPolygonF( QPointF(11.7914,46.9628) QPointF(11.8021,46.9628) QPointF(11.8021,46.9555) QPointF(11.7914,46.9555) ) coded in three map levels: 0/24bit, 1/23bit and 2/22bit. This would give me a nice working reference to compare. Thanks & Cheers Oliver ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Fix Sea Patch
Hi Mike What is the advantage of using your code to pre-process coastline data? Why not feed in the raw coastline ways and let the SeaGenerator handling all the joining and closing. As long as your coastline ways cover the whole of each final tile, you shouldn't get problems that need solving with "[extend-]sea-sectors", but you might need "close -gaps". Or just use --precomp-sea=... Anti-islands are enclosed seas and really should trigger a big warning as, I think, the only one is the Caspian. All other coastline should extend off the tile or be islands. I don't understand the basis on which your pre-processor is allowed to generate anti-islands. The example of a road/bridge generating 2 sea areas confuses me. Won't there be valid coastline in both directions under the bridge and how far away from this do you go before joining/ enclosing the 2 areas of sea - 1 of which shouldn't be enclosed. Ticker On Tue, 2021-01-05 at 08:39 +, Gerd Petermann wrote: > Hi Mike & Ticker, > > I would not want to add code to mkgmap to fix problems which only > occur in data that is produced by a 3rd party software. My > understanding is that the "fixing" should happen in that 3rd party > software, not in mkgmap. > > Gerd > > > Von: mkgmap-dev im Auftrag > von Mike Baggaley > Gesendet: Montag, 4. Januar 2021 20:40 > An: 'Development list for mkgmap' > Betreff: Re: [mkgmap-dev] Fix Sea Patch > > Hi Ticker, > > I use coastline data that is generated from just line data and the > algorithm used is not able to properly determine whether polygons are > islands or water. It does however make sure polygons are closed, so I > don't have problems with having to join ways together and hence I > don't use close-gaps or extend sea-sectors. > > I'm unclear exactly what an anti-island is supposed to be - I have > considered it to be a separate bit of sea, and in my data I have lots > of those that are correct. They are only incorrect if they are within > the sea, rather than the land. For example, if there is a coast road > with sea on both sides of it, I am likely to have a separate sea > polygon within the land if its connection to the sea is under a > bridge. The patch checks for sea within sea and land within land. It > doesn't then go back and recursively check for nested problems - I > suspect this would be quite an overhead. > > The code is certainly not perfect, but does produce enormously > improved results for me at least. I can still see at least one error > in my map, but I think the remaining errors are tile boundary issues > that are resolved differently on adjacent tiles. I am thinking of a > small app to read the mkgmap log file and the coastline data, > reversing whatever mkgmap says is wrong. By running mkgmap without > splitter on just the coastline data I should be able to avoid any > tile boundary problems. > > Cheers, > Mike > > -Original Message- > From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk] > Sent: 04 January 2021 13:58 > To: Development list for mkgmap > Subject: Re: [mkgmap-dev] Fix Sea Patch > > Hi Mike & Gerd > > I always try to use the coastline data in the downloaded OSM map to > generate the sea with option: > --generate-sea=multipolygon,extend-sea > -sectors,close-gaps=750 > and have only ever had 1 problem with faulty > coastline. In this case it wasn't a reversed section but a lake had > been tagged with coastline, worse, in the wrong direction so it > wasn't > treated as an internal sea, rather an island, flipping the rest of > the > tile to sea. > > I sometimes have problems with the continuation of the downloaded > country's coastlines being cut off and ending up near the middle of > tiles, but closer to the wrong edge or, when extended to the edge, > they are in the same direction as an adjacent coastline, because the > un-crossing is outside the downloaded area. > > @Mike - Do you use --coastlinefile to circumvent this type of problem > and is there an advantage to this over using --precomp-sea? The data > seems to need a lot of correcting! > > If arbitrary bits of coastline are in the wrong direction, should you > have another phase, after joining in the same direction and removing > anti/islands. Try to join against their direction and moving closed > ways to an ambiguous closed list and other ways that joined to an > ambiguous linear list. Then see if the ambiguous ones can be > resolved, maybe by weighting by the direction of the majority. > > I feel that some of your fixes of land/sea are too late in the flow > of code, ie after generateSeaBackgound has been set. > > It seems a reasonably assertion that all anti-islands are a mistake > in the data. I think the only one is the Caspian Sea, which is > unlikely to be fully contained in a tile. > > checkIslands(), to do the full job, would need to look at the nesting > of sea/land/sea... so, given above, I don't think it worthwhile. > > In verifyHits(), I don't
Re: [mkgmap-dev] Tiles pruned in DEM map
Hi Gerd shapeMergeFilter.merge() sorts the shapes according to typ, skipSize, fullArea and name. For --order-by to work for the overview, this must not happen; the order in the ovm_ files must be used. This is the same idea as when the more than 1 detail tiles are displayed on a device. The size of osmmap.img for my test area, with the patch, is: 9216 --no-order-by-decreasing-area throughout 10752 --order-by-decreasing-area throughout 9219 --order-by-decreasing-area at start, --no-order-by-decreasing-area for the combiners So, there is a slight increase, as expected, it really isn't of any significance. --order-by-decreasing-area needs to be applied to both phases for it to work correctly. If applied to the tile phase only, the overview map will render polygons in order of the results of the the shapeMergeFilter. If applied to the overview phase only, probably similar; the order of the shapeMergeFilter governed ordering in the ovm_ .img Ticker On Mon, 2021-01-04 at 18:52 +, Gerd Petermann wrote: > Hi Ticker, > > thanks for the patch. I'll have a closer look during the next days. I > don't yet understand why shapes aren't always merged. > What is the impact on the size of the overview map? What happens for > those users who create the overview map in an extra step that doesn't > have the --order-by-decreasing-area option? What happens when it's > the other way around, no --order-by-decreasing-area option for the > tiles but --order-by-decreasing-area for the overview map? > > Gerd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit r4592: improve documentation - minordoc.patch by Mike Baggaley
Version mkgmap-r4592 was committed by gerd on Tue, 05 Jan 2021 improve documentation - minordoc.patch by Mike Baggaley http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4592 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Fix Sea Patch
Hi Mike & Ticker, I would not want to add code to mkgmap to fix problems which only occur in data that is produced by a 3rd party software. My understanding is that the "fixing" should happen in that 3rd party software, not in mkgmap. Gerd Von: mkgmap-dev im Auftrag von Mike Baggaley Gesendet: Montag, 4. Januar 2021 20:40 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] Fix Sea Patch Hi Ticker, I use coastline data that is generated from just line data and the algorithm used is not able to properly determine whether polygons are islands or water. It does however make sure polygons are closed, so I don't have problems with having to join ways together and hence I don't use close-gaps or extend sea-sectors. I'm unclear exactly what an anti-island is supposed to be - I have considered it to be a separate bit of sea, and in my data I have lots of those that are correct. They are only incorrect if they are within the sea, rather than the land. For example, if there is a coast road with sea on both sides of it, I am likely to have a separate sea polygon within the land if its connection to the sea is under a bridge. The patch checks for sea within sea and land within land. It doesn't then go back and recursively check for nested problems - I suspect this would be quite an overhead. The code is certainly not perfect, but does produce enormously improved results for me at least. I can still see at least one error in my map, but I think the remaining errors are tile boundary issues that are resolved differently on adjacent tiles. I am thinking of a small app to read the mkgmap log file and the coastline data, reversing whatever mkgmap says is wrong. By running mkgmap without splitter on just the coastline data I should be able to avoid any tile boundary problems. Cheers, Mike -Original Message- From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk] Sent: 04 January 2021 13:58 To: Development list for mkgmap Subject: Re: [mkgmap-dev] Fix Sea Patch Hi Mike & Gerd I always try to use the coastline data in the downloaded OSM map to generate the sea with option: --generate-sea=multipolygon,extend-sea -sectors,close-gaps=750 and have only ever had 1 problem with faulty coastline. In this case it wasn't a reversed section but a lake had been tagged with coastline, worse, in the wrong direction so it wasn't treated as an internal sea, rather an island, flipping the rest of the tile to sea. I sometimes have problems with the continuation of the downloaded country's coastlines being cut off and ending up near the middle of tiles, but closer to the wrong edge or, when extended to the edge, they are in the same direction as an adjacent coastline, because the un-crossing is outside the downloaded area. @Mike - Do you use --coastlinefile to circumvent this type of problem and is there an advantage to this over using --precomp-sea? The data seems to need a lot of correcting! If arbitrary bits of coastline are in the wrong direction, should you have another phase, after joining in the same direction and removing anti/islands. Try to join against their direction and moving closed ways to an ambiguous closed list and other ways that joined to an ambiguous linear list. Then see if the ambiguous ones can be resolved, maybe by weighting by the direction of the majority. I feel that some of your fixes of land/sea are too late in the flow of code, ie after generateSeaBackgound has been set. It seems a reasonably assertion that all anti-islands are a mistake in the data. I think the only one is the Caspian Sea, which is unlikely to be fully contained in a tile. checkIslands(), to do the full job, would need to look at the nesting of sea/land/sea... so, given above, I don't think it worthwhile. In verifyHits(), I don't see where any changes that resolves "adjacent hits in same direction" are applied. The 'fix' could make it totally wrong rather than partially wrong. Looking for 3 in the same direction and reversing the middle one might be better. As I said earlier, I've never had a problem where this type of fixing would be of any use. The swapping between land and sea needs to do more than just re-tagging; the multi-polygon handling needs to be considered and also the fullArea of sea. Ticker On Sat, 2021-01-02 at 10:32 +, Gerd Petermann wrote: > Hi Mike, > > > This was removed some time ago because it didn't work properly > Do you have a version number where this happened? I only know the > floodblocker option which is still evaluated in the source. > > Gerd > > > > Von: mkgmap-dev im Auftrag > von Mike Baggaley > Gesendet: Donnerstag, 31. Dezember 2020 16:17 > An: 'Development list for mkgmap' > Betreff: [mkgmap-dev] Fix Sea Patch > > Hi Gerd, > > Mkgmap used to contain some code that attempted to correct incorrect > sea and > land data where polygons were ordered in
