Datatype property restriction to float is causing loss of significant digits on lat/lon measurements

[obi-bot]

The range restriction on 'has measurement value' is currently float. This causes us to lose significant digits on lat/lon represented as decimal degrees (as opposed to dd mm ss).

Some options:

1. Just change it to double
2. Remove the restriction altogether. Then one could define subproperties: 'has integer measurement value', 'has float measurement value', 'has double measurement value', etc. based on need, each with the appropriate range restriction. Then all these things would still satisfy the definition of value specification.

Reported by: hoganwr

Original Ticket: obi/obi-terms/772

[obi-bot]

If we change, maybe it should be to decimal - http://www.w3.org/TR/xmlschema-2/#decimal - That offers, minimally, 18 digits of precision. However could you say a bit more about what is happening? You specify lat/long with more than 6 significant digits?

Original comment by: alanruttenberg

[obi-bot]

http://www.w3.org/TR/xmlschema-2/#decimal

Original comment by: alanruttenberg

[obi-bot]

The behavior I am seeing in Protege is that a longitude of -92.086231 gets truncated to -92.08623. Similarly, other values are getting truncated to 5 digits to right of decimal point.

the data are not generated by us. it is a synthetic population created by RTI for agent-based epidemic simulators. so it's just the precision given to us by our source data.

but i would think there are plenty of applications that would want to limit to integers in some cases, would need double precision in others, etc.

Original comment by: hoganwr

[obi-bot]

See http://gis.stackexchange.com/questions/8650/how-to-measure-the-accuracy-of-latitude-and-longitude

It looks to me that your simulator folks are using more digits than make sense for the application. It looks to me that only 3 decimal places make sense for their application. Solving the issue you raise is complicated. Having different properties for different data types is a disaster for integration, particularly where there's no hard and fast rule about when they should be used.

I would support changing the value to double, since that's a change that compatible with what we have now. You are also free to add new properties - note that has-measurement-value was created for scalar values. Lat/Long is vector. It would be justified to extend IAO to have non-scalar measurement values, I think.

In the spirit of laziness, we should only go here if its absolutely necessary (since it will be work). If I'm right about how many digits of precision are needed I think taking that tact would be the easiest route.

Original comment by: alanruttenberg

[obi-bot]

• assigned_to: jzheng

Original comment by: zhengj2007

[obi-bot]

Modified IAO, changed 'has measurement value' range from float to double

Original comment by: zhengj2007

[obi-bot]

• status: open --> closed

Original comment by: zhengj2007