You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Problem description
In current API specification we specified that maxPplDensity, minPplDensity or pplDensity are defined as number with format Double.
Thanks @bigludo7 for bringing this up. I also aligned with you , for most users, understanding 'people per square kilometer' does not require precision beyond whole numbers, as fractional people are not meaningful in our API context .So yes, better to have integer in this case.
Technically, "double" does not enforce anyone to return exact math result like "1717.986420914645" in the API.
One still can return "1717" or even "1700" if the accuracy is +/- 50ppl/km2 (rounding must also match accuracy).
But, yes, integer would be a better type here.
Problem description
In current API specification we specified that
maxPplDensity
,minPplDensity
orpplDensity
are defined as number with format Double.It means that result could look like:
This is a bit odd to project to have 1717.986420914645 people. 1718 is probably better.
Should we change this 3 attributes 'format' to integer?
Possible evolution
Alternative solution
Additional context
The text was updated successfully, but these errors were encountered: