What is the more accepted practice for defining tolerance values?

Question

The Context
Due to restrictions, I have an application that requires line features to be selected if they are within a user defined tolerance from a points data set. I can not currently use any third party API to perform so have written an efficient algorithm that completes this task effectively. The application will be used by people that may or may not have a sufficient grasp on spatial concepts such as the defined unit of measure for their data set, or parameters requiring 'acceptable' values in map units.

My Befuddlement

1. The use of the Tolerance parameter and whether I should keep the tolerance in a commonly known unit such as Centimetres, Meters or Kilometres and perform the required calculations to massage the input into an appropriate value; or
2. Assume the user knows the data, or has the ability to ascertain the data sets map units and enter an intelligent, useful parameter value.
   

The Question:
What is the more accepted practice?

The Implications
If Befuddlement 1 is the accepted practice or considered more user friendly, can you proved the some direction towards ascertaining the Datum and other relevant coordinate information to perform the required function.

If Befuddlement 2 is more generally accepted, then case solved. Though it does make the solution easier and more straight forward, I feel forcing the user to go through a discovery process may lessen the user experience of the software.

Any thoughts on the matter would be greatly appreciated.

Answer 1

If the map units are in any sort of projected coordinate system, taking input in meters, miles, or beard-seconds should be relatively easy. If the map units are geographic, you probably ought to project them for an operation like this anyhow to make your algorithm easier (the problem with geographic coordinates is that north-south degrees are not the same ground length as east-west degrees; to make matters worse, the ratio varies depending on your latitude).

When buffering, ArcGIS takes the input in user-selectable units and converts them on-the-fly to map units. This can make more sense, since it's a lot easier to think of a 5 mile buffer than a 26,400 foot buffer. So, I think #1 is probably better from a UX standpoint.

Answer 2

Just to throw something out there, I think most people would expect to be able to specify the tolerance units independent of the units the data is actually stored in.

You could either a) make the unit selection a dropdown list or b) parse it out from the tolerance text input area.

In the case of b) you would for example have a value of 500 Feet entered and you would parse out the word Feet, make sure it matches a list of supported measurement units, and use that unit for your tolerance calculation, converting it to the dataset's measurement unit if necessary. If no unit is entered then assume it is in the same units as the dataset.

Answer 3

I'd be inclined to bite the bullet and find a way of interrogating the dataset for its units, because it's dangerous to make assumptions about the data especially if it comes from multiple sources, and it is even more dangerous to make assumptions about the competence of the user. Then you can provide, as @blah238 says, a drop-down list of options, with the projection's units as the default.

Can you get the EPSG code or Proj4 definition of the projection? You can use the former to get the latter by parsing the epsg text file that comes with Proj4. The Proj4 +units parameter gives you the linear units of that projection, and even sometimes a +to_meter value. From there it is a simple multiplication.

Edit: If you're just using Shapely, then you might be scuppered because as the manual says:

Shapely does not support coordinate system transformations.

With the implication that it doesn't even bother with projections at all. So you'll need to use the FOSS GDAL/OGR, which is really the defacto geospatial data handling library. It has good Python bindings, and plenty of functions for dealing with projections and units of measure.