[GitHub] [sedona] jiayuasu opened a new pull request, #746: [SEDONA-230] rdd.saveAsGeoJSON should generate feature properties with field names

2023-01-05 Thread GitBox


jiayuasu opened a new pull request, #746:
URL: https://github.com/apache/sedona/pull/746

   
   ## Did you read the Contributor Guide?
   
   - Yes, I have read [Contributor 
Rules](https://sedona.apache.org/community/rule/) and [Contributor Development 
Guide](https://sedona.apache.org/community/develop/)
   
   ## Is this PR related to a JIRA ticket?
   
   - Yes, the URL of the assoicated JIRA ticket is 
https://issues.apache.org/jira/browse/SEDONA-230. The PR name follows the 
format `[SEDONA-230] my subject`.
   
   
   ## What changes were proposed in this PR?
   
   1. SpatialRdd that has fields will be saved as a geojson that has correct 
property keys and values for each record.
   2. Null field value will be saved as empty space. E.g.,
   ```
   "properties": {"name": ""}
   ```
   3. SpatialRdd that has no fields will be save as
   ```
   "properties": null
   ```
   
   ## How was this patch tested?
   
   Add a few more tests and passed existing tests
   
   ## Did this PR include necessary documentation updates?
   
   - No, this PR does not affect any public API so no need to change the docs.
   


-- 
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.

To unsubscribe, e-mail: dev-unsubscr...@sedona.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[jira] [Commented] (SEDONA-229) Linter Messages in Build Log

2023-01-05 Thread Jia Yu (Jira)


[ 
https://issues.apache.org/jira/browse/SEDONA-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17655256#comment-17655256
 ] 

Jia Yu commented on SEDONA-229:
---

[~dougdennis] Yes, I 100% support this!

> Linter Messages in Build Log
> 
>
> Key: SEDONA-229
> URL: https://issues.apache.org/jira/browse/SEDONA-229
> Project: Apache Sedona
>  Issue Type: Improvement
>Reporter: Doug Dennis
>Priority: Major
>
> The build log gets pretty filled up with linter messages (especially in 
> sedona-sql). I found it hard to track down the reason for a failed build 
> because it was hidden inside of all of the other gobbledygook. Would you be 
> open to a PR that addressed these? Or at least most of them?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (SEDONA-230) rdd.saveAsGeoJSON should generate feature properties with field names

2023-01-05 Thread Jia Yu (Jira)
Jia Yu created SEDONA-230:
-

 Summary: rdd.saveAsGeoJSON should generate feature properties with 
field names
 Key: SEDONA-230
 URL: https://issues.apache.org/jira/browse/SEDONA-230
 Project: Apache Sedona
  Issue Type: Improvement
Reporter: Jia Yu


spatialRdd.saveAsGeoJSON in Sedona on or before 1.3.1 generates GeoJSON in the 
follow format

Line1: \{type":"Feature","geometry": XXX, "properties": {"userdata: """}}

Line2: \{type":"Feature","geometry": XXX, "properties": {"userdata: """}}

