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

Return extent based on dimensionality. #319

Merged
merged 2 commits into from
Aug 24, 2022
Merged

Return extent based on dimensionality. #319

merged 2 commits into from
Aug 24, 2022

Conversation

evetion
Copy link
Collaborator

@evetion evetion commented Aug 15, 2022

Before we always returned the 3d extent, even on 2d geometries.

@rafaqz
Copy link
Collaborator

rafaqz commented Aug 15, 2022

Lol I have an unfinished PR for this too.

@rafaqz
Copy link
Collaborator

rafaqz commented Aug 17, 2022

It should be possible to make this type stable? It could use is3d, which could also be type stable.

@evetion
Copy link
Collaborator Author

evetion commented Aug 17, 2022

As in having two functions and passing Val(is3d()) right?

@rafaqz
Copy link
Collaborator

rafaqz commented Aug 17, 2022

That won't be type stable cos is3d is currently runtime.

I mean make is3d depend on the type instead of on a GDAL function. Then it will constant prop at compile time without using Val.

@yeesian yeesian requested a review from rafaqz August 18, 2022 01:21
@yeesian yeesian mentioned this pull request Aug 19, 2022
@evetion
Copy link
Collaborator Author

evetion commented Aug 19, 2022

Ok, will do, but then we need to wait on #316.

@rafaqz
Copy link
Collaborator

rafaqz commented Aug 19, 2022

We don't need to wait tho it doesn't change the types

@evetion
Copy link
Collaborator Author

evetion commented Aug 19, 2022

Your PR introduces the AbstractGeometry{T} right? So

function GeoInterface.is3d(
        ::GeometryTraits,
        geom::Union{map(T -> AbstractGeometry{T}, ztypes)...},
    )
        return true
    end

would require #316

@rafaqz
Copy link
Collaborator

rafaqz commented Aug 19, 2022

Yeah you're right. My other PR for this just used a Union in the geometry types before I just changed the abstract types.

I might add is3d to the other PR as it falls under type stability improvements. Then this PR can just call is3d.

Edit: I guess even getcoorddim can be a compile time trait. In which case this PR is fine as-is.

@evetion
Copy link
Collaborator Author

evetion commented Aug 20, 2022

To be fair, I would opt for using GI.is3d here. I like to make all GeoInterface methods compile time based and leave the ArchGDAL functions calling GDAL as is.

@rafaqz
Copy link
Collaborator

rafaqz commented Aug 20, 2022

Yeah that sounds like a good idea.

But also it turns out to be not so easy to do this at all because there is no wkbPointZ. So out points are type unstable between 2/3 tuples. We probably need to ecode the dimensionality as an additional parameter in the point type.

@evetion
Copy link
Collaborator Author

evetion commented Aug 20, 2022

There's wkbPoint25D right? It's confusing, I agree.

@rafaqz
Copy link
Collaborator

rafaqz commented Aug 20, 2022

Yeah but no Z when there is ZM? I cant tell how its all mean to work.

@evetion
Copy link
Collaborator Author

evetion commented Aug 20, 2022

wkbPoint =>    X Y 
wkbPoint25D => X Y Z
wkbPointM =>   X Y M
wkbPointZM =>  X Y Z M

And to make it more confusing, for the extended geometries, they didn't use 25D, but Z again (wkbCircularStringZ to wkbTriangleZ)

@rafaqz
Copy link
Collaborator

rafaqz commented Aug 21, 2022

Yeah thats what threw me... there are Z geometries and 25D geometries.

@evetion
Copy link
Collaborator Author

evetion commented Aug 24, 2022

If @rafaqz agrees, this can now be merged as is. is3d can be sped up in the other PR(s).

@rafaqz
Copy link
Collaborator

rafaqz commented Aug 24, 2022

Yep let's do that.

@evetion
Copy link
Collaborator Author

evetion commented Aug 24, 2022

Note that I can't merge because we need at least 1 reviewer approving ;)

Copy link
Collaborator

@rafaqz rafaqz left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Owner

@yeesian yeesian left a comment

Choose a reason for hiding this comment

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

Note that I can't merge because we need at least 1 reviewer approving ;)

Sorry I set it up per https://github.com/SciML/ColPrac/blob/b6cacb2942753a0bb6b721c81543b649f9765063/README.md?plain=1#L29

@rafaqz FYI I think you should have the requisite permissions to approve PRs through the github UI too :)

@yeesian yeesian merged commit f4ac3e5 into master Aug 24, 2022
@yeesian yeesian deleted the fix/extent branch August 24, 2022 23:26
@yeesian
Copy link
Owner

yeesian commented Aug 24, 2022

Thank you for this!

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.

3 participants