Comments for Account of my unadventures

Comment on Unscientific GPS note by gpsreviews

gpsreviews — Tue, 08 Dec 2009 09:24:19 +0000

that is a lidar data?

Comment on QPE 4.3.0 plus QEMU by Rencontre Sexe Mobile

Rencontre Sexe Mobile — Tue, 24 Nov 2009 06:27:10 +0000

well.. it’s like I said! f

Comment on Wikipedia overlay by balrog

balrog — Sat, 21 Nov 2009 16:55:42 +0000

Hey,
the page already uses wikipedia:[lang]= as well as wikiepdia=[lang]: tags. The former form is displayed in grey and the latter blue (because I prefer that form).

Please check that it works, if it doesn’t work then I need to fix something :)

Comment on Wikipedia overlay by Link Mauve

Link Mauve — Sat, 21 Nov 2009 01:45:44 +0000

Wow, this map is really great!
But can you use the localized wikipedia tag (wikipedia:fr for the French Wikipedia) if there is no English wikipedia tag? I have mapped many cities that only have localized Wikipedia pages, and it’ll be very useful to show links to them.
Thanks a lot!

Comment on Accelerating in my pocket by Radek

Radek — Wed, 21 Oct 2009 09:06:05 +0000

Hi, have found out solution to wrong colors in qvga. Hope it helps someone:

* 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.

Comment on Accelerating in my pocket by Andy

Andy — Tue, 20 Oct 2009 20:13:31 +0000

Great blog! Thank you for posting about the Openmoko platform. I think it is so exciting! Please check out my blog @ http://www.okmko.com and let me know what you think. Cheers!

Comment on Unscientific GPS note by Allied Antennas

Allied Antennas — Fri, 09 Oct 2009 01:50:49 +0000

Accuracy is the word to describe it. To get accurate data for OSM , you need to do this test many times, record and compare.

Comment on 2: ABI translation by photos of rye

photos of rye — Sat, 26 Sep 2009 15:53:20 +0000

Excellent comment, subscribing to your blog now!,

Comment on Morton numbers by Eric

Eric — Mon, 14 Sep 2009 06:34:55 +0000

Mappage (my webapp) is here:
http://home.exetel.com.au/eric5014/mappage/map.htm

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.

Comment on Morton numbers by balrog

balrog — Sun, 13 Sep 2009 17:38:07 +0000

Hi Eric,
[plug]I can’t help asking if you’ve considered switching over to OpenStreetMap for your web app?

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