[DONE] Remove Integers and only use Floats

[eseglem]

I almost put this in as PR, but figured it was worth a discussion first.

Based on RFC 7946 I would like to see NumType removed and replaced with just float in all locations.

A position is an array of numbers. There MUST be two or more
elements. The first two elements are longitude and latitude, or
easting and northing, precisely in that order and using decimal
numbers. Altitude or elevation MAY be included as an optional third
element.

Based on the requirement of being a "decimal number" I would say an int is not valid output. So "coordinates": [0,0] would not be ok but "coordinates": [0.0,0.0] is fine. Using float everywhere would guarantee the decimal place. It would not prevent someone inputting an int or anything along those lines. They would just be converted automatically to a float by pydantic. Which I feel would be more correct.

I would actually propose Position = conlist(float, min_items=2, max_items=3) but the Tuple vs List could be saved for a different discussion.

An alternative option would be to use decimal.Decimal to avoid issues with floats. Or maybe even use condecimal to constrain the total decimal places perhaps in come configurable manner?

[vincentsarago]

if the RFC says float we should only do float!

as for tuple vs list, it's down to was OpenAPI schema support now. For a long time we had to use tuple. Let's talk about this in an other PR/discussion

[eseglem]

It doesn't specify that it must be a "float" but for something to be a "decimal number" I think it needs to have a decimal in it. Meaning "0" is a number, but not a decimal number. But I don't know if "decimal number" is actually well defined.

GeoJSON Position starts by defining it as an "array of numbers". And the JSON RFC defines Numbers as having the fractional part optional. But GeoJSON then goes on to say they must be in a specific order and "decimal numbers" which appears to be an additional requirement on top of "numbers".

Only other thing I have going for my interpretation is that every example in the RFC uses .0 except in a section about Foreign Members. Where it states "semantics do not apply to foreign members and their descendants, regardless of their names and values" and an example has something that looks like a "geometry" but is not.

[eseglem]

I decided the best thing to do was actually email the geojson working group about this. The thread can be found here: https://mailarchive.ietf.org/arch/msg/geojson/B6N2iLvHxsBD-xTdSHp6Mpo0YVs/

I believe the answer is that JSON is a method of transportation, and does not attempt to limit how a consumer represents a number internally. It just wants to convey values. So it is up to an implementation as to how the handle it.

Now, I still find it compelling to use just float in the pydantic representation of it for a few reasons:

• Consistency. Some of the numbers will certainly be floats, and I would rather see all of them be the same type, not a list of mixed types.
• JavaScript, where JSON came from, only uses floats so the use of floats is consistent with that.
• Many other implementations also only use floats under the hood. Though they may print those strings out to JSON in different manners.
• Pydantic doesn't prevent users from inputting other types, it just converts them to the target type. So its not likely to break anything.
• It was already limiting to float and int, ignoring decimal.Decimal another numeric type.

If that is not enough, then would it be acceptable to come up with a more generic implementation allowing for overriding Position with whatever type the end user wants? Because personally I want it to be floats, and would be willing to make that happen.

[geospatial-jeff]

Another argument for using float is its the simplest solution and I think the very large majority of people won't care. I'm not a huge fan of generic types in python especially if they are overused. We are already using generic types for properties (see #29) and I hesitate to add any more.

I'd say go with float.

[sthagen]

On Application Level

It is all numbers, reduces complexity and does not lose precision with the typical coordinate values, right? We think about parsing a 42 as a 42.0 and do not receive end of the universe values like 1234567890123456789012345678910123456789. I like that and of course do like geojson-pydantic ❤️ based on the wonderful pydantic library from Samuel (@samuelcolvin).

On Specification Level

I responded as one of the editors per this mail in the thread started by Erik (@eseglem) on the level of specification. What the host language runtime does stays within the host. All good, and explicit is better than implicit at least some times.

As nicely put by my co-editor Allan (@adoyle), stated here to serve any reader:

I think the key sentence In RFC 7159, section 6 [1] is the one that says:

"A number is represented in base 10 using decimal digits"

Which is meant to make clear that numbers may not be binary, octal, hexadecimal, etc.

RFC 7946 section 1.4 [2] states:

"the terms object, member, name, value, array, number, true, false, and null, are to be
interpreted as defined in [RFC7159].

The use of "decimal number" in RFC 7946 section 3.1.1 [3] is consistent with the meaning "base 10", and is not implying that a >decimal point must be present.

[1] https://www.rfc-editor.org/rfc/rfc7159#section-6
[2] https://www.rfc-editor.org/rfc/rfc7946#section-1.4
[3] https://www.rfc-editor.org/rfc/rfc7946#section-3.1.1

I suggest to keep the language in the RFC as it really helps many to block other than base ten representations over the wire and is in line with the underlying JSON RFC we use.

[vincentsarago]

Thanks everyone 🙏
I've merged #83 and will release 0.5.0 once other PR are merged 🙏