asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hillery <>
Subject Re: json vs. JSON
Date Wed, 12 Aug 2015 17:15:40 GMT
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"

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

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

aka Chris Hillery

On Fri, Aug 7, 2015 at 11:08 PM, Mike Carey <> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message