Subject: Re: [Geojson] Call for adoption draft-butler-geojson

From: Sean Gillies <[email-masked]>
Date: Tue, 3 Nov 2015 08:39:59 -0700

Martin,

In fact, there's one last change I'd like to make before we adopt. Erik concurs.

  https://github.com/geojson/draft-geojson/pull/108

I've alerted the WG in a separate email yesterday and received only
favorable responses.

Shall I upload a draft-butler-geojson-07?

On Tue, Oct 27, 2015 at 4:07 PM, Sean Gillies <[email-masked]> wrote:
> Yes for adoption.

-- 
Sean Gillies

---

From: Martin Thomson <[email-masked]>
Date: Wed, 4 Nov 2015 10:38:30 +0900

>   https://github.com/geojson/draft-geojson/pull/108

I think that this change is fine.

We can take that in a -00 draft unless it's clear that we don't have
consensus for the change (early feedback looks positive).

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 10 Nov 2015 13:51:37 +0100

Le 28/10/2015 23:08, Sean Gillies a écrit :
> Hi Alex,
>
> On Wed, Oct 28, 2015 at 6:01 AM, Alexandre Petrescu
> <[email-masked]> wrote:
>> Hi,
>>
>> I do not object to adoption, but I continue pondering over the
>> following.
>>
>> The draft says in its abstract:
>>>
>>> This document recommends a single coordinate reference system
>>> based on WGS 84.  Other coordinate reference systems are not
>>> recommended.
>>
>>
>> I still think this looks reductive, because tehre are many more
>> such systems out there, not just WGS 84.  For example, a recent
>> consumer Internet-connected product mentions WGS84, UTM, MGRS, BNG,
>> ETRS-TM35FIN, KKJ, IG, RT90, CH1903, NAD27, NAD83.
>>
>> Conversion has some times some inconvenients, that's why these
>> systems exist.
>>
>> Why the exclusivity of WGS 84?
>>
>> Alex
>
> We wanted to standardize on a single global reference system and
> couldn't think of a reason why that single system shouldn't be
> WGS84. WGS84 isn't perfect, but is very widely used, and it seems
> like a location standard benefits from a single reference system just
> as much as date and time on the internet (RFC 3339) benefits from a
> single calendar system (Gregorian).

That's an interesting point that date and time on the Internet use a
single calendar system, the Gregorian.  I didnt know that.

Some time-related IETF protocols may have introduced software bug risks.
  Causes include factors such as the beginning of time to be the Epoch
(year 1970, later than Gregory), or the bitfield length encoding time
too short to accommodate year 2031.  Today other concepts like the leap
seconds, or even the time zones, are subject to change - they may simply
disappear; when they're hardcoded in RFC, they may lead to software bug
risks as well.

Similar conversion or extensibility risks may or may not materialize if
standardizing on a single geo- reference system.

Alex

> That's all. Nothing is implied about the fitness of MGRS or BNG in
> their domains.
>
> I'm happy that adoption has your support and happy to have your
> participation!
>

---

From: Carl Reed <[email-masked]>
Date: Tue, 10 Nov 2015 08:53:50 -0700

Alex -

Thanks for raising the issue of "time". The following is more about
information sharing than an issue with GeoJSON.

Over the last couple of years, the OGC Members have increasingly invested
time and effort into standards work related to the temporal aspects of
location referenced (geo) data. The expression of time, including time
series, is a critical interoperability requirement in many domains and has
huge implications in such activities in public safety, simulation and
modeling, hydrology, meteorology, and aviation.

The OGC has a very active Temporal Domain Working Group (
http://www.opengeospatial.org/projects/groups/temporaldwg) and a Time
Series Standards Working Group. Many of the use cases and requirements are
coming from the Meteorology, Hydrology, Aviation, Sensor, and Defence
communities. A fundamental understanding is that time reference systems
(TRS) are as critical to the geo-community as are coordinate reference
systems (CRS) and that the two are related. This is why the OGC community
is using the term "temporal CRS".

There are already a number of public OGC documents that deal with time -
going back to 2006:
http://portal.opengeospatial.org/files/?artifact_id=14898 and
https://portal.opengeospatial.org/files/?artifact_id=56394 for example. In
a few weeks, the OGC will publish a proposed JSON encoding for ISO/OGC
Observations and Measurements. This proposed encoding has rules specified
for time-position, time duration, time instance, and so on.

Regards

Carl

On Tue, Nov 10, 2015 at 5:51 AM, Alexandre Petrescu <
[email-masked]> wrote:

> _______________________________________________
> GeoJSON mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geojson
>

-- 
Carl Reed, PhD
Carl Reed and Associates

Mobile: 970-402-0284

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Nov 2015 10:42:39 -0800

While it's true that time is hard, at least we don't have to deal with
the added complexity of Julian and Mayan calendars.  What you have
here is an argument for WGS84 only.  At least we know that for
positions on the earth we don't have the problem of numbers increasing
beyond the bounds of the integer we use to store them in.

Also I see arguments for eliminating daylight savings, reducing time
zones, and moving to UT1 over UTC.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 12 Nov 2015 15:44:28 -0800

On 27 October 2015 at 14:47, Martin Thomson <[email-masked]> wrote:
> This is a two week call for adoption of draft-butler-geojson [1].

The working group has consensus to adopt the draft.

Authors, can you please submit a version of the draft with the name
draft-ietf-geojson at your next convenience.