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)
- 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)
- 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)
- 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)
- Yes, my edit, lacking further exposition, probably is opening a can of worms. Reverted. --goldfndr (talk) 06:34, 25 November 2014 (UTC)
Small areas
I not fond of the recently added recommendation to use nodes for objects smaller than 25 m². While it is often acceptable to use nodes for these features, areas still offer strictly more information as long as they are reasonably accurate, e.g. about the shape of the object. This shouldn't be discouraged. People are routinely mapping smaller features as areas, e.g. buildings like sheds or carports, and of course all sorts of indoor mapping and micromapping. --Tordanik 20:05, 12 August 2019 (UTC)