Standard for entering latitude/longitude in text fields

Question

Is there a standard for users to enter latitude and longitude into two text fields?

Decimal degrees is probably easiest, as it can be entered in one single fell swoop. The standard for geocaching (not related to our application but still frequently used) is full degrees and decimal minutes. And perhaps some users might want to enter degrees-minutes-seconds.

Is there a standard way to parse text? (e.g., "45d 15m 20.91s")

Additionally, our application is primarily used in North America, where latitude is considered positive (north of the equator) and longitude is considered negative (west of Greenwich). Should I display units of degrees-north and degrees-east, or just degrees (and assume that a user knows the convention for north-south and east-west)?

Another potential "feature" is to detect the range of continental US lat/long and "autocorrect" users. Of course that only works until we get users in Southeast Asia who will wonder why their assets appear to be in the States.

Answer 1

I would go with decimal and here are 2 examples.

1) If you set your location to exact on twitter using an application twitter will output your lat/long in decimal format (iPhone: 33.948615,-118.401382)

2) When sharing a location on Google Maps the link is encoded with the lat/long in decimal format http://maps.google.ca/maps?ll=43.367559,-80.980482&spn=0.01106,0.01869&t=m&z=16&iwloc=A&lci=com.panoramio.all

I am sure there are more than just these two major players that are using decimal format for lat/long formatting.

So if your user doesn't know their lat/long and they go searching for it there is a good chance they will get it in decimal format.

Answer 2

Going for decimal is an "Easy Out" for us programmers but doesn't always satisfy the user. There is a standard for Latitude and Longitude formats - ISO 6709 - and it defines formats for Human Interface.

Here is an extract [from Wikipedia] on the ISO 6709 format:

• Coordinate values (latitude, longitude, and altitude) should be delimited by spaces.
• The decimal point is a part of the value, thus must usually be configured by the operating system.
• Multiple points should be represented by multiple lines.
• Latitude and longitude should be displayed by sexagesimal fractions (i.e. minutes and seconds).
• When minutes and seconds are less than ten, leading zeroes should be shown.
• Degree, minutes and seconds should be followed by the symbols ° (U+00B0), ' (U+0027), and " (U+0022), without spaces between the number and symbol.
• North and south latitudes should be indicated by N and S following immediately after the digits.
• East and west longitudes should be indicated by E and W following immediately after the digits.

Assumptions are dangerous. To say that user will "most likely" get lat/longs from xxxx, is a VERY BAD assumption. Look at the Lat/Long display/entry options on GPS devices. Most support the following formats:

• DD.DDDDDD
• DD MM.MMMM
• DD MM SS.SS

IOS/OS X provide very powerful converter classes which can be easily customised to handle the above Lat/Long formats:

NSScanner - to convert user input (NSString) to degrees (double)

NSFormatter - to convert from degrees (double) to string.

Answer 3

Having worked on a variety of web and app mapping UI, I would recommend using decimal degrees for the input. It's increasingly rare for sources to provide alternative formats. You may consider, however, if space and circumstances permit, offering an option of changing to another format. (Perhaps the user could even be allowed to set this as a default).

I would recommend using an input mask inside the fields, e.g. 00.000000. This will further clue the user into the default format. (Incidentally, six decimal places is more than enough to ensure meter-level accuracy).

On the subject of positive or negative units to denote east/west or north/south, it isn't easy to make a recommendation. To a degree (ouch), it depends on users' knowledge in this area. They may be aware that negative numbers denote west or south. Additionally complicating the issue is that numbers copied from a source, e.g. Google Maps, will be in that format, e.g. "44.463005, -110.366479"

One possibility is to have user-changeable E/W and N/S UI. If the user enters a negative value in the longitude field, for example, this UI could automatically change to "W". If the user entered a positive value they could still change it to "W" manually, e.g done automatically:

(If the user selected "E" instead, then it would make sense to correct the value by removing the negative sign).

Alternately, you could enforce the informational-only aspect of the directional indicators:

This will indicate to and train the user how lat/lon values work. And, if that doesn't do it, seeing a map with the wrong area displayed may!

And if you really want to get fancy schmancy:

Answer 4

I've not seen One Way to Rule Them All when it comes to entering lat/long, and in the more popular and general use geo-related sites and web apps I've seen more often than not offer both HDDD MM.MM and decimal options for users.

If yours is a general use app, this would be a prime opportunity to spend some time coming up with personas, with specific emphasis on which notation they're more likely to know/have at their disposal when using your app. I would also say that whatever decision(s) you make, get some wireframes in front of potential users for A/B testing sooner rather than later, because if you do find that you need to accommodate both options, you'll want that info as early as possible so as not to try to shove it into the design at the end.

Also, unless this is a really clearly targeted app and you're very confident about the knowledge of the users, I'd caution against making any assumptions about what the users do or do not know regarding notation. Let the focus groups and testing provide you with good data, which may or may not prove the hypothesis you began with.