Re: [Geojson] Position Clarification
Sean Gillies <sean.gillies@gmail.com> Wed, 03 August 2022 17:37 UTC
Return-Path: <sean.gillies@gmail.com>
X-Original-To: geojson@ietfa.amsl.com
Delivered-To: geojson@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 943FDC14F730 for <geojson@ietfa.amsl.com>; Wed, 3 Aug 2022 10:37:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xtb0OJEobyaK for <geojson@ietfa.amsl.com>; Wed, 3 Aug 2022 10:37:00 -0700 (PDT)
Received: from mail-yw1-x1136.google.com (mail-yw1-x1136.google.com [IPv6:2607:f8b0:4864:20::1136]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D5E5C14F74A for <geojson@ietf.org>; Wed, 3 Aug 2022 10:37:00 -0700 (PDT)
Received: by mail-yw1-x1136.google.com with SMTP id 00721157ae682-3246910dac3so126669077b3.12 for <geojson@ietf.org>; Wed, 03 Aug 2022 10:37:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=aC3ppG8j00sakv8oj7lvgGXw61L5GvpYcTA3YOK8sDo=; b=As536CYyVx61cNerkv3DX4NPBkHOMZFOzZWf2mgiujyQ4XPz1qbPeVR5RWvRf8nHp6 4mTbho/Skxs1tYA7n6dAKXe6IDbbpnliM5nNFUIdKzPo8htcOFpZPD2dY6l/WSGUvqmy Kd05+3ZbPS5JPg7uuNshWp8L8YjSl2WNCcwaX+NDKBF21396BHYRAY8oKNzcah2pBPwW viamH2HbDmWx/oqK20HgAKNXF1oV/LTIJQcr6mJlbD3bF7BMLLl6U5ynq1aebYZaTg8B 1EznqUlKdZr5GZ8pER/2as7JrdXvlm0OxrO1mEDRKiKYGzFk9626QamrHqqVVfazqPPc CIXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=aC3ppG8j00sakv8oj7lvgGXw61L5GvpYcTA3YOK8sDo=; b=4UY8+gUVa3XUJshzLQ5cN0a55Q5vU4uvyrCgq94O0RXb2Ol73sQEPXE8xtgie6t06p o7LwkfW4J6uv6iJvDlN0dtS52rsaCchop0Vd7pIoUQXjfoLDW1fnBgsVc9fxH+fKbj5m nVIQvdCLGRHmHP1phbEwPcFTIoazFalRY/6LbgpK04mWndhSXFSpAgwDmmkFNf9IiIqE LWduJyI4JPl/TrYh+9frz/dDHTsDhFFgnV93fPjBdUxBIgxoMG0JV9SQMKZs8TxZ01AG ViFQ3VwTSR0fRHUYFGEPnrv+9g04sZ2LpfAYvay1Fef53Y2e0Q/vmmSQkNELPLG2R8kI OhXw==
X-Gm-Message-State: ACgBeo0yohxEYQs2Dk6yDcK5j3dDg1xlrt2786vrAOHz7DZv1c8ppgtu htlayc9ttc+u0+D1gSeBWheyj45/Z3eQ6iT2IfHqsphzIWY=
X-Google-Smtp-Source: AA6agR4LOBWkPPbb1J6ALIrSd7ap7lKY6SPpH1HLW6S4pdHNjqZEglgtl+PvG6mcVfUzwgW+vxmTgDssvohPlRw0PIg=
X-Received: by 2002:a0d:ebc8:0:b0:31f:4f08:63aa with SMTP id u191-20020a0debc8000000b0031f4f0863aamr23916532ywe.145.1659548218965; Wed, 03 Aug 2022 10:36:58 -0700 (PDT)
MIME-Version: 1.0
References: <CAPrYNak4-9QqecJpG19t39mCkq_0sxYBuWAvaTkb7epTJi_LCg@mail.gmail.com> <CAPrYNa=MtPzJGG9j-asR4iFrisWxzLLKcAmER7cdTg8g_zOH2A@mail.gmail.com> <12EFB7A1-49C7-4065-856C-EDEAF75A264E@intl-interfaces.com> <CAPrYNa=dEQCckZ=AkAgtjjDceW9B_rXA-p6zxw8JEOay6Vt3dw@mail.gmail.com> <1659502903368.6.100116@webmail-backend-production-65bcc99cff-2p92w> <CAPrYNa=eEXqGPU0c9+Qfz9F5gMnrDyRo21ZmgFeEue6eXgjkeA@mail.gmail.com>
In-Reply-To: <CAPrYNa=eEXqGPU0c9+Qfz9F5gMnrDyRo21ZmgFeEue6eXgjkeA@mail.gmail.com>
From: Sean Gillies <sean.gillies@gmail.com>
Date: Wed, 03 Aug 2022 13:36:47 -0400
Message-ID: <CAOodmJrHfGvZqHbgUyiUnfPaJfX-a44fspf1AaJ7gqJgNMe=-Q@mail.gmail.com>
To: geojson@ietf.org
Cc: Erik Seglem <erik.seglem@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000001444d605e559ae84"
Archived-At: <https://mailarchive.ietf.org/arch/msg/geojson/inSlDXKGPFyNe9tw61g3o40dK7s>
Subject: Re: [Geojson] Position Clarification
X-BeenThere: geojson@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF GeoJSON WG <geojson.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/geojson>, <mailto:geojson-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/geojson/>
List-Post: <mailto:geojson@ietf.org>
List-Help: <mailto:geojson-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/geojson>, <mailto:geojson-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Aug 2022 17:37:04 -0000
Hi Erik, If I remember correctly, "decimal" was an attempt to make it clear that longitudes and latitudes are not to be expressed using degrees, minutes, and seconds. "Decimal" appears 5 times in the RFC, twice as "decimal degree", twice as "decimal place", and once as "decimal number". I don't think we will publish a new RFC to correct this, but adding errata that said something like "and using decimal degrees, not degrees, minutes, and seconds" (thus eliminating the third case) would be welcome. Yours, On Wed, Aug 3, 2022 at 9:54 AM Erik Seglem <erik.seglem@gmail.com> wrote: > Thank you for another great response. I definitely agree that > specification prose is hard, and I am extremely grateful to everyone who > has worked on this and other specs like it. > > Perhaps I was missing the forest for the trees on this one. I was digging > farther into it than really necessary. > > I just wanted to be sure about the intent of the authors in using the > phrase. I was unable to find an authoritative definition of a "decimal > number," as it has been used to mean different things. Some, like me, > interpret "decimal number" to mean a number with a decimal in it but others > interpret it as a number using base 10 digits. > > It may be asking too much, but would it make sense to remove the phrase > "and using decimal numbers" with an errata? If an "array of numbers" > already defines what the values need to be, then the phrase is not adding > value to the statement. And to some limited subset of readers it has > introduced a level of ambiguity to the meaning. Removing it would eliminate > the potential confusion entirely. > > Thank you again for the responses, > Erik > > On Wed, Aug 3, 2022 at 1:01 AM Stefan Hagen <stefan@dilettant.eu> wrote: > >> On3. August 2022 at 03:41:43 +02:00, Erik Seglem <erik.seglem@gmail.com> >> 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 <adoyle@intl-interfaces.com> >> 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 <erik.seglem@gmail.com> 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 >> > > -- Sean Gillies
- [Geojson] Position Clarification Erik Seglem
- Re: [Geojson] Position Clarification Allan Doyle
- Re: [Geojson] Position Clarification Erik Seglem
- Re: [Geojson] Position Clarification Stefan Hagen
- Re: [Geojson] Position Clarification Erik Seglem
- Re: [Geojson] Position Clarification Sean Gillies