[GitHub] [incubator-sedona] Imbruced commented on pull request #498: Documentation update
Imbruced commented on pull request #498: URL: https://github.com/apache/incubator-sedona/pull/498#issuecomment-749132534 @jiayuasu Please give me one additional day to make sure I am not missing anything. I removed to_df method from Raw join query result and kept it in Adapter only. During writing the docs I thought that may be confusing. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [incubator-sedona] Imbruced opened a new pull request #498: Documentation update
Imbruced opened a new pull request #498: URL: https://github.com/apache/incubator-sedona/pull/498 ## Is this PR related to a proposed Issue? Documentation update for first Sedona release Remove duplicated function ## What changes were proposed in this PR? Documentation update ## How was this patch tested? Python unit tests ## Did this PR include necessary documentation updates? yes This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: First Sedona release
Succeeded to push the snapshots. On Mon, 21 Dec 2020 at 12:04, Netanel Malka wrote: > Thanks. but unfortunately, it's not working. > I got the prompt for the PGP passphrase at the release:prepare phase. > > It looks like I don't have permission to push to the Sedona > nexus artifactory. > > I will try to fix that later. > > On Mon, 21 Dec 2020 at 11:55, Jia Yu wrote: > >> @Netanel Malka >> >> Sometimes, if you are using Mac, you need to enter the following in your >> terminal before using GPG key to sign an artifact: >> https://gist.github.com/jiayuasu/8bab8ecb0234dfc280264fb587fd8b01 >> >> GPG_TTY=$(tty) >> export GPG_TTY >> >> >> >> On Mon, Dec 21, 2020 at 1:52 AM Netanel Malka >> wrote: >> >>> Hi Jia, >>> I tried to deploy but I got a 401 Unauthorized error, full error: >>> https://gist.github.com/netanel246/04c5be423d242a3bb9ef9a300c8817c8 >>> >>> I created a settings.xml file with my apache user and an encrypted >>> password. I also have a GPG key. >>> Did you encounter this problem? >>> >>> >>> Thanks, >>> Netanel Malka. >>> >>> >>> On Sun, 20 Dec 2020 at 20:12, Netanel Malka >>> wrote: >>> >>> > That's great!! >>> > Hope to try it today. >>> > >>> > >>> > On Fri, 18 Dec 2020 at 10:36, Jia Yu wrote: >>> > >>> >> Hi Netanel and Paweł, >>> >> >>> >> The JTS issue has resolved. I am now waiting for JTS 1.18 release but >>> we >>> >> are currently using 1.17.1 + copied files. So we are good anyway. >>> >> >>> >> So the next step will be documentation and stage the first release. >>> >> Although I really want to resolve the ST_Transform lock contention >>> issue, >>> >> it requires a new ST_FlipCoordinate which may take a few days. I will >>> see >>> >> whether I can finish this by Christmas but not sure. >>> >> >>> >> @Netanel Malka Could you please compile the >>> master >>> >> branch and try to deploy a SNAPSHOT release on your own? I have >>> pushed a >>> >> few snapshots but I would like to see whether you can do it too. >>> Please >>> >> follow the steps here: >>> >> https://gist.github.com/jiayuasu/849e1f3bf7a2dd11593ca27c14e9e92d >>> >> >>> >> @Paweł Kociński Step 1. Could you please >>> >> update >>> >> the new Python Adaptor documentation? Step 2. Could you please try to >>> >> deploy a SNAPSHOT release to PyPI? You can find some help here: >>> >> https://incubator.apache.org/guides/distribution.html >>> >> >>> >> Thank you very much! >>> >> Jia >>> >> >>> >> >>> >> On Thu, Dec 10, 2020 at 3:26 PM Jim Hughes wrote: >>> >> >>> >> > Hi Jia, >>> >> > >>> >> > A JTS 1.18.0 release would not be just for Apache Sedona.;) Getting >>> it >>> >> > out sooner would let others projects adopt it sooner (I'm thinking >>> of >>> >> > GeoTools and GeoServer). I'm excited to see the improvements to the >>> >> > overlay operations... >>> >> > >>> >> > I've traded some emails and chats with Martin. It sounds like he >>> is ok >>> >> > with cutting JTS 1.18.0 in the next week; I'll be working with him >>> and >>> >> > Jody to do our best to make that happen. >>> >> > >>> >> > Anyhow, in terms of shading, there are few things I'd suggest. >>> First, >>> >> > I'd suggest that libraries which can function as libraries have a >>> >> > version of the jar which does not include any dependencies. If you >>> go >>> >> > along with that, sedona-core should produce a jar on its own and >>> another >>> >> > module could build a "batteries included" jar for users to drop into >>> >> Spark. >>> >> > >>> >> > Separate from that, I'd recommend that when you copy entire files >>> into a >>> >> > project that you change the package for those classes. Concretely, >>> you >>> >> > could just prepend org.apache.sedona to the package names for those >>> 5 >>> >> > classes. (This assumes that it is possible. Sometimes there may be >>> >> > issues around package protected access, etc.) >>> >> > >>> >> > As it stands right now, if a user tries to use Sedona with any other >>> >> > library that pulls in JTS, then they will be at the mercy of the >>> class >>> >> > loading order. If the JTS jar comes in elsewhere, your versions of >>> the >>> >> > RTree may not be loaded! The exception would look like a JTS issue >>> and >>> >> > it be fairly confusing for most people to debug. >>> >> > >>> >> > With those issues taken together, a user could load up a >>> sedona-core jar >>> >> > (which wouldn't have JTS or org.wololo.geojson) with a different >>> version >>> >> > of JTS potentially provided by another project and be able to use >>> Sedona >>> >> > and other projects together. >>> >> > >>> >> > Thanks for working through the issues to be able to use a release of >>> >> > JTS. Hopefully we can knock this out over the next week, and if >>> not, >>> >> > you do have an approach which would let you release Sedona. >>> >> > >>> >> > Cheers, >>> >> > >>> >> > Jim >>> >> > >>> >> > On 12/10/2020 2:33 PM, Jia Yu wrote: >>> >> > > Hi Jim, >>> >> > > >>> >> > > Thanks for your feedback. >>> >> > > >>> >> > > 1. I indeed asked Mart
Re: First Sedona release
Thanks. but unfortunately, it's not working. I got the prompt for the PGP passphrase at the release:prepare phase. It looks like I don't have permission to push to the Sedona nexus artifactory. I will try to fix that later. On Mon, 21 Dec 2020 at 11:55, Jia Yu wrote: > @Netanel Malka > > Sometimes, if you are using Mac, you need to enter the following in your > terminal before using GPG key to sign an artifact: > https://gist.github.com/jiayuasu/8bab8ecb0234dfc280264fb587fd8b01 > > GPG_TTY=$(tty) > export GPG_TTY > > > > On Mon, Dec 21, 2020 at 1:52 AM Netanel Malka > wrote: > >> Hi Jia, >> I tried to deploy but I got a 401 Unauthorized error, full error: >> https://gist.github.com/netanel246/04c5be423d242a3bb9ef9a300c8817c8 >> >> I created a settings.xml file with my apache user and an encrypted >> password. I also have a GPG key. >> Did you encounter this problem? >> >> >> Thanks, >> Netanel Malka. >> >> >> On Sun, 20 Dec 2020 at 20:12, Netanel Malka wrote: >> >> > That's great!! >> > Hope to try it today. >> > >> > >> > On Fri, 18 Dec 2020 at 10:36, Jia Yu wrote: >> > >> >> Hi Netanel and Paweł, >> >> >> >> The JTS issue has resolved. I am now waiting for JTS 1.18 release but >> we >> >> are currently using 1.17.1 + copied files. So we are good anyway. >> >> >> >> So the next step will be documentation and stage the first release. >> >> Although I really want to resolve the ST_Transform lock contention >> issue, >> >> it requires a new ST_FlipCoordinate which may take a few days. I will >> see >> >> whether I can finish this by Christmas but not sure. >> >> >> >> @Netanel Malka Could you please compile the >> master >> >> branch and try to deploy a SNAPSHOT release on your own? I have pushed >> a >> >> few snapshots but I would like to see whether you can do it too. Please >> >> follow the steps here: >> >> https://gist.github.com/jiayuasu/849e1f3bf7a2dd11593ca27c14e9e92d >> >> >> >> @Paweł Kociński Step 1. Could you please >> >> update >> >> the new Python Adaptor documentation? Step 2. Could you please try to >> >> deploy a SNAPSHOT release to PyPI? You can find some help here: >> >> https://incubator.apache.org/guides/distribution.html >> >> >> >> Thank you very much! >> >> Jia >> >> >> >> >> >> On Thu, Dec 10, 2020 at 3:26 PM Jim Hughes wrote: >> >> >> >> > Hi Jia, >> >> > >> >> > A JTS 1.18.0 release would not be just for Apache Sedona.;) Getting >> it >> >> > out sooner would let others projects adopt it sooner (I'm thinking of >> >> > GeoTools and GeoServer). I'm excited to see the improvements to the >> >> > overlay operations... >> >> > >> >> > I've traded some emails and chats with Martin. It sounds like he is >> ok >> >> > with cutting JTS 1.18.0 in the next week; I'll be working with him >> and >> >> > Jody to do our best to make that happen. >> >> > >> >> > Anyhow, in terms of shading, there are few things I'd suggest. First, >> >> > I'd suggest that libraries which can function as libraries have a >> >> > version of the jar which does not include any dependencies. If you >> go >> >> > along with that, sedona-core should produce a jar on its own and >> another >> >> > module could build a "batteries included" jar for users to drop into >> >> Spark. >> >> > >> >> > Separate from that, I'd recommend that when you copy entire files >> into a >> >> > project that you change the package for those classes. Concretely, >> you >> >> > could just prepend org.apache.sedona to the package names for those 5 >> >> > classes. (This assumes that it is possible. Sometimes there may be >> >> > issues around package protected access, etc.) >> >> > >> >> > As it stands right now, if a user tries to use Sedona with any other >> >> > library that pulls in JTS, then they will be at the mercy of the >> class >> >> > loading order. If the JTS jar comes in elsewhere, your versions of >> the >> >> > RTree may not be loaded! The exception would look like a JTS issue >> and >> >> > it be fairly confusing for most people to debug. >> >> > >> >> > With those issues taken together, a user could load up a sedona-core >> jar >> >> > (which wouldn't have JTS or org.wololo.geojson) with a different >> version >> >> > of JTS potentially provided by another project and be able to use >> Sedona >> >> > and other projects together. >> >> > >> >> > Thanks for working through the issues to be able to use a release of >> >> > JTS. Hopefully we can knock this out over the next week, and if not, >> >> > you do have an approach which would let you release Sedona. >> >> > >> >> > Cheers, >> >> > >> >> > Jim >> >> > >> >> > On 12/10/2020 2:33 PM, Jia Yu wrote: >> >> > > Hi Jim, >> >> > > >> >> > > Thanks for your feedback. >> >> > > >> >> > > 1. I indeed asked Martin, Jody, and you in the JTS Gitter chat. It >> >> looks >> >> > > like Martin still needs some time to fix some functions. In fact, I >> >> feel >> >> > it >> >> > > is inappropriate to push Martin, an OSS contributor, to draw a >> release >> >> > just >>
Re: First Sedona release
@Netanel Malka Sometimes, if you are using Mac, you need to enter the following in your terminal before using GPG key to sign an artifact: https://gist.github.com/jiayuasu/8bab8ecb0234dfc280264fb587fd8b01 GPG_TTY=$(tty) export GPG_TTY On Mon, Dec 21, 2020 at 1:52 AM Netanel Malka wrote: > Hi Jia, > I tried to deploy but I got a 401 Unauthorized error, full error: > https://gist.github.com/netanel246/04c5be423d242a3bb9ef9a300c8817c8 > > I created a settings.xml file with my apache user and an encrypted > password. I also have a GPG key. > Did you encounter this problem? > > > Thanks, > Netanel Malka. > > > On Sun, 20 Dec 2020 at 20:12, Netanel Malka wrote: > > > That's great!! > > Hope to try it today. > > > > > > On Fri, 18 Dec 2020 at 10:36, Jia Yu wrote: > > > >> Hi Netanel and Paweł, > >> > >> The JTS issue has resolved. I am now waiting for JTS 1.18 release but we > >> are currently using 1.17.1 + copied files. So we are good anyway. > >> > >> So the next step will be documentation and stage the first release. > >> Although I really want to resolve the ST_Transform lock contention > issue, > >> it requires a new ST_FlipCoordinate which may take a few days. I will > see > >> whether I can finish this by Christmas but not sure. > >> > >> @Netanel Malka Could you please compile the > master > >> branch and try to deploy a SNAPSHOT release on your own? I have pushed a > >> few snapshots but I would like to see whether you can do it too. Please > >> follow the steps here: > >> https://gist.github.com/jiayuasu/849e1f3bf7a2dd11593ca27c14e9e92d > >> > >> @Paweł Kociński Step 1. Could you please > >> update > >> the new Python Adaptor documentation? Step 2. Could you please try to > >> deploy a SNAPSHOT release to PyPI? You can find some help here: > >> https://incubator.apache.org/guides/distribution.html > >> > >> Thank you very much! > >> Jia > >> > >> > >> On Thu, Dec 10, 2020 at 3:26 PM Jim Hughes wrote: > >> > >> > Hi Jia, > >> > > >> > A JTS 1.18.0 release would not be just for Apache Sedona.;) Getting it > >> > out sooner would let others projects adopt it sooner (I'm thinking of > >> > GeoTools and GeoServer). I'm excited to see the improvements to the > >> > overlay operations... > >> > > >> > I've traded some emails and chats with Martin. It sounds like he is > ok > >> > with cutting JTS 1.18.0 in the next week; I'll be working with him and > >> > Jody to do our best to make that happen. > >> > > >> > Anyhow, in terms of shading, there are few things I'd suggest. First, > >> > I'd suggest that libraries which can function as libraries have a > >> > version of the jar which does not include any dependencies. If you go > >> > along with that, sedona-core should produce a jar on its own and > another > >> > module could build a "batteries included" jar for users to drop into > >> Spark. > >> > > >> > Separate from that, I'd recommend that when you copy entire files > into a > >> > project that you change the package for those classes. Concretely, you > >> > could just prepend org.apache.sedona to the package names for those 5 > >> > classes. (This assumes that it is possible. Sometimes there may be > >> > issues around package protected access, etc.) > >> > > >> > As it stands right now, if a user tries to use Sedona with any other > >> > library that pulls in JTS, then they will be at the mercy of the class > >> > loading order. If the JTS jar comes in elsewhere, your versions of > the > >> > RTree may not be loaded! The exception would look like a JTS issue > and > >> > it be fairly confusing for most people to debug. > >> > > >> > With those issues taken together, a user could load up a sedona-core > jar > >> > (which wouldn't have JTS or org.wololo.geojson) with a different > version > >> > of JTS potentially provided by another project and be able to use > Sedona > >> > and other projects together. > >> > > >> > Thanks for working through the issues to be able to use a release of > >> > JTS. Hopefully we can knock this out over the next week, and if not, > >> > you do have an approach which would let you release Sedona. > >> > > >> > Cheers, > >> > > >> > Jim > >> > > >> > On 12/10/2020 2:33 PM, Jia Yu wrote: > >> > > Hi Jim, > >> > > > >> > > Thanks for your feedback. > >> > > > >> > > 1. I indeed asked Martin, Jody, and you in the JTS Gitter chat. It > >> looks > >> > > like Martin still needs some time to fix some functions. In fact, I > >> feel > >> > it > >> > > is inappropriate to push Martin, an OSS contributor, to draw a > release > >> > just > >> > > for us :) > >> > > 2. I also saw your comment on the GitHub PR. My current solution in > >> that > >> > PR > >> > > is that use JTS 1.17.1 official release + 5 copied JTS index > classes. > >> I > >> > > also use the maven shade plugin to filter out the 5 corresponding > >> classes > >> > > in JTS 1.17.1 jar ( > >> > > > >> > > >> > https://github.com/apache/incubator-sedona/pull/495/files#diff-9c5fb3d1b7e3b0f54bc5c4182965
Re: First Sedona release
Hi Jia, I tried to deploy but I got a 401 Unauthorized error, full error: https://gist.github.com/netanel246/04c5be423d242a3bb9ef9a300c8817c8 I created a settings.xml file with my apache user and an encrypted password. I also have a GPG key. Did you encounter this problem? Thanks, Netanel Malka. On Sun, 20 Dec 2020 at 20:12, Netanel Malka wrote: > That's great!! > Hope to try it today. > > > On Fri, 18 Dec 2020 at 10:36, Jia Yu wrote: > >> Hi Netanel and Paweł, >> >> The JTS issue has resolved. I am now waiting for JTS 1.18 release but we >> are currently using 1.17.1 + copied files. So we are good anyway. >> >> So the next step will be documentation and stage the first release. >> Although I really want to resolve the ST_Transform lock contention issue, >> it requires a new ST_FlipCoordinate which may take a few days. I will see >> whether I can finish this by Christmas but not sure. >> >> @Netanel Malka Could you please compile the master >> branch and try to deploy a SNAPSHOT release on your own? I have pushed a >> few snapshots but I would like to see whether you can do it too. Please >> follow the steps here: >> https://gist.github.com/jiayuasu/849e1f3bf7a2dd11593ca27c14e9e92d >> >> @Paweł Kociński Step 1. Could you please >> update >> the new Python Adaptor documentation? Step 2. Could you please try to >> deploy a SNAPSHOT release to PyPI? You can find some help here: >> https://incubator.apache.org/guides/distribution.html >> >> Thank you very much! >> Jia >> >> >> On Thu, Dec 10, 2020 at 3:26 PM Jim Hughes wrote: >> >> > Hi Jia, >> > >> > A JTS 1.18.0 release would not be just for Apache Sedona.;) Getting it >> > out sooner would let others projects adopt it sooner (I'm thinking of >> > GeoTools and GeoServer). I'm excited to see the improvements to the >> > overlay operations... >> > >> > I've traded some emails and chats with Martin. It sounds like he is ok >> > with cutting JTS 1.18.0 in the next week; I'll be working with him and >> > Jody to do our best to make that happen. >> > >> > Anyhow, in terms of shading, there are few things I'd suggest. First, >> > I'd suggest that libraries which can function as libraries have a >> > version of the jar which does not include any dependencies. If you go >> > along with that, sedona-core should produce a jar on its own and another >> > module could build a "batteries included" jar for users to drop into >> Spark. >> > >> > Separate from that, I'd recommend that when you copy entire files into a >> > project that you change the package for those classes. Concretely, you >> > could just prepend org.apache.sedona to the package names for those 5 >> > classes. (This assumes that it is possible. Sometimes there may be >> > issues around package protected access, etc.) >> > >> > As it stands right now, if a user tries to use Sedona with any other >> > library that pulls in JTS, then they will be at the mercy of the class >> > loading order. If the JTS jar comes in elsewhere, your versions of the >> > RTree may not be loaded! The exception would look like a JTS issue and >> > it be fairly confusing for most people to debug. >> > >> > With those issues taken together, a user could load up a sedona-core jar >> > (which wouldn't have JTS or org.wololo.geojson) with a different version >> > of JTS potentially provided by another project and be able to use Sedona >> > and other projects together. >> > >> > Thanks for working through the issues to be able to use a release of >> > JTS. Hopefully we can knock this out over the next week, and if not, >> > you do have an approach which would let you release Sedona. >> > >> > Cheers, >> > >> > Jim >> > >> > On 12/10/2020 2:33 PM, Jia Yu wrote: >> > > Hi Jim, >> > > >> > > Thanks for your feedback. >> > > >> > > 1. I indeed asked Martin, Jody, and you in the JTS Gitter chat. It >> looks >> > > like Martin still needs some time to fix some functions. In fact, I >> feel >> > it >> > > is inappropriate to push Martin, an OSS contributor, to draw a release >> > just >> > > for us :) >> > > 2. I also saw your comment on the GitHub PR. My current solution in >> that >> > PR >> > > is that use JTS 1.17.1 official release + 5 copied JTS index classes. >> I >> > > also use the maven shade plugin to filter out the 5 corresponding >> classes >> > > in JTS 1.17.1 jar ( >> > > >> > >> https://github.com/apache/incubator-sedona/pull/495/files#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R278 >> > ) >> > > to avoid duplicates . Do you think I should even use the shade plugin >> to >> > > relocate these classes to a different path? >> > > >> > > Thanks, >> > > Jia >> > > >> > > On Thu, Dec 10, 2020 at 6:25 AM Jim Hughes wrote: >> > > >> > >> Hi all, >> > >> >> > >> It may be worth discussing with the JTS directly what their schedule >> is >> > >> rather than guessing at it. >> > >> >> > >> I am for finding a way for Sedona to work with JTS with the least >> > >> friction for the Sedona develo
Re: First Sedona release
I should finish documentation update today/tomorrow (with notebooks also). Regards, Paweł niedz., 20 gru 2020 o 19:12 Netanel Malka napisał(a): > That's great!! > Hope to try it today. > > > On Fri, 18 Dec 2020 at 10:36, Jia Yu wrote: > >> Hi Netanel and Paweł, >> >> The JTS issue has resolved. I am now waiting for JTS 1.18 release but we >> are currently using 1.17.1 + copied files. So we are good anyway. >> >> So the next step will be documentation and stage the first release. >> Although I really want to resolve the ST_Transform lock contention issue, >> it requires a new ST_FlipCoordinate which may take a few days. I will see >> whether I can finish this by Christmas but not sure. >> >> @Netanel Malka Could you please compile the master >> branch and try to deploy a SNAPSHOT release on your own? I have pushed a >> few snapshots but I would like to see whether you can do it too. Please >> follow the steps here: >> https://gist.github.com/jiayuasu/849e1f3bf7a2dd11593ca27c14e9e92d >> >> @Paweł Kociński Step 1. Could you please >> update >> the new Python Adaptor documentation? Step 2. Could you please try to >> deploy a SNAPSHOT release to PyPI? You can find some help here: >> https://incubator.apache.org/guides/distribution.html >> >> Thank you very much! >> Jia >> >> >> On Thu, Dec 10, 2020 at 3:26 PM Jim Hughes wrote: >> >> > Hi Jia, >> > >> > A JTS 1.18.0 release would not be just for Apache Sedona.;) Getting it >> > out sooner would let others projects adopt it sooner (I'm thinking of >> > GeoTools and GeoServer). I'm excited to see the improvements to the >> > overlay operations... >> > >> > I've traded some emails and chats with Martin. It sounds like he is ok >> > with cutting JTS 1.18.0 in the next week; I'll be working with him and >> > Jody to do our best to make that happen. >> > >> > Anyhow, in terms of shading, there are few things I'd suggest. First, >> > I'd suggest that libraries which can function as libraries have a >> > version of the jar which does not include any dependencies. If you go >> > along with that, sedona-core should produce a jar on its own and another >> > module could build a "batteries included" jar for users to drop into >> Spark. >> > >> > Separate from that, I'd recommend that when you copy entire files into a >> > project that you change the package for those classes. Concretely, you >> > could just prepend org.apache.sedona to the package names for those 5 >> > classes. (This assumes that it is possible. Sometimes there may be >> > issues around package protected access, etc.) >> > >> > As it stands right now, if a user tries to use Sedona with any other >> > library that pulls in JTS, then they will be at the mercy of the class >> > loading order. If the JTS jar comes in elsewhere, your versions of the >> > RTree may not be loaded! The exception would look like a JTS issue and >> > it be fairly confusing for most people to debug. >> > >> > With those issues taken together, a user could load up a sedona-core jar >> > (which wouldn't have JTS or org.wololo.geojson) with a different version >> > of JTS potentially provided by another project and be able to use Sedona >> > and other projects together. >> > >> > Thanks for working through the issues to be able to use a release of >> > JTS. Hopefully we can knock this out over the next week, and if not, >> > you do have an approach which would let you release Sedona. >> > >> > Cheers, >> > >> > Jim >> > >> > On 12/10/2020 2:33 PM, Jia Yu wrote: >> > > Hi Jim, >> > > >> > > Thanks for your feedback. >> > > >> > > 1. I indeed asked Martin, Jody, and you in the JTS Gitter chat. It >> looks >> > > like Martin still needs some time to fix some functions. In fact, I >> feel >> > it >> > > is inappropriate to push Martin, an OSS contributor, to draw a release >> > just >> > > for us :) >> > > 2. I also saw your comment on the GitHub PR. My current solution in >> that >> > PR >> > > is that use JTS 1.17.1 official release + 5 copied JTS index classes. >> I >> > > also use the maven shade plugin to filter out the 5 corresponding >> classes >> > > in JTS 1.17.1 jar ( >> > > >> > >> https://github.com/apache/incubator-sedona/pull/495/files#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R278 >> > ) >> > > to avoid duplicates . Do you think I should even use the shade plugin >> to >> > > relocate these classes to a different path? >> > > >> > > Thanks, >> > > Jia >> > > >> > > On Thu, Dec 10, 2020 at 6:25 AM Jim Hughes wrote: >> > > >> > >> Hi all, >> > >> >> > >> It may be worth discussing with the JTS directly what their schedule >> is >> > >> rather than guessing at it. >> > >> >> > >> I am for finding a way for Sedona to work with JTS with the least >> > >> friction for the Sedona development team and the Sedona users. I >> feel >> > >> that copying or forking complex codebases will likely lead to bigger >> > >> issues downstream. >> > >> >> > >> Also, is the only hang-up around the seriali
