You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sedona.apache.org by Jia Yu <ji...@apache.org> on 2020/08/09 23:41:39 UTC
Re: Use JTS as a dependency instead of JTSPlus
Hi Netanel, CCed Pawel (GeoSpark Python), Georg (who might be also
interested in this issue), Sedona-dev
I think reflection would be a neat solution but it may bring technical debt
in the future and cause problems to the python API.
In the long run, a wrapper around JTS geometry would be a better solution
although we may need to change many places in the code.
Folks, what do you think?
Thanks,
Jia
On Sun, Aug 9, 2020 at 7:49 AM Netanel Malka <ne...@gmail.com> wrote:
> Hi,
> Currently, we are having some problems with userData on Geometry.
> The problems are:
>
> 1. Geometry toString function doesn't take userData into account
> 2. Geometry equals function doesn't take userData into account
>
>
> Our proposed solution is to wrap Geometry with a proxy object, that holds
> the Geometry and handles other columns instead of using Goemtery user data.
> Another possible solution is using reflection to change methods on
> Geometry itself
>
> What do you think we should do?
>
> Thanks. Regards
>
> On Thu, Jul 23, 2020, 21:32 Jia Yu <ji...@asu.edu> wrote:
>
>> Hi Netanel,
>>
>> Sorry. I somehow missed this email. The only test that GeoSpark does not
>> cover for JTSplus is this one:
>> https://github.com/jiayuasu/JTSplus/blob/master/src/test/java/jtsplustest/GeometryToStringTest.java
>>
>> If you can add this back to GeoSpark, I think you are good to go.
>>
>> Thanks,
>> Jia
>>
>> On Thu, Jul 23, 2020 at 6:08 AM Netanel Malka <ne...@gmail.com>
>> wrote:
>>
>>> Hi,
>>> Have you had time to look at this?
>>>
>>> Best regards,
>>> Netanel Malka.
>>>
>>> ---------- Forwarded message ---------
>>> From: Netanel Malka <ne...@gmail.com>
>>> Date: Tue, 7 Jul 2020 at 11:06
>>> Subject: Re: Use JTS as a dependency instead of JTSPlus
>>> To: Jia Yu <ji...@asu.edu>
>>>
>>>
>>> OK.
>>> We saw that in Geometry the userData field changed from null to "", is
>>> it crucial? because this is a change that I believe that JTS won't accept.
>>>
>>> Also, does GeoSpark tests are covered JTSPlus changes? If all the
>>> geospark tests are working, does it mean that we didn't break anything?
>>>
>>>
>>> On Thu, 2 Jul 2020 at 18:54, Jia Yu <ji...@asu.edu> wrote:
>>>
>>>> HI Netanel,
>>>>
>>>> Thanks for your work on this.
>>>>
>>>> userData in Envelope can be ignored. We will no longer support userData
>>>> in Envelope.
>>>>
>>>> Userdata field is used to hold non-spatial attributes in GeoSpark core.
>>>> When print a spatial object, userData will be printed out as a WKT string.
>>>>
>>>> In GeoSpark, I think it only calls the getUserData or setUserData, but
>>>> the majority of the work was done in JTSplus. When check the equality of
>>>> two objects in JTSplus, we also check the UserData but JTS by default does
>>>> not check that.
>>>>
>>>>
>>>> We communicate via mail since this thread is gonna be long.
>>>>
>>>> Thanks,
>>>> Jia
>>>>
>>>> ------------------------------------
>>>>
>>>> Jia Yu
>>>>
>>>> Ph.D. in Computer Science
>>>>
>>>> Arizona State University <http://www.asu.edu/>
>>>>
>>>> Reach me via: Homepage <http://jiayuasu.github.io/> | GitHub
>>>> <https://github.com/jiayuasu>
>>>>
>>>>
>>>> On Thu, Jul 2, 2020 at 3:01 AM Netanel Malka <ne...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>> how are you?
>>>>>
>>>>> I am working on this issue
>>>>> <https://github.com/DataSystemsLab/GeoSpark/issues/435> which I and
>>>>> my friends trying to upgrade the JTS version on GeoSpark.
>>>>> We are facing the userData field on Envelope which arent exists on JTS.
>>>>> Based on this PR <https://github.com/locationtech/jts/issues/364> I
>>>>> saw it's deprecated, can we ignore it?
>>>>>
>>>>> Also, We started to search for the using of userData for Geometry on
>>>>> GeoSpark and we found only this place:
>>>>> added equality of userData in Circle
>>>>> <https://github.com/superDoss/GeoSpark/commit/b8681267b9c32b8f40f8e4476d5dcce18b7dedc7>
>>>>>
>>>>> We would like to know if there are *more places* that we need to
>>>>> implement the equals on *userData*.
>>>>>
>>>>> *p.s.*
>>>>> Did a mail is a convenient communication channel for you?
>>>>> Or do you prefer I will open a new bug for that issue?
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Netanel Malka
>>>>>
>>>>
Re: Use JTS as a dependency instead of JTSPlus
Posted by Netanel Malka <ne...@gmail.com>.
Yes, that's right.
We are already working on that.
I hope to create the PR soon.
On Fri, Aug 21, 2020, 11:35 Jia Yu <ji...@gmail.com> wrote:
> Hi folks,
>
> I believe the conclusion is that we should use the wrapper solution
> instead of the reflection, right? (of course, with additional care to the
> wrapper)
>
> Thanks,
> Jia
>
> On Sun, Aug 9, 2020 at 11:37 PM Paweł Kociński <pa...@gmail.com>
> wrote:
>
>> Hi,
>> From my point of view, Python API needs only a few changes in that case.
>> First of all, few type annotation names change (Python API already has some
>> proxy object which holds shapely geometry and user data as a
>> separate attribute), If the new object has getter *getUserData, *the
>> change should be minimal. And those are changes for RDD API. SQL API should
>> not require changes due to the fact that translation between Dataframe and
>> RDD is hidden for Python (I assume that GeometryUDT will remain the same).
>>
>> Regards,
>> Pawel
>>
>> pon., 10 sie 2020 o 07:08 Georg Heiler <he...@csh.ac.at> napisał(a):
>>
>>> I agree with @Jia Yu <ji...@gmail.com> and think it is better to
>>> move forward with the wrapper.
>>>
>>> Best,
>>> Georg
>>>
>>> Am Mo., 10. Aug. 2020 um 01:41 Uhr schrieb Jia Yu <ji...@apache.org>:
>>>
>>>> Hi Netanel, CCed Pawel (GeoSpark Python), Georg (who might be also
>>>> interested in this issue), Sedona-dev
>>>>
>>>> I think reflection would be a neat solution but it may bring
>>>> technical debt in the future and cause problems to the python API.
>>>>
>>>> In the long run, a wrapper around JTS geometry would be a better
>>>> solution although we may need to change many places in the code.
>>>>
>>>> Folks, what do you think?
>>>>
>>>> Thanks,
>>>> Jia
>>>>
>>>> On Sun, Aug 9, 2020 at 7:49 AM Netanel Malka <ne...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>> Currently, we are having some problems with userData on Geometry.
>>>>> The problems are:
>>>>>
>>>>> 1. Geometry toString function doesn't take userData into account
>>>>> 2. Geometry equals function doesn't take userData into account
>>>>>
>>>>>
>>>>> Our proposed solution is to wrap Geometry with a proxy object, that
>>>>> holds the Geometry and handles other columns instead of using Goemtery user
>>>>> data.
>>>>> Another possible solution is using reflection to change methods on
>>>>> Geometry itself
>>>>>
>>>>> What do you think we should do?
>>>>>
>>>>> Thanks. Regards
>>>>>
>>>>> On Thu, Jul 23, 2020, 21:32 Jia Yu <ji...@asu.edu> wrote:
>>>>>
>>>>>> Hi Netanel,
>>>>>>
>>>>>> Sorry. I somehow missed this email. The only test that GeoSpark does
>>>>>> not cover for JTSplus is this one:
>>>>>> https://github.com/jiayuasu/JTSplus/blob/master/src/test/java/jtsplustest/GeometryToStringTest.java
>>>>>>
>>>>>> If you can add this back to GeoSpark, I think you are good to go.
>>>>>>
>>>>>> Thanks,
>>>>>> Jia
>>>>>>
>>>>>> On Thu, Jul 23, 2020 at 6:08 AM Netanel Malka <ne...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>> Have you had time to look at this?
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Netanel Malka.
>>>>>>>
>>>>>>> ---------- Forwarded message ---------
>>>>>>> From: Netanel Malka <ne...@gmail.com>
>>>>>>> Date: Tue, 7 Jul 2020 at 11:06
>>>>>>> Subject: Re: Use JTS as a dependency instead of JTSPlus
>>>>>>> To: Jia Yu <ji...@asu.edu>
>>>>>>>
>>>>>>>
>>>>>>> OK.
>>>>>>> We saw that in Geometry the userData field changed from null to "",
>>>>>>> is it crucial? because this is a change that I believe that JTS won't
>>>>>>> accept.
>>>>>>>
>>>>>>> Also, does GeoSpark tests are covered JTSPlus changes? If all the
>>>>>>> geospark tests are working, does it mean that we didn't break anything?
>>>>>>>
>>>>>>>
>>>>>>> On Thu, 2 Jul 2020 at 18:54, Jia Yu <ji...@asu.edu> wrote:
>>>>>>>
>>>>>>>> HI Netanel,
>>>>>>>>
>>>>>>>> Thanks for your work on this.
>>>>>>>>
>>>>>>>> userData in Envelope can be ignored. We will no longer support
>>>>>>>> userData in Envelope.
>>>>>>>>
>>>>>>>> Userdata field is used to hold non-spatial attributes in GeoSpark
>>>>>>>> core. When print a spatial object, userData will be printed out as a WKT
>>>>>>>> string.
>>>>>>>>
>>>>>>>> In GeoSpark, I think it only calls the getUserData or setUserData,
>>>>>>>> but the majority of the work was done in JTSplus. When check the equality
>>>>>>>> of two objects in JTSplus, we also check the UserData but JTS by default
>>>>>>>> does not check that.
>>>>>>>>
>>>>>>>>
>>>>>>>> We communicate via mail since this thread is gonna be long.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Jia
>>>>>>>>
>>>>>>>> ------------------------------------
>>>>>>>>
>>>>>>>> Jia Yu
>>>>>>>>
>>>>>>>> Ph.D. in Computer Science
>>>>>>>>
>>>>>>>> Arizona State University <http://www.asu.edu/>
>>>>>>>>
>>>>>>>> Reach me via: Homepage <http://jiayuasu.github.io/> | GitHub
>>>>>>>> <https://github.com/jiayuasu>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Jul 2, 2020 at 3:01 AM Netanel Malka <ne...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>> how are you?
>>>>>>>>>
>>>>>>>>> I am working on this issue
>>>>>>>>> <https://github.com/DataSystemsLab/GeoSpark/issues/435> which I
>>>>>>>>> and my friends trying to upgrade the JTS version on GeoSpark.
>>>>>>>>> We are facing the userData field on Envelope which arent exists on
>>>>>>>>> JTS.
>>>>>>>>> Based on this PR <https://github.com/locationtech/jts/issues/364> I
>>>>>>>>> saw it's deprecated, can we ignore it?
>>>>>>>>>
>>>>>>>>> Also, We started to search for the using of userData for Geometry
>>>>>>>>> on GeoSpark and we found only this place:
>>>>>>>>> added equality of userData in Circle
>>>>>>>>> <https://github.com/superDoss/GeoSpark/commit/b8681267b9c32b8f40f8e4476d5dcce18b7dedc7>
>>>>>>>>>
>>>>>>>>> We would like to know if there are *more places* that we need to
>>>>>>>>> implement the equals on *userData*.
>>>>>>>>>
>>>>>>>>> *p.s.*
>>>>>>>>> Did a mail is a convenient communication channel for you?
>>>>>>>>> Or do you prefer I will open a new bug for that issue?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Netanel Malka
>>>>>>>>>
>>>>>>>>
Re: Use JTS as a dependency instead of JTSPlus
Posted by Jia Yu <ji...@gmail.com>.
Hi folks,
I believe the conclusion is that we should use the wrapper solution instead
of the reflection, right? (of course, with additional care to the wrapper)
Thanks,
Jia
On Sun, Aug 9, 2020 at 11:37 PM Paweł Kociński <pa...@gmail.com>
wrote:
> Hi,
> From my point of view, Python API needs only a few changes in that case.
> First of all, few type annotation names change (Python API already has some
> proxy object which holds shapely geometry and user data as a
> separate attribute), If the new object has getter *getUserData, *the
> change should be minimal. And those are changes for RDD API. SQL API should
> not require changes due to the fact that translation between Dataframe and
> RDD is hidden for Python (I assume that GeometryUDT will remain the same).
>
> Regards,
> Pawel
>
> pon., 10 sie 2020 o 07:08 Georg Heiler <he...@csh.ac.at> napisał(a):
>
>> I agree with @Jia Yu <ji...@gmail.com> and think it is better to
>> move forward with the wrapper.
>>
>> Best,
>> Georg
>>
>> Am Mo., 10. Aug. 2020 um 01:41 Uhr schrieb Jia Yu <ji...@apache.org>:
>>
>>> Hi Netanel, CCed Pawel (GeoSpark Python), Georg (who might be also
>>> interested in this issue), Sedona-dev
>>>
>>> I think reflection would be a neat solution but it may bring
>>> technical debt in the future and cause problems to the python API.
>>>
>>> In the long run, a wrapper around JTS geometry would be a better
>>> solution although we may need to change many places in the code.
>>>
>>> Folks, what do you think?
>>>
>>> Thanks,
>>> Jia
>>>
>>> On Sun, Aug 9, 2020 at 7:49 AM Netanel Malka <ne...@gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>> Currently, we are having some problems with userData on Geometry.
>>>> The problems are:
>>>>
>>>> 1. Geometry toString function doesn't take userData into account
>>>> 2. Geometry equals function doesn't take userData into account
>>>>
>>>>
>>>> Our proposed solution is to wrap Geometry with a proxy object, that
>>>> holds the Geometry and handles other columns instead of using Goemtery user
>>>> data.
>>>> Another possible solution is using reflection to change methods on
>>>> Geometry itself
>>>>
>>>> What do you think we should do?
>>>>
>>>> Thanks. Regards
>>>>
>>>> On Thu, Jul 23, 2020, 21:32 Jia Yu <ji...@asu.edu> wrote:
>>>>
>>>>> Hi Netanel,
>>>>>
>>>>> Sorry. I somehow missed this email. The only test that GeoSpark does
>>>>> not cover for JTSplus is this one:
>>>>> https://github.com/jiayuasu/JTSplus/blob/master/src/test/java/jtsplustest/GeometryToStringTest.java
>>>>>
>>>>> If you can add this back to GeoSpark, I think you are good to go.
>>>>>
>>>>> Thanks,
>>>>> Jia
>>>>>
>>>>> On Thu, Jul 23, 2020 at 6:08 AM Netanel Malka <ne...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>> Have you had time to look at this?
>>>>>>
>>>>>> Best regards,
>>>>>> Netanel Malka.
>>>>>>
>>>>>> ---------- Forwarded message ---------
>>>>>> From: Netanel Malka <ne...@gmail.com>
>>>>>> Date: Tue, 7 Jul 2020 at 11:06
>>>>>> Subject: Re: Use JTS as a dependency instead of JTSPlus
>>>>>> To: Jia Yu <ji...@asu.edu>
>>>>>>
>>>>>>
>>>>>> OK.
>>>>>> We saw that in Geometry the userData field changed from null to "",
>>>>>> is it crucial? because this is a change that I believe that JTS won't
>>>>>> accept.
>>>>>>
>>>>>> Also, does GeoSpark tests are covered JTSPlus changes? If all the
>>>>>> geospark tests are working, does it mean that we didn't break anything?
>>>>>>
>>>>>>
>>>>>> On Thu, 2 Jul 2020 at 18:54, Jia Yu <ji...@asu.edu> wrote:
>>>>>>
>>>>>>> HI Netanel,
>>>>>>>
>>>>>>> Thanks for your work on this.
>>>>>>>
>>>>>>> userData in Envelope can be ignored. We will no longer support
>>>>>>> userData in Envelope.
>>>>>>>
>>>>>>> Userdata field is used to hold non-spatial attributes in GeoSpark
>>>>>>> core. When print a spatial object, userData will be printed out as a WKT
>>>>>>> string.
>>>>>>>
>>>>>>> In GeoSpark, I think it only calls the getUserData or setUserData,
>>>>>>> but the majority of the work was done in JTSplus. When check the equality
>>>>>>> of two objects in JTSplus, we also check the UserData but JTS by default
>>>>>>> does not check that.
>>>>>>>
>>>>>>>
>>>>>>> We communicate via mail since this thread is gonna be long.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Jia
>>>>>>>
>>>>>>> ------------------------------------
>>>>>>>
>>>>>>> Jia Yu
>>>>>>>
>>>>>>> Ph.D. in Computer Science
>>>>>>>
>>>>>>> Arizona State University <http://www.asu.edu/>
>>>>>>>
>>>>>>> Reach me via: Homepage <http://jiayuasu.github.io/> | GitHub
>>>>>>> <https://github.com/jiayuasu>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Jul 2, 2020 at 3:01 AM Netanel Malka <ne...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>> how are you?
>>>>>>>>
>>>>>>>> I am working on this issue
>>>>>>>> <https://github.com/DataSystemsLab/GeoSpark/issues/435> which I
>>>>>>>> and my friends trying to upgrade the JTS version on GeoSpark.
>>>>>>>> We are facing the userData field on Envelope which arent exists on
>>>>>>>> JTS.
>>>>>>>> Based on this PR <https://github.com/locationtech/jts/issues/364> I
>>>>>>>> saw it's deprecated, can we ignore it?
>>>>>>>>
>>>>>>>> Also, We started to search for the using of userData for Geometry
>>>>>>>> on GeoSpark and we found only this place:
>>>>>>>> added equality of userData in Circle
>>>>>>>> <https://github.com/superDoss/GeoSpark/commit/b8681267b9c32b8f40f8e4476d5dcce18b7dedc7>
>>>>>>>>
>>>>>>>> We would like to know if there are *more places* that we need to
>>>>>>>> implement the equals on *userData*.
>>>>>>>>
>>>>>>>> *p.s.*
>>>>>>>> Did a mail is a convenient communication channel for you?
>>>>>>>> Or do you prefer I will open a new bug for that issue?
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Netanel Malka
>>>>>>>>
>>>>>>>
Re: Use JTS as a dependency instead of JTSPlus
Posted by Paweł Kociński <pa...@gmail.com>.
Hi,
From my point of view, Python API needs only a few changes in that case.
First of all, few type annotation names change (Python API already has some
proxy object which holds shapely geometry and user data as a
separate attribute), If the new object has getter *getUserData, *the
change should be minimal. And those are changes for RDD API. SQL API should
not require changes due to the fact that translation between Dataframe and
RDD is hidden for Python (I assume that GeometryUDT will remain the same).
Regards,
Pawel
pon., 10 sie 2020 o 07:08 Georg Heiler <he...@csh.ac.at> napisał(a):
> I agree with @Jia Yu <ji...@gmail.com> and think it is better to
> move forward with the wrapper.
>
> Best,
> Georg
>
> Am Mo., 10. Aug. 2020 um 01:41 Uhr schrieb Jia Yu <ji...@apache.org>:
>
>> Hi Netanel, CCed Pawel (GeoSpark Python), Georg (who might be also
>> interested in this issue), Sedona-dev
>>
>> I think reflection would be a neat solution but it may bring
>> technical debt in the future and cause problems to the python API.
>>
>> In the long run, a wrapper around JTS geometry would be a better solution
>> although we may need to change many places in the code.
>>
>> Folks, what do you think?
>>
>> Thanks,
>> Jia
>>
>> On Sun, Aug 9, 2020 at 7:49 AM Netanel Malka <ne...@gmail.com>
>> wrote:
>>
>>> Hi,
>>> Currently, we are having some problems with userData on Geometry.
>>> The problems are:
>>>
>>> 1. Geometry toString function doesn't take userData into account
>>> 2. Geometry equals function doesn't take userData into account
>>>
>>>
>>> Our proposed solution is to wrap Geometry with a proxy object, that
>>> holds the Geometry and handles other columns instead of using Goemtery user
>>> data.
>>> Another possible solution is using reflection to change methods on
>>> Geometry itself
>>>
>>> What do you think we should do?
>>>
>>> Thanks. Regards
>>>
>>> On Thu, Jul 23, 2020, 21:32 Jia Yu <ji...@asu.edu> wrote:
>>>
>>>> Hi Netanel,
>>>>
>>>> Sorry. I somehow missed this email. The only test that GeoSpark does
>>>> not cover for JTSplus is this one:
>>>> https://github.com/jiayuasu/JTSplus/blob/master/src/test/java/jtsplustest/GeometryToStringTest.java
>>>>
>>>> If you can add this back to GeoSpark, I think you are good to go.
>>>>
>>>> Thanks,
>>>> Jia
>>>>
>>>> On Thu, Jul 23, 2020 at 6:08 AM Netanel Malka <ne...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>> Have you had time to look at this?
>>>>>
>>>>> Best regards,
>>>>> Netanel Malka.
>>>>>
>>>>> ---------- Forwarded message ---------
>>>>> From: Netanel Malka <ne...@gmail.com>
>>>>> Date: Tue, 7 Jul 2020 at 11:06
>>>>> Subject: Re: Use JTS as a dependency instead of JTSPlus
>>>>> To: Jia Yu <ji...@asu.edu>
>>>>>
>>>>>
>>>>> OK.
>>>>> We saw that in Geometry the userData field changed from null to "", is
>>>>> it crucial? because this is a change that I believe that JTS won't accept.
>>>>>
>>>>> Also, does GeoSpark tests are covered JTSPlus changes? If all the
>>>>> geospark tests are working, does it mean that we didn't break anything?
>>>>>
>>>>>
>>>>> On Thu, 2 Jul 2020 at 18:54, Jia Yu <ji...@asu.edu> wrote:
>>>>>
>>>>>> HI Netanel,
>>>>>>
>>>>>> Thanks for your work on this.
>>>>>>
>>>>>> userData in Envelope can be ignored. We will no longer support
>>>>>> userData in Envelope.
>>>>>>
>>>>>> Userdata field is used to hold non-spatial attributes in GeoSpark
>>>>>> core. When print a spatial object, userData will be printed out as a WKT
>>>>>> string.
>>>>>>
>>>>>> In GeoSpark, I think it only calls the getUserData or setUserData,
>>>>>> but the majority of the work was done in JTSplus. When check the equality
>>>>>> of two objects in JTSplus, we also check the UserData but JTS by default
>>>>>> does not check that.
>>>>>>
>>>>>>
>>>>>> We communicate via mail since this thread is gonna be long.
>>>>>>
>>>>>> Thanks,
>>>>>> Jia
>>>>>>
>>>>>> ------------------------------------
>>>>>>
>>>>>> Jia Yu
>>>>>>
>>>>>> Ph.D. in Computer Science
>>>>>>
>>>>>> Arizona State University <http://www.asu.edu/>
>>>>>>
>>>>>> Reach me via: Homepage <http://jiayuasu.github.io/> | GitHub
>>>>>> <https://github.com/jiayuasu>
>>>>>>
>>>>>>
>>>>>> On Thu, Jul 2, 2020 at 3:01 AM Netanel Malka <ne...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>> how are you?
>>>>>>>
>>>>>>> I am working on this issue
>>>>>>> <https://github.com/DataSystemsLab/GeoSpark/issues/435> which I and
>>>>>>> my friends trying to upgrade the JTS version on GeoSpark.
>>>>>>> We are facing the userData field on Envelope which arent exists on
>>>>>>> JTS.
>>>>>>> Based on this PR <https://github.com/locationtech/jts/issues/364> I
>>>>>>> saw it's deprecated, can we ignore it?
>>>>>>>
>>>>>>> Also, We started to search for the using of userData for Geometry on
>>>>>>> GeoSpark and we found only this place:
>>>>>>> added equality of userData in Circle
>>>>>>> <https://github.com/superDoss/GeoSpark/commit/b8681267b9c32b8f40f8e4476d5dcce18b7dedc7>
>>>>>>>
>>>>>>> We would like to know if there are *more places* that we need to
>>>>>>> implement the equals on *userData*.
>>>>>>>
>>>>>>> *p.s.*
>>>>>>> Did a mail is a convenient communication channel for you?
>>>>>>> Or do you prefer I will open a new bug for that issue?
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Netanel Malka
>>>>>>>
>>>>>>
Re: Use JTS as a dependency instead of JTSPlus
Posted by Georg Heiler <he...@csh.ac.at>.
I agree with @Jia Yu <ji...@gmail.com> and think it is better to move
forward with the wrapper.
Best,
Georg
Am Mo., 10. Aug. 2020 um 01:41 Uhr schrieb Jia Yu <ji...@apache.org>:
> Hi Netanel, CCed Pawel (GeoSpark Python), Georg (who might be also
> interested in this issue), Sedona-dev
>
> I think reflection would be a neat solution but it may bring
> technical debt in the future and cause problems to the python API.
>
> In the long run, a wrapper around JTS geometry would be a better solution
> although we may need to change many places in the code.
>
> Folks, what do you think?
>
> Thanks,
> Jia
>
> On Sun, Aug 9, 2020 at 7:49 AM Netanel Malka <ne...@gmail.com> wrote:
>
>> Hi,
>> Currently, we are having some problems with userData on Geometry.
>> The problems are:
>>
>> 1. Geometry toString function doesn't take userData into account
>> 2. Geometry equals function doesn't take userData into account
>>
>>
>> Our proposed solution is to wrap Geometry with a proxy object, that holds
>> the Geometry and handles other columns instead of using Goemtery user data.
>> Another possible solution is using reflection to change methods on
>> Geometry itself
>>
>> What do you think we should do?
>>
>> Thanks. Regards
>>
>> On Thu, Jul 23, 2020, 21:32 Jia Yu <ji...@asu.edu> wrote:
>>
>>> Hi Netanel,
>>>
>>> Sorry. I somehow missed this email. The only test that GeoSpark does not
>>> cover for JTSplus is this one:
>>> https://github.com/jiayuasu/JTSplus/blob/master/src/test/java/jtsplustest/GeometryToStringTest.java
>>>
>>> If you can add this back to GeoSpark, I think you are good to go.
>>>
>>> Thanks,
>>> Jia
>>>
>>> On Thu, Jul 23, 2020 at 6:08 AM Netanel Malka <ne...@gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>> Have you had time to look at this?
>>>>
>>>> Best regards,
>>>> Netanel Malka.
>>>>
>>>> ---------- Forwarded message ---------
>>>> From: Netanel Malka <ne...@gmail.com>
>>>> Date: Tue, 7 Jul 2020 at 11:06
>>>> Subject: Re: Use JTS as a dependency instead of JTSPlus
>>>> To: Jia Yu <ji...@asu.edu>
>>>>
>>>>
>>>> OK.
>>>> We saw that in Geometry the userData field changed from null to "", is
>>>> it crucial? because this is a change that I believe that JTS won't accept.
>>>>
>>>> Also, does GeoSpark tests are covered JTSPlus changes? If all the
>>>> geospark tests are working, does it mean that we didn't break anything?
>>>>
>>>>
>>>> On Thu, 2 Jul 2020 at 18:54, Jia Yu <ji...@asu.edu> wrote:
>>>>
>>>>> HI Netanel,
>>>>>
>>>>> Thanks for your work on this.
>>>>>
>>>>> userData in Envelope can be ignored. We will no longer support
>>>>> userData in Envelope.
>>>>>
>>>>> Userdata field is used to hold non-spatial attributes in GeoSpark
>>>>> core. When print a spatial object, userData will be printed out as a WKT
>>>>> string.
>>>>>
>>>>> In GeoSpark, I think it only calls the getUserData or setUserData, but
>>>>> the majority of the work was done in JTSplus. When check the equality of
>>>>> two objects in JTSplus, we also check the UserData but JTS by default does
>>>>> not check that.
>>>>>
>>>>>
>>>>> We communicate via mail since this thread is gonna be long.
>>>>>
>>>>> Thanks,
>>>>> Jia
>>>>>
>>>>> ------------------------------------
>>>>>
>>>>> Jia Yu
>>>>>
>>>>> Ph.D. in Computer Science
>>>>>
>>>>> Arizona State University <http://www.asu.edu/>
>>>>>
>>>>> Reach me via: Homepage <http://jiayuasu.github.io/> | GitHub
>>>>> <https://github.com/jiayuasu>
>>>>>
>>>>>
>>>>> On Thu, Jul 2, 2020 at 3:01 AM Netanel Malka <ne...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>> how are you?
>>>>>>
>>>>>> I am working on this issue
>>>>>> <https://github.com/DataSystemsLab/GeoSpark/issues/435> which I and
>>>>>> my friends trying to upgrade the JTS version on GeoSpark.
>>>>>> We are facing the userData field on Envelope which arent exists on
>>>>>> JTS.
>>>>>> Based on this PR <https://github.com/locationtech/jts/issues/364> I
>>>>>> saw it's deprecated, can we ignore it?
>>>>>>
>>>>>> Also, We started to search for the using of userData for Geometry on
>>>>>> GeoSpark and we found only this place:
>>>>>> added equality of userData in Circle
>>>>>> <https://github.com/superDoss/GeoSpark/commit/b8681267b9c32b8f40f8e4476d5dcce18b7dedc7>
>>>>>>
>>>>>> We would like to know if there are *more places* that we need to
>>>>>> implement the equals on *userData*.
>>>>>>
>>>>>> *p.s.*
>>>>>> Did a mail is a convenient communication channel for you?
>>>>>> Or do you prefer I will open a new bug for that issue?
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Netanel Malka
>>>>>>
>>>>>