Thank you for checking and sharing, Hyukjin. :)
Dongjoon.
On Mon, Jan 16, 2023 at 4:37 PM Hyukjin Kwon wrote:
> Hi all,
>
> AppVeyor is currently broken assuming the flaky Github authorization issue
> (
> https://help.appveyor.com/discussions/problems/11287-the-build-phase-is-set-to-msbuild-mod
Hey folks,
Traditionally GIS functionality is distributed a bit separately - i.e.
PostGIS is a great example; and indeed for GIS needs Sedona / GeoMesa /
GeoWave may work out; I think GeoMesa implements GeoHash (see
https://www.geomesa.org/documentation/stable/user/spark/sparksql_functions.html
-
Hi all,
AppVeyor is currently broken assuming the flaky Github authorization issue (
https://help.appveyor.com/discussions/problems/11287-the-build-phase-is-set-to-msbuild-mode-default-but-no-visual-studio-project-or-solution-files-were-found
).
AppVeyor build is specific to SparkR (on WIndows) s
Martin, thanks for chiming in and mentioning Apache SIS. However, Mark was
asking about Geo in Spark, which Sedona already supports.
Yet, I like the idea of making all dependencies within the Apache family. I
believe a good solution would be for you (or the SIS community at large) to
include A
Hello Mark
Indeed Sedona is surely a serious candidate. Maybe one aspect to take in
consideration, depending how "core" the geospatial services would be, is that
Sedona depends on a LGPL library (GeoTools, bundled separately) for map
projections, Shapefile and GeoTIFF support. So those features
Mark,
There is already another Apache project (namely Apache Sedona) that provides
comprehensive support of geospatial operations in Spark. Please check it out:
Github: https://github.com/apache/sedona
Website: https://sedona.apache.org
Please feel free to contribute more geospatial functions t