[PATCH v1] Performance improvement by removing unused elements before the style processing
Hi, this is another performance improvement: Usually the mkgmap input tiles are larger than the processed bounding box (splitter parameter overlap). So there are much many elements which are processed but thrown away at a late step in mkgmap. The patch tries to remove them much earlier before the style files are processed and before the LocationHook starts (which ignores them but that must also be calculated). The patch contains one drawback: Ways which have all its points outside the bounding box of the tile but which cross the tile are also removed. If that's a point the patch must be improved. Have fun! WanMil
Hi, WanMil wrote
Usually the mkgmap input tiles are larger than the processed bounding box (splitter parameter overlap). So there are much many elements which are processed but thrown away at a late step in mkgmap.
It makes mkgmap faster, but wouldn't it be better to filter that data in splitter? Gerd -- View this message in context: http://gis.638310.n2.nabble.com/PATCH-v1-Performance-improvement-by-removing... Sent from the Mkgmap Development mailing list archive at Nabble.com.
WanMil <wmgcnfg@web.de> writes:
Hi,
this is another performance improvement:
Usually the mkgmap input tiles are larger than the processed bounding box (splitter parameter overlap). So there are much many elements which are processed but thrown away at a late step in mkgmap.
The patch tries to remove them much earlier before the style files are processed and before the LocationHook starts (which ignores them but that must also be calculated).
The patch contains one drawback: Ways which have all its points outside the bounding box of the tile but which cross the tile are also removed. If that's a point the patch must be improved.
Isn't that the whole point of the larger bounding box, to not lose roads which cross at corners?
Hi Greg, hi Gerd, yes, it would be great if the splitter throws those elements away. But that's a discussion that pops up every few months. Filtering out those elements seems to be difficult and makes the splitter *much* slower. As far as I understood you need (at least?) two passes of the input file for that. Splitter would have to detect all ways that intersect the bounding box and all ways and nodes that are part of a multipolygon intersecting the bounding box. That also means that splitter has to implement an multipolygon handling. Routing and multipolygons require the splitter overlap functionality. By increasing the overlap parameter many more multipolygons are complete or in such a status that the MP algorithm of mkgmap can do its best to guess how the holes must be completed. The patch also removes all ways and nodes without any tag. They exist because mkgmap only loads tags that are referenced by the style. But mkgmap cannot throw them away during loading because they might be referenced by multipolygons. The patch has bug: Ways and nodes without any tag must not be thrown away if they are referenced by a relation. The relation might be used to tag the ways and nodes (e.g. a bus route). I will post an update later on. WanMil
Hi,
this is another performance improvement:
Usually the mkgmap input tiles are larger than the processed bounding box (splitter parameter overlap). So there are much many elements which are processed but thrown away at a late step in mkgmap.
The patch tries to remove them much earlier before the style files are processed and before the LocationHook starts (which ignores them but that must also be calculated).
The patch contains one drawback: Ways which have all its points outside the bounding box of the tile but which cross the tile are also removed. If that's a point the patch must be improved.
Have fun! WanMil
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
The 2nd patch fixes the remaining problems: 1. Ways without tags but referenced by relations are no longer removed (they might be tagged by the relation style file and could therefore appear in the map) 2. Intersection of ways with the tile bounding box is now checked instead of only checking that at least one point is contained in the bounding box. Only very few ways are affected by this but otherwise routing problems are possible. The performance improvement seems to be good (measured with my test map): r2159: ~250s patched: ~225s I also expect (although I haven't tested) that the max memory requirement of mkgmap is decreased. I think max mem is used when the style file is just processed. At this stage all raw OSM elements and all style file processed elements are kept in memory. With the patch the number of OSM elements is noticeably reduced. WanMil
Hi,
this is another performance improvement:
Usually the mkgmap input tiles are larger than the processed bounding box (splitter parameter overlap). So there are much many elements which are processed but thrown away at a late step in mkgmap.
The patch tries to remove them much earlier before the style files are processed and before the LocationHook starts (which ignores them but that must also be calculated).
The patch contains one drawback: Ways which have all its points outside the bounding box of the tile but which cross the tile are also removed. If that's a point the patch must be improved.
Have fun! WanMil
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi WanMil, I tested the patch with my tiles for Saarland. I can confirm a reduction of processing time ~ 6% compared to r2160, and also a reduction for the peek value of heap memory usage (238M -> 210M), so that's both good! BUT I also see a difference in one of the seven output img files (plus the resulting gmapsupp.img), and I think this is not intended. Both files have the same size, but are different in many bytes. Let me know when I should send details, maybe the new result is better than the old ;-) Ciao, Gerd WanMil wrote
The 2nd patch fixes the remaining problems: 1. Ways without tags but referenced by relations are no longer removed (they might be tagged by the relation style file and could therefore appear in the map) 2. Intersection of ways with the tile bounding box is now checked instead of only checking that at least one point is contained in the bounding box. Only very few ways are affected by this but otherwise routing problems are possible.
The performance improvement seems to be good (measured with my test map): r2159: ~250s patched: ~225s
I also expect (although I haven't tested) that the max memory requirement of mkgmap is decreased. I think max mem is used when the style file is just processed. At this stage all raw OSM elements and all style file processed elements are kept in memory. With the patch the number of OSM elements is noticeably reduced.
WanMil
Hi,
this is another performance improvement:
Usually the mkgmap input tiles are larger than the processed bounding box (splitter parameter overlap). So there are much many elements which are processed but thrown away at a late step in mkgmap.
The patch tries to remove them much earlier before the style files are processed and before the LocationHook starts (which ignores them but that must also be calculated).
The patch contains one drawback: Ways which have all its points outside the bounding box of the tile but which cross the tile are also removed. If that's a point the patch must be improved.
Have fun! WanMil
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- View this message in context: http://gis.638310.n2.nabble.com/PATCH-v1-Performance-improvement-by-removing... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd, yes of course I am interested, Send me all information you have. Thanks WanMil
Hi WanMil,
I tested the patch with my tiles for Saarland. I can confirm a reduction of processing time ~ 6% compared to r2160, and also a reduction for the peek value of heap memory usage (238M -> 210M), so that's both good! BUT I also see a difference in one of the seven output img files (plus the resulting gmapsupp.img), and I think this is not intended. Both files have the same size, but are different in many bytes. Let me know when I should send details, maybe the new result is better than the old ;-)
Ciao, Gerd
WanMil wrote
The 2nd patch fixes the remaining problems: 1. Ways without tags but referenced by relations are no longer removed (they might be tagged by the relation style file and could therefore appear in the map) 2. Intersection of ways with the tile bounding box is now checked instead of only checking that at least one point is contained in the bounding box. Only very few ways are affected by this but otherwise routing problems are possible.
The performance improvement seems to be good (measured with my test map): r2159: ~250s patched: ~225s
I also expect (although I haven't tested) that the max memory requirement of mkgmap is decreased. I think max mem is used when the style file is just processed. At this stage all raw OSM elements and all style file processed elements are kept in memory. With the patch the number of OSM elements is noticeably reduced.
WanMil
Hi,
this is another performance improvement:
Usually the mkgmap input tiles are larger than the processed bounding box (splitter parameter overlap). So there are much many elements which are processed but thrown away at a late step in mkgmap.
The patch tries to remove them much earlier before the style files are processed and before the LocationHook starts (which ignores them but that must also be calculated).
The patch contains one drawback: Ways which have all its points outside the bounding box of the tile but which cross the tile are also removed. If that's a point the patch must be improved.
Have fun! WanMil
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- View this message in context: http://gis.638310.n2.nabble.com/PATCH-v1-Performance-improvement-by-removing... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hello WanMil, I can reproduce the problem with the attached files like this: 1) download saarland.osm.pbf from geofabrik created 04-Jan-2012 04:36 2) Use splitter r198 with --max-nodes=200000 3) compile r2160 with my identical_output.patch 4) execute mkgmap with the parms in test.bat 5) copy the output files to somewhwere else 6) execute mkgmap again with the same commands, verify that the new output files are identical to the copy 7) compile r2160 with my identical_output.patch + c:\TEMP\remove_unused_elements_v2.patch 8) execute mkgmap again with the same commands. I would again expect identical output, but I see this C:\temp\prove_patch>diff -qb ..\prove . Files ..\prove\63240003.img and .\63240003.img differ Files ..\prove\gmapsupp.img and .\gmapsupp.img differ Files ..\prove\mkgmap.jar and .\mkgmap.jar differ Files ..\prove\osmmap.tdb and .\osmmap.tdb differ Files ..\prove\osmmap_mdr.img and .\osmmap_mdr.img differ Ciao, Gerd
Date: Wed, 4 Jan 2012 19:10:28 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] [PATCH v2] Performance improvement by removing unused elements before the style processing
Hi Gerd,
yes of course I am interested, Send me all information you have.
Thanks WanMil
Hi WanMil,
I tested the patch with my tiles for Saarland. I can confirm a reduction of processing time ~ 6% compared to r2160, and also a reduction for the peek value of heap memory usage (238M -> 210M), so that's both good! BUT I also see a difference in one of the seven output img files (plus the resulting gmapsupp.img), and I think this is not intended. Both files have the same size, but are different in many bytes. Let me know when I should send details, maybe the new result is better than the old ;-)
Ciao, Gerd
WanMil wrote
The 2nd patch fixes the remaining problems: 1. Ways without tags but referenced by relations are no longer removed (they might be tagged by the relation style file and could therefore appear in the map) 2. Intersection of ways with the tile bounding box is now checked instead of only checking that at least one point is contained in the bounding box. Only very few ways are affected by this but otherwise routing problems are possible.
The performance improvement seems to be good (measured with my test map): r2159: ~250s patched: ~225s
I also expect (although I haven't tested) that the max memory requirement of mkgmap is decreased. I think max mem is used when the style file is just processed. At this stage all raw OSM elements and all style file processed elements are kept in memory. With the patch the number of OSM elements is noticeably reduced.
WanMil
Hi,
this is another performance improvement:
Usually the mkgmap input tiles are larger than the processed bounding box (splitter parameter overlap). So there are much many elements which are processed but thrown away at a late step in mkgmap.
The patch tries to remove them much earlier before the style files are processed and before the LocationHook starts (which ignores them but that must also be calculated).
The patch contains one drawback: Ways which have all its points outside the bounding box of the tile but which cross the tile are also removed. If that's a point the patch must be improved.
Have fun! WanMil
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- View this message in context: http://gis.638310.n2.nabble.com/PATCH-v1-Performance-improvement-by-removing... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ 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
Steve, can you do me a favour? I have uploaded both versions to http://files.mkgmap.org.uk/detail/46 (only files that differ and not the gmapsupp.img). Can you run the display tool and check if you can quickly find the difference? I would have to completely install the display tool and have to get warm with it... I think you are much quicker? ;-) Thanks! WanMil
Hello WanMil,
I can reproduce the problem with the attached files like this: 1) download saarland.osm.pbf from geofabrik created 04-Jan-2012 04:36 2) Use splitter r198 with --max-nodes=200000 3) compile r2160 with my identical_output.patch 4) execute mkgmap with the parms in test.bat 5) copy the output files to somewhwere else 6) execute mkgmap again with the same commands, verify that the new output files are identical to the copy 7) compile r2160 with my identical_output.patch + c:\TEMP\remove_unused_elements_v2.patch 8) execute mkgmap again with the same commands. I would again expect identical output, but I see this C:\temp\prove_patch>diff -qb ..\prove . Files ..\prove\63240003.img and .\63240003.img differ Files ..\prove\gmapsupp.img and .\gmapsupp.img differ Files ..\prove\mkgmap.jar and .\mkgmap.jar differ Files ..\prove\osmmap.tdb and .\osmmap.tdb differ Files ..\prove\osmmap_mdr.img and .\osmmap_mdr.img differ
Ciao, Gerd
Date: Wed, 4 Jan 2012 19:10:28 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] [PATCH v2] Performance improvement by removing unused elements before the style processing
Hi Gerd,
yes of course I am interested, Send me all information you have.
Thanks WanMil
Hi WanMil,
I tested the patch with my tiles for Saarland. I can confirm a reduction of processing time ~ 6% compared to r2160, and also a reduction for the peek value of heap memory usage (238M -> 210M), so that's both good! BUT I also see a difference in one of the seven output img files (plus the resulting gmapsupp.img), and I think this is not intended. Both files have the same size, but are different in many bytes. Let me know when I should send details, maybe the new result is better than the old ;-)
Ciao, Gerd
WanMil wrote
The 2nd patch fixes the remaining problems: 1. Ways without tags but referenced by relations are no longer removed (they might be tagged by the relation style file and could therefore appear in the map) 2. Intersection of ways with the tile bounding box is now checked instead of only checking that at least one point is contained in the bounding box. Only very few ways are affected by this but otherwise routing problems are possible.
The performance improvement seems to be good (measured with my
test map):
r2159: ~250s patched: ~225s
I also expect (although I haven't tested) that the max memory requirement of mkgmap is decreased. I think max mem is used when the style file is just processed. At this stage all raw OSM elements and all style file processed elements are kept in memory. With the patch the number of OSM elements is noticeably reduced.
WanMil
Hi,
this is another performance improvement:
Usually the mkgmap input tiles are larger than the processed bounding box (splitter parameter overlap). So there are much many elements which are processed but thrown away at a late step in mkgmap.
The patch tries to remove them much earlier before the style files are processed and before the LocationHook starts (which ignores them but that must also be calculated).
The patch contains one drawback: Ways which have all its points outside the bounding box of the tile but which cross the tile are also removed. If that's a point the patch must be improved.
Have fun! WanMil
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- View this message in context: http://gis.638310.n2.nabble.com/PATCH-v1-Performance-improvement-by-removing... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ 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
On 04/01/12 20:14, WanMil wrote:
Steve,
can you do me a favour? I have uploaded both versions to http://files.mkgmap.org.uk/detail/46 (only files that differ and not the gmapsupp.img).
Can you run the display tool and check if you can quickly find the difference? I would have to completely install the display tool and have to get warm with it... I think you are much quicker? ;-)
At first sight there is no difference in the number of elements of any kind. The difference is in the poi_properties section, where the patched version is larger than the unpatched by 6 bytes. So I would be looking at tags. I may be able to pin it down a bit further tomorrow. ..Steve
On 04/01/12 20:14, WanMil wrote:
Steve,
can you do me a favour? I have uploaded both versions to http://files.mkgmap.org.uk/detail/46 (only files that differ and not the gmapsupp.img).
Can you run the display tool and check if you can quickly find the difference? I would have to completely install the display tool and have to get warm with it... I think you are much quicker? ;-)
At first sight there is no difference in the number of elements of any kind.
The difference is in the poi_properties section, where the patched version is larger than the unpatched by 6 bytes.
So I would be looking at tags. I may be able to pin it down a bit further tomorrow.
..Steve
Hi Steve, that already helped! I printed out the tags of all POIs and the POI: [mkgmap:city=Saarbrücken,mkgmap:postcode=66117,building=yes,mkgmap:admin_level2=DEU,shop=supermarket,mkgmap:admin_level4=Saarland,mkgmap:admin_level6=Regionalverband Saarbrücken,mkgmap:postal_code=66117,mkgmap:admin_level8=Saarbrücken,mkgmap:area2poi=true,mkgmap:region=Regionalverband Saarbrücken,mkgmap:country=DEU] with internal Garmin coords lat:2293768 long:324722 is included in the patched but not in the unpatched version. The bounding box is: minlat: 2293760 minlong: 323584 maxlat: 2297856 maxlong: 327680 I am a bit helpless why the POI appears with the patched but not with the unpatched release... WanMil
Hi WanMil, I guess this is generated in this part of POIGeneratorHook.java: if (poiCoord == null) { // did not find any label coord // use the common center point of the area poiCoord = polygon.getCofG(); } Node poi = createPOI(polygon, poiCoord, AREA2POI_TAG); Ciao, Gerd -- View this message in context: http://gis.638310.n2.nabble.com/PATCH-v1-Performance-improvement-by-removing... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd, yes but why is it generated in the patched version and not in the unpatched? The patch only removes elements but does not add any... WanMil
Hi WanMil,
I guess this is generated in this part of POIGeneratorHook.java: if (poiCoord == null) { // did not find any label coord // use the common center point of the area poiCoord = polygon.getCofG(); }
Node poi = createPOI(polygon, poiCoord, AREA2POI_TAG);
Ciao, Gerd
-- View this message in context: http://gis.638310.n2.nabble.com/PATCH-v1-Performance-improvement-by-removing... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi WanMil, the comment says that something was not found, so the center of an area is taken. I assume this happens only in the patched version because that deletes this "something". Gerd WanMil wrote
Hi Gerd,
yes but why is it generated in the patched version and not in the unpatched? The patch only removes elements but does not add any...
WanMil
Hi WanMil,
I guess this is generated in this part of POIGeneratorHook.java: if (poiCoord == null) { // did not find any label coord // use the common center point of the area poiCoord = polygon.getCofG(); }
Node poi = createPOI(polygon, poiCoord, AREA2POI_TAG);
Ciao, Gerd
-- View this message in context: http://gis.638310.n2.nabble.com/PATCH-v1-Performance-improvement-by-removing... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- View this message in context: http://gis.638310.n2.nabble.com/PATCH-v1-Performance-improvement-by-removing... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd, I should read my own comments... :-) But that seems to be a possible reason. The POIGeneratorHook checks polygons for nodes tagged with building=entrance. If one node is found it is used by the POIGeneratorHook to set the POI for the polygon. The building=entrance node might be removed by the patch and therefore the POIGeneratorHook places the node in the middle of the polygon. But that's easy to check. I just have to move the point where new hook runs. WanMil
Hi WanMil,
the comment says that something was not found, so the center of an area is taken. I assume this happens only in the patched version because that deletes this "something".
Gerd
WanMil wrote
Hi Gerd,
yes but why is it generated in the patched version and not in the unpatched? The patch only removes elements but does not add any...
WanMil
Hi WanMil,
I guess this is generated in this part of POIGeneratorHook.java: if (poiCoord == null) { // did not find any label coord // use the common center point of the area poiCoord = polygon.getCofG(); }
Node poi = createPOI(polygon, poiCoord, AREA2POI_TAG);
Ciao, Gerd
-- View this message in context: http://gis.638310.n2.nabble.com/PATCH-v1-Performance-improvement-by-removing... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- View this message in context: http://gis.638310.n2.nabble.com/PATCH-v1-Performance-improvement-by-removing... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Thanks, binary output is now identical. But now I have to check if the performance improvement is still there. WanMil
Hi Gerd,
I should read my own comments... :-)
But that seems to be a possible reason. The POIGeneratorHook checks polygons for nodes tagged with building=entrance. If one node is found it is used by the POIGeneratorHook to set the POI for the polygon.
The building=entrance node might be removed by the patch and therefore the POIGeneratorHook places the node in the middle of the polygon.
But that's easy to check. I just have to move the point where new hook runs.
WanMil
Hi WanMil,
the comment says that something was not found, so the center of an area is taken. I assume this happens only in the patched version because that deletes this "something".
Gerd
WanMil wrote
Hi Gerd,
yes but why is it generated in the patched version and not in the unpatched? The patch only removes elements but does not add any...
WanMil
Hi WanMil,
I guess this is generated in this part of POIGeneratorHook.java: if (poiCoord == null) { // did not find any label coord // use the common center point of the area poiCoord = polygon.getCofG(); }
Node poi = createPOI(polygon, poiCoord, AREA2POI_TAG);
Ciao, Gerd
-- View this message in context: http://gis.638310.n2.nabble.com/PATCH-v1-Performance-improvement-by-removing... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- View this message in context: http://gis.638310.n2.nabble.com/PATCH-v1-Performance-improvement-by-removing... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ 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 WanMil This patch is a really great idea. It does make a big reduction in the number of ways and nodes processed. I don't see much difference in time on my home machine, some improvement on my server however . I'm beginning to think that my machine is not CPU bound for these tasks. Anyway it's great that others are seeing big differences. ..Steve
Hello WanMil, while working on an improvement regarding the BoundaryPreparer I wonder what we do with the administrative boundaries that are found in the OSM data. If I see this right, we store the precompiled boundaries as well as those from OSM input files. Maybe that's another place to remove unused data? Gerd -- View this message in context: http://gis.638310.n2.nabble.com/PATCH-v1-Performance-improvement-by-removing... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hello WanMil,
while working on an improvement regarding the BoundaryPreparer I wonder what we do with the administrative boundaries that are found in the OSM data. If I see this right, we store the precompiled boundaries as well as those from OSM input files. Maybe that's another place to remove unused data?
Gerd
Gerd, the precompiled bounds are used only to assign the country, region, city and zip information. They are not used outside the LocationHook. WanMil
Hi WanMil, yes, and both use different classes to store the information. So, the data is not unused but duplicated. I see no easy way to change that, so forget that for now. Ciao, Gerd
Date: Thu, 5 Jan 2012 22:04:48 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] [PATCH v2] Performance improvement by removing unused elements before the style processing
Hello WanMil,
while working on an improvement regarding the BoundaryPreparer I wonder what we do with the administrative boundaries that are found in the OSM data. If I see this right, we store the precompiled boundaries as well as those from OSM input files. Maybe that's another place to remove unused data?
Gerd
Gerd,
the precompiled bounds are used only to assign the country, region, city and zip information. They are not used outside the LocationHook.
WanMil _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (5)
-
Gerd Petermann -
GerdP
-
Greg Troxel -
Steve Ratcliffe -
WanMil