[Geojson] [Technical Errata Reported] RFC7946 (5069)

RFC Errata System <rfc-editor@rfc-editor.org> Fri, 14 July 2017 15:44 UTC

Return-Path: <wwwrun@rfc-editor.org>
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 18D2712F290 for <geojson@ietfa.amsl.com>; Fri, 14 Jul 2017 08:44:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.203
X-Spam-Level:
X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxoNHoUcns5w for <geojson@ietfa.amsl.com>; Fri, 14 Jul 2017 08:44:37 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADCC8129AF6 for <geojson@ietf.org>; Fri, 14 Jul 2017 08:44:37 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id DD8A3B80157; Fri, 14 Jul 2017 08:44:33 -0700 (PDT)
To: howard@hobu.co, martin.daly@cadcorp.com, adoyle@intl-interfaces.com, sean.gillies@gmail.com, stefan@hagen.link, tim.schaub@gmail.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, erik.wilde@dret.net, martin.thomson@gmail.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: carcher@drillinginfo.com, geojson@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20170714154433.DD8A3B80157@rfc-editor.org>
Date: Fri, 14 Jul 2017 08:44:33 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/geojson/pch2wQGsoZTwIvh2hrQmrtqbbo0>
X-Mailman-Approved-At: Fri, 14 Jul 2017 10:35:47 -0700
Subject: [Geojson] [Technical Errata Reported] RFC7946 (5069)
X-BeenThere: geojson@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 14 Jul 2017 15:44:39 -0000

The following errata report has been submitted for RFC7946,
"The GeoJSON Format".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5069

--------------------------------------
Type: Technical
Reported by: Clark Archer <carcher@drillinginfo.com>

Section: 3.1.6

Original Text
-------------
3.1.6.  Polygon

   To specify a constraint specific to Polygons, it is useful to
   introduce the concept of a linear ring:

   o  A linear ring is a closed LineString with four or more positions.

   o  The first and last positions are equivalent, and they MUST contain
      identical values; their representation SHOULD also be identical.

   o  A linear ring is the boundary of a surface or the boundary of a
      hole in a surface.

   o  A linear ring MUST follow the right-hand rule with respect to the
      area it bounds, i.e., exterior rings are counterclockwise, and
      holes are clockwise.

   Note: the [GJ2008] specification did not discuss linear ring winding
   order.  For backwards compatibility, parsers SHOULD NOT reject
   Polygons that do not follow the right-hand rule.

   Though a linear ring is not explicitly represented as a GeoJSON
   geometry type, it leads to a canonical formulation of the Polygon
   geometry type definition as follows:

   o  For type "Polygon", the "coordinates" member MUST be an array of
      linear ring coordinate arrays.

   o  For Polygons with more than one of these rings, the first MUST be
      the exterior ring, and any others MUST be interior rings.  The
      exterior ring bounds the surface, and the interior rings (if
      present) bound holes within the surface.


Corrected Text
--------------
3.1.6.  Polygon

   To specify a constraint specific to Polygons, it is useful to
   introduce the concept of a linear ring:

   o  A linear ring is a closed LineString with four or more positions.

   o  The first and last positions are equivalent, and they MUST contain
      identical values; their representation SHOULD also be identical.

   o  A linear ring is the boundary of a surface or the boundary of a
      hole in a surface.

   o  A linear ring MUST follow the right-hand rule with respect to the
      area it bounds, i.e., exterior rings are clockwise, and holes are
      counterclockwise.

   Note: the [GJ2008] specification did not discuss linear ring winding
   order.  For backwards compatibility, parsers SHOULD NOT reject
   Polygons that do not follow the right-hand rule.

   Though a linear ring is not explicitly represented as a GeoJSON
   geometry type, it leads to a canonical formulation of the Polygon
   geometry type definition as follows:

   o  For type "Polygon", the "coordinates" member MUST be an array of
      linear ring coordinate arrays.

   o  For Polygons with more than one of these rings, the first MUST be
      the exterior ring, and any others MUST be interior rings.  The
      exterior ring bounds the surface, and the interior rings (if
      present) bound holes within the surface.


Notes
-----
This is only for the bullet point describing the right-hand rule for linear rings. It seems like the clockwise/counterclockwise descriptions are the opposite of the right-hand rule. Walking an exterior ring in a counterclockwise direction would have the exterior of the ring to the right of the observer.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC7946 (draft-ietf-geojson-04)
--------------------------------------
Title               : The GeoJSON Format
Publication Date    : August 2016
Author(s)           : H. Butler, M. Daly, A. Doyle, S. Gillies, S. Hagen, T. Schaub
Category            : PROPOSED STANDARD
Source              : Geographic JSON
Area                : Applications and Real-Time
Stream              : IETF
Verifying Party     : IESG