Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix typos #180

Merged
merged 1 commit into from
Jul 20, 2024
Merged

fix typos #180

merged 1 commit into from
Jul 20, 2024

Conversation

spaette
Copy link
Contributor

@spaette spaette commented Jul 19, 2024

Is the intention geometries' or geometry's here?

$ ed -s GeometryOps.jl/src/methods/geom_relations/disjoint.jl <<<'173,178p'
#= Geometry is disjoint from a linestring if the line's interior and boundary
points don't intersect with the geometrie's interior and boundary points. =#
_disjoint(
    trait1::Union{GI.LinearRingTrait, GI.PolygonTrait}, g1,
    trait2::Union{GI.LineTrait, GI.LineStringTrait}, g2,
) = _disjoint(trait2, g2, trait1, g1)
$ 

The pull has the typo fixed but the wording is a bit awkward here.

$ ed -s GeometryOps.jl/src/methods/area.jl <<<'79p'
This is computed slighly differently for different geometries:
$ 

Copy link
Member

@asinghvi17 asinghvi17 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot, @spaette ! Hope you didn't have to do all of this by hand :)

@asinghvi17
Copy link
Member

The intention there was for the singular form so that works.

@asinghvi17
Copy link
Member

The wording for area should probably read "computed differently for different geometry types"

@spaette
Copy link
Contributor Author

spaette commented Jul 19, 2024

by hand

The work was based on dumped repo strings.

"computed differently for different geometry types"

How about rewording as one of the following?

For different geometries the computation is slightly modified:

The computation is slightly modified for the different geometries:

@spaette
Copy link
Contributor Author

spaette commented Jul 19, 2024

@asinghvi17

Go ahead and merge.

src/methods/area.jl

I'm leaving any debate on a possible rewrite to the Maintainers.

Guess I'm not enthusiastic of different appearing twice in the sentence.

@spaette spaette marked this pull request as ready for review July 19, 2024 20:22
@asinghvi17 asinghvi17 merged commit 2da44be into JuliaGeo:main Jul 20, 2024
3 checks passed
@asinghvi17
Copy link
Member

Hmm, that makes sense. I am refactoring a bunch of stuff anyway so will sneak a rewrite in there.

@spaette
Copy link
Contributor Author

spaette commented Jul 21, 2024

if the line is changed

here's another attempt

The computing is dependent on the different geometry types:

one might want a potential rewrite to be suitable to both circumstances where the current line occurs

$ ed -s GeometryOps.jl/src/methods/area.jl <<<'53,68p'
"""
    area(geom, [T = Float64])::T

Returns the area of a geometry or collection of geometries. 
This is computed slightly differently for different geometries:

    - The area of a point/multipoint is always zero.
    - The area of a curve/multicurve is always zero.
    - The area of a polygon is the absolute value of the signed area.
    - The area multi-polygon is the sum of the areas of all of the sub-polygons.
    - The area of a geometry collection, feature collection of array/iterable 
        is the sum of the areas of all of the sub-geometries. 

Result will be of type T, where T is an optional argument with a default value
of Float64.
"""
$ ed -s GeometryOps.jl/src/methods/area.jl <<<'75,91p'
"""
    signed_area(geom, [T = Float64])::T

Returns the signed area of a single geometry, based on winding order. 
This is computed slightly differently for different geometries:

    - The signed area of a point is always zero.
    - The signed area of a curve is always zero.
    - The signed area of a polygon is computed with the shoelace formula and is
    positive if the polygon coordinates wind clockwise and negative if
    counterclockwise.
    - You cannot compute the signed area of a multipolygon as it doesn't have a
    meaning as each sub-polygon could have a different winding order.

Result will be of type T, where T is an optional argument with a default value
of Float64.
"""
$ 

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants