* Install fbset program

* Create /etc/fb.modes

mode “vga”
geometry 480 640 480 1280 16
timings 40816 8 16 2 16 8 2
rgba 5/11,6/5,5/0,0/0
endmode

mode “qvga”
geometry 480 640 480 1280 16
timings 100000 8 16 2 16 8 2
rgba 5/11,6/5,5/0,0/0
endmode

Calling “fbset qvga” and “echo qvga-normal > /sys/bus/spi/devices/spi2.0/state”
is needed for mplayer in 320×240 with correct colors.

The features I described are not yet on the live version though.

OSM looks OK, and I’m generally a fan of free/open stuff. Adelaide is mostly covered now, and I suspect an old friend of mine has mapped most of the northern suburbs. GM was the best option when I started Mappage: for things like geocoding and translucent polygon overlay there was nothing else. Later it might be possible to decouple from GM so it can sit on something else, but unlikely.

My solution to getting the rectangular range was much like what you suggested.

Scale-wise I kept the scale the same in both directions, keeping the 16th bit clear so I could do comparisons without worrying about sign. Accuracy isn’t important as it’s only for rough sorting, and being in Australia the graticules are close to square.

Re looking up sites inside a rectangular region, I pondered the same issue and my solution (although not implemented yet) is for every pair of opposite corners to be converted to four (or fewer) integer ranges mapping to one, two or four db queries, depending on where exactly the two corners fall in that “grid”. Complexity wise making it four lookups instead of one makes no difference. So if the corners were at, say (-1,-1), (3, 3), then you’d split it up into four square lookups:

(-1, -1)-(0, 0),
(-4, 0)-(0, 4),
(0, -4)-(4, 0),
(0, 0)-(4,4),

each power-of-two-sized, then, in my case, I will just have the server return all results that matched and have the javascript filter out unwanted results. Assuming the original query is usually for objects visible on the screen, the query will almost always have a screen like width:height ratio, so nearly square, and if it’s square, the area returned from the four queries will never sum up to more than twice the original area.

Note that you can do (lat+90)*360 in the conversion to integers to get a better resolution, unless you have other use for that 16th bit there. Cheers

I used (lon+180)*180 and (lat+90)*180 to get 16 & 15 bit integers. I’m using JavaScript and PHP/MySQL.

So I would use this number to filter which sites I load from my DB. I get the two opposite corners, convert both to the integer to see what range I need. A small window will always give you a small integer range unless your window happens to cross a major division.

Alas, that’s exactly what happened! Adelaide (my city) is 138.6E.
(138.6 + 180) * 180 = 0xE004. So the 7/8 of the way around the world longitude line ran right through the area I was looking at! This rendered the filter useless, and I’ve since refined it to get around such problems, but it was just funny that I chose an easy trick with a scaling system that would work almost anywhere but here!

btw Morton number in SQL: conv(bin(n1),4,10) + 2*conv(bin(n2),4,10)

So you don’t need to switch to fixed-point to get “two positions that are close to each other in an array sorted by this number probably are close to each other on the map”; it works with even when mixing floats. Looking at the high bits to “locate something with a desired accuracy” does have a pretty warped scale, though, and the arithmetic tricks here won’t work either.

Strace’ing the python program, I saw it use a particular syscall and wanted to know where that was happening in the python code. I don’t think pdb would let you set a breakpoint at a random memory address given by strace? That’s where gdb comes helpful.