Bad performance because of complex boundary relation

Hi, this might be an OSM problem... While working on a "beautifyRoundabout" algo I wondered why one tile in Southamerica needed a very long time to calculate. It turned out to be a problem in the location hook. The boundary relation 1981462 is a very complex polygon. I don't see a simple solution in mkgmap, but wouldn't it be better to create a simple way enclosing the area to map this boundary? Gerd

Hi Gerd, yes, this relation takes ~40% of processing time when precompiling bounds of the whole world. Simplifying it would be great! WanMil
Hi,
this might be an OSM problem... While working on a "beautifyRoundabout" algo I wondered why one tile in Southamerica needed a very long time to calculate. It turned out to be a problem in the location hook. The boundary relation 1981462 is a very complex polygon. I don't see a simple solution in mkgmap, but wouldn't it be better to create a simple way enclosing the area to map this boundary?
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@www.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi all, it seems that finally someone did it :-) I assume that this will reduce the size of the bounds file for this area, so maybe you have to allow a decrease in the size of the bounds-latest.zip file. Gerd WanMil wrote
Hi Gerd,
yes, this relation takes ~40% of processing time when precompiling bounds of the whole world. Simplifying it would be great!
WanMil
Hi,
this might be an OSM problem... While working on a "beautifyRoundabout" algo I wondered why one tile in Southamerica needed a very long time to calculate. It turned out to be a problem in the location hook. The boundary relation 1981462 is a very complex polygon. I don't see a simple solution in mkgmap, but wouldn't it be better to create a simple way enclosing the area to map this boundary?
Gerd
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/Bad-performance-because-of-complex-boundary-r... Sent from the Mkgmap Development mailing list archive at Nabble.com.

Hi, On Tue, Jun 17, GerdP wrote:
Hi all,
it seems that finally someone did it :-)
I assume that this will reduce the size of the bounds file for this area, so maybe you have to allow a decrease in the size of the bounds-latest.zip file.
Thanks for the hint ;) I uploaded a new boundary file now. Thorsten
Gerd
WanMil wrote
Hi Gerd,
yes, this relation takes ~40% of processing time when precompiling bounds of the whole world. Simplifying it would be great!
WanMil
Hi,
this might be an OSM problem... While working on a "beautifyRoundabout" algo I wondered why one tile in Southamerica needed a very long time to calculate. It turned out to be a problem in the location hook. The boundary relation 1981462 is a very complex polygon. I don't see a simple solution in mkgmap, but wouldn't it be better to create a simple way enclosing the area to map this boundary?
Gerd
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/Bad-performance-because-of-complex-boundary-r... 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
-- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
participants (4)
-
Gerd Petermann
-
GerdP
-
Thorsten Kukuk
-
WanMil