It sounds like the best option is 4 minus parsing, then, if we can do
that. (Which would also address Wail's comments, which could be a
killer for big data eventually.) If not, we could go with 2 for the
summer as a first step, I guess? (But figuring out the feasibility of 4
would be great...)
Cheers,
Mike
On 6/26/17 2:59 AM, Ahmed Eldawy wrote:
It seems that (3) would require modifying the open source Esri API library
which I don't like. Not only for the overhead of understanding and
modifying the code, but also for deviating from the standard library which
means we will miss future updates. One of the reasons we chose to use Esri
API is the hope that it will be well-maintained in the future.
This leaves us with (4). I don't know if it is technically possible to
depend on the standard Esri API without using the non-compliant library or
not. If this is possible, then we can just use the computational geometry
(CG) functionality from the library, and provide our own GeoJSON parser. If
this is not possible, then I would rather consider the use of another
library, e.g., JTS.
Thanks
Ahmed
On Sun, Jun 25, 2017 at 11:47 AM, Wail Alkowaileet <[email protected]>
wrote:
I can see from the code that there is a serder steps as such: Asterix
Object (binary) --> JSON (String) --> Esri geometry (Java object) --> Esri
geometry (binary).
I think it would be nice if there is a binary-to-binary conversion without
any deserialization (4th option).
On Sun, Jun 25, 2017 at 6:36 PM, Mike Carey <[email protected]> wrote:
Agreed that 3 or 4 are what we'll need to do....! (Sigh.)
On 6/25/17 5:57 AM, Till Westmann wrote:
Hi Riyafa,
I think that the problem is bigger than the failing test. The JSON
license itself is not acceptable for inclusion in an Apache artifact
[4]. So we cannot use the ESRI API as-is, if we want the GeoJSON
functionality be a non-optional part of AsterixDB.
Here are a few options I see:
1) Make GeoJSON an optional part of AsterixDB (separate download from a
non-Apache location).
2) Make JSON.org a dependency that is not shipped (i.e. each user would
have to download and install those jars separately - and get error
messages if the jars are not available).
3) Create a clone/copy of the ESRI API that uses another JSON library.
4) Do all of the parsing independently from the ESRI API.
I’m not sure if 1) is a good option as the extensibility in this part
of the code might not be sufficient to support this option easily.
2) is technically easier, but it involves an unpleasant user
experience.
Also, I think that both 1) and 2) are not desirable, as GeoJSON should
be supported by vanilla AsterixDB.
For 3) and 4) we would need to look into the details to see how much
work is required for each of those options and if there are other legal
hurdles.
Are there other options?
Other thoughts/concerns?
Cheers,
Till
[4] https://www.apache.org/legal/resolved.html#category-x
On 25 Jun 2017, at 13:57, Riyafa Abdul Hameed wrote:
Dear all,
I implemented parse_geojon() function[1] using esri-geometry api[2]
which
is apache-2.0 licensed. But this api uses org.json as a dependency.
org.json is licensed under JSON which causes a license issue in the
code
I
have written[3]. What can I do about this issue?
[1] https://asterix-gerrit.ics.uci.edu/1838
[2]https://github.com/Esri/geometry-api-java
[3]
https://asterix-jenkins.ics.uci.edu/job/asterix-gerrit-integ
ration-tests/3290/
Thank you.
Yours sincerely,
Riyafa
--
*Regards,*
Wail Alkowaileet
