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
