[OSM-talk] Server slowness

[Nick Hill]

Hello Ivan

I have experimented with a test scenario using a spatial index and had a very 
long debate over this around 17th September 2006 on dev.

The point type takes a bounding box of 4 x 64 bit floats. The index therefore 
tends to be very large, the stored data very large, and has a big hit on I/O. 
The performance was disappointing.

I then had a discussion about a scheduling system and tile invalidation 
tecniques with example code. A conclusion was that a 64 bit index on a 64 bit 
field consisting of a compound lat/lon (ie a tile) would provide both good 
performance using a b-tree and adequate accuracy (+/-5.5mm or better).

I suppose an even better solution would be to devise a spacial indexing scheme 
for MySQL or postgress using b-tree based on the discussion. I don't think it 
would be ultra-complex and would be composed of interleaved integers.


Iván Sánchez Ortega wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> El Domingo 14 de Enero de 2007 04:56, Nick Hill escribió:
>> This could cause a substantial hit for queries hitting Europe. Our database
>> currently narrows the index down on either lat or lon, not both.
> 
> Why doesn't OSM use MySQL's spatial extensions, then? If the 'latitude' 
> and 'altitude' columns are merged into a single column of type 'Point', you 
> can narrow the search by both lat and long, defining a bounding rectangle.
> 
> - -- 
> - ----------------------------------
> Iván Sánchez Ortega <ivansanchez at escomposlinux.org>
> 
> Now listening to: Hooverphonic - No More Sweet Music (disc 2) (2005) - [8] 
> Heartbeat (remixed by Alex Callier) (3:52) (99%)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> 
> iD8DBQFFqkNpR56dWuhgxGgRAn1LAKCRTl82jf08agJiZVrZC9BjP3BX9QCgps3Z
> c5IyzBpGQi9VP4WZ5j9WsKc=
> =PGWh
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> talk mailing list
> talk at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk