3

I have a huge GIS related project with multiple parts which was originally developed for metric usage (meters).

Now I need to make a comprehensive audit of the system to come up with a plan to let it support imperial unit (feet) natively (not just convert at the display end because of accuracy concern).

What is a good way to support multiple units for a system?

Edit:

The application has a Java backend, JS web client, PostgreSQL database and many scripts in python, C++ and Perl)

In our software you can create multiple "projects" and ideally I want to set "metric" or "imperial" while initialising a project so this project will stick to this unit (unlikely to switch after init). This means the software should support two units at the same time. Nonetheless, we actually deploy isolated server for each project(client) so that it's still acceptable to make it a higher level switch that make one deployment supports metric or imperial only.

Edit 2: The values are not just stored and displayed as the application have a lot of calculation using these numbers.

Edit 3: More background info as I did more research. The one I need to support is survey foot(1200⁄3937m) as it is more widely used than international foot (exactly 0.3048m) for mapping.

Survey foot: When the international foot was defined in 1959, a great deal of survey data was already available based on the former definitions, especially in the United States and in India. The small difference between the survey and the international foot would not be detectable on a survey of a small parcel, but becomes significant for mapping, or when the state plane coordinate system (SPCS) is used in the US, because the origin of the system may be hundreds of thousands of feet (hundreds of miles) from the point of interest. Hence the previous definitions continued to be used for surveying in the United States and India for many years, and are denoted survey feet to distinguish them from the international foot.

  • Describe the requirement more precisely, especially the granularity. Do you need the whole system to be switched to "imperial" at once (so one installation for one customer runs in metrics, and a different one with completely different data runs in "feet")? Or do you need this at a level where users can pick their preferred system and just switch on run-time (so the same data needs to be converted on-the-fly)? Or do you need it at the per-attribute level? – Doc Brown Oct 3 at 4:56
  • Thanks Doc, preferably to make it at a level users can pick. I also edited the post to include this info – eth4io Oct 3 at 5:12
  • Do you need to do calculations with the numbers, or are you just storing and reproducing the numbers as they come in? – Bart van Ingen Schenau Oct 3 at 6:25
  • Yes we need to do a lot of calculations with the numbers. – eth4io Oct 3 at 6:35
  • 4
    Accuracy concern? The conversion between metric and imperial is known exactly: 1 inch = 25.4 mm exactly. Do stuff in double precision floats, and your accuracy will be better than anyone could sensibly want (provided you avoid horribly unstable algorithms). I suggest you push back on this idea, because you'd regret it in the long run. – Simon B Oct 3 at 7:33
9

Actually, keeping values in one unit and converting them at some interface would be an easier and most likely less risky solution. I would question and address the accuracy concerns. Are they just gut feelings or well-informed concerns based on hard limitations of your software?

Since the conversion between metric and imperial measurements is well-defined, it is possible to represent imperial values in a metric system with sufficient precision accurately, as an inch is defined as exactly 25.4 mm (see https://en.m.wikipedia.org/wiki/Inch).

Therefore, it should be sufficient to use numeric fields with enough decimal places in the metric representation, and convert from/to imperial values as needed.

  • Thanks Hans for your answer. Sadly it's almost non-negotiable for the project given 1. we need to support some CRS (Coordinate Reference System) in feet. 2. The application requires precise accuracy and it heavily relys on distance calculation, so a tiny difference caused by conversion may bring huge error at the end – eth4io Oct 3 at 6:34
  • "would be the best solution" - I would be way more careful in using the term "best". It is probably "the most-easy-to-implement" solution, but not necessarily a correct solution. Nevertheless, +1 for pointing out the unit conversion can be made lossless. – Doc Brown Oct 3 at 6:58
  • 2
    @eth4io: this answer is telling you the conversion can be made lossless when using decimal numbers and metrics as a unit for the base representation, since the conversion is basically an integer multiplication with the factor 254. If done correctly, there will be no "tiny differences". – Doc Brown Oct 3 at 7:03
  • 3
    "The application requires precise accuracy". No application can provide precise accuracy. Even if you stored everything in Plank lengths (1.6 x10-35 m), you'd still have imprecise measurements being fed in as we can't measure distances of many meters precisely to the exact number of Plank lengths. So what you actually need is precision to the nearest unit of measurement. So what is that for your CRS system? The nearest foot? Inch? Thousandth of an inch? – David Arno Oct 3 at 9:38
  • 2
    It the number that comes out at the end in meters is not accurate then it doesn't matter if you treat it in feet the same way, it will still be wrong. If it is accurate, then converting to feet will still be accurate. Most systems that deal with units have more than two, often user definable, and only store it in one. And it's not necessarily any of them. – Spike Oct 7 at 6:54
4

Since you are asking here, the first step would be to find actual requirements, based on the knowledge of someone who knows what he’s talking about. Take the distinction between intl’ foot and survey foot, for example.

PS Double precision has errors up to one part in 2^53. Earth circumference is 40,000 km, which can be represented with an error of around 5 nanometers.

If tiny errors in locations produce large errors elsewhere then your maths is wrong or your whole approach is wrong, because a tiny distance in your measurements (surely more than 5 manometers) will produce even bigger errors.

3

You already received good answers, I will not repeat the information there.

I am not a mechanical engineer / architect, so I do not need to care much about this personally, but I had to use information about the real world in the past, in the projects I worked for.

I was puzzled one time that a US engineer, working in the US for a US company, provided me the answers in metric units, instead if imperial. I "confronted" him about this, and he told me that while the imperial system is used in the US for many things, they actually use metric for real engineering.

All information combined, do yourself (company) a favor and implement only the engineering system in the core of your application, and only change the displayed information in the interface, as needed.

-5

You should use feet. There are two different feet in the USA, the international foot (0.3048 m) defined in 1959, and the older survey foot (1200/3937 m). They differ by a small amount. Some US states use the international foot, some use the survey foot, and some do not specify which one they use for surveying. The survey foot in India is 0.3047996 m. Over large distances the small differences can become significant if you use the wrong conversion to meters.

  • The numerical differences between these definitions are on the order of 2 parts per million. I would be surprised if the measurement accuracy is better than that. The Wikipedia article on Surveying states: Though tolerances will vary from project to project, in the field and day to day usage beyond a 100th of a foot is often impractical. – Hans-Martin Mosner Oct 7 at 10:28
  • 2
    Your answer is actually a proof of why the imperial system should NOT be used for engineering. – virolino Oct 7 at 11:22
  • Sorry to see many downvotes on this answer but this actually helped with my problem. I just found out in GIS industry they are still using the survey foot (1200/3937m) and this is the place will cause conversion distortion – eth4io Oct 8 at 23:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.