logo separator

[mkgmap-dev] [Patch v5] LocationHook with new Quadtree

From Gerd Petermann gpetermann_muenchen at hotmail.com on Thu Jan 19 17:02:41 GMT 2012


Hi WanMil,

I have coded a first version of the preparer with quadtree. It works so far, the bnd files are not 
much bigger and the format is still the old one (boundaryLister can read them), the creation is a 
little bit faster compared to trunk.

I think I understand now your question regarding the merging the tags.
In the trunk implementation we save all kinds of tags for the boundary, although only a few are 
needed by LocationHook. Now, when BoundaryQuadTree.Node.merge() has executed, I have 
some areas that are intersections of two or more boundaries. It is clear that we have to save the 
location relevant tags, but what about the other? Can we simply ignore them? I guess no, because 
we loose information like name:en, name:fr if they exist.

Any ideas?

Ciao,
Gerd




> Date: Wed, 18 Jan 2012 22:43:46 +0100
> From: wmgcnfg at web.de
> To: mkgmap-dev at lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] [Patch v5] LocationHook with new Quadtree
> 
> I have done a few checks and the results were all as expected.
> 
> Regarding the changes to the BoundaryPreparer:
> Do you plan to pimp the bnd File format?
> Merging the polygons of the different bounds is quite easy. But how do 
> you plan to merge the tags? Do you plan to use a Tag object for each 
> admin_level or do you use special tag prefixes (e.g. 
> mkgmap:admin_level2:name) to mark the different boundary levels?
> 
> I would aggree to use more than one Tag object for each merged Boundary 
> (which also means that the bnd format must be changed slightly).
> 
> WanMil
> 
> > Hi WanMil,
> >
> > I have no special reason for using the nano second timer. I tried it because
> > I noticed that the mili second timer is very inaccurate. I got the
> > impression that nano seconds are more precise, but of course the only usable
> > value is a mean value of long running tasks.
> >
> > ciao,
> > Gerd
> >
> >
> > WanMil wrote
> >>
> >> Hi Gerd,
> >>
> >> thanks for your further patch.
> >> I have a question about it: I see that you measure timings with nano
> >> second timer. I am quite sure that such accuracy is not given in such
> >> time measurements and often lead to wrong results. Do you really require
> >> that accuracy? In such a case I am sure that you can stop coding because
> >> there would be nothing more to improve so that the total runtime
> >> decreases. It would be just a matter of fortune.
> >>
> >> I think the only reasonable indicator is to measure the sum of the
> >> overall LocationHook timing for several tiles (>20). If that decreases
> >> significantly there is an improvement.
> >>
> >> WanMil
> >>
> >>
> >>
> >>> Hi WanMil,
> >>>
> >>> attached is the new version of the patch, now based on r2171.
> >>> I've invested a lot of time testing the result of LocationHook, I think
> >>> it
> >>> is always as good or better than trunk.
> >>> I will now try to add the quadtree to the preparer.
> >>>
> >>> Changes:
> >>> - build.xml with includeantruntime="false" to calm down ant
> >>> - added a few debugging aids and printout of complete runtime
> >>> - performance improvements in add() and merge() methods
> >>> - if a search in the nodes of the quadtree doesn't find the area,
> >>> additional
> >>> searches are performed for points
> >>>     in the neighbourhood
> >>> - for ways, the mid point is searched first. If the search returns null,
> >>> all
> >>> points are searched from the first one until a result is found. With my
> >>> test
> >>> data, quadtree never returned null, so this last loop is probably only
> >>> needed when boundary data is very incomplete.
> >>>
> >>> http://gis.638310.n2.nabble.com/file/n7199763/locationHook_speedup_v5.patch
> >>> locationHook_speedup_v5.patch
> >>>
> >>> ciao,
> >>> Gerd
> >>>
> >>> --
> >>> View this message in context:
> >>> http://gis.638310.n2.nabble.com/Patch-v5-LocationHook-with-new-Quadtree-tp7199763p7199763.html
> >>> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> >>> _______________________________________________
> >>> mkgmap-dev mailing list
> >>> mkgmap-dev at .org
> >>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> >>
> >> _______________________________________________
> >> mkgmap-dev mailing list
> >> mkgmap-dev at .org
> >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> >>
> >
> >
> > --
> > View this message in context: http://gis.638310.n2.nabble.com/Patch-v5-LocationHook-with-new-Quadtree-tp7199763p7201442.html
> > Sent from the Mkgmap Development mailing list archive at Nabble.com.
> > _______________________________________________
> > mkgmap-dev mailing list
> > mkgmap-dev at lists.mkgmap.org.uk
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> 
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20120119/461245fc/attachment.html 


More information about the mkgmap-dev mailing list