# Talk:Node

## data type *float* for longitude/latitude?

Why does the article demand to use *float* as storage type for longitude and latitude? These values do not have a relative accuracy. *Fixed-point* would be a much better choice. And why should we demand a specific data type in the first place? It would be better to just say that we need to store a number between –180 and +180 with an accuracy of at least 7 decimal places after decimal point. Then the coder will choose the right data type depending on the application to be developed and on the programming language being used. This might be *float*, *double*, *Real*, *Number*, or whatever the type is called in that programming language. – What do you think? --Marqqs (talk) 19:04, 27 July 2014 (UTC)

- I don't see it as a
*demand*any more than*integer*is a*demand*for the id. The specification, a range with 7 decimal digits of precision, is right there for anyone to read and interpret. One could argue that a*long signed integer*for the id might be clearer. But to me,*float*is a valid quick description for programmers to grok. On a related note, I have to laugh about how many instances of False precision I've seen (and bug-reported) -- often 15 decimal places, around angstrom precision. --goldfndr (talk) 07:00, 28 July 2014 (UTC)

- Thanks for your reply! So,
*float*and*integer*are considered as mathematical number types rather than data types. Sounds good! Then I would like to change the word*float*to*rational number*, since*float*is not a mathematical number type.*float*is a specific data type in more than one programming language and could therefore lead to misinterpretation – as you can see in my case. :-) --Marqqs (talk) 09:47, 28 July 2014 (UTC)

- Thanks for your reply! So,

- neither is is very good, rational has a distinct mathematical meaning. Technically it is xml so the value is "an alphanumeric text representing a floating point number in the range +-90". Mabye numeric value? I don't think anyone really cares much about this detail. RicoZ (talk) 17:10, 29 July 2014 (UTC)

- Right, it's neither a mathematical nor a programming language thing. We are talking about number representation in XML standard. I found this definition. Maybe this would be right: "XML
*decimal*, scale 7, range –180..180 (including), decimal point, no commas, no parentheses". --Marqqs (talk) 05:46, 1 August 2014 (UTC)

- Right, it's neither a mathematical nor a programming language thing. We are talking about number representation in XML standard. I found this definition. Maybe this would be right: "XML

- Decimal number + range sounds good to me. I would not go into the details of XML number formats as most users won't edit plain XML. Not sure about the precision/scale, I do not know what the implementation is and what is guaranteed to be supported. Some amount of excess precision is often needed when objects are modeled that are vertically stacked or closely adjacent but should not share ways or nodes. Even when objects should logically share ways or nodes they are often placed apart for technical reasons. RicoZ (talk) 10:44, 1 August 2014 (UTC)

Thanks to all of you! I just changed the description. Hope it's ok. --Marqqs (talk) 17:26, 8 August 2014 (UTC)

- I think "integer" is good enough and "decimal integer" sounds a bit odd. RicoZ (talk) 21:21, 8 August 2014 (UTC)

- At first I thought so as well. However,
*integer*means that there are no decimal places and no decimal point whereas*decimal*refers to the radix and emphasises that the digits go from 0 to 9 and not from 0 to F or something like that. So, "decimal integer" sounds a bit strange but it might be correct... --Marqqs (talk) 06:56, 9 August 2014 (UTC)

- At first I thought so as well. However,

- In the other examples "decimal" is used in the sense of "decimal notation" whereas in this case you mean "decimal numeral system". This would substantially increase opportunity for confusion. At this point we would also need to carefully consider whether we are speaking about the XML number representing the data, internal representation of it in some database or whatever is entered at data entry time by some editing software. I think this level of detail is irrelevant for users and programmers need to read the source code anyway. RicoZ (talk) 12:43, 9 August 2014 (UTC)

- Now I am confused also. :-) The internal representation is not relevant, right. We should refer only to the notation. What do you suggest? To just write "decimal number, no decimal places"? Please feel free to edit the page, my English has limits, I'm not a native speaker. --Marqqs (talk) 20:44, 9 August 2014 (UTC)

In terms of storage, the actual internal database stores lat and lon as integers (range −2,147,483,648 to 2,147,483,647), and effectively performs a decimal point shift (effective range about -214 to 214 degrees). I've added the reference to the article. --goldfndr (talk) 06:37, 11 August 2014 (UTC)

## False precision

I think this edit is inviting trouble. False precision does usually little harm. Truncating can do a lot of trouble, it may be safe in some cases but that would need to be described in great detail and I am not sure if it is safe in this case when converting from fixed point to double. Also, if any computation or conversion to decimal is done on the numbers it is usually necessary to use much more precision than what was originally available in order to minimize accumulation of errors. RicoZ (talk) 23:05, 24 November 2014 (UTC)