W3C home > Mailing lists > Public > public-mw4d@w3.org > February 2011

Re: Question on gps info in cellphone-snapped pictures -- for short article on mobile web

From: Stephane Boyera <boyera@w3.org>
Date: Wed, 09 Feb 2011 08:57:47 +0100
Message-ID: <4D5248FB.6080706@w3.org>
To: CE Whitehead <cewcathar@hotmail.com>
CC: public-mw4d@w3.org
Hi CE,

Thanks for your questions. I'm happy to give it a first shot.

> 1. I am interested in mobiles' picture-snapping capability. Is the .gps
> ever automatically included in the .exif file in the picture? Or does
> the .exif normally include just the time unless you first generate a
> .gps location track and then matched with the time data in the .exif files?

First of all the availability of GPS on phone is very very rare in most 
developing countries, and only in the high-end part of the market.
Then in the smartphone world, i believe that most gps-enabled handset 
are able to geotag photo in exif see for instance: 
Even some non-gps enabled phone are sometimes able to geotag 
approximately the images.

 > 2.  Is having a mobile-ready web page normally include the idea of
 > having a page that does not take much bandwidth to download?  And is the
 > likelihood of getting a 404 not found message in the third world
 > increased because of bandwidth issues?

there are two parts in your questions.
i start with the latest one: you would never get a 404 due to bandwidth 
issue. a 404 is generated and send by a web server, so that that means 
that your request has reach the targeted web server which in does not 
have the right page and tell you so. The lack of bandwidth would give 
you a 'connection timeout' but not a http error code.
The bandwidth issue is at different level too:
- between the user and the internet: ie the pipe of the operator, the 
signal and the handset. the bottleneck can be between the user and the 
data service provider (ie the operator). there are at least three major 
reasons for such a bottleneck: the type of data service (GPRS vs 3G 
etc): in most countries today in e.g. Africa only GPRS is available 
outside urban area, which means a couple of KB of bandwidth only.
Then you might have a great 3G signal, but if your phone is only a 
GPRS-enabled one you wouldn't see any difference.
Finally, even gprs itself has a theoretical bandwidth and an effective 
one, which highly depends on the position of the user vis-a-vis the 
tower. the weaker the signal, the lower the bandwidth.
- between the operator and the requested web site: even if the user has 
a great connection to his provider, then the bottleneck could also be on 
the international bandwidth between the operator and the targeted site.

All in one, it is clear that the bandwidth available to user in 
developing countries is almost always low. It is therefore critical to 
ensure that coding techniques and content development techniques takes 
that constraints into account.
It is also important to note that the bandwidth is not the only reason 
for making the page small. As most data service plan (pre or post paid) 
are based on time or size of content, making small content means a 
cheaper one for the user. There are also device limitation, particularly 
memory limitation that would make some bigger content not 
usable/accessible/displayable on some devices.

The Mobile Web best practices (MWBP http://www.w3.org/TR/mobile-bp/ ) 
has a lot of recommendations concerning small content.
However, most of the MWBP are about why to make small content, and 
where, but not really how. This is more hands-on expertise. For instance 
W3C has online training courses with specific modules on this topic 
(http://www.w3.org/2009/03/mobitrain_course_description.html )
The Web Foundation is running face-to-face training in Africa with also 
modules on this topic (see http://www.mobilewebghana.org/training.html )

Let me know if you have other questions

Stephane Boyera		stephane@w3.org
W3C				+33 (0) 5 61 86 13 08
BP 93				fax: +33 (0) 4 92 38 78 22
F-06902 Sophia Antipolis Cedex,		
Received on Wednesday, 9 February 2011 07:57:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:07:11 UTC