OSGeos LocationTech owns GeoTools. I am thinking whether I should have my
wrapper on Maven Central to bring those Sedona required GeoTools jars to
Maven Central. Since it is LGPL, it might be OK to do so.
On Thu, Feb 11, 2021 at 5:18 PM Felix Cheung wrote:
> Who owns or manages GeoTools if it
Who owns or manages GeoTools if it is LGPL?
On Thu, Feb 11, 2021 at 12:01 PM Jia Yu wrote:
> Pawel,
>
> Python-adapter module is always being used by users. But it does not come
> with GeoTools. To use it, users have to (1) compile the source code of
> Python-adapter, or (2) add GeoTools
Pawel,
Python-adapter module is always being used by users. But it does not come
with GeoTools. To use it, users have to (1) compile the source code of
Python-adapter, or (2) add GeoTools coordiantes from OSGEO repo via
config(""), or (3) download and copy GeoTools jars to SPARK_HOME/jars/
The
Hi Gregory,
Can you please try to install the jars on the Databricks Cluster?
For example:
On clusters -> choose your cluster -> libraries -> install new:
1.Coordinates: org.geotools:gt-main:24.0
2.repo: https://repo.osgeo.org/repository/release/
I successfully did it.
Please let me know if
I think that we can make it work on Databricks without any changes.
After creating a cluster on Databricks, the user can install the geotools
packages and provide the osego *(or any other repo) explicitly.*
As you can see in the picture:
[image: image.png]
I can provide the details on how to
Hi folks,
As you can see from the recent discussion in the mailing list
<[Bug][Python] Missing Java class>, in Sedona 1.0.0, because those LGPL
GeoTools jars are not on Maven Central (only in OSGEO repo), Databricks
cannot get GeoTools jars.
I believe this will cause lots of trouble to our
Honestly, not the worst thing I had to compile on Windows. Aside from the
Javadoc step and that weird issue with the dynamic versioning, it went
pretty smoothly; it just took a while because every try was taking a fair
bit of time.
I'll keep an eye on further announcements to see what comes next!
Thanks for letting us know. Yes, our source code is not supposed to be
compiled on Windows. I didn't expect so much trouble to get this jar. We
will figure a better way to solve this issue soon.
On Thu, Feb 11, 2021 at 1:46 AM Grégory Dugernier wrote:
> In fact, you should let us know about
>
> In fact, you should let us know about your situation early on. In fact,
> you can download the GeoTools jars manually and copy to SPARK_HOME/jars/
> folder... You don't have to compile the code. Download links are given in
> the comments:
>
Thanks, Gregory. I think this behavior is not expected. We will look into
this.
In fact, you should let us know about your situation early on. In fact, you
can download the GeoTools jars manually and copy to SPARK_HOME/jars/
folder... You don't have to compile the code. Download links are given
Hi Jia,
After much sweat and tears, I went the long road and compiled the code
locally. I'm working on Windows so I had to change a few things in the
POM.xml:
- When trying to compile just the python-adapter lib, Maven didn't like
the dynamic versioning of sedona-core and sedona-sql, so I
11 matches
Mail list logo
