-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eddy Petrișor schrieb: > 2009/3/27 Eddy Petrișor <[email protected]>: >> 2009/3/27 <[email protected]>: >>> * Is there a way to use is_in or other hints to make this more >>> accurate? >> how about extending the bounding box to >> >> Xdelta = max (DEFAULT_*_SIZE, max(abs (Cx - Pix) | for every i >> node)) Ydelta = max (DEFAULT_*_SIZE, max(abs (Cy - Piy) | for >> every i node)) >> >> Where: - (Cx, Cy) is the origin of the place and - (Pnx, Pny) is >> the position of n-th node that contains place's name in the is_in >> value*. > > Note that you should consider every node of each way that has > contains place's name in is_in. Considering only the ends of the > way is not correct since for a curved way the nodes in the middle > might be more outwards than the ends.
Indeed I could do that while building the Address-Database. It would never shrink the place if an updated node with a changed location comes in but that should nave little effect. In don`t think it will change much as is_in is practically unused. It would also slow down map-imports even more as for every node and way with an is_in or is_in:city I need to do a name-normalisatio and "where name like" - -lookup in the HSQLDB. Loading all nodes of an incomming way should not slow down things as they get loaded anyway to set their back-references to the ways that use them and nodes are stored in a memory-sensitive cache when being loaded. But still a good idea. It may help in seldom cases Marcus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknNCZMACgkQf1hPnk3Z0cT2pwCgxJrF4nZMWPY11xau14tlBYNu a1sAn2Ec44QosuQ95v61PezKsiQsnH/O =BrWZ -----END PGP SIGNATURE----- _______________________________________________ Routing mailing list [email protected] http://lists.openstreetmap.org/listinfo/routing
