[PATCH v1] Reduce number of cuts in multipolygon processing

The patch reduces the number of cuts that must be performed for each inner polygon. The current code performs one cut for each inner polygon. The patch reduces the number of cuts by selecting cut lines that hit more than one inner polygon at once. This has two advantages: 1. The artefacts on the cut lines in Mapsource are reduced because there are less cut lines. 2. The performance of the mp code for large multipolygons is very much dependend on how many cuts must be performed. Tests in Finland with generate-sea=multipolygon have shown a 75%(!) drop on processing time. In case there are no large multipolygons the performance stays quite the same. WanMil

Hi WanMil,
This has two advantages: 1. The artefacts on the cut lines in Mapsource are reduced because there are less cut lines. 2. The performance of the mp code for large multipolygons is very much dependend on how many cuts must be performed.
A third advantage: the image file might be slightly smaller. I found something strange in my test: Error at line 2341764, col 41 Bad file format: 63240004.osm.gz Exception in thread "main" java.lang.NullPointerException at uk.me.parabola.mkgmap.combiners.FileInfo.getFileInfo(FileInfo.java:136) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:369) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:124) at uk.me.parabola.mkgmap.main.Main.main(Main.java:122) This would be the 'outer' in the following line: <relation id='302404'> <member type='way' ref='31755158' role='outer'/> I will retest without the patch, and also test the patch with yesterday's dump. Marko

I wrote:
I found something strange in my test:
Error at line 2341764, col 41 Bad file format: 63240004.osm.gz Exception in thread "main" java.lang.NullPointerException at uk.me.parabola.mkgmap.combiners.FileInfo.getFileInfo (FileInfo.java:136) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:369) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs CommandArgsReader.java:124) at uk.me.parabola.mkgmap.main.Main.main(Main.java:122)
This would be the 'outer' in the following line:
<relation id='302404'> <member type='way' ref='31755158' role='outer'/>
I will retest without the patch, and also test the patch with yesterday's dump.
I could not repeat this, and I do not see how it could possibly be related to the patch. If nobody opposes, I will commit the patch. Marko

Mark,
Marko,
If nobody opposes, I will commit the patch.
Fine, but why not hang on for a while and give people a chance to try it out and report back before it gets committed.
Sure, it is a non-trivial change to the algorithm. What about one week? If I forget, WanMil please remind me. :-) Marko

Hello Marko,
Sure, it is a non-trivial change to the algorithm. What about one week? If I forget, WanMil please remind me. :-)
My rule of thumb for committing non-trivial changes goes along the lines of: if you receive negative reports, either fix the patch or convince the reporter the're doing something wrong! if you receive positive reports, commit the patch when you feel confident that it's received a reasonable amount of testing - the more positive reports you receive, the greater the likelyhood that's it's going to be OK and you can commit sooner rather than later. if you receive no reports, either badger people to try it out or just commit the patch anyway and if it breaks everything that's their fault for not helping with the testing. Something like that. Mark

I too ran into problems using the patch (on Austria from geofabrik): java.lang.NullPointerException at uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation.cutOutInnerPolygons(MultiPolygonRelation.java:892) at uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation.processElements(MultiPolygonRelation.java:640) at uk.me.parabola.mkgmap.reader.osm.xml.Osm5XmlHandler.endRelation(Osm5XmlHandler.java:569) at uk.me.parabola.mkgmap.reader.osm.xml.Osm5XmlHandler.endElement(Osm5XmlHandler.java:539) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(Unknown Source) at com.sun.org.apache.xerces.internal.xinclude.XIncludeHandler.endElement(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown Source) at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at javax.xml.parsers.SAXParser.parse(Unknown Source) at javax.xml.parsers.SAXParser.parse(Unknown Source) at uk.me.parabola.mkgmap.reader.osm.xml.Osm5MapDataSource.load(Osm5MapDataSource.java:81) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:148) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:56) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:189) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:186) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Exiting - if you want to carry on regardless, use the --keep-going option 16:35:25 Maybe both Marko and me am using some other patches that break something here? --- therefore attached my patches to mkgmap I'm currently using (except a bit copyright info changes for maps created, mainly a patch to change dp filter independantly for polygons).

Hi Felix, WanMil,
Maybe both Marko and me am using some other patches that break something here?
The only other patch I have on top of r1584 default style is the translation of traffic_calming=* in the POI file. No changes to the code. Could it be some hard-to-trigger race condition? I am running on a laptop with a dual-core Intel Core (L2400), and my map has 4 tiles at the moment. The problem did not occur on the second try. Marko
participants (4)
-
Felix Hartmann
-
Mark Burton
-
Marko Mäkelä
-
WanMil