Forum: General Topics

I'm working on a piece of software that will among other things geotag photos -- it's pretty much an OSM only thing, but it could come in vaugly useful to other people.

I have always liked automating tasks -- reduce a complex manual process down to a couple of steps, the ultimate dream is to be able to walk into my house, have the gps tracks sucked off my gps device via bluetooth, auto uploaded to the OSM server (I'm pretty close to the above as it is, it still involves wires though) and plug the camera in, run a single program, and all my photos will be sucked off, and geotaged for me.

This is a way off, but there is one bit that is particularly annoying about geotagging, and that's the clock skew thing.

The current way that most people do is to take a photo of a gps set, then type the time in from that.

It then occurred to me that there is such a thing as barcode reading software, if TMJ had a mode in which it could display the current time in the form of a barcode, It would be possible to completely automate the computer side.

I started a discussion thread at another website on the topic:

http://www.qrme.co.uk/qr-code-forum.html?func=view&catid=2&id=194

I know that this isn't a huge technological leap -- there are phone application that display contact details on a callphone's display in the form of a barcode for another phone's camera to read in the form of a QR code -- the whole idea strikes me as a bit odd -- in the age of bluetooth and wifi, people are pointing cameras at lcd screens, but hey, it works, and is catching on -- most of japan are using this stuff every day -- and all in the land that vhs killed the betamax.

The only technical problem is that to get enough resolution, the image has to be updated once per second, and i've seen plenty of images of gps displays that have occurred part in one second and part in the next, such that both times are displayed over the top of one another, there are 2 ways to overcome this:

1) Tell the user to take 2 photos -- messy, but ok short term fix -- a standard qr code (as discussed on the other site) would work fine for this

2) Display 2 barcodes that change at different times -- the best way to do this is to use different colour channels for each, (again as discussed in the other site)

I would be happy to publish the work on how to read the barcodes -- that is likelly all going to be open source anyway.

Do you think this fits closely enough into the area TMJ is in to warrant work? I've done quite a bit of research and thinking into this, and would be happy to share some of it with you if you are interested.

After a little research, it seems that indeed the licencing will be prohibitive on all the products that I can see available.

Would there be any way to build a simple modular interface such that a gpl tool could be plugged into TMJ, and work, but without breaking the licencing? how much work would this be? Is it even technically posible with j2me?

I've done some maths (below) and and you can store lat and long in a QR code, but you either sacrifice significantly on human readability (if somone decodes it with a generic decoder application) error correction or size -- and all three are reasonably important, I'd put it in as an option, and use the first example given below, it's size 2, but complies with everything else.

I can't work out any situation where storing lat long in a barcode would be usefull

We are dealing with either (size1) 29 pixels or (size2) 34 pixels square (including required white border)


------------ technical code size drivvel below line -----------
The following message:

TS20091230_231159-51.393897+120.453117

could be stored in size 2 with medium error correction -- or in pure numeric format:

9392009123023115951393897620453117
(I took the liberty of using some odd encoding for the positive/negitiveness, the first 3 digits are resered for a UID as you need to be able to idenitfy the diference between a useful barcode and somone elses phone number)

this could be stored in a size 1 medium

a binary representation would also work with 32 bit unix time, 32 bits each of the lat and long, with 2 bytes left over for a UID also at size 1m. Though this is suseptable to the 2038 problem.

to store only lat long to course resolution (no time at all) (2.4 meters -- 24bit per axis) -- size 1 high error correction could be used, leaving one byte left for some kind of UID.

You are right that there is a standard format for a link to google maps in QR codes -- this is very common, what I meant (as you also observe) is that there seems to be little need for this in TMJ.

QR codes can hold a gargantuan amount of data (up to 4296 alpha-nums), but the number of pixels increase dramatically when you start to store more data, and the more pixels, the less the chance of a clean read when passing it to a camera.

The following gives the capacityies of the diferent sizes:
http://www.swetake.com/qr/qr_table0.html

I'm also a proponent of human readbility.

how about:
ts20090826205132

that fits in the smallest size with good error correction.

Mmmm.

I'd still like to be able to store a bit more than just the time, it would at least fit better with TMJs other location-based functions. (I don't really see the point of adding all the extra code if its just going to display a timestamp!)

From that table, version 3L can store 77 characters, which would just about hold the text in my previous post. 100 characters would probably be more ideal though, to store a slightly longer URL and extra digits in the lat/lng/alt. How well do you think this size of qrcode would this copy from a phone screen?

Been looking at the guide at http://www.swetake.com/qr/qr1_en.html. Not sure that I fancy coding all of that!

Incidentally, have you considered an OCR approach - eg if TMJ just displayed a timestamp in its standard 'calculator' font, and somehow automate reading that instead? Probably have to be more accurate in aligning the camera to the phone screen...