Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Mike OK - I think I understand the problem. Can you try with --order-by-decreasing-area and let me know if that stops the unbound recursion, and, in the meantime, I'll work on it. Thanks Ticker On Wed, 2017-02-15 at 00:48 +0000, Mike Baggaley wrote:
HI Ticker, having run this under the debugger now, it appears that it is not the postcode data after all - I was getting confused between the too small to split messages and too many POIs messages. I was previously getting too small to split messages in splitter, but not in mkgmap.
I temporarily changed the code to:
} else if (mustSplit) { // can't reduce size, so force more subdivisions if (depth < 1000) { log.debug("splitting area by contents", area); MapArea[] sublist = area.split(1, 1, bounds, true); addAreasToList(sublist, alist, depth + 1); continue; } else { log.error("Area too small to split at " + area.getBounds().getCenter().toOSMURL() + " (reduce the density of points, length of lines, etc.)");
} }
This ran successfully and gave a single error: Area too small to split at http://www.openstreetmap.org/?mlat=51.797190&mlon=0.918646&zoom=17 (r educe the density of points, length of lines, etc.
Stopping in the debugger, I can see that sizes[MapArea.SHAPE_KIND] is 68076 and from the coordinate it is processing the coastline. The call stack has the same value for the sizes[MapArea.SHAPE_KIND] in every instance of addAreasToList, so it looks like the call to area.split is not actually splitting. Looking at the resulting file in BaseCamp, I can see that the coastline is corrupt.
Hope that helps, Mike
-----Original Message----- From: Ticker Berkin [mailto:rwb-mkgmap@jagit.co.uk] Sent: 14 February 2017 23:21 To: Mike Baggaley <mike@tvage.co.uk> Subject: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Mike
I have the raw postcode data (codePointOpen.zip) which I processes just to take the first few at the same point but I can change it do all of them individually. Do you feed it with a map through the splitter or just make a postcode only overlay? What is the bit of style you use to represent each postcode? I can probably knock up something similar.
The code should cope - I can't see anything obviously wrong so need to try and reproduce the problem
Ticker
On Tue, 2017-02-14 at 18:17 +0000, Mike Baggaley wrote:
Hi Ticker the data is postcode centres (points). As well as geographic postcodes, the Royal Mail postcode data includes a number of postcodes that are centred on sorting offices (presumably for box numbers). There are quite a few at large sorting offices, but if each split should be able to accept 255 points, and it is exceeding 2000 splits before crashing, it looks like the splitting is not working - there won't be more than 2000 * 255 postcodes at the same place. My OSM file is rather large. I can see whether I can extract a map centred on a sorting office.
Regards, Mike
-----Original Message----- From: Ticker Berkin [mailto:rwb-mkgmap@jagit.co.uk] Sent: 14 February 2017 17:52 To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Mike
This is an area of code I've changed and it should be able to cope with many items at the same location without recursing.
Do you have some sample data? what are the items (point/line/shape extended?)
Ticker
On Tue, 2017-02-14 at 17:40 +0000, Mike Baggaley wrote:
Hi Gerd, since this change I am getting a java.lang.StackOverflowError crash caused by the code recursively attempting to split something which is unsplittable (assuming the split is based on location), as I have a large number of points at exactly the same location (from external data I add to the OSM data).
The offending line is at uk.me.parabola.mkgmap.build.MapSplitter.addAreasToList(MapSplitte r. ja va:187) . It is failing on my system with a depth of 2342. I suggest there needs to be a maximum depth after which it should give up trying to split.
} else if (mustSplit) { // can't reduce size, so force more subdivisions log.debug("splitting area by contents", area); MapArea[] sublist = area.split(1, 1, bounds, true); addAreasToList(sublist, alist, depth + 1); continue; }
I am unsure whether you would want a fixed depth limit, would want it to be set by parameter, would prefer to catch the error or think it would be possible to see whether the proposed area split has made any improvement, and give up if it hasn't.
Regards, Mike
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd / Mike I've just committed a fix for this to the split-shape branch Ticker On Wed, 2017-02-15 at 08:53 +0000, Ticker Berkin wrote:
Hi Mike
OK - I think I understand the problem.
Can you try with --order-by-decreasing-area and let me know if that stops the unbound recursion, and, in the meantime, I'll work on it.
Thanks Ticker
On Wed, 2017-02-15 at 00:48 +0000, Mike Baggaley wrote:
HI Ticker, having run this under the debugger now, it appears that it is not the postcode data after all - I was getting confused between the too small to split messages and too many POIs messages. I was previously getting too small to split messages in splitter, but not in mkgmap.
I temporarily changed the code to:
} else if (mustSplit) { // can't reduce size, so force more subdivisions if (depth < 1000) { log.debug("splitting area by contents", area); MapArea[] sublist = area.split(1, 1, bounds, true); addAreasToList(sublist, alist, depth + 1); continue; } else { log.error("Area too small to split at " + area.getBounds().getCenter().toOSMURL() + " (reduce the density of points, length of lines, etc.)");
} }
This ran successfully and gave a single error: Area too small to split at http://www.openstreetmap.org/?mlat=51.797190&mlon=0.918646&zoom=17 (r educe the density of points, length of lines, etc.
Stopping in the debugger, I can see that sizes[MapArea.SHAPE_KIND] is 68076 and from the coordinate it is processing the coastline. The call stack has the same value for the sizes[MapArea.SHAPE_KIND] in every instance of addAreasToList, so it looks like the call to area.split is not actually splitting. Looking at the resulting file in BaseCamp, I can see that the coastline is corrupt.
Hope that helps, Mike
-----Original Message----- From: Ticker Berkin [mailto:rwb-mkgmap@jagit.co.uk] Sent: 14 February 2017 23:21 To: Mike Baggaley <mike@tvage.co.uk> Subject: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Mike
I have the raw postcode data (codePointOpen.zip) which I processes just to take the first few at the same point but I can change it do all of them individually. Do you feed it with a map through the splitter or just make a postcode only overlay? What is the bit of style you use to represent each postcode? I can probably knock up something similar.
The code should cope - I can't see anything obviously wrong so need to try and reproduce the problem
Ticker
On Tue, 2017-02-14 at 18:17 +0000, Mike Baggaley wrote:
Hi Ticker the data is postcode centres (points). As well as geographic postcodes, the Royal Mail postcode data includes a number of postcodes that are centred on sorting offices (presumably for box numbers). There are quite a few at large sorting offices, but if each split should be able to accept 255 points, and it is exceeding 2000 splits before crashing, it looks like the splitting is not working - there won't be more than 2000 * 255 postcodes at the same place. My OSM file is rather large. I can see whether I can extract a map centred on a sorting office.
Regards, Mike
-----Original Message----- From: Ticker Berkin [mailto:rwb-mkgmap@jagit.co.uk] Sent: 14 February 2017 17:52 To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Mike
This is an area of code I've changed and it should be able to cope with many items at the same location without recursing.
Do you have some sample data? what are the items (point/line/shape extended?)
Ticker
On Tue, 2017-02-14 at 17:40 +0000, Mike Baggaley wrote:
Hi Gerd, since this change I am getting a java.lang.StackOverflowError crash caused by the code recursively attempting to split something which is unsplittable (assuming the split is based on location), as I have a large number of points at exactly the same location (from external data I add to the OSM data).
The offending line is at uk.me.parabola.mkgmap.build.MapSplitter.addAreasToList(MapSplit te r. ja va:187) . It is failing on my system with a depth of 2342. I suggest there needs to be a maximum depth after which it should give up trying to split.
} else if (mustSplit) { // can't reduce size, so force more subdivisions log.debug("splitting area by contents", area); MapArea[] sublist = area.split(1, 1, bounds, true); addAreasToList(sublist, alist, depth + 1); continue; }
I am unsure whether you would want a fixed depth limit, would want it to be set by parameter, would prefer to catch the error or think it would be possible to see whether the proposed area split has made any improvement, and give up if it hasn't.
Regards, 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
HI Ticker, I've tried the patch without the --order-by-decreasing-area option and it does now run without crashing. However, it suffers from the same problem as I mentioned earlier when trying --order-by-decreasing-area without the patch, in that the coastline is corrupted. I haven't yet turned on detailed logging - I can do that if it would help. I note that in MapSplitter.java there is a new line: log.info("Single item larger that WANTED_MAX_AREA_SIZE", area.getBounds().getCenter().toOSMURL()); I think this should say 'than' rather than 'that' and probably WANTED_MAX_AREA_SIZE should be outside the string so we see an actual number. Regards, Mike -----Original Message----- From: Ticker Berkin [mailto:rwb-mkgmap@jagit.co.uk] Sent: 15 February 2017 16:14 To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch Hi Gerd / Mike I've just committed a fix for this to the split-shape branch Ticker On Wed, 2017-02-15 at 08:53 +0000, Ticker Berkin wrote:
Hi Mike
OK - I think I understand the problem.
Can you try with --order-by-decreasing-area and let me know if that stops the unbound recursion, and, in the meantime, I'll work on it.
Thanks Ticker
On Wed, 2017-02-15 at 00:48 +0000, Mike Baggaley wrote:
HI Ticker, having run this under the debugger now, it appears that it is not the postcode data after all - I was getting confused between the too small to split messages and too many POIs messages. I was previously getting too small to split messages in splitter, but not in mkgmap.
I temporarily changed the code to:
} else if (mustSplit) { // can't reduce size, so force more subdivisions if (depth < 1000) { log.debug("splitting area by contents", area); MapArea[] sublist = area.split(1, 1, bounds, true); addAreasToList(sublist, alist, depth + 1); continue; } else { log.error("Area too small to split at " + area.getBounds().getCenter().toOSMURL() + " (reduce the density of points, length of lines, etc.)");
} }
This ran successfully and gave a single error: Area too small to split at http://www.openstreetmap.org/?mlat=51.797190&mlon=0.918646&zoom=17 (r educe the density of points, length of lines, etc.
Stopping in the debugger, I can see that sizes[MapArea.SHAPE_KIND] is 68076 and from the coordinate it is processing the coastline. The call stack has the same value for the sizes[MapArea.SHAPE_KIND] in every instance of addAreasToList, so it looks like the call to area.split is not actually splitting. Looking at the resulting file in BaseCamp, I can see that the coastline is corrupt.
Hope that helps, Mike
-----Original Message----- From: Ticker Berkin [mailto:rwb-mkgmap@jagit.co.uk] Sent: 14 February 2017 23:21 To: Mike Baggaley <mike@tvage.co.uk> Subject: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Mike
I have the raw postcode data (codePointOpen.zip) which I processes just to take the first few at the same point but I can change it do all of them individually. Do you feed it with a map through the splitter or just make a postcode only overlay? What is the bit of style you use to represent each postcode? I can probably knock up something similar.
The code should cope - I can't see anything obviously wrong so need to try and reproduce the problem
Ticker
On Tue, 2017-02-14 at 18:17 +0000, Mike Baggaley wrote:
Hi Ticker the data is postcode centres (points). As well as geographic postcodes, the Royal Mail postcode data includes a number of postcodes that are centred on sorting offices (presumably for box numbers). There are quite a few at large sorting offices, but if each split should be able to accept 255 points, and it is exceeding 2000 splits before crashing, it looks like the splitting is not working - there won't be more than 2000 * 255 postcodes at the same place. My OSM file is rather large. I can see whether I can extract a map centred on a sorting office.
Regards, Mike
-----Original Message----- From: Ticker Berkin [mailto:rwb-mkgmap@jagit.co.uk] Sent: 14 February 2017 17:52 To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Mike
This is an area of code I've changed and it should be able to cope with many items at the same location without recursing.
Do you have some sample data? what are the items (point/line/shape extended?)
Ticker
On Tue, 2017-02-14 at 17:40 +0000, Mike Baggaley wrote:
Hi Gerd, since this change I am getting a java.lang.StackOverflowError crash caused by the code recursively attempting to split something which is unsplittable (assuming the split is based on location), as I have a large number of points at exactly the same location (from external data I add to the OSM data).
The offending line is at uk.me.parabola.mkgmap.build.MapSplitter.addAreasToList(MapSplit te r. ja va:187) . It is failing on my system with a depth of 2342. I suggest there needs to be a maximum depth after which it should give up trying to split.
} else if (mustSplit) { // can't reduce size, so force more subdivisions log.debug("splitting area by contents", area); MapArea[] sublist = area.split(1, 1, bounds, true); addAreasToList(sublist, alist, depth + 1); continue; }
I am unsure whether you would want a fixed depth limit, would want it to be set by parameter, would prefer to catch the error or think it would be possible to see whether the proposed area split has made any improvement, and give up if it hasn't.
Regards, 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
Hi Mike I'll fix/improve the message. Can you tell if it is the sea polygons, the line 'coastline', or the island area (if your style generates this) that is corrupt. Maybe send your splitter options / areas.list, mkgmap options and style and I'll see if I can reproduce. Ticker On Thu, 2017-02-16 at 01:23 +0000, Mike Baggaley wrote:
HI Ticker, I've tried the patch without the --order-by-decreasing -area option and it does now run without crashing. However, it suffers from the same problem as I mentioned earlier when trying - -order-by-decreasing-area without the patch, in that the coastline is corrupted. I haven't yet turned on detailed logging - I can do that if it would help.
I note that in MapSplitter.java there is a new line:
log.info("Single item larger that WANTED_MAX_AREA_SIZE", area.getBounds().getCenter().toOSMURL());
I think this should say 'than' rather than 'that' and probably WANTED_MAX_AREA_SIZE should be outside the string so we see an actual number.
Regards, Mike
HI Ticker, I'll package up some data for you. I have generate-sea:extend-sea-sectors in my options file, I think it will be related to that. Regards, Mike -----Original Message----- From: Ticker Berkin [mailto:rwb-mkgmap@jagit.co.uk] Sent: 16 February 2017 08:17 To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch Hi Mike I'll fix/improve the message. Can you tell if it is the sea polygons, the line 'coastline', or the island area (if your style generates this) that is corrupt. Maybe send your splitter options / areas.list, mkgmap options and style and I'll see if I can reproduce. Ticker On Thu, 2017-02-16 at 01:23 +0000, Mike Baggaley wrote:
HI Ticker, I've tried the patch without the --order-by-decreasing -area option and it does now run without crashing. However, it suffers from the same problem as I mentioned earlier when trying - -order-by-decreasing-area without the patch, in that the coastline is corrupted. I haven't yet turned on detailed logging - I can do that if it would help.
I note that in MapSplitter.java there is a new line:
log.info("Single item larger that WANTED_MAX_AREA_SIZE", area.getBounds().getCenter().toOSMURL());
I think this should say 'than' rather than 'that' and probably WANTED_MAX_AREA_SIZE should be outside the string so we see an actual number.
Regards, Mike
Hi Ticker, In case you need test data: I've uploaded a file : http://files.mkgmap.org.uk/download/334/88009211.osm.pbf Produces the error with r3811 without any options, just java -jar mkpgmap.jar 88009211.osm.pbf Seems to work okay with r3807. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Donnerstag, 16. Februar 2017 10:40:55 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch HI Ticker, I'll package up some data for you. I have generate-sea:extend-sea-sectors in my options file, I think it will be related to that. Regards, Mike -----Original Message----- From: Ticker Berkin [mailto:rwb-mkgmap@jagit.co.uk] Sent: 16 February 2017 08:17 To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch Hi Mike I'll fix/improve the message. Can you tell if it is the sea polygons, the line 'coastline', or the island area (if your style generates this) that is corrupt. Maybe send your splitter options / areas.list, mkgmap options and style and I'll see if I can reproduce. Ticker On Thu, 2017-02-16 at 01:23 +0000, Mike Baggaley wrote:
HI Ticker, I've tried the patch without the --order-by-decreasing -area option and it does now run without crashing. However, it suffers from the same problem as I mentioned earlier when trying - -order-by-decreasing-area without the patch, in that the coastline is corrupted. I haven't yet turned on detailed logging - I can do that if it would help.
I note that in MapSplitter.java there is a new line:
log.info("Single item larger that WANTED_MAX_AREA_SIZE", area.getBounds().getCenter().toOSMURL());
I think this should say 'than' rather than 'that' and probably WANTED_MAX_AREA_SIZE should be outside the string so we see an actual number.
Regards, Mike
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd I fixed this problem with r3807 in the split-shape branch and this should probably be merged into trunk. Mike was also getting another problem that might be related to generate-sea:extend-sea-sectors I don't know much about this area, but just having this option and nothing else of significance, it seems as if the overview map has all sea if it has a coastline Ticker On Thu, 2017-02-16 at 20:12 +0000, Gerd Petermann wrote:
Hi Ticker,
In case you need test data: I've uploaded a file : http://files.mkgmap.org.uk/download/334/88009211.osm.pbf Produces the error with r3811 without any options, just java -jar mkpgmap.jar 88009211.osm.pbf Seems to work okay with r3807.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Donnerstag, 16. Februar 2017 10:40:55 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
HI Ticker, I'll package up some data for you. I have generate -sea:extend-sea-sectors in my options file, I think it will be related to that.
Regards, Mike
-----Original Message----- From: Ticker Berkin [mailto:rwb-mkgmap@jagit.co.uk] Sent: 16 February 2017 08:17 To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Mike
I'll fix/improve the message.
Can you tell if it is the sea polygons, the line 'coastline', or the island area (if your style generates this) that is corrupt.
Maybe send your splitter options / areas.list, mkgmap options and style and I'll see if I can reproduce.
Ticker
On Thu, 2017-02-16 at 01:23 +0000, Mike Baggaley wrote:
HI Ticker, I've tried the patch without the --order-by-decreasing -area option and it does now run without crashing. However, it suffers from the same problem as I mentioned earlier when trying - -order-by-decreasing-area without the patch, in that the coastline is corrupted. I haven't yet turned on detailed logging - I can do that if it would help.
I note that in MapSplitter.java there is a new line:
log.info("Single item larger that WANTED_MAX_AREA_SIZE", area.getBounds().getCenter().toOSMURL());
I think this should say 'than' rather than 'that' and probably WANTED_MAX_AREA_SIZE should be outside the string so we see an actual number.
Regards, 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
Hi Ticker, okay, I'll merge the branch into trunk. Please post some test data to show the coastline problem and I'll try to fix it. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 17. Februar 2017 09:50:17 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch Hi Gerd I fixed this problem with r3807 in the split-shape branch and this should probably be merged into trunk. Mike was also getting another problem that might be related to generate-sea:extend-sea-sectors I don't know much about this area, but just having this option and nothing else of significance, it seems as if the overview map has all sea if it has a coastline Ticker On Thu, 2017-02-16 at 20:12 +0000, Gerd Petermann wrote:
Hi Ticker,
In case you need test data: I've uploaded a file : http://files.mkgmap.org.uk/download/334/88009211.osm.pbf Produces the error with r3811 without any options, just java -jar mkpgmap.jar 88009211.osm.pbf Seems to work okay with r3807.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Donnerstag, 16. Februar 2017 10:40:55 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
HI Ticker, I'll package up some data for you. I have generate -sea:extend-sea-sectors in my options file, I think it will be related to that.
Regards, Mike
-----Original Message----- From: Ticker Berkin [mailto:rwb-mkgmap@jagit.co.uk] Sent: 16 February 2017 08:17 To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Mike
I'll fix/improve the message.
Can you tell if it is the sea polygons, the line 'coastline', or the island area (if your style generates this) that is corrupt.
Maybe send your splitter options / areas.list, mkgmap options and style and I'll see if I can reproduce.
Ticker
On Thu, 2017-02-16 at 01:23 +0000, Mike Baggaley wrote:
HI Ticker, I've tried the patch without the --order-by-decreasing -area option and it does now run without crashing. However, it suffers from the same problem as I mentioned earlier when trying - -order-by-decreasing-area without the patch, in that the coastline is corrupted. I haven't yet turned on detailed logging - I can do that if it would help.
I note that in MapSplitter.java there is a new line:
log.info("Single item larger that WANTED_MAX_AREA_SIZE", area.getBounds().getCenter().toOSMURL());
I think this should say 'than' rather than 'that' and probably WANTED_MAX_AREA_SIZE should be outside the string so we see an actual number.
Regards, 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
Hi Ticker, don't need test data, found out what you meant. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@hotmail.com> Gesendet: Freitag, 17. Februar 2017 09:52:56 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch Hi Ticker, okay, I'll merge the branch into trunk. Please post some test data to show the coastline problem and I'll try to fix it. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 17. Februar 2017 09:50:17 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch Hi Gerd I fixed this problem with r3807 in the split-shape branch and this should probably be merged into trunk. Mike was also getting another problem that might be related to generate-sea:extend-sea-sectors I don't know much about this area, but just having this option and nothing else of significance, it seems as if the overview map has all sea if it has a coastline Ticker On Thu, 2017-02-16 at 20:12 +0000, Gerd Petermann wrote:
Hi Ticker,
In case you need test data: I've uploaded a file : http://files.mkgmap.org.uk/download/334/88009211.osm.pbf Produces the error with r3811 without any options, just java -jar mkpgmap.jar 88009211.osm.pbf Seems to work okay with r3807.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Donnerstag, 16. Februar 2017 10:40:55 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
HI Ticker, I'll package up some data for you. I have generate -sea:extend-sea-sectors in my options file, I think it will be related to that.
Regards, Mike
-----Original Message----- From: Ticker Berkin [mailto:rwb-mkgmap@jagit.co.uk] Sent: 16 February 2017 08:17 To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Mike
I'll fix/improve the message.
Can you tell if it is the sea polygons, the line 'coastline', or the island area (if your style generates this) that is corrupt.
Maybe send your splitter options / areas.list, mkgmap options and style and I'll see if I can reproduce.
Ticker
On Thu, 2017-02-16 at 01:23 +0000, Mike Baggaley wrote:
HI Ticker, I've tried the patch without the --order-by-decreasing -area option and it does now run without crashing. However, it suffers from the same problem as I mentioned earlier when trying - -order-by-decreasing-area without the patch, in that the coastline is corrupted. I haven't yet turned on detailed logging - I can do that if it would help.
I note that in MapSplitter.java there is a new line:
log.info("Single item larger that WANTED_MAX_AREA_SIZE", area.getBounds().getCenter().toOSMURL());
I think this should say 'than' rather than 'that' and probably WANTED_MAX_AREA_SIZE should be outside the string so we see an actual number.
Regards, 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
Hi Ticker, I think the problems were introduced with the highprec changes in MultiPolygonRelation in r3771. When I revert those the problem is gone. If you don't mind I commit this revert. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@hotmail.com> Gesendet: Freitag, 17. Februar 2017 10:02:38 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch Hi Ticker, don't need test data, found out what you meant. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@hotmail.com> Gesendet: Freitag, 17. Februar 2017 09:52:56 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch Hi Ticker, okay, I'll merge the branch into trunk. Please post some test data to show the coastline problem and I'll try to fix it. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 17. Februar 2017 09:50:17 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch Hi Gerd I fixed this problem with r3807 in the split-shape branch and this should probably be merged into trunk. Mike was also getting another problem that might be related to generate-sea:extend-sea-sectors I don't know much about this area, but just having this option and nothing else of significance, it seems as if the overview map has all sea if it has a coastline Ticker On Thu, 2017-02-16 at 20:12 +0000, Gerd Petermann wrote:
Hi Ticker,
In case you need test data: I've uploaded a file : http://files.mkgmap.org.uk/download/334/88009211.osm.pbf Produces the error with r3811 without any options, just java -jar mkpgmap.jar 88009211.osm.pbf Seems to work okay with r3807.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Donnerstag, 16. Februar 2017 10:40:55 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
HI Ticker, I'll package up some data for you. I have generate -sea:extend-sea-sectors in my options file, I think it will be related to that.
Regards, Mike
-----Original Message----- From: Ticker Berkin [mailto:rwb-mkgmap@jagit.co.uk] Sent: 16 February 2017 08:17 To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Mike
I'll fix/improve the message.
Can you tell if it is the sea polygons, the line 'coastline', or the island area (if your style generates this) that is corrupt.
Maybe send your splitter options / areas.list, mkgmap options and style and I'll see if I can reproduce.
Ticker
On Thu, 2017-02-16 at 01:23 +0000, Mike Baggaley wrote:
HI Ticker, I've tried the patch without the --order-by-decreasing -area option and it does now run without crashing. However, it suffers from the same problem as I mentioned earlier when trying - -order-by-decreasing-area without the patch, in that the coastline is corrupted. I haven't yet turned on detailed logging - I can do that if it would help.
I note that in MapSplitter.java there is a new line:
log.info("Single item larger that WANTED_MAX_AREA_SIZE", area.getBounds().getCenter().toOSMURL());
I think this should say 'than' rather than 'that' and probably WANTED_MAX_AREA_SIZE should be outside the string so we see an actual number.
Regards, 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 _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd Yes - if that fixes it. But in r3771 were there a couple of other changes not to MultiPolygon... haven't a lot more changes been made since to MultiPolygon... Ticker On Fri, 2017-02-17 at 09:19 +0000, Gerd Petermann wrote:
Hi Ticker,
I think the problems were introduced with the highprec changes in MultiPolygonRelation in r3771. When I revert those the problem is gone. If you don't mind I commit this revert.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@hotmail.com> Gesendet: Freitag, 17. Februar 2017 10:02:38 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Ticker,
don't need test data, found out what you meant.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@hotmail.com> Gesendet: Freitag, 17. Februar 2017 09:52:56 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Ticker,
okay, I'll merge the branch into trunk. Please post some test data to show the coastline problem and I'll try to fix it.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 17. Februar 2017 09:50:17 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Gerd
I fixed this problem with r3807 in the split-shape branch and this should probably be merged into trunk.
Mike was also getting another problem that might be related to generate-sea:extend-sea-sectors
I don't know much about this area, but just having this option and nothing else of significance, it seems as if the overview map has all sea if it has a coastline
Ticker
On Thu, 2017-02-16 at 20:12 +0000, Gerd Petermann wrote:
Hi Ticker,
In case you need test data: I've uploaded a file : http://files.mkgmap.org.uk/download/334/88009211.osm.pbf Produces the error with r3811 without any options, just java -jar mkpgmap.jar 88009211.osm.pbf Seems to work okay with r3807.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Donnerstag, 16. Februar 2017 10:40:55 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
HI Ticker, I'll package up some data for you. I have generate -sea:extend-sea-sectors in my options file, I think it will be related to that.
Regards, Mike
-----Original Message----- From: Ticker Berkin [mailto:rwb-mkgmap@jagit.co.uk] Sent: 16 February 2017 08:17 To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Mike
I'll fix/improve the message.
Can you tell if it is the sea polygons, the line 'coastline', or the island area (if your style generates this) that is corrupt.
Maybe send your splitter options / areas.list, mkgmap options and style and I'll see if I can reproduce.
Ticker
On Thu, 2017-02-16 at 01:23 +0000, Mike Baggaley wrote:
HI Ticker, I've tried the patch without the --order-by-decreasing -area option and it does now run without crashing. However, it suffers from the same problem as I mentioned earlier when trying - -order-by-decreasing-area without the patch, in that the coastline is corrupted. I haven't yet turned on detailed logging - I can do that if it would help.
I note that in MapSplitter.java there is a new line:
log.info("Single item larger that WANTED_MAX_AREA_SIZE", area.getBounds().getCenter().toOSMURL());
I think this should say 'than' rather than 'that' and probably WANTED_MAX_AREA_SIZE should be outside the string so we see an actual number.
Regards, 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 _______________________________________________ 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
Hi Ticker, attached is the patch I've created with help of svn. It only reverts the changes made to MultiPolygonRelation in r3771. I don't know yet why they cause trouble. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 17. Februar 2017 10:32:11 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch Hi Gerd Yes - if that fixes it. But in r3771 were there a couple of other changes not to MultiPolygon... haven't a lot more changes been made since to MultiPolygon... Ticker On Fri, 2017-02-17 at 09:19 +0000, Gerd Petermann wrote:
Hi Ticker,
I think the problems were introduced with the highprec changes in MultiPolygonRelation in r3771. When I revert those the problem is gone. If you don't mind I commit this revert.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@hotmail.com> Gesendet: Freitag, 17. Februar 2017 10:02:38 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Ticker,
don't need test data, found out what you meant.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@hotmail.com> Gesendet: Freitag, 17. Februar 2017 09:52:56 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Ticker,
okay, I'll merge the branch into trunk. Please post some test data to show the coastline problem and I'll try to fix it.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 17. Februar 2017 09:50:17 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Gerd
I fixed this problem with r3807 in the split-shape branch and this should probably be merged into trunk.
Mike was also getting another problem that might be related to generate-sea:extend-sea-sectors
I don't know much about this area, but just having this option and nothing else of significance, it seems as if the overview map has all sea if it has a coastline
Ticker
On Thu, 2017-02-16 at 20:12 +0000, Gerd Petermann wrote:
Hi Ticker,
In case you need test data: I've uploaded a file : http://files.mkgmap.org.uk/download/334/88009211.osm.pbf Produces the error with r3811 without any options, just java -jar mkpgmap.jar 88009211.osm.pbf Seems to work okay with r3807.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Donnerstag, 16. Februar 2017 10:40:55 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
HI Ticker, I'll package up some data for you. I have generate -sea:extend-sea-sectors in my options file, I think it will be related to that.
Regards, Mike
-----Original Message----- From: Ticker Berkin [mailto:rwb-mkgmap@jagit.co.uk] Sent: 16 February 2017 08:17 To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Mike
I'll fix/improve the message.
Can you tell if it is the sea polygons, the line 'coastline', or the island area (if your style generates this) that is corrupt.
Maybe send your splitter options / areas.list, mkgmap options and style and I'll see if I can reproduce.
Ticker
On Thu, 2017-02-16 at 01:23 +0000, Mike Baggaley wrote:
HI Ticker, I've tried the patch without the --order-by-decreasing -area option and it does now run without crashing. However, it suffers from the same problem as I mentioned earlier when trying - -order-by-decreasing-area without the patch, in that the coastline is corrupted. I haven't yet turned on detailed logging - I can do that if it would help.
I note that in MapSplitter.java there is a new line:
log.info("Single item larger that WANTED_MAX_AREA_SIZE", area.getBounds().getCenter().toOSMURL());
I think this should say 'than' rather than 'that' and probably WANTED_MAX_AREA_SIZE should be outside the string so we see an actual number.
Regards, 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 _______________________________________________ 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
Hi Gerd Good. Ticker On Fri, 2017-02-17 at 09:41 +0000, Gerd Petermann wrote:
Hi Ticker,
attached is the patch I've created with help of svn. It only reverts the changes made to MultiPolygonRelation in r3771.
I don't know yet why they cause trouble.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 17. Februar 2017 10:32:11 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Gerd
Yes - if that fixes it. But in r3771 were there a couple of other changes not to MultiPolygon... haven't a lot more changes been made since to MultiPolygon...
Ticker
On Fri, 2017-02-17 at 09:19 +0000, Gerd Petermann wrote:
Hi Ticker,
I think the problems were introduced with the highprec changes in MultiPolygonRelation in r3771. When I revert those the problem is gone. If you don't mind I commit this revert.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@hotmail.com> Gesendet: Freitag, 17. Februar 2017 10:02:38 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Ticker,
don't need test data, found out what you meant.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@hotmail.com> Gesendet: Freitag, 17. Februar 2017 09:52:56 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Ticker,
okay, I'll merge the branch into trunk. Please post some test data to show the coastline problem and I'll try to fix it.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 17. Februar 2017 09:50:17 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Gerd
I fixed this problem with r3807 in the split-shape branch and this should probably be merged into trunk.
Mike was also getting another problem that might be related to generate-sea:extend-sea-sectors
I don't know much about this area, but just having this option and nothing else of significance, it seems as if the overview map has all sea if it has a coastline
Ticker
On Thu, 2017-02-16 at 20:12 +0000, Gerd Petermann wrote:
Hi Ticker,
In case you need test data: I've uploaded a file : http://files.mkgmap.org.uk/download/334/88009211.osm.pbf Produces the error with r3811 without any options, just java -jar mkpgmap.jar 88009211.osm.pbf Seems to work okay with r3807.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Donnerstag, 16. Februar 2017 10:40:55 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
HI Ticker, I'll package up some data for you. I have generate -sea:extend-sea-sectors in my options file, I think it will be related to that.
Regards, Mike
-----Original Message----- From: Ticker Berkin [mailto:rwb-mkgmap@jagit.co.uk] Sent: 16 February 2017 08:17 To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Mike
I'll fix/improve the message.
Can you tell if it is the sea polygons, the line 'coastline', or the island area (if your style generates this) that is corrupt.
Maybe send your splitter options / areas.list, mkgmap options and style and I'll see if I can reproduce.
Ticker
On Thu, 2017-02-16 at 01:23 +0000, Mike Baggaley wrote:
HI Ticker, I've tried the patch without the --order-by -decreasing -area option and it does now run without crashing. However, it suffers from the same problem as I mentioned earlier when trying - -order-by-decreasing-area without the patch, in that the coastline is corrupted. I haven't yet turned on detailed logging - I can do that if it would help.
I note that in MapSplitter.java there is a new line:
log.info("Single item larger that WANTED_MAX_AREA_SIZE", area.getBounds().getCenter().toOSMURL());
I think this should say 'than' rather than 'that' and probably WANTED_MAX_AREA_SIZE should be outside the string so we see an actual number.
Regards, 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 _______________________________________________ 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
Hi Ticker, problem is in these lines: if (remove) { // check if the polygon contains the complete bounding box if (w.getBounds().contains(tileArea.getBounds())) { remove = false; } } 1) The SeaGenerator creates an outer way which is larger than the tile bounds. 2) This test was wrong because w.getBounds() returns a bbox in highprec values and tileArea.getBounds() is in Garmin units Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 17. Februar 2017 11:00:49 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch Hi Gerd Good. Ticker On Fri, 2017-02-17 at 09:41 +0000, Gerd Petermann wrote:
Hi Ticker,
attached is the patch I've created with help of svn. It only reverts the changes made to MultiPolygonRelation in r3771.
I don't know yet why they cause trouble.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 17. Februar 2017 10:32:11 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Gerd
Yes - if that fixes it. But in r3771 were there a couple of other changes not to MultiPolygon... haven't a lot more changes been made since to MultiPolygon...
Ticker
On Fri, 2017-02-17 at 09:19 +0000, Gerd Petermann wrote:
Hi Ticker,
I think the problems were introduced with the highprec changes in MultiPolygonRelation in r3771. When I revert those the problem is gone. If you don't mind I commit this revert.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@hotmail.com> Gesendet: Freitag, 17. Februar 2017 10:02:38 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Ticker,
don't need test data, found out what you meant.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@hotmail.com> Gesendet: Freitag, 17. Februar 2017 09:52:56 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Ticker,
okay, I'll merge the branch into trunk. Please post some test data to show the coastline problem and I'll try to fix it.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 17. Februar 2017 09:50:17 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Gerd
I fixed this problem with r3807 in the split-shape branch and this should probably be merged into trunk.
Mike was also getting another problem that might be related to generate-sea:extend-sea-sectors
I don't know much about this area, but just having this option and nothing else of significance, it seems as if the overview map has all sea if it has a coastline
Ticker
On Thu, 2017-02-16 at 20:12 +0000, Gerd Petermann wrote:
Hi Ticker,
In case you need test data: I've uploaded a file : http://files.mkgmap.org.uk/download/334/88009211.osm.pbf Produces the error with r3811 without any options, just java -jar mkpgmap.jar 88009211.osm.pbf Seems to work okay with r3807.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Donnerstag, 16. Februar 2017 10:40:55 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
HI Ticker, I'll package up some data for you. I have generate -sea:extend-sea-sectors in my options file, I think it will be related to that.
Regards, Mike
-----Original Message----- From: Ticker Berkin [mailto:rwb-mkgmap@jagit.co.uk] Sent: 16 February 2017 08:17 To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Mike
I'll fix/improve the message.
Can you tell if it is the sea polygons, the line 'coastline', or the island area (if your style generates this) that is corrupt.
Maybe send your splitter options / areas.list, mkgmap options and style and I'll see if I can reproduce.
Ticker
On Thu, 2017-02-16 at 01:23 +0000, Mike Baggaley wrote:
HI Ticker, I've tried the patch without the --order-by -decreasing -area option and it does now run without crashing. However, it suffers from the same problem as I mentioned earlier when trying - -order-by-decreasing-area without the patch, in that the coastline is corrupted. I haven't yet turned on detailed logging - I can do that if it would help.
I note that in MapSplitter.java there is a new line:
log.info("Single item larger that WANTED_MAX_AREA_SIZE", area.getBounds().getCenter().toOSMURL());
I think this should say 'than' rather than 'that' and probably WANTED_MAX_AREA_SIZE should be outside the string so we see an actual number.
Regards, 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 _______________________________________________ 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
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd Yes - sorry, my fault. I've just tested a fix to this and the sea is OK now. Is is worth keeping the high-res changes in the split-shape branch pending more work on MultiPolygonRelation? If so I'll commit. Ticker On Fri, 2017-02-17 at 10:49 +0000, Gerd Petermann wrote:
Hi Ticker,
problem is in these lines: if (remove) { // check if the polygon contains the complete bounding box if (w.getBounds().contains(tileArea.getBounds())) { remove = false; } } 1) The SeaGenerator creates an outer way which is larger than the tile bounds. 2) This test was wrong because w.getBounds() returns a bbox in highprec values and tileArea.getBounds() is in Garmin units
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 17. Februar 2017 11:00:49 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Gerd
Good.
Ticker
On Fri, 2017-02-17 at 09:41 +0000, Gerd Petermann wrote:
Hi Ticker,
attached is the patch I've created with help of svn. It only reverts the changes made to MultiPolygonRelation in r3771.
I don't know yet why they cause trouble.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 17. Februar 2017 10:32:11 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Gerd
Yes - if that fixes it. But in r3771 were there a couple of other changes not to MultiPolygon... haven't a lot more changes been made since to MultiPolygon...
Ticker
On Fri, 2017-02-17 at 09:19 +0000, Gerd Petermann wrote:
Hi Ticker,
I think the problems were introduced with the highprec changes in MultiPolygonRelation in r3771. When I revert those the problem is gone. If you don't mind I commit this revert.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@hotmail.com> Gesendet: Freitag, 17. Februar 2017 10:02:38 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Ticker,
don't need test data, found out what you meant.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@hotmail.com> Gesendet: Freitag, 17. Februar 2017 09:52:56 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Ticker,
okay, I'll merge the branch into trunk. Please post some test data to show the coastline problem and I'll try to fix it.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 17. Februar 2017 09:50:17 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Gerd
I fixed this problem with r3807 in the split-shape branch and this should probably be merged into trunk.
Mike was also getting another problem that might be related to generate-sea:extend-sea-sectors
I don't know much about this area, but just having this option and nothing else of significance, it seems as if the overview map has all sea if it has a coastline
Ticker
On Thu, 2017-02-16 at 20:12 +0000, Gerd Petermann wrote:
Hi Ticker,
In case you need test data: I've uploaded a file : http://files.mkgmap.org.uk/download/334/88009211.osm.pbf Produces the error with r3811 without any options, just java -jar mkpgmap.jar 88009211.osm.pbf Seems to work okay with r3807.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Donnerstag, 16. Februar 2017 10:40:55 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
HI Ticker, I'll package up some data for you. I have generate -sea:extend-sea-sectors in my options file, I think it will be related to that.
Regards, Mike
-----Original Message----- From: Ticker Berkin [mailto:rwb-mkgmap@jagit.co.uk] Sent: 16 February 2017 08:17 To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Mike
I'll fix/improve the message.
Can you tell if it is the sea polygons, the line 'coastline', or the island area (if your style generates this) that is corrupt.
Maybe send your splitter options / areas.list, mkgmap options and style and I'll see if I can reproduce.
Ticker
On Thu, 2017-02-16 at 01:23 +0000, Mike Baggaley wrote:
HI Ticker, I've tried the patch without the --order-by -decreasing -area option and it does now run without crashing. However, it suffers from the same problem as I mentioned earlier when trying - -order-by-decreasing-area without the patch, in that the coastline is corrupted. I haven't yet turned on detailed logging - I can do that if it would help.
I note that in MapSplitter.java there is a new line:
log.info("Single item larger that WANTED_MAX_AREA_SIZE", area.getBounds().getCenter().toOSMURL());
I think this should say 'than' rather than 'that' and probably WANTED_MAX_AREA_SIZE should be outside the string so we see an actual number.
Regards, 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 _______________________________________________ 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
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
Hi Ticker, I did not see an advantage in using high-prec. Why do you think it should be used? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 17. Februar 2017 13:27:28 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch Hi Gerd Yes - sorry, my fault. I've just tested a fix to this and the sea is OK now. Is is worth keeping the high-res changes in the split-shape branch pending more work on MultiPolygonRelation? If so I'll commit. Ticker On Fri, 2017-02-17 at 10:49 +0000, Gerd Petermann wrote:
Hi Ticker,
problem is in these lines: if (remove) { // check if the polygon contains the complete bounding box if (w.getBounds().contains(tileArea.getBounds())) { remove = false; } } 1) The SeaGenerator creates an outer way which is larger than the tile bounds. 2) This test was wrong because w.getBounds() returns a bbox in highprec values and tileArea.getBounds() is in Garmin units
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 17. Februar 2017 11:00:49 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Gerd
Good.
Ticker
On Fri, 2017-02-17 at 09:41 +0000, Gerd Petermann wrote:
Hi Ticker,
attached is the patch I've created with help of svn. It only reverts the changes made to MultiPolygonRelation in r3771.
I don't know yet why they cause trouble.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 17. Februar 2017 10:32:11 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Gerd
Yes - if that fixes it. But in r3771 were there a couple of other changes not to MultiPolygon... haven't a lot more changes been made since to MultiPolygon...
Ticker
On Fri, 2017-02-17 at 09:19 +0000, Gerd Petermann wrote:
Hi Ticker,
I think the problems were introduced with the highprec changes in MultiPolygonRelation in r3771. When I revert those the problem is gone. If you don't mind I commit this revert.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@hotmail.com> Gesendet: Freitag, 17. Februar 2017 10:02:38 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Ticker,
don't need test data, found out what you meant.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@hotmail.com> Gesendet: Freitag, 17. Februar 2017 09:52:56 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Ticker,
okay, I'll merge the branch into trunk. Please post some test data to show the coastline problem and I'll try to fix it.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 17. Februar 2017 09:50:17 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Gerd
I fixed this problem with r3807 in the split-shape branch and this should probably be merged into trunk.
Mike was also getting another problem that might be related to generate-sea:extend-sea-sectors
I don't know much about this area, but just having this option and nothing else of significance, it seems as if the overview map has all sea if it has a coastline
Ticker
On Thu, 2017-02-16 at 20:12 +0000, Gerd Petermann wrote:
Hi Ticker,
In case you need test data: I've uploaded a file : http://files.mkgmap.org.uk/download/334/88009211.osm.pbf Produces the error with r3811 without any options, just java -jar mkpgmap.jar 88009211.osm.pbf Seems to work okay with r3807.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Donnerstag, 16. Februar 2017 10:40:55 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
HI Ticker, I'll package up some data for you. I have generate -sea:extend-sea-sectors in my options file, I think it will be related to that.
Regards, Mike
-----Original Message----- From: Ticker Berkin [mailto:rwb-mkgmap@jagit.co.uk] Sent: 16 February 2017 08:17 To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Mike
I'll fix/improve the message.
Can you tell if it is the sea polygons, the line 'coastline', or the island area (if your style generates this) that is corrupt.
Maybe send your splitter options / areas.list, mkgmap options and style and I'll see if I can reproduce.
Ticker
On Thu, 2017-02-16 at 01:23 +0000, Mike Baggaley wrote:
HI Ticker, I've tried the patch without the --order-by -decreasing -area option and it does now run without crashing. However, it suffers from the same problem as I mentioned earlier when trying - -order-by-decreasing-area without the patch, in that the coastline is corrupted. I haven't yet turned on detailed logging - I can do that if it would help.
I note that in MapSplitter.java there is a new line:
log.info("Single item larger that WANTED_MAX_AREA_SIZE", area.getBounds().getCenter().toOSMURL());
I think this should say 'than' rather than 'that' and probably WANTED_MAX_AREA_SIZE should be outside the string so we see an actual number.
Regards, 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 _______________________________________________ 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
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
Hi Gerd Thoughts were: I was having problems with a multi-polygon relation where OSM showed a very small gap between 2 parts, but some final cutting of the shape found that these lines now intersected, and I thought it could be a mapPrec vs highPrec problem where the multiPolygonRelation logic is looking for this sort of thing. Changing it to highPrec didn't fix it (you found that the problem was roundCoord filter) but the changes looked worth keeping because: MultiPolygon cutting to expose holes uses highPrec and it seemed best to be consistent, avoiding cuts that might leave very small areas. A general move in the direction of all coordinates/bounds/etc being the held only in highPrec and resolution 24 not being a special case. But I don't have strong feelings about it. Ticker On Fri, 2017-02-17 at 13:12 +0000, Gerd Petermann wrote:
Hi Ticker,
I did not see an advantage in using high-prec. Why do you think it should be used?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 17. Februar 2017 13:27:28 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Gerd
Yes - sorry, my fault. I've just tested a fix to this and the sea is OK now. Is is worth keeping the high-res changes in the split-shape branch pending more work on MultiPolygonRelation? If so I'll commit.
Ticker
On Fri, 2017-02-17 at 10:49 +0000, Gerd Petermann wrote:
Hi Ticker,
problem is in these lines: if (remove) { // check if the polygon contains the complete bounding box if (w.getBounds().contains(tileArea.getBounds())) { remove = false; } } 1) The SeaGenerator creates an outer way which is larger than the tile bounds. 2) This test was wrong because w.getBounds() returns a bbox in highprec values and tileArea.getBounds() is in Garmin units
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 17. Februar 2017 11:00:49 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Gerd
Good.
Ticker
On Fri, 2017-02-17 at 09:41 +0000, Gerd Petermann wrote:
Hi Ticker,
attached is the patch I've created with help of svn. It only reverts the changes made to MultiPolygonRelation in r3771.
I don't know yet why they cause trouble.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 17. Februar 2017 10:32:11 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Gerd
Yes - if that fixes it. But in r3771 were there a couple of other changes not to MultiPolygon... haven't a lot more changes been made since to MultiPolygon...
Ticker
On Fri, 2017-02-17 at 09:19 +0000, Gerd Petermann wrote:
Hi Ticker,
I think the problems were introduced with the highprec changes in MultiPolygonRelation in r3771. When I revert those the problem is gone. If you don't mind I commit this revert.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@hotmail.com> Gesendet: Freitag, 17. Februar 2017 10:02:38 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Ticker,
don't need test data, found out what you meant.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@hotmail.com> Gesendet: Freitag, 17. Februar 2017 09:52:56 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Ticker,
okay, I'll merge the branch into trunk. Please post some test data to show the coastline problem and I'll try to fix it.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 17. Februar 2017 09:50:17 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Gerd
I fixed this problem with r3807 in the split-shape branch and this should probably be merged into trunk.
Mike was also getting another problem that might be related to generate-sea:extend-sea-sectors
I don't know much about this area, but just having this option and nothing else of significance, it seems as if the overview map has all sea if it has a coastline
Ticker
On Thu, 2017-02-16 at 20:12 +0000, Gerd Petermann wrote:
Hi Ticker,
In case you need test data: I've uploaded a file : http://files.mkgmap.org.uk/download/334/88009211.osm.pbf Produces the error with r3811 without any options, just java -jar mkpgmap.jar 88009211.osm.pbf Seems to work okay with r3807.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Donnerstag, 16. Februar 2017 10:40:55 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
HI Ticker, I'll package up some data for you. I have generate -sea:extend-sea-sectors in my options file, I think it will be related to that.
Regards, Mike
-----Original Message----- From: Ticker Berkin [mailto:rwb-mkgmap@jagit.co.uk] Sent: 16 February 2017 08:17 To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Mike
I'll fix/improve the message.
Can you tell if it is the sea polygons, the line 'coastline', or the island area (if your style generates this) that is corrupt.
Maybe send your splitter options / areas.list, mkgmap options and style and I'll see if I can reproduce.
Ticker
On Thu, 2017-02-16 at 01:23 +0000, Mike Baggaley wrote:
HI Ticker, I've tried the patch without the --order-by -decreasing -area option and it does now run without crashing. However, it suffers from the same problem as I mentioned earlier when trying - -order-by-decreasing-area without the patch, in that the coastline is corrupted. I haven't yet turned on detailed logging - I can do that if it would help.
I note that in MapSplitter.java there is a new line:
log.info("Single item larger that WANTED_MAX_AREA_SIZE", area.getBounds().getCenter().toOSMURL());
I think this should say 'than' rather than 'that' and probably WANTED_MAX_AREA_SIZE should be outside the string so we see an actual number.
Regards, 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 _______________________________________________ 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
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
Hi Ticker, I thought about this for a while and I am still not sure where to go. One problem with the high-prec stuff is that it is missleading. When I started to code the highprec() code my only intention was to be able to retreive "the original" position as coded in OSM. You probably learned it the hard way that the value returned by Coord.getLatitude() sometimes is different to the value from a rounded Coord.getHighPrecLat() . The reason is that functions like Coord.getAlternativePositions() used by WrongAngleFixer create Coord instances with the same highprec positions but different rounding (a bit more to the left or right, a bit more up or down). The idea is that the map looks better when the error for that single point is increased. A good place to check this are multiple parallel rails. I am still trying to find good code to calculate the bounding box for coords with this special case. When such a point is close to or "on" the bounding box in one precision it might be outside with the other. I wonder if it would be better to use low precision as soon as possible. If you have a good idea for that please let me know. In the meantime I have found some reasons to change precision from 30 to 32 bit as this helps when checking mp-relations. I found new problems, e.g. 180.0 degrees and -180.0 degrees started to give the same 32 bit value. Working on that now... Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 17. Februar 2017 15:49:10 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch Hi Gerd Thoughts were: I was having problems with a multi-polygon relation where OSM showed a very small gap between 2 parts, but some final cutting of the shape found that these lines now intersected, and I thought it could be a mapPrec vs highPrec problem where the multiPolygonRelation logic is looking for this sort of thing. Changing it to highPrec didn't fix it (you found that the problem was roundCoord filter) but the changes looked worth keeping because: MultiPolygon cutting to expose holes uses highPrec and it seemed best to be consistent, avoiding cuts that might leave very small areas. A general move in the direction of all coordinates/bounds/etc being the held only in highPrec and resolution 24 not being a special case. But I don't have strong feelings about it. Ticker On Fri, 2017-02-17 at 13:12 +0000, Gerd Petermann wrote:
Hi Ticker,
I did not see an advantage in using high-prec. Why do you think it should be used?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 17. Februar 2017 13:27:28 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Gerd
Yes - sorry, my fault. I've just tested a fix to this and the sea is OK now. Is is worth keeping the high-res changes in the split-shape branch pending more work on MultiPolygonRelation? If so I'll commit.
Ticker
On Fri, 2017-02-17 at 10:49 +0000, Gerd Petermann wrote:
Hi Ticker,
problem is in these lines: if (remove) { // check if the polygon contains the complete bounding box if (w.getBounds().contains(tileArea.getBounds())) { remove = false; } } 1) The SeaGenerator creates an outer way which is larger than the tile bounds. 2) This test was wrong because w.getBounds() returns a bbox in highprec values and tileArea.getBounds() is in Garmin units
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 17. Februar 2017 11:00:49 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Gerd
Good.
Ticker
On Fri, 2017-02-17 at 09:41 +0000, Gerd Petermann wrote:
Hi Ticker,
attached is the patch I've created with help of svn. It only reverts the changes made to MultiPolygonRelation in r3771.
I don't know yet why they cause trouble.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 17. Februar 2017 10:32:11 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Gerd
Yes - if that fixes it. But in r3771 were there a couple of other changes not to MultiPolygon... haven't a lot more changes been made since to MultiPolygon...
Ticker
On Fri, 2017-02-17 at 09:19 +0000, Gerd Petermann wrote:
Hi Ticker,
I think the problems were introduced with the highprec changes in MultiPolygonRelation in r3771. When I revert those the problem is gone. If you don't mind I commit this revert.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@hotmail.com> Gesendet: Freitag, 17. Februar 2017 10:02:38 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Ticker,
don't need test data, found out what you meant.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@hotmail.com> Gesendet: Freitag, 17. Februar 2017 09:52:56 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Ticker,
okay, I'll merge the branch into trunk. Please post some test data to show the coastline problem and I'll try to fix it.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 17. Februar 2017 09:50:17 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Gerd
I fixed this problem with r3807 in the split-shape branch and this should probably be merged into trunk.
Mike was also getting another problem that might be related to generate-sea:extend-sea-sectors
I don't know much about this area, but just having this option and nothing else of significance, it seems as if the overview map has all sea if it has a coastline
Ticker
On Thu, 2017-02-16 at 20:12 +0000, Gerd Petermann wrote:
Hi Ticker,
In case you need test data: I've uploaded a file : http://files.mkgmap.org.uk/download/334/88009211.osm.pbf Produces the error with r3811 without any options, just java -jar mkpgmap.jar 88009211.osm.pbf Seems to work okay with r3807.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Donnerstag, 16. Februar 2017 10:40:55 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
HI Ticker, I'll package up some data for you. I have generate -sea:extend-sea-sectors in my options file, I think it will be related to that.
Regards, Mike
-----Original Message----- From: Ticker Berkin [mailto:rwb-mkgmap@jagit.co.uk] Sent: 16 February 2017 08:17 To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Mike
I'll fix/improve the message.
Can you tell if it is the sea polygons, the line 'coastline', or the island area (if your style generates this) that is corrupt.
Maybe send your splitter options / areas.list, mkgmap options and style and I'll see if I can reproduce.
Ticker
On Thu, 2017-02-16 at 01:23 +0000, Mike Baggaley wrote:
HI Ticker, I've tried the patch without the --order-by -decreasing -area option and it does now run without crashing. However, it suffers from the same problem as I mentioned earlier when trying - -order-by-decreasing-area without the patch, in that the coastline is corrupted. I haven't yet turned on detailed logging - I can do that if it would help.
I note that in MapSplitter.java there is a new line:
log.info("Single item larger that WANTED_MAX_AREA_SIZE", area.getBounds().getCenter().toOSMURL());
I think this should say 'than' rather than 'that' and probably WANTED_MAX_AREA_SIZE should be outside the string so we see an actual number.
Regards, 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 _______________________________________________ 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
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
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Andrzej, no, it causes lots of problems. For example, the bounding box for planet is (-90.0, -180.0, 90.0, 180.0). If we don't distinct the positions of the left side from the right the area is a line with width 0. The funny thing is that the precision in OSM doesn't even use all possible 32 bit integers, only those for -180 * 10_000_000 to 180 * 10_000_000 so the extreme values near Integer.MAX_VALUE are never used (at least that is the conversion done in pbf or o5m format). I think about using this format for Coord and maybe also Area. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Dienstag, 21. Februar 2017 12:23:57 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch Hi Gerd,
I found new problems, e.g. 180.0 degrees and -180.0 degrees started to give the same 32 bit value.
Isn't it good? The same is true for 24 bit precision and even for 8bit angles. -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, could you really make a map, which include both +180 and -180 coordinates? I create a map of Asia and I intentionally limit area to 179.9999, because of compilation problems. Maybe if you limit input data that way, that you never process -180 and +180 at the same time, then you could ignore double meaning of +-180? -- Best regards, Andrzej
Hi Andrzej, sounds possible, but would require lots of difficult changes. That's the problem, each possible way seems to include lots of changes :-( I think the first step is to code more unit tests ... Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Dienstag, 21. Februar 2017 13:13:25 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch Hi Gerd, could you really make a map, which include both +180 and -180 coordinates? I create a map of Asia and I intentionally limit area to 179.9999, because of compilation problems. Maybe if you limit input data that way, that you never process -180 and +180 at the same time, then you could ignore double meaning of +-180? -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi According to my calcs, full 32 bit integers give a resolution of about 10mm at the equator. Why do you need better than existing high-res (30 bits - ~40mm)? Maybe go to 31 to save the +-180 degree problem. Not to have the resolution as a powerOfTwo of the garmin map unit would require a lot of changes throughout the code and a run-time cost. Manipulating high-res deltas such that the rounded values diverges from the the std lat/long value seems very wrong (is this what it does, or does it simply change one but not the other). Maybe wrong-angle stuff should be looked at to see if there is a better way. This is an area I've never been near. Would be great if Area/bounds and Coord used the same (high-prec) units and there was no ambiguity about contains(). Ticker
Hi Ticker, okay, I'll try to find out (again) why I decided to do the move only in low-prec. I know that I was not happy with that, but I forgot the reason. I think one was that the WrongAngleFixer started to move points too far. Anyway, I should fix this first. I started to go for 32 bits because some algos which I coded for JOSM use this res. It seemed easier to change mkgmap to also use 32 bits, but I am no longer sure about that. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 21. Februar 2017 18:44:35 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch Hi According to my calcs, full 32 bit integers give a resolution of about 10mm at the equator. Why do you need better than existing high-res (30 bits - ~40mm)? Maybe go to 31 to save the +-180 degree problem. Not to have the resolution as a powerOfTwo of the garmin map unit would require a lot of changes throughout the code and a run-time cost. Manipulating high-res deltas such that the rounded values diverges from the the std lat/long value seems very wrong (is this what it does, or does it simply change one but not the other). Maybe wrong-angle stuff should be looked at to see if there is a better way. This is an area I've never been near. Would be great if Area/bounds and Coord used the same (high-prec) units and there was no ambiguity about contains(). Ticker _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Ticker, okay, here are my findings so far: 1) We assume that the double values read from OSM or polist (*.mp) format are precise 2) The code in the Coord class tries to reduce rounding errors. It calculates both the 24 values AND the high prec values from the given doubles. An alternative would be to calculate only the high prec values from the doubles and then calculate the 24 bit values by shifting, but that would in fact mean that the value is rounded two times. In some edge cases you will get different 24 values doing this. The delta values are stored in the Coord instance and for 30 bits precision they are -32 <= delta < 32. The picture grid1 shows some OSM elements and the Garmin Grid (24 bit resolution): http://files.mkgmap.org.uk/download/335/grid1.png and what the "normal" rounding does (note the zig-zagging rails) http://files.mkgmap.org.uk/download/336/grid2.png 3) The method Coord.getAlternativePositions() called by WrongAngleFixer introduces some additional problems: It creates Coord instances where the delta values can be up to 63 (-63 <= delta < 63). This sounds much, but it only happens for OSM nodes which are far from any Garmin grid point. Imagine that an OSM node lies exactly in the center of four Garmin grid points. All four would have the same rounding error, but the distance between them can be ~2.3 m. Which of the four Garmin points should be returned by the Coord.getDisplayedCoord() method? For a single POI like a natural=peak it doesn't really matter, but for a node which is part of a roundabout or a railway=rail you want to get the point which "looks" better. A human knows by experience that rails are not zig-zagging, so the goal of the WrongAngleFixer is find the Garmin point which causes the smallest errors in the angles. This is not only done for points which lie exactly in the center of Garmin grid points, but for all which are not close to one such point. The WrongAngleFixer uses a iterative try-error approach to find those nodes which should be "moved", and it needs to know the "original" position. I found no performant way to implement that with hashmaps, so I decided to code what we have now. The improved result looks like this: http://files.mkgmap.org.uk/download/337/grid3.png Later in the data flow the routines for the road network also need to know the real positions when they calculate the bearing values. In short: I found no better solution, it works quite well but one has to think twice if he needs the Garmin position or the high prec (OSM) position. Worth noting is that the WrongAngleFixer is called for lines and shapes, but at different stages. For lines (and roads), it is called before MapLine instances are created. For shapes, it is called by the ShapeMergeFilter which is called after all the sub division splitting happened. That means In the current code (r3820), the ShapeSplitter doesn't have to care about "moved" points in shapes. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@hotmail.com> Gesendet: Dienstag, 21. Februar 2017 20:01:06 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch Hi Ticker, okay, I'll try to find out (again) why I decided to do the move only in low-prec. I know that I was not happy with that, but I forgot the reason. I think one was that the WrongAngleFixer started to move points too far. Anyway, I should fix this first. I started to go for 32 bits because some algos which I coded for JOSM use this res. It seemed easier to change mkgmap to also use 32 bits, but I am no longer sure about that. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 21. Februar 2017 18:44:35 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch Hi According to my calcs, full 32 bit integers give a resolution of about 10mm at the equator. Why do you need better than existing high-res (30 bits - ~40mm)? Maybe go to 31 to save the +-180 degree problem. Not to have the resolution as a powerOfTwo of the garmin map unit would require a lot of changes throughout the code and a run-time cost. Manipulating high-res deltas such that the rounded values diverges from the the std lat/long value seems very wrong (is this what it does, or does it simply change one but not the other). Maybe wrong-angle stuff should be looked at to see if there is a better way. This is an area I've never been near. Would be great if Area/bounds and Coord used the same (high-prec) units and there was no ambiguity about contains(). Ticker _______________________________________________ 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
Hi Gerd Sorry about the delay in replying. Thoughts on some of this. Assuming the MapRes and highRes are related by powers of 2, and all the rounding is done consistently, there should never be any difference between going via highRes to get from the original doubleFloat value to a MapRes value. The most consistent rounding in mkgmap code is to the closest whole number with x.50000 rounding up towards plus infinity. This is also the definition of Math.round(). So, it would be much clearer and have the same effect if old:imgFmt.Utils.toMapUnit new:Coord.toHighPrec were re-coded as return Math.round(degrees / 360.0D * (1 << resolution)) Other cases of rounding should be checked - esp. Utils.roundup()), which I thought was wrong, but looking again seems OK. This effects how the base Lat/Lon for a subdivision is held - should be a correctly rounded value. In the new versions of Coord.getLatitude/Longitude(), could have/use final int DELTA_HALF = 1 << (DELTA_SHIFT - 1); I'm still studying the wrongAngleFixer/AlternativePos/DisplayedCoord stuff, but getting a little bit lost as to when need to keep the all the flags in the copy of the Coord and when not (ie getDisplayedCoord loses all the flags and highPrec info) and what is taken into account for the distance() function I have this feeling that Coord shouldn't have all this INC/DEC_LAT/LON stuff but wrongAngleFixer just make up an adjacent Coord if it does a better job Ticker On Fri, 2017-02-24 at 10:54 +0000, Gerd Petermann wrote:
Hi Ticker,
okay, here are my findings so far: 1) We assume that the double values read from OSM or polist (*.mp) format are precise 2) The code in the Coord class tries to reduce rounding errors. It calculates both the 24 values AND the high prec values from the given doubles. An alternative would be to calculate only the high prec values from the doubles and then calculate the 24 bit values by shifting, but that would in fact mean that the value is rounded two times. In some edge cases you will get different 24 values doing this. The delta values are stored in the Coord instance and for 30 bits precision they are -32 <= delta < 32. The picture grid1 shows some OSM elements and the Garmin Grid (24 bit resolution): http://files.mkgmap.org.uk/download/335/grid1.png and what the "normal" rounding does (note the zig-zagging rails) http://files.mkgmap.org.uk/download/336/grid2.png
3) The method Coord.getAlternativePositions() called by WrongAngleFixer introduces some additional problems: It creates Coord instances where the delta values can be up to 63 ( -63 <= delta < 63). This sounds much, but it only happens for OSM nodes which are far from any Garmin grid point. Imagine that an OSM node lies exactly in the center of four Garmin grid points. All four would have the same rounding error, but the distance between them can be ~2.3 m. Which of the four Garmin points should be returned by the Coord.getDisplayedCoord() method? For a single POI like a natural=peak it doesn't really matter, but for a node which is part of a roundabout or a railway=rail you want to get the point which "looks" better. A human knows by experience that rails are not zig-zagging, so the goal of the WrongAngleFixer is find the Garmin point which causes the smallest errors in the angles. This is not only done for points which lie exactly in the center of Garmin grid points, but for all which are not close to one such point. The WrongAngleFixer uses a iterative try-error approach to find those nodes which should be "moved", and it needs to know the "original" position. I found no performant way to implement that with hashmaps, so I decided to code what we have now. The improved result looks like this: http://files.mkgmap.org.uk/download/337/grid3.png
Later in the data flow the routines for the road network also need to know the real positions when they calculate the bearing values.
In short: I found no better solution, it works quite well but one has to think twice if he needs the Garmin position or the high prec (OSM) position.
Worth noting is that the WrongAngleFixer is called for lines and shapes, but at different stages. For lines (and roads), it is called before MapLine instances are created. For shapes, it is called by the ShapeMergeFilter which is called after all the sub division splitting happened. That means In the current code (r3820), the ShapeSplitter doesn't have to care about "moved" points in shapes.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@hotmail.com> Gesendet: Dienstag, 21. Februar 2017 20:01:06 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Ticker,
okay, I'll try to find out (again) why I decided to do the move only in low-prec. I know that I was not happy with that, but I forgot the reason. I think one was that the WrongAngleFixer started to move points too far. Anyway, I should fix this first.
I started to go for 32 bits because some algos which I coded for JOSM use this res. It seemed easier to change mkgmap to also use 32 bits, but I am no longer sure about that.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 21. Februar 2017 18:44:35 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi
According to my calcs, full 32 bit integers give a resolution of about 10mm at the equator. Why do you need better than existing high-res (30 bits - ~40mm)? Maybe go to 31 to save the +-180 degree problem.
Not to have the resolution as a powerOfTwo of the garmin map unit would require a lot of changes throughout the code and a run-time cost.
Manipulating high-res deltas such that the rounded values diverges from the the std lat/long value seems very wrong (is this what it does, or does it simply change one but not the other). Maybe wrong-angle stuff should be looked at to see if there is a better way. This is an area I've never been near.
Would be great if Area/bounds and Coord used the same (high-prec) units and there was no ambiguity about contains().
Ticker
_______________________________________________ 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
Hi Ticker, good to see that the code in WrongAngleFixer is reviewed. I am sure it can be improved. Just keep in mind that it sometimes finds out that it is better to place the "moved" point on top of another. If this happens with routing nodes you need a way to calculate the bearing values "between" these points. If you decide to remove the information from the coords you probably have to store it in the way. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Samstag, 25. Februar 2017 18:17:37 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch Hi Gerd Sorry about the delay in replying. Thoughts on some of this. Assuming the MapRes and highRes are related by powers of 2, and all the rounding is done consistently, there should never be any difference between going via highRes to get from the original doubleFloat value to a MapRes value. The most consistent rounding in mkgmap code is to the closest whole number with x.50000 rounding up towards plus infinity. This is also the definition of Math.round(). So, it would be much clearer and have the same effect if old:imgFmt.Utils.toMapUnit new:Coord.toHighPrec were re-coded as return Math.round(degrees / 360.0D * (1 << resolution)) Other cases of rounding should be checked - esp. Utils.roundup()), which I thought was wrong, but looking again seems OK. This effects how the base Lat/Lon for a subdivision is held - should be a correctly rounded value. In the new versions of Coord.getLatitude/Longitude(), could have/use final int DELTA_HALF = 1 << (DELTA_SHIFT - 1); I'm still studying the wrongAngleFixer/AlternativePos/DisplayedCoord stuff, but getting a little bit lost as to when need to keep the all the flags in the copy of the Coord and when not (ie getDisplayedCoord loses all the flags and highPrec info) and what is taken into account for the distance() function I have this feeling that Coord shouldn't have all this INC/DEC_LAT/LON stuff but wrongAngleFixer just make up an adjacent Coord if it does a better job Ticker On Fri, 2017-02-24 at 10:54 +0000, Gerd Petermann wrote:
Hi Ticker,
okay, here are my findings so far: 1) We assume that the double values read from OSM or polist (*.mp) format are precise 2) The code in the Coord class tries to reduce rounding errors. It calculates both the 24 values AND the high prec values from the given doubles. An alternative would be to calculate only the high prec values from the doubles and then calculate the 24 bit values by shifting, but that would in fact mean that the value is rounded two times. In some edge cases you will get different 24 values doing this. The delta values are stored in the Coord instance and for 30 bits precision they are -32 <= delta < 32. The picture grid1 shows some OSM elements and the Garmin Grid (24 bit resolution): http://files.mkgmap.org.uk/download/335/grid1.png and what the "normal" rounding does (note the zig-zagging rails) http://files.mkgmap.org.uk/download/336/grid2.png
3) The method Coord.getAlternativePositions() called by WrongAngleFixer introduces some additional problems: It creates Coord instances where the delta values can be up to 63 ( -63 <= delta < 63). This sounds much, but it only happens for OSM nodes which are far from any Garmin grid point. Imagine that an OSM node lies exactly in the center of four Garmin grid points. All four would have the same rounding error, but the distance between them can be ~2.3 m. Which of the four Garmin points should be returned by the Coord.getDisplayedCoord() method? For a single POI like a natural=peak it doesn't really matter, but for a node which is part of a roundabout or a railway=rail you want to get the point which "looks" better. A human knows by experience that rails are not zig-zagging, so the goal of the WrongAngleFixer is find the Garmin point which causes the smallest errors in the angles. This is not only done for points which lie exactly in the center of Garmin grid points, but for all which are not close to one such point. The WrongAngleFixer uses a iterative try-error approach to find those nodes which should be "moved", and it needs to know the "original" position. I found no performant way to implement that with hashmaps, so I decided to code what we have now. The improved result looks like this: http://files.mkgmap.org.uk/download/337/grid3.png
Later in the data flow the routines for the road network also need to know the real positions when they calculate the bearing values.
In short: I found no better solution, it works quite well but one has to think twice if he needs the Garmin position or the high prec (OSM) position.
Worth noting is that the WrongAngleFixer is called for lines and shapes, but at different stages. For lines (and roads), it is called before MapLine instances are created. For shapes, it is called by the ShapeMergeFilter which is called after all the sub division splitting happened. That means In the current code (r3820), the ShapeSplitter doesn't have to care about "moved" points in shapes.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@hotmail.com> Gesendet: Dienstag, 21. Februar 2017 20:01:06 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Ticker,
okay, I'll try to find out (again) why I decided to do the move only in low-prec. I know that I was not happy with that, but I forgot the reason. I think one was that the WrongAngleFixer started to move points too far. Anyway, I should fix this first.
I started to go for 32 bits because some algos which I coded for JOSM use this res. It seemed easier to change mkgmap to also use 32 bits, but I am no longer sure about that.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 21. Februar 2017 18:44:35 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi
According to my calcs, full 32 bit integers give a resolution of about 10mm at the equator. Why do you need better than existing high-res (30 bits - ~40mm)? Maybe go to 31 to save the +-180 degree problem.
Not to have the resolution as a powerOfTwo of the garmin map unit would require a lot of changes throughout the code and a run-time cost.
Manipulating high-res deltas such that the rounded values diverges from the the std lat/long value seems very wrong (is this what it does, or does it simply change one but not the other). Maybe wrong-angle stuff should be looked at to see if there is a better way. This is an area I've never been near.
Would be great if Area/bounds and Coord used the same (high-prec) units and there was no ambiguity about contains().
Ticker
_______________________________________________ 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
Hi Ticker, that stops the unbound recursion, however the map it produces is faulty. The only areas that show up as land are complete rectangles within the mainland (see attachment). Even small islets do not have any land area. Of course this may be a different problem. Regards, Mike -----Original Message----- From: Ticker Berkin [mailto:rwb-mkgmap@jagit.co.uk] Sent: 15 February 2017 08:53 To: mkgmap development <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch Hi Mike OK - I think I understand the problem. Can you try with --order-by-decreasing-area and let me know if that stops the unbound recursion, and, in the meantime, I'll work on it. Thanks Ticker On Wed, 2017-02-15 at 00:48 +0000, Mike Baggaley wrote:
HI Ticker, having run this under the debugger now, it appears that it is not the postcode data after all - I was getting confused between the too small to split messages and too many POIs messages. I was previously getting too small to split messages in splitter, but not in mkgmap.
I temporarily changed the code to:
} else if (mustSplit) { // can't reduce size, so force more subdivisions if (depth < 1000) { log.debug("splitting area by contents", area); MapArea[] sublist = area.split(1, 1, bounds, true); addAreasToList(sublist, alist, depth + 1); continue; } else { log.error("Area too small to split at " + area.getBounds().getCenter().toOSMURL() + " (reduce the density of points, length of lines, etc.)");
} }
This ran successfully and gave a single error: Area too small to split at http://www.openstreetmap.org/?mlat=51.797190&mlon=0.918646&zoom=17 (r educe the density of points, length of lines, etc.
Stopping in the debugger, I can see that sizes[MapArea.SHAPE_KIND] is 68076 and from the coordinate it is processing the coastline. The call stack has the same value for the sizes[MapArea.SHAPE_KIND] in every instance of addAreasToList, so it looks like the call to area.split is not actually splitting. Looking at the resulting file in BaseCamp, I can see that the coastline is corrupt.
Hope that helps, Mike
-----Original Message----- From: Ticker Berkin [mailto:rwb-mkgmap@jagit.co.uk] Sent: 14 February 2017 23:21 To: Mike Baggaley <mike@tvage.co.uk> Subject: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Mike
I have the raw postcode data (codePointOpen.zip) which I processes just to take the first few at the same point but I can change it do all of them individually. Do you feed it with a map through the splitter or just make a postcode only overlay? What is the bit of style you use to represent each postcode? I can probably knock up something similar.
The code should cope - I can't see anything obviously wrong so need to try and reproduce the problem
Ticker
On Tue, 2017-02-14 at 18:17 +0000, Mike Baggaley wrote:
Hi Ticker the data is postcode centres (points). As well as geographic postcodes, the Royal Mail postcode data includes a number of postcodes that are centred on sorting offices (presumably for box numbers). There are quite a few at large sorting offices, but if each split should be able to accept 255 points, and it is exceeding 2000 splits before crashing, it looks like the splitting is not working - there won't be more than 2000 * 255 postcodes at the same place. My OSM file is rather large. I can see whether I can extract a map centred on a sorting office.
Regards, Mike
-----Original Message----- From: Ticker Berkin [mailto:rwb-mkgmap@jagit.co.uk] Sent: 14 February 2017 17:52 To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Mike
This is an area of code I've changed and it should be able to cope with many items at the same location without recursing.
Do you have some sample data? what are the items (point/line/shape extended?)
Ticker
On Tue, 2017-02-14 at 17:40 +0000, Mike Baggaley wrote:
Hi Gerd, since this change I am getting a java.lang.StackOverflowError crash caused by the code recursively attempting to split something which is unsplittable (assuming the split is based on location), as I have a large number of points at exactly the same location (from external data I add to the OSM data).
The offending line is at uk.me.parabola.mkgmap.build.MapSplitter.addAreasToList(MapSplitte r. ja va:187) . It is failing on my system with a depth of 2342. I suggest there needs to be a maximum depth after which it should give up trying to split.
} else if (mustSplit) { // can't reduce size, so force more subdivisions log.debug("splitting area by contents", area); MapArea[] sublist = area.split(1, 1, bounds, true); addAreasToList(sublist, alist, depth + 1); continue; }
I am unsure whether you would want a fixed depth limit, would want it to be set by parameter, would prefer to catch the error or think it would be possible to see whether the proposed area split has made any improvement, and give up if it hasn't.
Regards, Mike
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Mike I think this is just a problem with the rules the tool you are using to show the image conflicting with what --order-by-decreasing-area aims to achieve on a Garmin device. For instance, observations of GPSMapEdit shows it renders smaller polygons on top of larger ones as the way of deciding what is shown. --order-by-decreasing-area has split polygons geographical and so this size-based rule becomes meaningless and can result in what you are seeing. Given it didn't crash, I hope I've understood what your original problem was and fixed it in split-shape branch. Regards Ticker On Wed, 2017-02-15 at 17:12 +0000, Mike Baggaley wrote:
Hi Ticker, that stops the unbound recursion, however the map it produces is faulty. The only areas that show up as land are complete rectangles within the mainland (see attachment). Even small islets do not have any land area. Of course this may be a different problem.
Regards, Mike
participants (4)
-
Andrzej Popowski -
Gerd Petermann -
Mike Baggaley -
Ticker Berkin