asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Riyafa Abdul Hameed <riy...@apache.org>
Subject Re: Support GeoJSON in AsterixDB
Date Sun, 18 Jun 2017 14:12:33 GMT
Hi,

The plan is to implement a function as *parse_geojson()* which would take
as input json objects. My concern is when the input (ie. json objects) is
parsed within AsterixDB it would be as *Records*. Then *Records* might have
to converted to WKB or to OGCGeometry type of Esri api. Is it the way to
follow in this case?

Sorry about the ignorance.

Thank you.
Yours sincerely,
Riyafa

On 14 June 2017 at 02:19, Mike Carey <dtabass@gmail.com> wrote:

> 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