Re: [Geojson] Position Clarification

[Stefan Hagen <[e-mail]>]

On3. August 2022 at 03:41:43 +02:00, Erik Seglem <<[e-mail]>> wrote/cited:

> Thanks for the response. I know it's probably digging way too far into it, and probably doesn't matter all that much. Just trying to be precise.
> 
> RFC 7159 uses the phrase "decimal digits" while defining a number. And RFC 7946 uses a different phrase "decimal numbers." It uses the word "number" which has been defined and adds what seems to be a modifier "decimal" to it.
> 
> If a Position is just an array of numbers why would additional qualifications be added to the definition? If the intent was to say "base 10" that was already accomplished in the definition of an array of numbers. However it states "The first two elements are ...precisely in that order and using decimal numbers." This reads as if it is adding an additional requirement to be "decimal numbers". And it's not just me reading it this way.
> 
> Looking at some other geo related RFCs they do have it as optional. So it is definitely not far-fetched to believe it can be ignored. But all of the examples in RFC 7946 have chosen not to ignore the `.0` for some reason. That could just be personal preference or something more meaningful. It just makes me wonder when taken in conjunction with the above.
> 
> RFC 5870 (Geo URI) section 3 [1] defines num, latitude, and longitude as optional decimal and additional digits.
> RFC 5491 (GEOPRIV) section 5 [2] says they are expressed using the lexical representation for "double" [3] which has more options but is also still optional.
> 
> [1] <https://www.rfc-editor.org/rfc/rfc5870#section-3.3>
> 
> [2] <https://www.rfc-editor.org/rfc/rfc5491#section-5>
> [3] <https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#double>
> 
> Thanks,
> Erik
> 
> 
> 
> On Tue, Aug 2, 2022 at 7:36 PM Allan Doyle <<[e-mail]>> wrote:
> 
> > Hi Erik,
> > 
> > 
> > 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 hope this helps.
> > 
> > 
> > Allan
> > 
> > 
> > > On Aug 2, 2022, at 5:26 PM, Erik Seglem <<[e-mail]>> wrote:
> > >
> > > I was looking over the spec and came across a bit that seems open to some level of interpretation. In 3.1.1 it says "A position is an array of numbers." And then goes on to specify the order and "using decimal numbers."
> > >
> > > The JSON RFC says the fractional part of a "number" is optional. But, to me, stating they are "decimal numbers" is an additional requirement on top of a "number".
> > >
> > > This seems to be backed up by the examples all having decimals in them, but doesn't seem to be consistent across implementations across the community. Some appear to allow integers, and some stick with floats.
> > >
> > > In looking around for answers a Stack Exchange question came up with the same question as mine: <https://gis.stackexchange.com/questions/429184/are-positions-without-decimals-valid-geojson> but no definitive answer either. I figured the best thing to do would be ask this group.
> > >
> > > I guess it comes down to is this a valid GeoJSON Point?
> > > {
> > > "type": "Point",
> > > "coordinates": [100, 0]
> > > }
> > >
> > > If in fact they do require a decimal place. Does that also apply to the elevation or just the long / lat? It seems to only say the first two elements must be decimal numbers, and the third is optional without that clarification.
> > >
> > > Would this be valid?
> > > {
> > > "type": "Point",
> > > "coordinates": [100.0, 0.0, 124]
> > > }
> > >
> > > And what about bounding boxes? The spec says it's an array and specifies the length, but not the type of the values.
> > >
> > > Would this be valid?
> > > {
> > > "type": "Feature",
> > > "bbox": [-10, -10, 10, 10],
> > > "geometry": {
> > > "type": "Polygon",
> > > "coordinates": [
> > > [
> > > [-10.0, -10.0],
> > > [10.0, -10.0],
> > > [10.0, 10.0],
> > > [-10.0, -10.0]
> > > ]
> > > ]
> > > }
> > > //...
> > > }
> > >
> > > Thanks,
> > > Erik
> > > _______________________________________________
> > 
> > 
> > 
> > 
I like the scope for numbers in JSON as stated in the introduction of ISO/IEC-21778:217(en):

"JSON is agnostic about the semantics of numbers. In any programming language, there can
be a variety of number types of various capacities and complements, fixed or floating, binary
or decimal. That can make interchange between different programming languages difficult.
JSON instead offers only the representation of numbers that humans use: a sequence of digits.
All programming languages know how to make sense of digit sequences even if they disagree
on internal representations. That is enough to allow interchange." (and ECMA-404 of course)


JSON is a static representation part. The use case of GeoJSON is dynamic and focusing on
exchange, i.e. producing, transporting, and consuming the data through an intermediary host
processor. For example: the number 42 (as written here) is a completely valid member of the set
of the mathematical real numbers. Wun consumer may end up with an integer value in her
language, another may continue using 42.0 or even 42.000000000001. Who knows ...

JSON never even (hard-)limited the number of digits nor did the underlying cause for the
existence of JSON (the host language javascript) ever care about integers - in there, all such
numbers are stored as IEEE 754 floats.

In my experience, guaranteeing roundtrips preserving "nothingness" - like floats with a fractional
part of zero - is not possible without interpreting every number as a string on the processing side
(producer and consumer alike).

Also, specification prose is hard, esp. when sandwiched between a schema (explicit or not) and
code examples. How does one know, if a prose not stating "Decimal Numerals" but instead
"Decimal Numbers" really meant the former - or, like Alan wrote, instead the decimal base used
in representing? As an editor I would love to either convey some information in prose or use an

underlying computer constraint language, but often have to do both and risk inconsistency and misunderstanding.
I am sure we could have used ASN.1 to solve all ambiguities, but instead chose the pragmatic JSON
as vocabulary to formulate what the community (long before I joined) had found to be an optimal
format to exchange geographical feature data. Not ideal for everyone, but optimal.

All the best,
Stefan