Line3: \{type":"Feature","geometry": XXX, "properties": {"userdata: """}}

 

The field names in the original SpatialRDD is lost.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[GitHub] [sedona] jiayuasu merged pull request #742: [SEDONA-223] Add ST_Split

2023-01-05 Thread GitBox


jiayuasu merged PR #742:
URL: https://github.com/apache/sedona/pull/742


-- 
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.

To unsubscribe, e-mail: dev-unsubscr...@sedona.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [sedona] jiayuasu commented on pull request #742: [SEDONA-223] Add ST_Split

2023-01-05 Thread GitBox


jiayuasu commented on PR #742:
URL: https://github.com/apache/sedona/pull/742#issuecomment-1373023036

   Awesome. Will merge.


-- 
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.

To unsubscribe, e-mail: dev-unsubscr...@sedona.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



Re: JoinQueryRaw.SpatialJoinQueryFlat for polygon - linestring join?

2023-01-05 Thread Jia Yu
And, I believe you should be able to post things directly if you join the
Sedona community server.

On Thu, Jan 5, 2023 at 4:44 PM Jia Yu  wrote:

> Hi Mark,
>
> Sedona supports polygon-linestring joins. Did you set
> 'ConsiderBoundaryIntersection' to true? See:
> https://sedona.apache.org/1.3.1-incubating/tutorial/core-python/#write-a-spatial-join-query
>
> This is the last parameter in Sedona Python
> JoinQueryRaw.SpatialJoinQueryFlat().
>
> Thanks,
> Jia
>
> -- Forwarded message -
> From: Mark Broich 
> Date: Thu, Jan 5, 2023 at 4:27 PM
> Subject: JoinQueryRaw.SpatialJoinQueryFlat for polygon - linestring join?
> To: 
> Cc: 
>
>
> Hi all,
>
> I am trying to use JoinQueryRaw.SpatialJoinQueryFlat() to join polygons
> and linestrings but the result is empty despite overlap in the polygons and
> linestrings.
>
> I am wondering if JoinQueryRaw.SpatialJoinQueryFlat can do the join I am
> after or if I need to do a RangeQuery.SpatialRangeQuery().
>
> Also, how do I get posting rights on the Apache Sedona community server
> ?
>
> Tnx for any pointers. Regards, Mark
>


Fwd: JoinQueryRaw.SpatialJoinQueryFlat for polygon - linestring join?

2023-01-05 Thread Jia Yu
Hi Mark,

Sedona supports polygon-linestring joins. Did you set
'ConsiderBoundaryIntersection' to true? See:
https://sedona.apache.org/1.3.1-incubating/tutorial/core-python/#write-a-spatial-join-query

This is the last parameter in Sedona Python
JoinQueryRaw.SpatialJoinQueryFlat().

Thanks,
Jia

-- Forwarded message -
From: Mark Broich 
Date: Thu, Jan 5, 2023 at 4:27 PM
Subject: JoinQueryRaw.SpatialJoinQueryFlat for polygon - linestring join?
To: 
Cc: 


Hi all,

I am trying to use JoinQueryRaw.SpatialJoinQueryFlat() to join polygons and
linestrings but the result is empty despite overlap in the polygons and
linestrings.

I am wondering if JoinQueryRaw.SpatialJoinQueryFlat can do the join I am
after or if I need to do a RangeQuery.SpatialRangeQuery().

Also, how do I get posting rights on the Apache Sedona community server
?

Tnx for any pointers. Regards, Mark


[GitHub] [sedona] Kimahriman commented on a diff in pull request #742: [SEDONA-223] Add ST_Split

2023-01-05 Thread GitBox


Kimahriman commented on code in PR #742:
URL: https://github.com/apache/sedona/pull/742#discussion_r1062985739


##
common/src/main/java/org/apache/sedona/common/utils/GeometrySplitter.java:
##
@@ -0,0 +1,331 @@
+/**
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ * 
+ * http://www.apache.org/licenses/LICENSE-2.0
+ * 
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.sedona.common.utils;
+
+import java.util.ArrayDeque;
+import java.util.ArrayList;
+import java.util.Arrays;
+import java.util.Deque;
+import java.util.Iterator;
+import java.util.List;
+
+import org.apache.log4j.Logger;
+import org.locationtech.jts.geom.Coordinate;
+import org.locationtech.jts.geom.Geometry;
+import org.locationtech.jts.geom.GeometryCollection;
+import org.locationtech.jts.geom.GeometryFactory;
+import org.locationtech.jts.geom.LineString;
+import org.locationtech.jts.geom.MultiLineString;
+import org.locationtech.jts.geom.MultiPoint;
+import org.locationtech.jts.geom.MultiPolygon;
+import org.locationtech.jts.geom.Point;
+import org.locationtech.jts.geom.Polygon;
+import org.locationtech.jts.linearref.LinearGeometryBuilder;
+import org.locationtech.jts.operation.polygonize.Polygonizer;
+
+
+/**
+ * Class to split geometry by other geometry.
+ */
+public final class GeometrySplitter {
+private final GeometryFactory geometryFactory;
+
+public GeometrySplitter(GeometryFactory geometryFactory) {
+this.geometryFactory = geometryFactory;
+}
+
+/**
+ * Split input geometry by the blade geometry.
+ * Input geometry can be lineal (LineString or MultiLineString)
+ * or polygonal (Polygon or MultiPolygon). A GeometryCollection
+ * can also be used as an input but it must be homogeneous.
+ * For lineal geometry refer to the
+ * {@link splitLines(Geometry, Geometry) splitLines} method for
+ * restrictions on the blade. Refer to
+ * {@link splitPolygons(Geometry, Geometry) splitPolygons} for
+ * restrictions on the blade for polygonal input geometry.
+ * 
+ * The result will be null if the input geometry and blade are either
+ * invalid in general or in relation to eachother. Otherwise, the result
+ * will always be a MultiLineString or MultiPolygon depending on the input,
+ * and even if the result is a single geometry.
+ *
+ * @param  input input geometry
+ * @param  blade geometry to use as a blade
+ * @return   multi-geometry resulting from the split or null if invalid
+ */
+public GeometryCollection split(Geometry input, Geometry blade) {
+GeometryCollection result = null;
+
+if (GeomUtils.geometryIsLineal(input)) {
+result = splitLines(input, blade);
+} else if (GeomUtils.geometryIsPolygonal(input)) {
+result = splitPolygons(input, blade);
+}
+
+return result;
+}
+
+/**
+ * Split linear input geometry by the blade geometry.
+ * Input geometry is assumed to be either a LineString,
+ * MultiLineString, or a homogeneous collection of lines in a
+ * GeometryCollection. The blade geometry can be any indivdual
+ * puntal, lineal, or polygonal geometry or homogeneous collection
+ * of those geometries. Blades that are polygonal will use their
+ * boundary for the split. Will always return a MultiLineString.
+ *
+ * @param  input input geometry to be split that must be lineal
+ * @param  blade blade geometry to use for split
+ *
+ * @return   input geometry split by blade
+ */
+public MultiLineString splitLines(Geometry input, Geometry blade) {
+MultiLineString result = null;
+
+if (GeomUtils.geometryIsPolygonal(blade)) {
+blade = blade.getBoundary();
+}
+
+if (GeomUtils.geometryIsPuntal(blade)) {
+result = splitLinesByPoints(input, blade);
+} else if (GeomUtils.geometryIsLineal(blade)) {
+result = splitLinesByLines(input, blade);
+}
+
+return result;
+}
+
+/**
+ * Split polygonal input geometry by the blade geometry.
+ * Input geometry is assumed to be either a Polygon, MultiPolygon,
+ * or a GeometryCollection of only polygons. The blade geometry
+ * can be any individual lineal or polygonal geometry or homogeneous
+ * collection of those geometries. Blades that are polygonal
+ * will use their boundary for the split. Will always return a
+ * MultiPolygon.
+ *
+ * @param  input input polygonal geometry to split
+ * 

[GitHub] [sedona] neontty commented on pull request #744: [SEDONA-156] Support spatial filter push-down for GeoParquetFileFormat

2023-01-05 Thread GitBox


neontty commented on PR #744:
URL: https://github.com/apache/sedona/pull/744#issuecomment-1372809028

   @Kontinuation your code is so clean! Thank you for putting in this work.


-- 
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.

To unsubscribe, e-mail: dev-unsubscr...@sedona.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [sedona] jiayuasu commented on pull request #745: [SEDONA-227] Python Serde Refactor

2023-01-05 Thread GitBox


jiayuasu commented on PR #745:
URL: https://github.com/apache/sedona/pull/745#issuecomment-1372700871

   @Kontinuation @Imbruced Please feel free to chime in with comments :-)


-- 
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.

To unsubscribe, e-mail: dev-unsubscr...@sedona.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [sedona] jiayuasu commented on pull request #743: [SEDONA-228] Standardize logging modules

2023-01-05 Thread GitBox


jiayuasu commented on PR #743:
URL: https://github.com/apache/sedona/pull/743#issuecomment-1372632857

   Great explanation! Thank you!


-- 
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.

To unsubscribe, e-mail: dev-unsubscr...@sedona.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[jira] [Commented] (SEDONA-156) predicate pushdown support for GeoParquet

2023-01-05 Thread RJ Marcus (Jira)


[ 
https://issues.apache.org/jira/browse/SEDONA-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17655105#comment-17655105
 ] 

RJ Marcus commented on SEDONA-156:
--

Jia is correct; my work schedule was reprioritized and I'm not currently 
working on it. 

For context, the road I was going down seemed like it would require significant 
changes upstream in Spark to allow Data Sources to push down V2 `Predicates` 
instead of `Filters` since our predicate is "postgresql" syntax instead of just 
sql. The large amount of upstream changes required became a significant 
roadblock for me in terms of time. 

It sounds like you have a simpler implementation, [~Kontinuation] , which is 
good in my opinion. If you are interested in the method I was trying, please 
reach out. 

> predicate pushdown support for GeoParquet
> -
>
> Key: SEDONA-156
> URL: https://issues.apache.org/jira/browse/SEDONA-156
> Project: Apache Sedona
>  Issue Type: New Feature
>Reporter: RJ Marcus
>Assignee: Kristin Cowalcijk
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Support for filter predicate for the new GeoParquet reader. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[GitHub] [sedona] douglasdennis commented on a diff in pull request #742: [SEDONA-223] Add ST_Split

2023-01-05 Thread GitBox


douglasdennis commented on code in PR #742:
URL: https://github.com/apache/sedona/pull/742#discussion_r1062589421


##
common/src/main/java/org/apache/sedona/common/utils/GeometrySplitter.java:
##
@@ -0,0 +1,331 @@
+/**
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ * 
+ * http://www.apache.org/licenses/LICENSE-2.0
+ * 
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.sedona.common.utils;
+
+import java.util.ArrayDeque;
+import java.util.ArrayList;
+import java.util.Arrays;
+import java.util.Deque;
+import java.util.Iterator;
+import java.util.List;
+
+import org.apache.log4j.Logger;
+import org.locationtech.jts.geom.Coordinate;
+import org.locationtech.jts.geom.Geometry;
+import org.locationtech.jts.geom.GeometryCollection;
+import org.locationtech.jts.geom.GeometryFactory;
+import org.locationtech.jts.geom.LineString;
+import org.locationtech.jts.geom.MultiLineString;
+import org.locationtech.jts.geom.MultiPoint;
+import org.locationtech.jts.geom.MultiPolygon;
+import org.locationtech.jts.geom.Point;
+import org.locationtech.jts.geom.Polygon;
+import org.locationtech.jts.linearref.LinearGeometryBuilder;
+import org.locationtech.jts.operation.polygonize.Polygonizer;
+
+
+/**
+ * Class to split geometry by other geometry.
+ */
+public final class GeometrySplitter {
+private final GeometryFactory geometryFactory;
+
+public GeometrySplitter(GeometryFactory geometryFactory) {
+this.geometryFactory = geometryFactory;
+}
+
+/**
+ * Split input geometry by the blade geometry.
+ * Input geometry can be lineal (LineString or MultiLineString)
+ * or polygonal (Polygon or MultiPolygon). A GeometryCollection
+ * can also be used as an input but it must be homogeneous.
+ * For lineal geometry refer to the
+ * {@link splitLines(Geometry, Geometry) splitLines} method for
+ * restrictions on the blade. Refer to
+ * {@link splitPolygons(Geometry, Geometry) splitPolygons} for
+ * restrictions on the blade for polygonal input geometry.
+ * 
+ * The result will be null if the input geometry and blade are either
+ * invalid in general or in relation to eachother. Otherwise, the result
+ * will always be a MultiLineString or MultiPolygon depending on the input,
+ * and even if the result is a single geometry.
+ *
+ * @param  input input geometry
+ * @param  blade geometry to use as a blade
+ * @return   multi-geometry resulting from the split or null if invalid
+ */
+public GeometryCollection split(Geometry input, Geometry blade) {
+GeometryCollection result = null;
+
+if (GeomUtils.geometryIsLineal(input)) {
+result = splitLines(input, blade);
+} else if (GeomUtils.geometryIsPolygonal(input)) {
+result = splitPolygons(input, blade);
+}
+
+return result;
+}
+
+/**
+ * Split linear input geometry by the blade geometry.
+ * Input geometry is assumed to be either a LineString,
+ * MultiLineString, or a homogeneous collection of lines in a
+ * GeometryCollection. The blade geometry can be any indivdual
+ * puntal, lineal, or polygonal geometry or homogeneous collection
+ * of those geometries. Blades that are polygonal will use their
+ * boundary for the split. Will always return a MultiLineString.
+ *
+ * @param  input input geometry to be split that must be lineal
+ * @param  blade blade geometry to use for split
+ *
+ * @return   input geometry split by blade
+ */
+public MultiLineString splitLines(Geometry input, Geometry blade) {
+MultiLineString result = null;
+
+if (GeomUtils.geometryIsPolygonal(blade)) {
+blade = blade.getBoundary();
+}
+
+if (GeomUtils.geometryIsPuntal(blade)) {
+result = splitLinesByPoints(input, blade);
+} else if (GeomUtils.geometryIsLineal(blade)) {
+result = splitLinesByLines(input, blade);
+}
+
+return result;
+}
+
+/**
+ * Split polygonal input geometry by the blade geometry.
+ * Input geometry is assumed to be either a Polygon, MultiPolygon,
+ * or a GeometryCollection of only polygons. The blade geometry
+ * can be any individual lineal or polygonal geometry or homogeneous
+ * collection of those geometries. Blades that are polygonal
+ * will use their boundary for the split. Will always return a
+ * MultiPolygon.
+ *
+ * @param  input input polygonal geometry to split
+ * 

[jira] [Created] (SEDONA-229) Linter Messages in Build Log

2023-01-05 Thread Doug Dennis (Jira)
Doug Dennis created SEDONA-229:
--

 Summary: Linter Messages in Build Log
 Key: SEDONA-229
 URL: https://issues.apache.org/jira/browse/SEDONA-229
 Project: Apache Sedona
  Issue Type: Improvement
Reporter: Doug Dennis


The build log gets pretty filled up with linter messages (especially in 
sedona-sql). I found it hard to track down the reason for a failed build 
because it was hidden inside of all of the other gobbledygook. Would you be 
open to a PR that addressed these? Or at least most of them?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[GitHub] [sedona] Kimahriman commented on a diff in pull request #742: [SEDONA-223] Add ST_Split

2023-01-05 Thread GitBox


Kimahriman commented on code in PR #742:
URL: https://github.com/apache/sedona/pull/742#discussion_r1062394602


##
common/src/main/java/org/apache/sedona/common/utils/GeometrySplitter.java:
##
@@ -0,0 +1,331 @@
+/**
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ * 
+ * http://www.apache.org/licenses/LICENSE-2.0
+ * 
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.sedona.common.utils;
+
+import java.util.ArrayDeque;
+import java.util.ArrayList;
+import java.util.Arrays;
+import java.util.Deque;
+import java.util.Iterator;
+import java.util.List;
+
+import org.apache.log4j.Logger;
+import org.locationtech.jts.geom.Coordinate;
+import org.locationtech.jts.geom.Geometry;
+import org.locationtech.jts.geom.GeometryCollection;
+import org.locationtech.jts.geom.GeometryFactory;
+import org.locationtech.jts.geom.LineString;
+import org.locationtech.jts.geom.MultiLineString;
+import org.locationtech.jts.geom.MultiPoint;
+import org.locationtech.jts.geom.MultiPolygon;
+import org.locationtech.jts.geom.Point;
+import org.locationtech.jts.geom.Polygon;
+import org.locationtech.jts.linearref.LinearGeometryBuilder;
+import org.locationtech.jts.operation.polygonize.Polygonizer;
+
+
+/**
+ * Class to split geometry by other geometry.
+ */
+public final class GeometrySplitter {
+private final GeometryFactory geometryFactory;
+
+public GeometrySplitter(GeometryFactory geometryFactory) {
+this.geometryFactory = geometryFactory;
+}
+
+/**
+ * Split input geometry by the blade geometry.
+ * Input geometry can be lineal (LineString or MultiLineString)
+ * or polygonal (Polygon or MultiPolygon). A GeometryCollection
+ * can also be used as an input but it must be homogeneous.
+ * For lineal geometry refer to the
+ * {@link splitLines(Geometry, Geometry) splitLines} method for
+ * restrictions on the blade. Refer to
+ * {@link splitPolygons(Geometry, Geometry) splitPolygons} for
+ * restrictions on the blade for polygonal input geometry.
+ * 
+ * The result will be null if the input geometry and blade are either
+ * invalid in general or in relation to eachother. Otherwise, the result
+ * will always be a MultiLineString or MultiPolygon depending on the input,
+ * and even if the result is a single geometry.
+ *
+ * @param  input input geometry
+ * @param  blade geometry to use as a blade
+ * @return   multi-geometry resulting from the split or null if invalid
+ */
+public GeometryCollection split(Geometry input, Geometry blade) {
+GeometryCollection result = null;
+
+if (GeomUtils.geometryIsLineal(input)) {
+result = splitLines(input, blade);
+} else if (GeomUtils.geometryIsPolygonal(input)) {
+result = splitPolygons(input, blade);
+}
+
+return result;
+}
+
+/**
+ * Split linear input geometry by the blade geometry.
+ * Input geometry is assumed to be either a LineString,
+ * MultiLineString, or a homogeneous collection of lines in a
+ * GeometryCollection. The blade geometry can be any indivdual
+ * puntal, lineal, or polygonal geometry or homogeneous collection
+ * of those geometries. Blades that are polygonal will use their
+ * boundary for the split. Will always return a MultiLineString.
+ *
+ * @param  input input geometry to be split that must be lineal
+ * @param  blade blade geometry to use for split
+ *
+ * @return   input geometry split by blade
+ */
+public MultiLineString splitLines(Geometry input, Geometry blade) {
+MultiLineString result = null;
+
+if (GeomUtils.geometryIsPolygonal(blade)) {
+blade = blade.getBoundary();
+}
+
+if (GeomUtils.geometryIsPuntal(blade)) {
+result = splitLinesByPoints(input, blade);
+} else if (GeomUtils.geometryIsLineal(blade)) {
+result = splitLinesByLines(input, blade);
+}
+
+return result;
+}
+
+/**
+ * Split polygonal input geometry by the blade geometry.
+ * Input geometry is assumed to be either a Polygon, MultiPolygon,
+ * or a GeometryCollection of only polygons. The blade geometry
+ * can be any individual lineal or polygonal geometry or homogeneous
+ * collection of those geometries. Blades that are polygonal
+ * will use their boundary for the split. Will always return a
+ * MultiPolygon.
+ *
+ * @param  input input polygonal geometry to split
+ * 

[GitHub] [sedona] Kimahriman commented on pull request #743: [SEDONA-228] Standardize logging modules

2023-01-05 Thread GitBox


Kimahriman commented on PR #743:
URL: https://github.com/apache/sedona/pull/743#issuecomment-1372116194

   Do you mean for tests or for real use?
   
   For tests the logs should all go to `target/unit-tests.log`. Copied this 
from Spark so the stdout/err of the tests is less verbose and mostly just shows 
passed/failed tests. Some of the CI test logs were so verbose it's hard to find 
what test actually failed. I think the python tests are still probably pretty 
verbose.
   
   For real use, the logs should keep working exactly as they were 
automatically using the logging frameworks provided by Flink and Spark. If 
someone were to try to use the common module directly without Flink or Spark, 
then they would need to provide their own logging configs. 


-- 
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.

To unsubscribe, e-mail: dev-unsubscr...@sedona.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [sedona] douglasdennis opened a new pull request, #745: [SEDONA-227] Python Serde Refactor

2023-01-05 Thread GitBox


douglasdennis opened a new pull request, #745:
URL: https://github.com/apache/sedona/pull/745

   
   ## Did you read the Contributor Guide?
   
   - Yes, I have read [Contributor 
Rules](https://sedona.apache.org/community/rule/) and [Contributor Development 
Guide](https://sedona.apache.org/community/develop/)
   
   ## Is this PR related to a JIRA ticket?
   
   - Yes, the URL of the associated JIRA ticket is 
https://issues.apache.org/jira/browse/SEDONA-227. The PR name follows the 
format `[SEDONA-XXX] my subject`.
   
   ## What changes were proposed in this PR?
   
   A refactor of some of the python serialization/deserialization functions is 
proposed. This is due to the performance regression experienced from the change 
in serialization formats. Most of the functions were refactored to increase 
performance. Attempts were made to maintain readability of the code at the same 
time.
   
   A significant pain point involves interacting with shapely geometry. Most of 
the shapely methods are too slow and involve repeated calls to native code. 
Once shapely 2.0 is adopted by Sedona and its users, it may be a good idea to 
revisit this code and attempt to utilize some of the libgeos connections that 
shapely exposes.
   
   There are other issues in the current implementation of serde:
   1. Shapely does not respect an M coordinate yet, and so that is not 
supported in python at the moment.
   2. SRID is not supported in python for a similar reason. Part of Sedona's 
python library does add a "userData" field to shapely geometry classes at 
runtime. This could be utilized to store SRIDs and possibly M coordinates.
   3. This PR mostly avoids using the GeometryBuffer class. I don't believe it 
will be the fastest solution in the future. However, I think it's a nice class 
for specifically handling the GeometryCollection type.
   4. Should the serialization format allow for empty geometry within 
collections? They have no WKT representation, so I'm not sure that should be 
allowed.
   
   Finally, here are performance results between current master and this branch:
   ```
   

   # MASTER#  REFACTOR  
  #
   

   short line serialize trial: #short line serialize 
trial:
   Total Time (seconds):   #Total Time 
(seconds):
   Shapely: 3.1197412  #Shapely: 
1.6295438
   Sedona: 7.6139485   #Sedona: 1.624361
   Factor: 1.440570551172642   #Factor: 
-0.00318052205776856
   #
   long line serialize trial:  #long line serialize 
trial:
   Total Time (seconds):   #Total Time 
(seconds):
   Shapely: 4.3532153  #Shapely: 
4.106511
   Sedona: 53.1161724  #Sedona: 
20.2585903
   Factor: 11.201595542494763  #Factor: 
3.9332852876809534
   #
   point serialize trial:  #point serialize trial:
   Total Time (seconds):   #Total Time 
(seconds):
   Shapely: 4.5569092  #Shapely: 
4.1321635
   Sedona: 12.9271814  #Sedona: 
3.6287594
   Factor: 1.8368310257312128  #Factor: 
-0.12182579416327549
   #
   small polygon serialize trial:  #small polygon serialize 
trial:
   Total Time (seconds):   #Total Time 
(seconds):
   Shapely: 1.9922023  #Shapely: 
1.6930909
   Sedona: 15.1673936  #Sedona: 
2.5668217
   Factor: 6.613380227499988   #Factor: 
0.5160566393688608
   #
   large polygon serialize trial:  #large polygon serialize 
trial:
   Total Time (seconds):   #Total Time 
(seconds):
   Shapely: 2.5921638  #Shapely: 
2.3090157
   Sedona: 27.4987078  #Sedona: 
2.8944101
   Factor: 9.608398975404254   #Factor: 
0.25352551738821005
   #
   small multipoint serialize trial:   #small multipoint 
serialize trial:
   Total Time (seconds):   #Total Time 
(seconds):
   Shapely: 0.0964883  

[jira] [Commented] (SEDONA-219) Github checks are failing due to ubuntu version for build 

2023-01-05 Thread awadhesh tanwar (Jira)


[ 
https://issues.apache.org/jira/browse/SEDONA-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17654885#comment-17654885
 ] 

awadhesh tanwar commented on SEDONA-219:


[~jiayu] ST_ConcaveHull builds passes even with the current version.

For now, the builds will only fail on the stated dates in the doc 
https://github.com/actions/runner-images/issues/6002. 

Then will deprecate on April 1st, 2023, as mentioned in the doc. 

 

> Github checks are failing due to ubuntu version for build 
> --
>
> Key: SEDONA-219
> URL: https://issues.apache.org/jira/browse/SEDONA-219
> Project: Apache Sedona
>  Issue Type: Bug
>Reporter: awadhesh tanwar
>Priority: Major
> Attachments: image-2022-12-16-01-52-25-120.png
>
>
> !image-2022-12-16-01-52-25-120.png|width=532,height=244!
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[GitHub] [sedona] douglasdennis commented on pull request #742: [SEDONA-223] Add ST_Split

2023-01-05 Thread GitBox


douglasdennis commented on PR #742:
URL: https://github.com/apache/sedona/pull/742#issuecomment-1371906517

   @jiayuasu  Added it in. Let me know if I was supposed to do it some other 
way. The output I see looks like this:
   `23/01/04 23:52:03 ERROR GeometrySplitter: Colinear sections detected 
between source and blade geometry. Returned null.`


-- 
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.

To unsubscribe, e-mail: dev-unsubscr...@sedona.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org