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 the wrong direction. This > was > removed some time ago because it didn't work properly. I have put > together > the attached patch that works much better and have been using it for > some > time. With the sea data that I use, which contains quite a large > number of > incorrectly ordered polygons, it manages to correct every error it > finds. It > won't be able to fix really gross errors, but providing most of the > data is > correct it
Re: [mkgmap-dev] Tiles pruned in DEM map
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 Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Montag, 4. Januar 2021 19:16 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map Hi Gerd I found another unexpected case: giving the --dem... option caused the overview map to have NET and NOD sections To stops surprises, we should either pass in all the args and let the receiver of them decide what to do with them or pass in only the presumed significant options. I think it much better to pass them all in; the logic to decide is then all in the place where it is significant. I've made some changes to this effect - attached. In the case of --order-by-decreasing area, the final overview map needs to know that this is wanted so it can keep the polygons in the same order in each detail tile. The large ovm_ size is because it has a LBL section containing all the names for all levels. Unused ones don't make it into the final overview so I don't think this is worth bothering with. I've removed the scans for 0x4a polygons and do the equivalent when they are inserted per detail tile. Also I've also removed some misleading comments Ticker On Wed, 2020-12-30 at 11:21 +, Gerd Petermann wrote: > Hi Ticker, > > yes, this code needs review, thanks for this. For now I've just > disabled the --order-by-decreasing-area option for the overview map > in r4590 > > I am not sure if it would be better to always pass the args to > MapBuilder or only those for DEM. I'd prefer to always pass them but > maybe there are other side effects > Reg. size 1%: My understanding was that the merging of shapes is > responsible for all of this, but I might be wrong. > > I am working on a routing issue that I found while looking at Carlos' > problem. It only happens with --x-no-force-end-nodes-routing-nodes. > > Gerd > > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Mittwoch, 30. Dezember 2020 09:50 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map > > Hi Gerd > > I'm going to experiment with the combined overview map and which > options cause problems. Also look at the effect of 0x4a polygons at > just 1 level. > > I also notices that the combined overview (osmmap.img) is a fraction > of > the size (~1%) of the sum of the ovm_ images that are used to build > it. > > Ticker > > On Tue, 2020-12-29 at 15:52 +, Gerd Petermann wrote: > > Hi Ticker, > > > > thanks for the hints. I agree that the code in OverviewBuilder is > > not > > very clear. I'll have a closer look tomorrow, but at least we > > should > > remove the -order-by-decreasing-area when copying the options. Or > > maybe I change the code so that only the hgt/dem options are > > copied. > > I guess I was too lazy there. > > > > Gerd > > > > > > Von: mkgmap-dev im Auftrag > > von Ticker Berkin > > Gesendet: Dienstag, 29. Dezember 2020 10:50 > > An: Development list for mkgmap > > Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map > > > > Hi Gerd & Carlos > > > > Reading and trying to understand the code, I'm finding a few > > strange > > things with the Overview map generation, DEM, 0x4a etc > > > > The most significant is that the MapBuilder invocation for the > > combined > > overview map normally runs without any options being passed to it. > > Only > > if --overview-dem-dist is supplied are all the other options > > (including > > --order-by-decreasing-area) passed in. I'm not sure if would be a > > good > > idea to supply all every time or just be more selective and filter > > out > > all but the necessary DEM options. > > > > I'm still investigating the overview map levels. The ovm_ files are > > produced with all the overview-levels as specified by options. When > > this is read back by the overview combiner, a 0x4a polygon is added > > covering each ovm_ tile, but it looks like it is at all levels, so, > > for > > a tile with a large area or lots of detail is very likely to be > > split > > (if --order-by) or shunted around into another subdivision and > > multiple > > copies might exist. > > > > My understanding of the purpose of the 0x4a is that, in the > > overview > > map, there should be exactly 1 per detailed tile. It would be > > sensible > > to set its maxResolution so it only occurs at one level. > > > > After the 0x4a polygon has been added, a couple of bits of code > > scan > > for them in all the overview polygons.
Re: [mkgmap-dev] Tiles pruned in DEM map
Hi Gerd I found another unexpected case: giving the --dem... option caused the overview map to have NET and NOD sections To stops surprises, we should either pass in all the args and let the receiver of them decide what to do with them or pass in only the presumed significant options. I think it much better to pass them all in; the logic to decide is then all in the place where it is significant. I've made some changes to this effect - attached. In the case of --order-by-decreasing area, the final overview map needs to know that this is wanted so it can keep the polygons in the same order in each detail tile. The large ovm_ size is because it has a LBL section containing all the names for all levels. Unused ones don't make it into the final overview so I don't think this is worth bothering with. I've removed the scans for 0x4a polygons and do the equivalent when they are inserted per detail tile. Also I've also removed some misleading comments Ticker On Wed, 2020-12-30 at 11:21 +, Gerd Petermann wrote: > Hi Ticker, > > yes, this code needs review, thanks for this. For now I've just > disabled the --order-by-decreasing-area option for the overview map > in r4590 > > I am not sure if it would be better to always pass the args to > MapBuilder or only those for DEM. I'd prefer to always pass them but > maybe there are other side effects > Reg. size 1%: My understanding was that the merging of shapes is > responsible for all of this, but I might be wrong. > > I am working on a routing issue that I found while looking at Carlos' > problem. It only happens with --x-no-force-end-nodes-routing-nodes. > > Gerd > > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Mittwoch, 30. Dezember 2020 09:50 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map > > Hi Gerd > > I'm going to experiment with the combined overview map and which > options cause problems. Also look at the effect of 0x4a polygons at > just 1 level. > > I also notices that the combined overview (osmmap.img) is a fraction > of > the size (~1%) of the sum of the ovm_ images that are used to build > it. > > Ticker > > On Tue, 2020-12-29 at 15:52 +, Gerd Petermann wrote: > > Hi Ticker, > > > > thanks for the hints. I agree that the code in OverviewBuilder is > > not > > very clear. I'll have a closer look tomorrow, but at least we > > should > > remove the -order-by-decreasing-area when copying the options. Or > > maybe I change the code so that only the hgt/dem options are > > copied. > > I guess I was too lazy there. > > > > Gerd > > > > > > Von: mkgmap-dev im Auftrag > > von Ticker Berkin > > Gesendet: Dienstag, 29. Dezember 2020 10:50 > > An: Development list for mkgmap > > Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map > > > > Hi Gerd & Carlos > > > > Reading and trying to understand the code, I'm finding a few > > strange > > things with the Overview map generation, DEM, 0x4a etc > > > > The most significant is that the MapBuilder invocation for the > > combined > > overview map normally runs without any options being passed to it. > > Only > > if --overview-dem-dist is supplied are all the other options > > (including > > --order-by-decreasing-area) passed in. I'm not sure if would be a > > good > > idea to supply all every time or just be more selective and filter > > out > > all but the necessary DEM options. > > > > I'm still investigating the overview map levels. The ovm_ files are > > produced with all the overview-levels as specified by options. When > > this is read back by the overview combiner, a 0x4a polygon is added > > covering each ovm_ tile, but it looks like it is at all levels, so, > > for > > a tile with a large area or lots of detail is very likely to be > > split > > (if --order-by) or shunted around into another subdivision and > > multiple > > copies might exist. > > > > My understanding of the purpose of the 0x4a is that, in the > > overview > > map, there should be exactly 1 per detailed tile. It would be > > sensible > > to set its maxResolution so it only occurs at one level. > > > > After the 0x4a polygon has been added, a couple of bits of code > > scan > > for them in all the overview polygons. It might be possible to > > improve > > this, given they have just been added in the same processing phase. > > > > If --order-by-decreasing-area is used, the overview map combiner > > shouldn't attempt to respect it because it doesn't have the full > > size > > information of polygons that cross a tile boundary. Rather it > > should > > respect the polygon ordering in each ovm_ tile. I'm not sure yet > > this > > is feasible; Maybe something like the equivalent of --preserve > > -element > > order for this phase and look at all the logic paths of polygons to > > stop any other order changes due to merging etc. > > > > Ticker > > > > > >
Re: [mkgmap-dev] Minor documentation patch
Hi Gerd I think it is simplest to do that. Then later some of the sea options texts can be reworded if any of us feel strongly about it. Ticker On Mon, 2021-01-04 at 15:30 +, Gerd Petermann wrote: > Hi Ticker, > > not sure what to do now. Do you think i should commit Mikes patch > without changes? > > Gerd ___ 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
On 04/01/2021 13:07, Oliver Eichler wrote: Hi Steve, I tested your map. It's not listed either. I have a GPSMap64s and placed it into the internal as well as into the external memory. Attempting to use the old code was probably a mistake, I've uploaded an empty map using a modern version of mkgmap: http://files.mkgmap.org.uk/detail/495 This is also in the proper gmapsupp format unlike the previous one. I made a minimum test.img, too. It contains no points, lines or areas. It has 3 zoom levels 22..24 with a sub-division each. I also uploaded a log from my test decoder. Maybe you can cross check if your device is willing to list them. My etrex30 does not list either of them. Re-packing the GMP file into a gmapsupp using mkgmap did not get it listed either. 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. Cheers, Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Minor documentation patch
Hi Ticker, not sure what to do now. Do you think i should commit Mikes patch without changes? Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Montag, 4. Januar 2021 15:52 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Minor documentation patch Hi Parts of what I said is not quite correct (I was looking at my modified version of SeaGenerator). The suggested wording for doc/options.txt is ok. However the trunk SeaGenerator.java does manipulate the coastline way but it is still available for rendering by the style. With option --coastlinefile, no manipulation takes place. Ticker On Sat, 2021-01-02 at 18:09 +, Ticker Berkin wrote: > Hi Mike & Gerd > > I'd suggest something like: > ... > When this option is specified the land and sea polygons are derived > from the given precompiled data rather than the natural=coastline > ways > from the input OSM files. > ... > > The coastline ways not removed or modified, leaving it up the style > to > decide to render then as lines. > > However --coastlinefile is different and doesn't pass them on > > Ticker > On Sat, 2021-01-02 at 17:43 +, Mike Baggaley wrote: > > HI Gerd, > > > > Thanks for the quick response. My issue with the existing wording > > is > > that it > > reads as if the input files are actually being modified. I'd be > > happy > > with > > "filtered out" or "are not loaded from the input OSM files". (Just > > noticed > > it actually says OSM tiles rather than OSM files in the first > > mention, so I > > think that needs changing as well.) Do either of the two > > suggestions > > seem > > better to you? > > > > Cheers, > > Mike > > > > -Original Message- > > From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] > > Sent: 02 January 2021 09:53 > > To: Development list for mkgmap > > Subject: Re: [mkgmap-dev] Minor documentation patch > > > > Hi Mike, > > > > thanks for the patch. I am not sure if I like the part for > > coastlines. I'm > > not 100% sure but I think the tag natural=coastline is really just > > removed > > before the OSM way is processed by the style rules. A way with > > more > > than a > > natural=coastline tag is still processed. That's very different to > > being > > "ignored", isn't it? > > > > Gerd > > > > > > Von: mkgmap-dev im Auftrag > > von Mike > > Baggaley > > Gesendet: Donnerstag, 31. Dezember 2020 16:14 > > An: 'Development list for mkgmap' > > Betreff: [mkgmap-dev] Minor documentation patch > > > > Hi Gerd, please find attached a patch that makes some minor > > improvements to > > the documentation. > > > > Please review and commit if OK. > > > > Cheers, > > Mike > > > > > > ___ > > mkgmap-dev mailing list > > mkgmap-dev@lists.mkgmap.org.uk > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Minor documentation patch
Hi Parts of what I said is not quite correct (I was looking at my modified version of SeaGenerator). The suggested wording for doc/options.txt is ok. However the trunk SeaGenerator.java does manipulate the coastline way but it is still available for rendering by the style. With option --coastlinefile, no manipulation takes place. Ticker On Sat, 2021-01-02 at 18:09 +, Ticker Berkin wrote: > Hi Mike & Gerd > > I'd suggest something like: > ... > When this option is specified the land and sea polygons are derived > from the given precompiled data rather than the natural=coastline > ways > from the input OSM files. > ... > > The coastline ways not removed or modified, leaving it up the style > to > decide to render then as lines. > > However --coastlinefile is different and doesn't pass them on > > Ticker > On Sat, 2021-01-02 at 17:43 +, Mike Baggaley wrote: > > HI Gerd, > > > > Thanks for the quick response. My issue with the existing wording > > is > > that it > > reads as if the input files are actually being modified. I'd be > > happy > > with > > "filtered out" or "are not loaded from the input OSM files". (Just > > noticed > > it actually says OSM tiles rather than OSM files in the first > > mention, so I > > think that needs changing as well.) Do either of the two > > suggestions > > seem > > better to you? > > > > Cheers, > > Mike > > > > -Original Message- > > From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] > > Sent: 02 January 2021 09:53 > > To: Development list for mkgmap > > Subject: Re: [mkgmap-dev] Minor documentation patch > > > > Hi Mike, > > > > thanks for the patch. I am not sure if I like the part for > > coastlines. I'm > > not 100% sure but I think the tag natural=coastline is really just > > removed > > before the OSM way is processed by the style rules. A way with > > more > > than a > > natural=coastline tag is still processed. That's very different to > > being > > "ignored", isn't it? > > > > Gerd > > > > > > Von: mkgmap-dev im Auftrag > > von Mike > > Baggaley > > Gesendet: Donnerstag, 31. Dezember 2020 16:14 > > An: 'Development list for mkgmap' > > Betreff: [mkgmap-dev] Minor documentation patch > > > > Hi Gerd, please find attached a patch that makes some minor > > improvements to > > the documentation. > > > > Please review and commit if OK. > > > > Cheers, > > Mike > > > > > > ___ > > mkgmap-dev mailing list > > mkgmap-dev@lists.mkgmap.org.uk > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ 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 & 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 the wrong direction. This > was > removed some time ago because it didn't work properly. I have put > together > the attached patch that works much better and have been using it for > some > time. With the sea data that I use, which contains quite a large > number of > incorrectly ordered polygons, it manages to correct every error it > finds. It > won't be able to fix really gross errors, but providing most of the > data is > correct it will produce good results. > > Please review and commit if happy. > > Cheers, > Mike > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ 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, I tested your map. It's not listed either. I have a GPSMap64s and placed it into the internal as well as into the external memory. I removed all other maps on the device, except the basemap. The basemap is the only one listed. I made a minimum test.img, too. It contains no points, lines or areas. It has 3 zoom levels 22..24 with a sub-division each. I also uploaded a log from my test decoder. https://www.magentacloud.de/share/s429h1z-r6 I uploaded a second one with the version in the header set to 2. So far the difference to be another offset for the FAT. Maybe you can cross check if your device is willing to list them. Cheers, Oliver > Gesendet: Sonntag, 03. Januar 2021 um 23:08 Uhr > Von: "Steve Ratcliffe" > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: Re: [mkgmap-dev] Embedding raster maps > > > Hi Oliver > > > What is the minimum data an IMG file has to contain to be listed > > on the device? > > Its an interesting question. I don't remember having too many problems > getting a map recognised in the beginning. At r20 it worked > according to the commit comment but I only added the test map > builder at r24. > > However on my etrex 30 the map produced by r24 does not work. > > The first one that does work is r79. With a bit of experimenting > I discovered that adding a sufficiently large gap between the > end of the TRE header and the first data would make r78 work too. > > Going back to r24 and adding more padding also produced a map that > was recognized. I was able to remove the second copyright message > too and all map data. > > The required gap was between 40 and 101, depending on the rest of > the code. > > So this all makes very little sense and it is possible that this is > covering for something else that we don't understand. > > I've uploaded the minimal IMG file at: >http://files.mkgmap.org.uk/download/494/gmapsupp.img > > (After this I also managed to remove the first copyright message, so > you do not need any copyright messages and the label section can be > empty) > > With this version there is no message displayed on startup, which is > something that was fixed in r79 I think. > > There is just a single zoom and subdivision in the TRE section and > no points, line or polygons. > > Cheers, > Steve > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
