Mailing-List: contact dev-help@asterixdb.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@asterixdb.incubator.apache.org
MIME-Version: 1.0
Sender: ceej@lambda.nu
In-Reply-To: <55C59CE7.8020602@gmail.com>
References: <55BCF130.1090805@gmail.com>
 <5F1DCABB-A9D4-4EF1-88B4-85AE6053F40B@apache.org>
 <55C1B59C.6040400@gmail.com>
 <CAHWyyRwnX1szvLHN12v4-udx1WpKZZrBnk5ypy-hgS5iTLPAkg@mail.gmail.com>
 <CAEYY6daLrvnLDfFBbqvVqo6oee15YXQ0SJFdFH7jg+Zki2j9yA@mail.gmail.com>
 <CAHWyyRzyBmJXE13LQjJLGt1t=13uMe4=G4XKCZ_qzrjtxLmyDg@mail.gmail.com>
 <55C290EB.7030709@gmail.com>
 <CAHWyyRz+5rUKx4xim1LAdJfp4JEeM_0HxU2zrX7hAr2L4fZ+Pw@mail.gmail.com>
 <CAEYY6dag+Yq2gm3AFWt2U584NPNvDJOsq3Af2v_vq8vrqW31OQ@mail.gmail.com>
 <CAHWyyRz-beqRZWnd72sf7eTOFsqeho=KLYzQ8Z0tnYKmdxwB=Q@mail.gmail.com>
 <CAEYY6dbpRe1bFjpOG1jJD4OwsZ-k36hDCVV56mXQ_sKa8Jhb-g@mail.gmail.com>
 <CANQf6Dq9puBFenJ9pXu0r8bhxDyOM_qmef5Va6vfsKicW46KNg@mail.gmail.com>
 <55C59CE7.8020602@gmail.com>
From: Chris Hillery <chillery@hillery.land>
Date: Wed, 12 Aug 2015 10:15:40 -0700
Message-ID: 
 <CAHWyyRx59sO2=mOfnR65VOQ0983_5AtWKbaE_wWdRVBZ5hhw7w@mail.gmail.com>
Subject: Re: json vs. JSON
To: dev@asterixdb.incubator.apache.org
Content-Type: multipart/alternative; boundary=001a113495e2658b01051d205f5f

--001a113495e2658b01051d205f5f
Content-Type: text/plain; charset=UTF-8

So I don't think we've reached anything like a consensus here regarding
spatial types. I'll restate my opinion that coercing them into any of the
complex specifications that have been mentioned (GeoJSON, arcgis, even
Well-Known Text) is inappropriate for serialization. Also, most of those
specifications are even more complex than the "lossless JSON" serialization
we already have, so would be doubly inappropriate for our "clean JSON"
variant.

That's what I don't think should be done, so what do I think should be
done? Well, the whole purpose of this exercise as initially suggested by
Mike was to allow a form of JSON output that was more like what someone
consuming this *as JSON* would expect. To me that means that the format
should be something that (a) is useful for downstream JSON tools, while (b)
being as simply-structured as possible. Also, a non-goal in my mind is that
this output format be able to be returned to its original ADM form; it is
explicitly "lossy" in that sense.

Till suggested that the rule should be that all atomic ADM types got
serialized as atomic JSON, generally by creating a string representation of
the data. That works nicely for numerics as well as things that are
basically strings anyway, such as UUID and Hex. It also suggests an obvious
way to handle date/time/duration types since there is something of a global
standard string representation for those.

However, upon thinking about it, I don't think that's the simplest nor the
most useful way for us to represent spatial types. The best we could do
there would be something not entirely unlike a dramatic subset of
Well-Known Text, eg. "POINT (30 10)". While that arguably meets criterion
(b) above, it definitely doesn't meet (a) since any downstream
JSON-accepting tool is going to have to do non-JSON string processing to
extract the actual meaning. I also come back again to the problem that
Circle cannot be represented unless we create a non-standard extension to
WKT.

After considering the various things that have been discussed, I've gotta
be honest: I still like my original proposal the best. It's a concise but
usable consolidation of the data represented in ADM, which best I can tell
is what we're looking to implement.

  "location2d" : [41.0, 44.0],
  "location3d" : [44.0, 13.0, 41.0],
  "line" : [ [10.1, 11.1], [10.2, 11.2] ],
  "rectangle" : [ [5.1, 11.8], [87.6, 15.6548] ],
  "polygon" : [ [1.2, 1.3], [2.1, 2.5], [3.5, 3.6], [4.6, 4.8] ],
  "circle" : { "radius" : 10.1, "center" : [ 11.1, 10.2 ] },

I'm not entirely happy that circle gets rendered as as an object; something
like  "circle": [ [11.1, 10.2], 10.1 ] could work too. Or, if necessary,
all shapes (not points) could be rendered as objects as per my secondary
proposal.

Ceej
aka Chris Hillery


On Fri, Aug 7, 2015 at 11:08 PM, Mike Carey <dtabass@gmail.com> wrote:

> I am willing to retract my proposal... :-)
> (Consider it retracted; I agree with Ted Dunning's comment, and similar
> comments by others.)
>
>
> On 8/7/15 10:35 PM, Chen Li wrote:
>
>> In today's weekly meeting Mike mentioned the idea of getting rid of
>> the "circle" data type.  It will be good to have a F2F discussion
>> before we make the final decision.
>>
>> Chen
>>
>
>

--001a113495e2658b01051d205f5f--