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