I am working on JIRA ticket TRUNK-5328 (https://issues.openmrs.org/browse/TRUNK-5328), which is currently needing assessment. This task will likely affect many parts of the system, so assessment is important before I continue to move forward. Would anyone be able to move this ticket into “ready for work” after assessing it?
Actually adding the fields is not complex, and doesn’t have particular dependencies.
However I am not familiar with the standard way to store geolocations. Can someone please give some reference or confirmation that this is the correct way to represent things? (I.e. is latitude + longitude + altitude + accuracy the standard set of fields?)
How you chose to store the values really boils down to what you intend to use them for, if you’re just storing them and retrieving them for display purposes and may be do basic computations where precision is not so important you can store them as floats since a precision of 5-6 decimal places would be sufficient, but if you intend to do any computations where it’s important to preserve exact precision then they need to be stored as BigDecimal in java and Decimal in the database, these are recommendations from the java and mysql datatype documentation.
I don’t seem to understand the role of the accuracy field, does it mean we want implementations to define the precision i.e the number of decimal places to store? Or for the person that recorded the value to define the level of accuracy attained when capturing the location.
This page explains how to determine the level of precision for each field in the latitude and longitude values.
When you take a GPS location you also have some sense of how accurate it is (in meters, I think, based on how many GPS satellites you can reach). On your phone you see this as having your location drawn as a larger or smaller circle. (See also https://stackoverflow.com/a/12655119)
So “accuracy” would store that value, not the precision in decimal places.
Currently we have latitude and longitude as varchar(50). While we could try to turn these into more appropriate datatypes, I would suggest we leave these as-is until someone cares to do the real research and work to make any changes there.
Assuming that altitude and accuracy are the other two fields we should be storing, I guess they could both be floats (number of meters).
(But again, I would like someone who actually knows about this domain, and has used geo data to comment before we proceed with anything…)
Here’s my take on the outstanding questions:
- Are Latitude, Longitude, Altitude and Accuracy the only items that need to be stored to accurately store a patient’s location?
- Are there any other GIS variables to consider?
- What data types should each of these fields be in the database and what type of precision should be used? (string vs. float)
- In your experience, is there any need to translate a string of degrees (Lat: 38’53’55N, Long: 77’2’16W)to a decimal (Lat: 38.898556, Long: -77.037852)?
- Are there common ways of grouping each of these fields for export to GIS services?
Craig
timestamp 
I’m not a GIS expert, but I have seen people arguing against use of floating point numbers, saying different languages & databases have different methods of parsing floating point numbers, so values might change based on context. Instead, they suggest approaches like geohash.
If using decimals, I’d assume 5 or 6 digits. Four digits is ~11 meters, which is probably sufficient for most applications, but could be more sensitive to rounding side effects in calculations.
I’d defer to someone with more GIS expertise, but would recommend we follow a standard like ISO-6709.
Just a little googling on the subject makes it clear that we’d benefit from some input from people with real GIS expertise.