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 <hei...@csh.ac.at> napisał(a): > I agree with @Jia Yu <jiayu198...@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 <netanel...@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 <jia...@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 <netanel...@gmail.com> >>>> wrote: >>>> >>>>> Hi, >>>>> Have you had time to look at this? >>>>> >>>>> Best regards, >>>>> Netanel Malka. >>>>> >>>>> ---------- Forwarded message --------- >>>>> From: Netanel Malka <netanel...@gmail.com> >>>>> Date: Tue, 7 Jul 2020 at 11:06 >>>>> Subject: Re: Use JTS as a dependency instead of JTSPlus >>>>> To: Jia Yu <jia...@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 <jia...@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 <netanel...@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 >>>>>>> >>>>>>
