asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Carey <dtab...@gmail.com>
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] https://tools.ietf.org/html/rfc7946
>> [2] https://github.com/Esri/geometry-api-java
>>
>> Thank you.
>> Yours sincerely,
>> Riyafa


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