Re: [mkgmap-dev] MDR building out-of-memory
Hi Ticker, I think the cache is not meant to improve run time, it is used to deduplicate and thus reduce memory. Maybe it would be better to use a smaller chunk size and no cache. No idea why I didn't use merged = new ArrayList<>(len); Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Dienstag, 11. Mai 2021 19:19 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] MDR building out-of-memory Hi Gerd I've looked at this, and if Mdr5 space becomes a problem again, I'll consider converting to it. A couple of comments: My map had 2909735 poi so the sort chunk size was ~727433. The cache sizes after each chunk were 563095, 603595, 597239 & 605718. Is the cache worth-while for this low hit-rate? Just running the Gmapsupp combiner on existing tiles (without --route, so no streets), I got a run time of 1 min 44 secs with the cache and 1 min 30 without! However most of this time is copying the tiles into gmapsupp.img so not an accurate statistic. You could pre-allocate List<> "merged" with the correct size. Ticker On Tue, 2021-05-11 at 14:40 +, Gerd Petermann wrote: > Hi Ticker, > > I've committed the patch as is. I've not seen big changes in > performance, but I've used a different (already existing) set of > files which was created with my own style. For me, > Mdr11.preWriteImpl() is the most problematic part reg. OOM errors. > > Maybe look at the code which uses LargeListSorter. > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Dienstag, 11. Mai 2021 13:27 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] MDR building out-of-memory > > Hi Gerd > > Here is updated version of patch. > > Changes from last: > > Uses your cache code for region and country (in 2 places). For > British > Isles, there are 190 regions and 7 countries, so I don't think the > extra memory will be a problem and there should be some performance > benefit. > > Delays allocating cities until it can use sortKeys.size() for initial > allocation. For above map this is 0.07% too big, so I don't think > trimToSize() is worthwhile. > > Shares the Sort object between the 4 methods. > > Ticker > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] MDR building out-of-memory
Hi Gerd I've looked at this, and if Mdr5 space becomes a problem again, I'll consider converting to it. A couple of comments: My map had 2909735 poi so the sort chunk size was ~727433. The cache sizes after each chunk were 563095, 603595, 597239 & 605718. Is the cache worth-while for this low hit-rate? Just running the Gmapsupp combiner on existing tiles (without --route, so no streets), I got a run time of 1 min 44 secs with the cache and 1 min 30 without! However most of this time is copying the tiles into gmapsupp.img so not an accurate statistic. You could pre-allocate List<> "merged" with the correct size. Ticker On Tue, 2021-05-11 at 14:40 +, Gerd Petermann wrote: > Hi Ticker, > > I've committed the patch as is. I've not seen big changes in > performance, but I've used a different (already existing) set of > files which was created with my own style. For me, > Mdr11.preWriteImpl() is the most problematic part reg. OOM errors. > > Maybe look at the code which uses LargeListSorter. > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Dienstag, 11. Mai 2021 13:27 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] MDR building out-of-memory > > Hi Gerd > > Here is updated version of patch. > > Changes from last: > > Uses your cache code for region and country (in 2 places). For > British > Isles, there are 190 regions and 7 countries, so I don't think the > extra memory will be a problem and there should be some performance > benefit. > > Delays allocating cities until it can use sortKeys.size() for initial > allocation. For above map this is 0.07% too big, so I don't think > trimToSize() is worthwhile. > > Shares the Sort object between the 4 methods. > > Ticker > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] MDR building out-of-memory
Hi Ticker, I've committed the patch as is. I've not seen big changes in performance, but I've used a different (already existing) set of files which was created with my own style. For me, Mdr11.preWriteImpl() is the most problematic part reg. OOM errors. Maybe look at the code which uses LargeListSorter. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Dienstag, 11. Mai 2021 13:27 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] MDR building out-of-memory Hi Gerd Here is updated version of patch. Changes from last: Uses your cache code for region and country (in 2 places). For British Isles, there are 190 regions and 7 countries, so I don't think the extra memory will be a problem and there should be some performance benefit. Delays allocating cities until it can use sortKeys.size() for initial allocation. For above map this is 0.07% too big, so I don't think trimToSize() is worthwhile. Shares the Sort object between the 4 methods. Ticker ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit r4705: reduce peak memory in Mdr5.preWriteImpl() (called by combiners for --index)
Version mkgmap-r4705 was committed by gerd on Tue, 11 May 2021 reduce peak memory in Mdr5.preWriteImpl() (called by combiners for --index) mdr5Mem_v3.patch by Ticker Berkin http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4705 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] multipolygon label
Hi Mike, might take a while before I use this patch. It conflicts with the faster-mp branch and I plan to merge that into trunk soon to get more feedback. Gerd Von: mkgmap-dev im Auftrag von Mike Baggaley Gesendet: Dienstag, 11. Mai 2021 13:54 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] multipolygon label Hi Gerd, Please find attached a small patch that fixes a problem with the use of the label role in multi-polygon relations. Currently, if a node has the role of label but has no name or a different name from the polygon, a message is output saying the node will not be used. However, it is used anyway. The patch stops the override and does not display a warning for a node with no name. Cheers, Mike ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit r4703: improve RoadMerger (based on merge-roads-reversed-v6.patch)
Hi Mike, okay, I commited the code to get some more feedback regarding the usability ;) Please check attached patch which would document new option --allow-reverse-merge=detect|no|yes I still don't know how to document the new internal tag. It probably needs a new section. Gerd Von: mkgmap-dev im Auftrag von Mike Baggaley Gesendet: Dienstag, 11. Mai 2021 14:08 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] Commit r4703: improve RoadMerger (based on merge-roads-reversed-v6.patch) Hi Gerd, No problem with that, but I don't think it should be a hidden option, and the use of 'force' suggests it will reverse ways that are direction sensitive. I suggest --allow-reverse-merge and add it to the documentation stating that if your style includes mkgmap:has_direction is it on by default. I don't have any direction sensitive ways in my style and hence will need to use the option. Cheers, Mike -Original Message- From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] Sent: 11 May 2021 12:21 To: Development list for mkgmap Subject: Re: [mkgmap-dev] Commit r4703: improve RoadMerger (based on merge-roads-reversed-v6.patch) Hi Mike, it is off by default because it will cause trouble with some styles / TYP files which rely on the direction but don't set that the new special tag (yet). Gerd Von: mkgmap-dev im Auftrag von Mike Baggaley Gesendet: Dienstag, 11. Mai 2021 13:15 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Commit r4703: improve RoadMerger (based on merge-roads-reversed-v6.patch) Hi Gerd, I may be misunderstanding this, but the explanation of when it is enabled seems illogical. It seems to me that reversing should be the default except on ways that have mkgmap:has-direction=true unless a switch is given to disable it. Or it could be off by default and a switch enables it, except for ways that have mkgmap:has-direction=true. Cheers, Mike -Original Message- From: svn commit [mailto:s...@mkgmap.org.uk] Sent: 11 May 2021 11:22 To: mkgmap-...@lists.mkgmap.org.uk; mkgmap-dev@lists.mkgmap.org.uk Subject: [mkgmap-dev] Commit r4703: improve RoadMerger (based on merge-roads-reversed-v6.patch) Version mkgmap-r4703 was committed by gerd on Tue, 11 May 2021 improve RoadMerger (based on merge-roads-reversed-v6.patch) This has two effects: - it allows RoadMerger to merge roads which build a sharp angle, if that is done an info message is logged - it allows RoadMerger to merge roads with different directions be reversing the order of points if special criteria are met - implement new special tag mkgmap:has-direction=true which tells mkgmap that the direction of the way is important and should not be reversed. The routing tags oneway=yes or oneway=-1 have the same effect, but they also effect routing. Use this tag if you have a TYP file which renders lines different (e.g. cycleway on the right or on the left side) to prevent a reverse merge - implements new experimental option --x-force-reverse-merge Merging with reverse produces smaller maps, esp. smaller NET and NOD files, it may have an influence on routing. Reversing of roads is disabled unless mkgmap detects that the style has at least one rule which adds mkgmap:has-direction=true in rule file lines or option --x-force-reverse-merge is used. The program checks if any line that was added for a given OSM way has the tag mkgmap:has-direction=true. If one is found the tag is propagated to the road(s) for that OSM way so no reversing happens. Roads with different direction attributes are not merged. The option --x-force-reverse-merge is meant for those who don't use a TYP file or don't render left/right attributes with different types. All others should not use the option and adapt the style instead. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4703 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev allow-reverse.patch Description: allow-reverse.patch ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit r4703: improve RoadMerger (based on merge-roads-reversed-v6.patch)
Hi Gerd, No problem with that, but I don't think it should be a hidden option, and the use of 'force' suggests it will reverse ways that are direction sensitive. I suggest --allow-reverse-merge and add it to the documentation stating that if your style includes mkgmap:has_direction is it on by default. I don't have any direction sensitive ways in my style and hence will need to use the option. Cheers, Mike -Original Message- From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] Sent: 11 May 2021 12:21 To: Development list for mkgmap Subject: Re: [mkgmap-dev] Commit r4703: improve RoadMerger (based on merge-roads-reversed-v6.patch) Hi Mike, it is off by default because it will cause trouble with some styles / TYP files which rely on the direction but don't set that the new special tag (yet). Gerd Von: mkgmap-dev im Auftrag von Mike Baggaley Gesendet: Dienstag, 11. Mai 2021 13:15 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Commit r4703: improve RoadMerger (based on merge-roads-reversed-v6.patch) Hi Gerd, I may be misunderstanding this, but the explanation of when it is enabled seems illogical. It seems to me that reversing should be the default except on ways that have mkgmap:has-direction=true unless a switch is given to disable it. Or it could be off by default and a switch enables it, except for ways that have mkgmap:has-direction=true. Cheers, Mike -Original Message- From: svn commit [mailto:s...@mkgmap.org.uk] Sent: 11 May 2021 11:22 To: mkgmap-...@lists.mkgmap.org.uk; mkgmap-dev@lists.mkgmap.org.uk Subject: [mkgmap-dev] Commit r4703: improve RoadMerger (based on merge-roads-reversed-v6.patch) Version mkgmap-r4703 was committed by gerd on Tue, 11 May 2021 improve RoadMerger (based on merge-roads-reversed-v6.patch) This has two effects: - it allows RoadMerger to merge roads which build a sharp angle, if that is done an info message is logged - it allows RoadMerger to merge roads with different directions be reversing the order of points if special criteria are met - implement new special tag mkgmap:has-direction=true which tells mkgmap that the direction of the way is important and should not be reversed. The routing tags oneway=yes or oneway=-1 have the same effect, but they also effect routing. Use this tag if you have a TYP file which renders lines different (e.g. cycleway on the right or on the left side) to prevent a reverse merge - implements new experimental option --x-force-reverse-merge Merging with reverse produces smaller maps, esp. smaller NET and NOD files, it may have an influence on routing. Reversing of roads is disabled unless mkgmap detects that the style has at least one rule which adds mkgmap:has-direction=true in rule file lines or option --x-force-reverse-merge is used. The program checks if any line that was added for a given OSM way has the tag mkgmap:has-direction=true. If one is found the tag is propagated to the road(s) for that OSM way so no reversing happens. Roads with different direction attributes are not merged. The option --x-force-reverse-merge is meant for those who don't use a TYP file or don't render left/right attributes with different types. All others should not use the option and adapt the style instead. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4703 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] multipolygon label
Hi Gerd, Please find attached a small patch that fixes a problem with the use of the label role in multi-polygon relations. Currently, if a node has the role of label but has no name or a different name from the polygon, a message is output saying the node will not be used. However, it is used anyway. The patch stops the override and does not display a warning for a node with no name. Cheers, Mike RelationLabel.patch Description: Binary data ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] MDR building out-of-memory
Hi Gerd
Here is updated version of patch.
Changes from last:
Uses your cache code for region and country (in 2 places). For British
Isles, there are 190 regions and 7 countries, so I don't think the
extra memory will be a problem and there should be some performance
benefit.
Delays allocating cities until it can use sortKeys.size() for initial
allocation. For above map this is 0.07% too big, so I don't think
trimToSize() is worthwhile.
Shares the Sort object between the 4 methods.
Ticker
Index: src/uk/me/parabola/imgfmt/app/mdr/Mdr5.java
===
--- src/uk/me/parabola/imgfmt/app/mdr/Mdr5.java (revision 4702)
+++ src/uk/me/parabola/imgfmt/app/mdr/Mdr5.java (working copy)
@@ -15,7 +15,9 @@
import java.text.Collator;
import java.util.ArrayList;
import java.util.Collections;
+import java.util.HashMap;
import java.util.List;
+import java.util.Map;
import uk.me.parabola.imgfmt.Utils;
import uk.me.parabola.imgfmt.app.ImgFileWriter;
@@ -32,12 +34,16 @@
* @author Steve Ratcliffe
*/
public class Mdr5 extends MdrMapSection {
- private List allCities = new ArrayList<>();
- private List cities = new ArrayList<>();
+ private ArrayList allCities = new ArrayList<>();
+ private ArrayList cities;
private int maxCityIndex;
private int localCitySize;
private int mdr20PointerSize = 0; // bytes for mdr20 pointer, or 0 if no mdr20
+ // We need a common area to save the mdr20 values, since there can be multiple
+ // city records with the same global city index
+ private int[] mdr20s;
+
public Mdr5(MdrConfig config) {
setConfig(config);
}
@@ -54,10 +60,20 @@
*/
@Override
public void preWriteImpl() {
+ allCities.trimToSize();
localCitySize = Utils.numberToPointerSize(maxCityIndex + 1);
+ Sort sort = getConfig().getSort();
+ genCitiesAndMdr20s(sort);
+ // calculate positions for the different road indexes
+ calcMdr20SortPos(sort);
+ calcMdr21SortPos(sort);
+ calcMdr22SortPos(sort);
+ }
+ private void genCitiesAndMdr20s(Sort sort) {
List> sortKeys = new ArrayList<>(allCities.size());
- Sort sort = getConfig().getSort();
+ Map regionCache = new HashMap<>();
+ Map countryCache = new HashMap<>();
for (Mdr5Record m : allCities) {
if (m.getName() == null)
continue;
@@ -64,21 +80,22 @@
// Sort by city name, region name, country name and map index.
SortKey sortKey = sort.createSortKey(m, m.getName());
- SortKey regionKey = sort.createSortKey(null, m.getRegionName());
- SortKey countryKey = sort.createSortKey(null, m.getCountryName(), m.getMapIndex());
+ SortKey regionKey = sort.createSortKey(null, m.getRegionName(), 0, regionCache);
+ SortKey countryKey = sort.createSortKey(null, m.getCountryName(), m.getMapIndex(), countryCache);
sortKey = new MultiSortKey<>(sortKey, regionKey, countryKey);
sortKeys.add(sortKey);
}
+ regionCache = null;
+ countryCache = null;
sortKeys.sort(null);
- Collator collator = getConfig().getSort().getCollator();
+ cities = new ArrayList<>(sortKeys.size());
+ Collator collator = sort.getCollator();
int count = 0;
Mdr5Record lastCity = null;
- // We need a common area to save the mdr20 values, since there can be multiple
- // city records with the same global city index
- int[] mdr20s = new int[sortKeys.size()+1];
+ mdr20s = new int[sortKeys.size()+1];
int mdr20count = 0;
for (SortKey key : sortKeys) {
@@ -99,18 +116,16 @@
lastCity = c;
}
}
- // calculate positions for the different road indexes
- calcMdr20SortPos();
- calcMdr21SortPos();
- calcMdr22SortPos();
+ //cities.trimToSize(); // it might be a fraction smaller than allocated, but not worth the cost of reallocation
}
-
+
/**
* Calculate a position when sorting by name, region, and country- This is used for MDR20.
*/
- private void calcMdr20SortPos() {
+ private void calcMdr20SortPos(Sort sort) {
List> sortKeys = new ArrayList<>(allCities.size());
- Sort sort = getConfig().getSort();
+ Map regionCache = new HashMap<>();
+ Map countryCache = new HashMap<>();
for (Mdr5Record m : allCities) {
if (m.getName() == null)
continue;
@@ -117,11 +132,13 @@
// Sort by city name, region name, and country name .
SortKey sortKey = sort.createSortKey(m, m.getName());
- SortKey regionKey = sort.createSortKey(null, m.getRegionName());
- SortKey countryKey = sort.createSortKey(null, m.getCountryName());
+ SortKey regionKey = sort.createSortKey(null, m.getRegionName(), 0, regionCache);
+ SortKey countryKey = sort.createSortKey(null, m.getCountryName(), 0, countryCache);
sortKey = new MultiSortKey<>(sortKey, regionKey, countryKey);
sortKeys.add(sortKey);
}
+ regionCache = null;
+ countryCache = null;
sortKeys.sort(null);
SortKey lastKey = null;
@@ -138,9 +155,8 @@
/**
* Calculate a position when sorting by region- This is used for MDR21.
*/
- private void calcMdr21SortPos() {
+ private void calcMdr
Re: [mkgmap-dev] Commit r4703: improve RoadMerger (based on merge-roads-reversed-v6.patch)
Hi Mike, it is off by default because it will cause trouble with some styles / TYP files which rely on the direction but don't set that the new special tag (yet). Gerd Von: mkgmap-dev im Auftrag von Mike Baggaley Gesendet: Dienstag, 11. Mai 2021 13:15 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Commit r4703: improve RoadMerger (based on merge-roads-reversed-v6.patch) Hi Gerd, I may be misunderstanding this, but the explanation of when it is enabled seems illogical. It seems to me that reversing should be the default except on ways that have mkgmap:has-direction=true unless a switch is given to disable it. Or it could be off by default and a switch enables it, except for ways that have mkgmap:has-direction=true. Cheers, Mike -Original Message- From: svn commit [mailto:s...@mkgmap.org.uk] Sent: 11 May 2021 11:22 To: mkgmap-...@lists.mkgmap.org.uk; mkgmap-dev@lists.mkgmap.org.uk Subject: [mkgmap-dev] Commit r4703: improve RoadMerger (based on merge-roads-reversed-v6.patch) Version mkgmap-r4703 was committed by gerd on Tue, 11 May 2021 improve RoadMerger (based on merge-roads-reversed-v6.patch) This has two effects: - it allows RoadMerger to merge roads which build a sharp angle, if that is done an info message is logged - it allows RoadMerger to merge roads with different directions be reversing the order of points if special criteria are met - implement new special tag mkgmap:has-direction=true which tells mkgmap that the direction of the way is important and should not be reversed. The routing tags oneway=yes or oneway=-1 have the same effect, but they also effect routing. Use this tag if you have a TYP file which renders lines different (e.g. cycleway on the right or on the left side) to prevent a reverse merge - implements new experimental option --x-force-reverse-merge Merging with reverse produces smaller maps, esp. smaller NET and NOD files, it may have an influence on routing. Reversing of roads is disabled unless mkgmap detects that the style has at least one rule which adds mkgmap:has-direction=true in rule file lines or option --x-force-reverse-merge is used. The program checks if any line that was added for a given OSM way has the tag mkgmap:has-direction=true. If one is found the tag is propagated to the road(s) for that OSM way so no reversing happens. Roads with different direction attributes are not merged. The option --x-force-reverse-merge is meant for those who don't use a TYP file or don't render left/right attributes with different types. All others should not use the option and adapt the style instead. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4703 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit r4703: improve RoadMerger (based on merge-roads-reversed-v6.patch)
Hi Gerd, I may be misunderstanding this, but the explanation of when it is enabled seems illogical. It seems to me that reversing should be the default except on ways that have mkgmap:has-direction=true unless a switch is given to disable it. Or it could be off by default and a switch enables it, except for ways that have mkgmap:has-direction=true. Cheers, Mike -Original Message- From: svn commit [mailto:s...@mkgmap.org.uk] Sent: 11 May 2021 11:22 To: mkgmap-...@lists.mkgmap.org.uk; mkgmap-dev@lists.mkgmap.org.uk Subject: [mkgmap-dev] Commit r4703: improve RoadMerger (based on merge-roads-reversed-v6.patch) Version mkgmap-r4703 was committed by gerd on Tue, 11 May 2021 improve RoadMerger (based on merge-roads-reversed-v6.patch) This has two effects: - it allows RoadMerger to merge roads which build a sharp angle, if that is done an info message is logged - it allows RoadMerger to merge roads with different directions be reversing the order of points if special criteria are met - implement new special tag mkgmap:has-direction=true which tells mkgmap that the direction of the way is important and should not be reversed. The routing tags oneway=yes or oneway=-1 have the same effect, but they also effect routing. Use this tag if you have a TYP file which renders lines different (e.g. cycleway on the right or on the left side) to prevent a reverse merge - implements new experimental option --x-force-reverse-merge Merging with reverse produces smaller maps, esp. smaller NET and NOD files, it may have an influence on routing. Reversing of roads is disabled unless mkgmap detects that the style has at least one rule which adds mkgmap:has-direction=true in rule file lines or option --x-force-reverse-merge is used. The program checks if any line that was added for a given OSM way has the tag mkgmap:has-direction=true. If one is found the tag is propagated to the road(s) for that OSM way so no reversing happens. Roads with different direction attributes are not merged. The option --x-force-reverse-merge is meant for those who don't use a TYP file or don't render left/right attributes with different types. All others should not use the option and adapt the style instead. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4703 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit r4702: show stacktrace when OutOfMemoryError occurs, helps to decide if maxjobs should be decreased or if one of the combiners is the problem
Hi Mike, yes, that would be even better. Gerd Von: mkgmap-dev im Auftrag von Mike Baggaley Gesendet: Dienstag, 11. Mai 2021 12:11 An: 'svn commit'; mkgmap-...@lists.mkgmap.org.uk; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Commit r4702: show stacktrace when OutOfMemoryError occurs,helps to decide if maxjobs should be decreased or if one of the combiners is the problem Hi Gerd, Would it not be better for the code to detect whether it is a combiner and adjust the message accordingly? Cheers, Mike -Original Message- From: svn commit [mailto:s...@mkgmap.org.uk] Sent: 11 May 2021 08:33 To: mkgmap-...@lists.mkgmap.org.uk; mkgmap-dev@lists.mkgmap.org.uk Subject: [mkgmap-dev] Commit r4702: show stacktrace when OutOfMemoryError occurs, helps to decide if maxjobs should be decreased or if one of the combiners is the problem Version mkgmap-r4702 was committed by gerd on Tue, 11 May 2021 show stacktrace when OutOfMemoryError occurs, helps to decide if maxjobs should be decreased or if one of the combiners is the problem http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4702 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit r4704: detect duplicate roads to log a warning when the lines rules add equal routable lines for one OSM way and ignore them
Version mkgmap-r4704 was committed by gerd on Tue, 11 May 2021 detect duplicate roads to log a warning when the lines rules add equal routable lines for one OSM way and ignore them - Uses the code in RoadMerger to detect roads with equal attributes (type, resolution, speed, class, oneway, vehicles, ...) - Enable logging of warnings in StyledConverter to see those messages. This is not (yet) detecting two roads where all attributes are equal despite the min/max resolution. It might be changed to detect that later as this also blows up the IMG file for no good reason. Styles which add multiple roads for one OSM way should make use of mkgmap:highest-resolution-only=true anyway. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4704 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit r4703: improve RoadMerger (based on merge-roads-reversed-v6.patch)
Version mkgmap-r4703 was committed by gerd on Tue, 11 May 2021 improve RoadMerger (based on merge-roads-reversed-v6.patch) This has two effects: - it allows RoadMerger to merge roads which build a sharp angle, if that is done an info message is logged - it allows RoadMerger to merge roads with different directions be reversing the order of points if special criteria are met - implement new special tag mkgmap:has-direction=true which tells mkgmap that the direction of the way is important and should not be reversed. The routing tags oneway=yes or oneway=-1 have the same effect, but they also effect routing. Use this tag if you have a TYP file which renders lines different (e.g. cycleway on the right or on the left side) to prevent a reverse merge - implements new experimental option --x-force-reverse-merge Merging with reverse produces smaller maps, esp. smaller NET and NOD files, it may have an influence on routing. Reversing of roads is disabled unless mkgmap detects that the style has at least one rule which adds mkgmap:has-direction=true in rule file lines or option --x-force-reverse-merge is used. The program checks if any line that was added for a given OSM way has the tag mkgmap:has-direction=true. If one is found the tag is propagated to the road(s) for that OSM way so no reversing happens. Roads with different direction attributes are not merged. The option --x-force-reverse-merge is meant for those who don't use a TYP file or don't render left/right attributes with different types. All others should not use the option and adapt the style instead. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4703 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Duplicate roads added by default style
Hi Gerd,
I had been thinking along those lines, but when I saw the previous posts
thought someone else was looking into the same problem.
Cheers,
Mike
-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
Sent: 11 May 2021 10:19
To: Development list for mkgmap
Subject: Re: [mkgmap-dev] Duplicate roads added by default style
Hi Mike,
maybe you can use the code for --report-similar-arcs as a base to detect and
possible drop identical arcs?
Didn't try it, I have no idea if that may create incorrect NOD data.
Gerd
Von: mkgmap-dev im Auftrag von Mike
Baggaley
Gesendet: Montag, 10. Mai 2021 17:15
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] Duplicate roads added by default style
Hi Gerd,
I misunderstood the problem you were discussing - I was indeed referring to
overlapping ways from different OSM ways. The multiple ways from the same
OSM way is not a problem for me in the style I use (I think - I haven't
enabled any logging of this so perhaps might not have noticed).
Overlapping ways from different OSM ways is however a problem I have. Mainly
because I include routing around car parks and some car parks have part of
their outline coincident with a road.
Cheers,
Mike
-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
Sent: 10 May 2021 16:07
To: Development list for mkgmap
Subject: Re: [mkgmap-dev] Duplicate roads added by default style
Hi Mike,
Please give an example, I don't understand what you mean. Do you talk about
the situation that two OSM ways are overlapping (sharing segments)? That
would be a completely different problem and requires a different check which
maybe also looks at the layer=* tag.
The issue here is that the style adds multiple identical routable lines for
the same OSM way. Those duplicates would just blows up the road network and
therefore can be safely ignored.
The attached patch is like v5 but contains the additional check in
StyledConverter.
Gerd
Von: mkgmap-dev im Auftrag von Mike
Baggaley
Gesendet: Montag, 10. Mai 2021 16:56
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] Duplicate roads added by default style
HI Gerd,
I would ideally like a new mkgmap tag that if found would remove the
duplicated way or part of a way. This could get tricky when the part to be
deleted is in the middle of the way, as it would need to produce two ways.
Something like:
railway=platform {set mkgmap:removeoverlap=true} [0x16 road_class=0
road_speed=0 resolution 23]
The code would need to check that the access of the overlapping way and
could merge the accesses if necessary. A decision would also have to be made
what to do if two overlapping ways both have the tag set.
Cheers,
Mike
-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
Sent: 10 May 2021 10:21
To: Development list for mkgmap
Subject: Re: [mkgmap-dev] Duplicate roads added by default style
Hi Felix,
sure, I meant roads which RoadMerger would combine. Roadmerger checks a lot
more attributes.
Multiple (different) routable ways for one OSM way are quite normal, esp.
with the --make-opposite-cycleways option.
I think it's worth to log a warning for each.
Gerd
Von: mkgmap-dev im Auftrag von
Felix Hartmann
Gesendet: Montag, 10. Mai 2021 11:16
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Duplicate roads added by default style
It makes the style very complicated to try to remove any identical copies -
I do this by setting loads of temporary keys, that are checked later for
existing or not existing and based on that add or not add other lines. I
guess some actual duplicates will still happen.
On Mon, 10 May 2021 at 17:14, Felix Hartmann
mailto:extremecar...@gmail.com>> wrote:
hmm no, please no warning. This can be very beneficial. As long as the type
OR road_speed OR road_class OR oneway plus direction is different. The above
of course makes no sense, as it will set exactly the same road twice.
On Mon, 10 May 2021 at 16:49, Gerd Petermann
mailto:gpetermann_muenc...@hotmail.com>>
wrote:
Hi all,
while double checking patch for the RoadMerger I wondered what might happen
if the style adds two or more identical roads for the same OSM way.
Of course this makes no sense but to my surprise I found out that this
really happens with the default style.
A way with e.g. highway=footway and railway=platform is added twice
...
highway=footway {set tmp:stopMopUp=yes} [0x16 road_class=0 road_speed=0
resolution 23 continue with_actions]
...
railway=platform [0x16 road_class=0 road_speed=0 resolution 23]
Of course the default style should be fixed to avoid that but I think mkgmap
can detect this easily and should print a warning when the style does that?
Gerd
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.
Re: [mkgmap-dev] Commit r4702: show stacktrace when OutOfMemoryError occurs, helps to decide if maxjobs should be decreased or if one of the combiners is the problem
Hi Gerd, Would it not be better for the code to detect whether it is a combiner and adjust the message accordingly? Cheers, Mike -Original Message- From: svn commit [mailto:s...@mkgmap.org.uk] Sent: 11 May 2021 08:33 To: mkgmap-...@lists.mkgmap.org.uk; mkgmap-dev@lists.mkgmap.org.uk Subject: [mkgmap-dev] Commit r4702: show stacktrace when OutOfMemoryError occurs, helps to decide if maxjobs should be decreased or if one of the combiners is the problem Version mkgmap-r4702 was committed by gerd on Tue, 11 May 2021 show stacktrace when OutOfMemoryError occurs, helps to decide if maxjobs should be decreased or if one of the combiners is the problem http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4702 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Duplicate roads added by default style
Hi Mike,
maybe you can use the code for --report-similar-arcs as a base to detect and
possible drop identical arcs?
Didn't try it, I have no idea if that may create incorrect NOD data.
Gerd
Von: mkgmap-dev im Auftrag von Mike
Baggaley
Gesendet: Montag, 10. Mai 2021 17:15
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] Duplicate roads added by default style
Hi Gerd,
I misunderstood the problem you were discussing - I was indeed referring to
overlapping ways from different OSM ways. The multiple ways from the same
OSM way is not a problem for me in the style I use (I think - I haven't
enabled any logging of this so perhaps might not have noticed).
Overlapping ways from different OSM ways is however a problem I have. Mainly
because I include routing around car parks and some car parks have part of
their outline coincident with a road.
Cheers,
Mike
-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
Sent: 10 May 2021 16:07
To: Development list for mkgmap
Subject: Re: [mkgmap-dev] Duplicate roads added by default style
Hi Mike,
Please give an example, I don't understand what you mean. Do you talk about
the situation that two OSM ways are overlapping (sharing segments)? That
would be a completely different problem and requires a different check which
maybe also looks at the layer=* tag.
The issue here is that the style adds multiple identical routable lines for
the same OSM way. Those duplicates would just blows up the road network and
therefore can be safely ignored.
The attached patch is like v5 but contains the additional check in
StyledConverter.
Gerd
Von: mkgmap-dev im Auftrag von Mike
Baggaley
Gesendet: Montag, 10. Mai 2021 16:56
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] Duplicate roads added by default style
HI Gerd,
I would ideally like a new mkgmap tag that if found would remove the
duplicated way or part of a way. This could get tricky when the part to be
deleted is in the middle of the way, as it would need to produce two ways.
Something like:
railway=platform {set mkgmap:removeoverlap=true} [0x16 road_class=0
road_speed=0 resolution 23]
The code would need to check that the access of the overlapping way and
could merge the accesses if necessary. A decision would also have to be made
what to do if two overlapping ways both have the tag set.
Cheers,
Mike
-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
Sent: 10 May 2021 10:21
To: Development list for mkgmap
Subject: Re: [mkgmap-dev] Duplicate roads added by default style
Hi Felix,
sure, I meant roads which RoadMerger would combine. Roadmerger checks a lot
more attributes.
Multiple (different) routable ways for one OSM way are quite normal, esp.
with the --make-opposite-cycleways option.
I think it's worth to log a warning for each.
Gerd
Von: mkgmap-dev im Auftrag von
Felix Hartmann
Gesendet: Montag, 10. Mai 2021 11:16
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Duplicate roads added by default style
It makes the style very complicated to try to remove any identical copies -
I do this by setting loads of temporary keys, that are checked later for
existing or not existing and based on that add or not add other lines. I
guess some actual duplicates will still happen.
On Mon, 10 May 2021 at 17:14, Felix Hartmann
mailto:extremecar...@gmail.com>> wrote:
hmm no, please no warning. This can be very beneficial. As long as the type
OR road_speed OR road_class OR oneway plus direction is different. The above
of course makes no sense, as it will set exactly the same road twice.
On Mon, 10 May 2021 at 16:49, Gerd Petermann
mailto:gpetermann_muenc...@hotmail.com>>
wrote:
Hi all,
while double checking patch for the RoadMerger I wondered what might happen
if the style adds two or more identical roads for the same OSM way.
Of course this makes no sense but to my surprise I found out that this
really happens with the default style.
A way with e.g. highway=footway and railway=platform is added twice
...
highway=footway {set tmp:stopMopUp=yes} [0x16 road_class=0 road_speed=0
resolution 23 continue with_actions]
...
railway=platform [0x16 road_class=0 road_speed=0 resolution 23]
Of course the default style should be fixed to avoid that but I think mkgmap
can detect this easily and should print a warning when the style does that?
Gerd
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
--
Felix Hartman - Openmtbmap.org & VeloMap.org
--
Felix Hartman - Openmtbmap.org & VeloMap.org
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] MDR building out-of-memory
Hi Ticker, sorry, here's the patch. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Dienstag, 11. Mai 2021 10:07 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] MDR building out-of-memory Hi Gerd allCities.trimToSize() is at the top of preWriteImpl(). cities is empty at this point. I should trim it at the end of genCitiesAndMdr20s or delay allocation so it can be made the same size as allCities. Is there any reason not to share "sort" between genCitiesAndMdr20s, calcMdr20/1/2SortPos() - I'll try it. Your patch wasn't attached. I had given up trying to understand the different combinations of sort keys for mrd20/1/2 and, until it runs out of memory again, I'd rather not touch it. I'll experiment a bit more and send another patch in a while. Just seen your change to show the stacktrace when OOM - good. Ticker On Tue, 2021-05-11 at 07:04 +, Gerd Petermann wrote: > Hi Ticker, > > thanks, good findings! > > the patch doesn't use trimToSize() on cities. Did you change your > mind? > The part about the scope is interesting. At first glance I thought > this should make no difference but it probably helps GC to detect > that this array cannot be garbage collected. > > The SortKeys stuff is really eating memory and it would good to find > a better solution. One approach is to use the cache as in attached > patch but that only helps when memory is really the problem, it slows > down processing for other situations. > Maybe better would be to first collect all combinations of > region+country, sort them, and use the position in that list to sort > other objects? > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Montag, 10. Mai 2021 23:05 > An: mkgmap development > Betreff: [mkgmap-dev] MDR building out-of-memory > > Hi Gerd > > Since downloading loading britain-and-ireland-latest.osm.pbf I had > been > unable to build a gmapsupp because of running out of heap (my > hardware > is 32 bit, -Xmx1540M is largest value allowed) > > My problem is mainly because I have 1731146 cities (along with > 1046096 > streets) > > Looking at Mdr5 processing, I've changed it in 3 ways to improve > memory > usage and garbage collection. > > 1/ use trimToSize() after all the cities are loaded from the > individual > tile .img. I presume that the growth factor gradually increases as it > runs out of allocated array space. I had to change the declaration > from > List to ArrayList to allow this, but I can't > see any problem in this. > > 2/ Move the main part of preWriteImpl into its own method so the > first > sortKeys ArrayList and Sort can be freed before calcMdr20/1/2() each > create another massive SortKeys and Sort. > > 3/ Move the scope of mdr20s to a class variable. This is referenced > by > all the Mdr5Records and the scope of where it was declared before > seemed to to cause the garbage collector major problems - it churned > for 5 mins using all the processors before running out of memory. > After > moving it, the whole of mdr is built in a couple of mins with cpu > usage > mostly < 125%. > > Ticker > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev mdr5Mem-with-cache.patch Description: mdr5Mem-with-cache.patch ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] MDR building out-of-memory
Hi Gerd allCities.trimToSize() is at the top of preWriteImpl(). cities is empty at this point. I should trim it at the end of genCitiesAndMdr20s or delay allocation so it can be made the same size as allCities. Is there any reason not to share "sort" between genCitiesAndMdr20s, calcMdr20/1/2SortPos() - I'll try it. Your patch wasn't attached. I had given up trying to understand the different combinations of sort keys for mrd20/1/2 and, until it runs out of memory again, I'd rather not touch it. I'll experiment a bit more and send another patch in a while. Just seen your change to show the stacktrace when OOM - good. Ticker On Tue, 2021-05-11 at 07:04 +, Gerd Petermann wrote: > Hi Ticker, > > thanks, good findings! > > the patch doesn't use trimToSize() on cities. Did you change your > mind? > The part about the scope is interesting. At first glance I thought > this should make no difference but it probably helps GC to detect > that this array cannot be garbage collected. > > The SortKeys stuff is really eating memory and it would good to find > a better solution. One approach is to use the cache as in attached > patch but that only helps when memory is really the problem, it slows > down processing for other situations. > Maybe better would be to first collect all combinations of > region+country, sort them, and use the position in that list to sort > other objects? > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Montag, 10. Mai 2021 23:05 > An: mkgmap development > Betreff: [mkgmap-dev] MDR building out-of-memory > > Hi Gerd > > Since downloading loading britain-and-ireland-latest.osm.pbf I had > been > unable to build a gmapsupp because of running out of heap (my > hardware > is 32 bit, -Xmx1540M is largest value allowed) > > My problem is mainly because I have 1731146 cities (along with > 1046096 > streets) > > Looking at Mdr5 processing, I've changed it in 3 ways to improve > memory > usage and garbage collection. > > 1/ use trimToSize() after all the cities are loaded from the > individual > tile .img. I presume that the growth factor gradually increases as it > runs out of allocated array space. I had to change the declaration > from > List to ArrayList to allow this, but I can't > see any problem in this. > > 2/ Move the main part of preWriteImpl into its own method so the > first > sortKeys ArrayList and Sort can be freed before calcMdr20/1/2() each > create another massive SortKeys and Sort. > > 3/ Move the scope of mdr20s to a class variable. This is referenced > by > all the Mdr5Records and the scope of where it was declared before > seemed to to cause the garbage collector major problems - it churned > for 5 mins using all the processors before running out of memory. > After > moving it, the whole of mdr is built in a couple of mins with cpu > usage > mostly < 125%. > > Ticker > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit r4702: show stacktrace when OutOfMemoryError occurs, helps to decide if maxjobs should be decreased or if one of the combiners is the problem
Version mkgmap-r4702 was committed by gerd on Tue, 11 May 2021 show stacktrace when OutOfMemoryError occurs, helps to decide if maxjobs should be decreased or if one of the combiners is the problem http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4702 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] MDR building out-of-memory
Hi Ticker, thanks, good findings! the patch doesn't use trimToSize() on cities. Did you change your mind? The part about the scope is interesting. At first glance I thought this should make no difference but it probably helps GC to detect that this array cannot be garbage collected. The SortKeys stuff is really eating memory and it would good to find a better solution. One approach is to use the cache as in attached patch but that only helps when memory is really the problem, it slows down processing for other situations. Maybe better would be to first collect all combinations of region+country, sort them, and use the position in that list to sort other objects? Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Montag, 10. Mai 2021 23:05 An: mkgmap development Betreff: [mkgmap-dev] MDR building out-of-memory Hi Gerd Since downloading loading britain-and-ireland-latest.osm.pbf I had been unable to build a gmapsupp because of running out of heap (my hardware is 32 bit, -Xmx1540M is largest value allowed) My problem is mainly because I have 1731146 cities (along with 1046096 streets) Looking at Mdr5 processing, I've changed it in 3 ways to improve memory usage and garbage collection. 1/ use trimToSize() after all the cities are loaded from the individual tile .img. I presume that the growth factor gradually increases as it runs out of allocated array space. I had to change the declaration from List to ArrayList to allow this, but I can't see any problem in this. 2/ Move the main part of preWriteImpl into its own method so the first sortKeys ArrayList and Sort can be freed before calcMdr20/1/2() each create another massive SortKeys and Sort. 3/ Move the scope of mdr20s to a class variable. This is referenced by all the Mdr5Records and the scope of where it was declared before seemed to to cause the garbage collector major problems - it churned for 5 mins using all the processors before running out of memory. After moving it, the whole of mdr is built in a couple of mins with cpu usage mostly < 125%. Ticker ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
