asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Carey <>
Subject Re: Support GeoJSON in AsterixDB
Date Tue, 13 Jun 2017 20:49:07 GMT
Agreed.  I also think we'll want to avoid an architecture where 
extending the system with a new JSON-based standard might require 
modifying its core components - the function approach seems more modular 
and cleaner.

On 6/13/17 1:14 PM, Till Westmann wrote:
> Hi,
> I’m sorry for the late comment on this. I think that we should not directly
> parse GeoJSON into WKB initially. As GeoJSON is valid JSON we’d need to
> a) determine if it’s GeoJSON every time we parse some JSON and
> b) do this independent of the users intention (maybe it’s just some JSON
>     that gets returned and never stored or processed).
> So I think that we should have a user action (e.g. a constructor function)
> that clearly documents the users intention.
> Cheers,
> Till
> On 9 Jun 2017, at 2:24, Riyafa Abdul Hameed wrote:
>> Hi all,
>> As the first step in resolving ASTERIXDB-1371 we plan to add support for
>> GeoJSON[1]. Hence initially a datatype known as 'Geometry' would be
>> implemented. Since we plan to use Esri-geometry-api[2] to achieve this, the
>> internal representation of the Geometry objects need to be in WKB(Well
>> Known Binary) format.
>> GeoJSON is also defined in JSON. Currently as I understand the JSON objects
>> and arrays are represented by the Record and OrderedList datatypes
>> respectively. But they are not internally parsed into WKB format. Thus it
>> wouldn't be possible to reuse them unless we write our own implementation
>> to convert these types to WKB format.
>> Hence my question is if it is a good idea to change the javcc grammar
>> (grammar.jj) to parse Geometry types directly which could then be
>> internally represented in the WKB format.
>> [1]
>> [2]
>> Thank you.
>> Yours sincerely,
>> Riyafa

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