You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add support for tables to apply and applyreduce (#91)
* Add support for tables to `apply`
* Fix the `reproject` implementation to use constructed traits
* Fix error when testing `threaded`
* Comment, fix indentation in apply
* Implement applyreduce
* document in readme and docs that tables are supported
* Add DataFrames and Shapefile to project and docs/project
* Remove unused function
Co-authored-by: Rafael Schouten <[email protected]>
* Add some truly wacko tests
* Fix test
* `_to_table` -> `_table`
* Annotate that `_is3d` only returns bools
Apparently this was not obvious to the compiler
* Don't be lazy when getting names
this promotes type stability and I guess we don't care about allocs anyway.
---------
Co-authored-by: Rafael Schouten <[email protected]>
Copy file name to clipboardExpand all lines: docs/src/introduction.md
+2Lines changed: 2 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -20,6 +20,8 @@ The `apply` function allows you to decompose a given collection of geometries do
20
20
21
21
Functionally, it's similar to `map` in the way you apply it to geometries.
22
22
23
+
`apply` and `applyreduce` take any geometry, vector of geometries, collection of geometries, or table (like `Shapefile.Table`, `DataFrame`, or `GeoTable`)!
24
+
23
25
### What's this `GeoInterface.Wrapper` thing?
24
26
25
27
Write a comment about GeoInterface.Wrapper and why it helps in type stability to guarantee a particular return type.
0 commit comments