Hi all, Yesterday I've committed r2546 in the overview2 branch. In addition to the functionality implemented in overview_v3.patch this implements also the support of data with extended types. Please try it with the known options: --x-overview-add-polygons --x-overview-add-lines --x-overview-add-points Now I wonder what kind of further configuration we could need. The following points were discussed: 1) Allow to read data from other levels, not only the one with the lowest resolution. I tried it and I don't think this will increase quality, but it increases run time quite heavily. 2) Allow to apply filters, so that fewer objects are placed in the overview map. I think this could be implemented with a simple list like this: # filter for overview map point:type_1 point:type_2 ... point:type_n line:* polygon: This would add points with the type type_1 to type_n, all lines and no polygons. The file woud replace the --x-overview-add-xxx options. I will try to implement it in this way, please suggest changes if something else is needed. 3) Style files for the overview map I don't see how this could be used when the data is read from *.img files. 4) Read data from other sources, e.g. precompiled sea/land polygons. I don't plan to code that but I think this remains a possible option to increase quality. Open questions: 1) The current implementation adds a background polygon with type 0x4a even if option --transparent is used. I assume this is correct? 2) The background is now added as a rectangle. This could be changed so that it covers only the areas covered by the *.img files. Is this needed? Ciao, Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Configuration-for-overview-map-tp5755669.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Gerd, when I process a few tiles with -c mkgmap.args directory/*.img it fails, it spits out a few lines with a few numbers like 65792 -22 -53 65792 -22 -47 65792 -22 -31 etc and in the error log: Exception in thread "main" java.lang.NullPointerException at uk.me.parabola.mkgmap.combiners.OverviewBuilder.readShapes(OverviewBuilder.java:200) at uk.me.parabola.mkgmap.combiners.OverviewBuilder.readFileIntoOverview(OverviewBuilder.java:131) at uk.me.parabola.mkgmap.combiners.OverviewBuilder.onMapEnd(OverviewBuilder.java:82) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:429) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:127) at uk.me.parabola.mkgmap.main.Main.main(Main.java:111)
Hi Minko, thanks for testing. The error was caused by a missing check. Fixed with r2550. This also implements the configuration file. Usage --x-overview-cfg=path-to-cfg-file Content of cfg-file should be as described before, except for the line polygon: This is not allowed. Just don't write any line starting with polygon if you don't want polygons. Gerd Minko-2 wrote
Gerd, when I process a few tiles with -c mkgmap.args directory/*.img it fails, it spits out a few lines with a few numbers like 65792 -22 -53 65792 -22 -47 65792 -22 -31 etc
and in the error log:
Exception in thread "main" java.lang.NullPointerException at uk.me.parabola.mkgmap.combiners.OverviewBuilder.readShapes(OverviewBuilder.java:200) at uk.me.parabola.mkgmap.combiners.OverviewBuilder.readFileIntoOverview(OverviewBuilder.java:131) at uk.me.parabola.mkgmap.combiners.OverviewBuilder.onMapEnd(OverviewBuilder.java:82) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:429) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:127) at uk.me.parabola.mkgmap.main.Main.main(Main.java:111) _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/Configuration-for-overview-map-tp5755669p5755... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Minko, Minko-2 wrote
Gerd wrote
thanks for testing. The error was caused by a missing check. Fixed with r2550.
Gerd, can you upload it again, the jar file is empty.
I did not upload the file, it was produced by the automatic build process. Don't know what went wrong, but r2551 is okay now. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Configuration-for-overview-map-tp5755669p5755... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Thanks, found it, now I have to fill in my configuration file, at what level/resolution is mkgmap retrieving the info? For instance I use point type 0x04 (big city) at different levels for different place categories. At the lowest levels only for major cities, but the higher the zoom level the more places (cities, towns) this poi gets (because I want to make the font size bigger as you zoom in). So if I fill in point:0x04 does it take also the smaller cities and towns that uses 0x04 at the highest zoom? That is not what I want.
I did not upload the file, it was produced by the automatic build process. Don't know what went wrong, but r2551 is okay now.
Gerd
Hi Minko, up to now all data is taken from the lowest resolution level only. Gerd Minko-2 wrote
Thanks, found it, now I have to fill in my configuration file, at what level/resolution is mkgmap retrieving the info?
For instance I use point type 0x04 (big city) at different levels for different place categories. At the lowest levels only for major cities, but the higher the zoom level the more places (cities, towns) this poi gets (because I want to make the font size bigger as you zoom in). So if I fill in point:0x04 does it take also the smaller cities and towns that uses 0x04 at the highest zoom? That is not what I want.
I did not upload the file, it was produced by the automatic build process. Don't know what went wrong, but r2551 is okay now.
Gerd
mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/Configuration-for-overview-map-tp5755669p5755... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Thanks Gerd, I have created an overview map of all 10137001.img-10137136.img tiles that are in this zip file: http://osm.pleiades.uni-wuppertal.de/openfietsmap/EU_2013/OFM_EU2013_E.zip The config file is overview.txt, it contains these elements: line:0x1c (artic circle) line:0x1001f (int. marine borders) line:0x1001e (country borders) point:0x04 (major / capital cities) point:0x1500 (countries) point:0x01 (sea, ocean) polygon:0x3d (water) polygon:0x010100 (background) polygon:0x32 (sea) Now not all the land polygons are filled with my background 0x010100 (white patches on overview.jpg). Any idea why?
Hi Minko, seems that the function which reads polygons with extended type data doesn't work. I'll look at this tomorrow. Gerd Minko-2 wrote
Thanks Gerd,
I have created an overview map of all 10137001.img-10137136.img tiles that are in this zip file: http://osm.pleiades.uni-wuppertal.de/openfietsmap/EU_2013/OFM_EU2013_E.zip
The config file is overview.txt, it contains these elements: line:0x1c (artic circle) line:0x1001f (int. marine borders) line:0x1001e (country borders) point:0x04 (major / capital cities) point:0x1500 (countries) point:0x01 (sea, ocean) polygon:0x3d (water) polygon:0x010100 (background) polygon:0x32 (sea)
Now not all the land polygons are filled with my background 0x010100 (white patches on overview.jpg). Any idea why?
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
overview.jpg (190K) <http://gis.19327.n5.nabble.com/attachment/5755780/0/overview.jpg>; OFM_EU2013_E.img (83K) <http://gis.19327.n5.nabble.com/attachment/5755780/1/OFM_EU2013_E.img>; overview.txt (204 bytes) <http://gis.19327.n5.nabble.com/attachment/5755780/2/overview.txt>;
-- View this message in context: http://gis.19327.n5.nabble.com/Configuration-for-overview-map-tp5755669p5755... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Minko, I found one stupid typo that caused the missing background polygons. This is fixed with r2552. But I think another problem is in your style files. The maps contain 6 levels with data: [L 5:14, L 4:16, L 3:18, L 2:20, L 1:22, L 0:24] (the empty level 7 with resolution 13 is ignored) The level with resolution 14 contains almost no data. Example: 10137001.img contains zero points, two lines : [Type=36, label=EV4 (CENTRAL EUROPE ROUTE), Type=36, label=EV4 (CENTRAL EUROPE ROUTE)] 30 polygons with the types 0x3d, 0x4b, and 0x010100 I hope this helps? Gerd Minko-2 wrote
seems that the function which reads polygons with extended type data doesn't work. I'll look at this tomorrow.
Gerd
Ok Gerd, I also noticed that not only extended polygons, but a lot of borders are missing now and country names too. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/Configuration-for-overview-map-tp5755669p5755... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd, The reason that my resolution 14 contains almost no data is because I was using it as sort of overview map. Since you have picked up this, there will be no need for it anymore as soon the overview map is working. So almost all elements in this resolution 14 I would like to see in my overview map, except type 0x36 (international cycling routes).
But I think another problem is in your style files. The maps contain 6 levels with data: [L 5:14, L 4:16, L 3:18, L 2:20, L 1:22, L 0:24] (the empty level 7 with resolution 13 is ignored)
The level with resolution 14 contains almost no data. Example: 10137001.img contains zero points, two lines : [Type=36, label=EV4 (CENTRAL EUROPE ROUTE), Type=36, label=EV4 (CENTRAL EUROPE ROUTE)] 30 polygons with the types 0x3d, 0x4b, and 0x010100
I hope this helps?
Gerd
So what is the problem there, am I using too many levels than allowed?
Hi Gerd, With mkgmap-overview2-r2552.jar the background polygons are ok now, thanks. Alse the country names, because I first used point:0x1500 (not working) instead of point:0x015 (working) Only the borders are still not complete, see screenshots. Borders: line:0x1001f (marine) line:0x1001e Can you find out what went wrong in those tiles?
Hi Minko, yes, I fixed another error. Please try r2554. Gerd Minko-2 wrote
Hi Gerd, With mkgmap-overview2-r2552.jar the background polygons are ok now, thanks. Alse the country names, because I first used point:0x1500 (not working) instead of point:0x015 (working)
Only the borders are still not complete, see screenshots.
Borders: line:0x1001f (marine) line:0x1001e
Can you find out what went wrong in those tiles?
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
resolution14.jpg (44K) <http://gis.19327.n5.nabble.com/attachment/5755845/0/resolution14.jpg>; overviewmap.jpg (40K) <http://gis.19327.n5.nabble.com/attachment/5755845/1/overviewmap.jpg>;
-- View this message in context: http://gis.19327.n5.nabble.com/Configuration-for-overview-map-tp5755669p5755... Sent from the Mkgmap Development mailing list archive at Nabble.com.
yes, I fixed another error. Please try r2554
Great, borders are complete now :-) One issue left, a lot of country name labels are missing now. 0x014 Bigger countries, only Serbia is rendered, missing: Romania, Greece, Bulgaria, Ukraine, Belarus, Hungary, Turkey 0x015 Smaller countries. Most are rendered, a few not (Slovak republik, Kosovo) In my resolution 14 map all of those names are displayed.
Hi Minko, please check: 0x014 and 0x015 are invalid hex numbers. Gerd
Date: Fri, 5 Apr 2013 12:20:11 +0200 From: ligfietser@online.nl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Configuration for overview map
yes, I fixed another error. Please try r2554
Great, borders are complete now :-)
One issue left, a lot of country name labels are missing now.
0x014 Bigger countries, only Serbia is rendered, missing: Romania, Greece, Bulgaria, Ukraine, Belarus, Hungary, Turkey 0x015 Smaller countries. Most are rendered, a few not (Slovak republik, Kosovo)
In my resolution 14 map all of those names are displayed.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Gerd, what are the valid hex numbers for those pois? I also tried 0x1400 and 0x1500 but these are not working gpsmapedit displays it as 0x1400 /0x1500 BTW you can find the overview map here: http://osm.pleiades.uni-wuppertal.de/openfietsmap/EU_2013/Updates/
please check: 0x014 and 0x015 are invalid hex numbers.
Gerd
Hi Minko, yes. I fixed two more errors. Some POI were ignored. and the decoding of the type was wrong for POI. If you style contains 0x1500, then you also have to use 0x1500 in the config file. I am not sure, but it seems that POI with types < 0x0100 should not be allowed, because a type 0x01 is written to the img file as 0x0100. Maybe someone can point me to a document abount this? Gerd
Date: Fri, 5 Apr 2013 12:37:17 +0200 From: ligfietser@online.nl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Configuration for overview map
PS, I have tried points:* and they are still missing _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Thanks Gerd, The last version seems to work: http://osm.pleiades.uni-wuppertal.de/openfietsmap/EU_2013/Updates/example.jp... http://osm.pleiades.uni-wuppertal.de/openfietsmap/EU_2013/Updates/OFM_EU2013...
I fixed two more errors. Some POI were ignored. and the decoding of the type was wrong for POI. If you style contains 0x1500, then you also have to use 0x1500 in the config file. I am not sure, but it seems that POI with types < 0x0100 should not be allowed, because a type 0x01 is written to the img file as 0x0100. Maybe someone can point me to a document abount this?
Yes I had to change it in my config file: 0x01 > 0x0100 0x04 > 0x0400 On http://www.cgpsmapper.com/download/cGPSmapper-UsrMan-v02.5.pdf, page 107 you can see the range that is allowed
Hi Minko, fine, thanks for the hints. I think I'll add a check to make sure that point types are >= 0x0100 and according to the TypWiz3 manual the sub type field must be <= 0x1f. Gerd Minko-2 wrote
Thanks Gerd, The last version seems to work: http://osm.pleiades.uni-wuppertal.de/openfietsmap/EU_2013/Updates/example.jp... http://osm.pleiades.uni-wuppertal.de/openfietsmap/EU_2013/Updates/OFM_EU2013...
I fixed two more errors. Some POI were ignored. and the decoding of the type was wrong for POI. If you style contains 0x1500, then you also have to use 0x1500 in the config file. I am not sure, but it seems that POI with types < 0x0100 should not be allowed, because a type 0x01 is written to the img file as 0x0100. Maybe someone can point me to a document abount this?
Yes I had to change it in my config file:
0x01 > 0x0100 0x04 > 0x0400
On http://www.cgpsmapper.com/download/cGPSmapper-UsrMan-v02.5.pdf, page 107 you can see the range that is allowed _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/Configuration-for-overview-map-tp5755669p5755... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Minko, GerdP wrote
I think I'll add a check to make sure that point types are >= 0x0100 and according to the TypWiz3 manual the sub type field must be <= 0x1f.
In r2556 I've implemented some checks for the type values, but I fear they cause problems with your overlays file. You lines style uses the invalid type 0x1602, this occurs also in the overlays file. I did not yet look at the code or debug that, so I am not sure what the meaning of the overlays file is. If it replaces the wrong type, I probably have to change the checks. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Configuration-for-overview-map-tp5755669p5755... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd, I use line type 0x1602 which is specified in my overlays style: #cycleway with track 0x1602: 0x0f, 0x10005 The meaning is that it uses 0f for routing and it draws line 10005 on top of it. I dont use those lines at low resolution so I hope this will not give a problem?
In r2556 I've implemented some checks for the type values, but I fear they cause problems with your overlays file. You lines style uses the invalid type 0x1602, this occurs also in the overlays file. I did not yet look at the code or debug that, so I am not sure what the meaning of the overlays file is. If it replaces the wrong type, I probably have to change the checks.
Gerd
Gerd, just tested it with a few maps, but no problems here. I guess because I don't use overlay line types at the lowest zoom level?
In r2556 I've implemented some checks for the type values, but I fear they cause problems with your overlays file. You lines style uses the invalid type 0x1602, this occurs also in the overlays file. I did not yet look at the code or debug that, so I am not sure what the meaning of the overlays file is. If it replaces the wrong type, I probably have to change the checks.
Gerd
Hi Gerd, I think you should change the checks, my total map generation for my Benelux map failed: SEVERE (GType): splitter\10010001.o5m: invalid type for point: 0x01
In my points file I noticed 0x01 instead of 0x0100: (place=sea | place=ocean) & mkgmap:area2poi!=true & name=* [0x01 resolution 16] Until far mkgmap rendered this point correctly. Maybe only add a warning with a line number where I can find this error in my scripts instead of breaking off the whole process completely?
Hi Gerd, I think you should change the checks, my total map generation for my Benelux map failed: SEVERE (GType): splitter\10010001.o5m: invalid type for point: 0x01
You were right Gerd, the overlay lines also stopped the mkgmap process. I would suggest to check all line types specified in the overlay file, then compare it with the invalid lines in the line style Report all invalid types (without those specified in the overlay file) only as warning message instead of a severe error that stops processing
Hi Minko, yes, it's quite difficult to find a good place for the checks. I can easily change the checks to report file name and line number in a warning, but I do not yet see how to handle the overlay file Another cosmetic problem is that all style files are read twice, so each warning is doubled. Working on it... Gerd
Date: Sat, 6 Apr 2013 10:22:40 +0200 From: ligfietser@online.nl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Configuration for overview map
You were right Gerd, the overlay lines also stopped the mkgmap process.
I would suggest to check all line types specified in the overlay file, then compare it with the invalid lines in the line style Report all invalid types (without those specified in the overlay file) only as warning message instead of a severe error that stops processing _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Minko, 0x1500 should be okay, but looking at the code I think this is not correctly processed because the 2nd byte is 0. You may try with 0x1501 to avoid that situation. I'll look at that later this day. Gerd Minko-2 wrote
Gerd, what are the valid hex numbers for those pois? I also tried 0x1400 and 0x1500 but these are not working gpsmapedit displays it as 0x1400 /0x1500
BTW you can find the overview map here: http://osm.pleiades.uni-wuppertal.de/openfietsmap/EU_2013/Updates/
please check: 0x014 and 0x015 are invalid hex numbers.
Gerd
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/Configuration-for-overview-map-tp5755669p5755... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi, On Thu, Apr 04, GerdP wrote:
Hi Minko,
thanks for testing. The error was caused by a missing check. Fixed with r2550. This also implements the configuration file. Usage --x-overview-cfg=path-to-cfg-file Content of cfg-file should be as described before, except for the line polygon: This is not allowed. Just don't write any line starting with polygon if you don't want polygons.
Works fine for me, too. I only need to put much more work into the style file to get it nice. But while I see the overview map in MapSource, I only see a black screen on my GPSmap 62s :( Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Hi Thorsten, The overview map is only meant for Mapsource and Basecamp. The GPS has its own basic map.
But while I see the overview map in MapSource, I only see a black screen on my GPSmap 62s :(
Thorsten
-- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On Fri, Apr 05, Minko wrote:
Hi Thorsten, The overview map is only meant for Mapsource and Basecamp. The GPS has its own basic map.
Hm, for Mapsource, at least for me, I don't see performance problems even without an overview map. But the basic map of old Garmin devices are next to useless or, on newer devices, breaks the OSM maps, since partiell data of this maps are always shown on top of all maps if you don't disable them. I'm afraid on a device it is not possible to have different tiles for each resolution? Bigger tiles if you zoom out would make it much more faster and useable, too. But one issue I see with my overview map: I only show motorways as lines. But there are big holes in the lines. If I zoom in, this holes vanish. Any idea what could be the reason for this? Thorsten
But while I see the overview map in MapSource, I only see a black screen on my GPSmap 62s :(
Thorsten
-- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Hi Thorsten,
The overview map is only meant for Mapsource and Basecamp. The GPS has its own basic map.
Hm, for Mapsource, at least for me, I don't see performance problems even without an overview map. But the basic map of old Garmin devices are next to useless or, on newer devices, breaks the OSM maps, since partiell data of this maps are always shown on top of all maps if you don't disable them.
I think the only improvement is that don't see an empty rectangle in MapSource or Basecamp when you open a map for the first time. I don't think that it has any impact on performance. Reg. the problems on the device: Do you see a possible solution for that in mkgmap?
I'm afraid on a device it is not possible to have different tiles for each resolution? Bigger tiles if you zoom out would make it much more faster and useable, too.
In fact the structure in the img file is like that. A single tile is devided into sub divisions, typically the higher the resolution, the more sub divisions are created. Maybe the algorithm that calculates the needed sub divisions might be improved, in some cases mkgmap creates deeply nested structures, e.g. when two equal large polygons are saved.
But one issue I see with my overview map: I only show motorways as lines. But there are big holes in the lines. If I zoom in, this holes vanish. Any idea what could be the reason for this?
Make sure to use r2555 or higher. If you configure the program to show only the basemap (Ctrl+G), you should not see this effect when zooming in, else either the data is missing on the lowest level or you found another error. In the latter case, please provide a link to the img file(s) Gerd
Am 06.04.2013 12:06, schrieb Gerd Petermann:
I think the only improvement is that don't see an empty rectangle in MapSource or Basecamp when you open a map for the first time. I don't think that it has any impact on performance. The "boost" could be, that we don't need low levels for the real map.
Henning
Hi Gerd, On Sat, Apr 06, Gerd Petermann wrote:
But one issue I see with my overview map: I only show motorways as lines. But there are big holes in the lines. If I zoom in, this holes vanish. Any idea what could be the reason for this?
Make sure to use r2555 or higher. If you configure the program to show only the basemap (Ctrl+G), you should not see this effect when zooming in, else either the data is missing on the lowest level or you found another error. In the latter case, please provide a link to the img file(s)
Ok, with Ctrl+G it's working fine. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Hi Gerd, thanks for your effort in this big open point in mkgmap!
The following points were discussed: 1) Allow to read data from other levels, not only the one with the lowest resolution. I tried it and I don't think this will increase quality, but it increases run time quite heavily.
Ok, it was just an idea. I think it should be proposed to use --merge-lines.
2) Allow to apply filters, so that fewer objects are placed in the overview map. I think this could be implemented with a simple list like this:
# filter for overview map point:type_1 point:type_2 ... point:type_n line:* polygon:
This would add points with the type type_1 to type_n, all lines and no polygons. The file woud replace the --x-overview-add-xxx options. I will try to implement it in this way, please suggest changes if something else is needed.
Maybe someone requires to configure reading data from specific levels. By default you would read from the lowest level but one could reconfigure it, e.g.: point:type_1:level point:type_2 So type_1 is read from the configured instead of the lowest level. This could be put on the TODO list until someone asks for it :-)
3) Style files for the overview map I don't see how this could be used when the data is read from *.img files.
I have two ideas: 1. a separate overview style file. When reading from .img files you would only check the element type definitions. All Garmin types used in the element type definitions would be used. 2. Add an overview statement to the element type definitions of the common style files. This could also be checked if reading from img files. Anyhow your solution with the config file does the same although it uses a new "format" of config file.
4) Read data from other sources, e.g. precompiled sea/land polygons. I don't plan to code that but I think this remains a possible option to increase quality.
Ok, can be added later on if required. Thanks! WanMil
participants (6)
-
Gerd Petermann -
GerdP
-
Henning Scholland -
Minko -
Thorsten Kukuk -
WanMil