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

New Geodesy v0.1.0 has no Bounds #85

Open
TotalVerb opened this issue Jun 8, 2016 · 6 comments
Open

New Geodesy v0.1.0 has no Bounds #85

TotalVerb opened this issue Jun 8, 2016 · 6 comments

Comments

@TotalVerb
Copy link

TotalVerb commented Jun 8, 2016

Tagged 7 days ago, Geodesy v0.1.0 has removed the Bounds type that this package depends on. This is causing failure to load on v0.4 and later, which Geodesy v0.1.0 supports. v0.3 is not affected because Geodesy has dropped support for that release.

I think that Geodesy could have given more warning (such as a proper deprecation) when removing Bounds, but it's too late to do anything now. It was their decision to move forward without deprecation warnings, as the changes in general were too dramatic for deprecations to make sense. An alternative solution would be to set a maximum version requirement in REQUIRE, but I don't think that's a good idea.

(Discovered on stack overflow; cc @andyferris)

@andyferris
Copy link

Oh right, sorry! I misunderstood the original README message in Geodesy as being a stripped-down package for general geo use, rather than a re-factor of OpenStreetMap (but in hindsight that was a silly assumption!). On top of that, we had re-written Goedesy three times before we were happy with it, and reinstating the error messages and warnings was forgotten in the last branch... (my fault)

I'm assuming that copy-pasting this code with possible minor changes into OpenStreetMap would fix the problem? Do you want some help with that?

@andyferris
Copy link

Oh, and while Bounds gets brought over here, we can fix JuliaGeo/Geodesy.jl#4 be defining map for Bounds to let us change the type of the points. In the new syntax, something like this would work:

trans = ENUfromLLA(origin, wgs84)
bounds_enu = map(p -> transform(trans, p), bounds_lla)

@andyferris
Copy link

As a general comment, I'm hoping that in JuliaGeometry we can define some kind of "point" supertype (or interface) that may be widely used. Points would naturally support things like affine and convex combinations. Your Bounds thing is really just a convenient way of querying if some new point is in the convex hull of some other points, so it would be naturally supported...

@tedsteiner
Copy link
Owner

@andyferris Thanks for pointing this out. Apparently my GitHub notifications list got so long that it wasn't showing things for this package anymore, but I'll try to get a fix in soon now that I've seen it.

I agree it would be nice to have some sort of point type with some bonus functionality. However, I go back and forth on whether I want to pull in dependencies for everything or not, since it can lead to errors like this coming up when the packages go in different directions. As an example, Geodesy.jl was originally just code I wrote for this package that later got pulled out to be more useful elsewhere, and now it can't do what I needed it to do anymore. 😄

@SimonDanisch
Copy link

Lol...

Just ran into this as well!
Just copying and pasting didn't work out very well.
I gave up at the point, where this turned up:

ENU(bounds::Bounds{LLA}, lla_ref::LLA = center(bounds), datum::Ellipsoid = WGS84)
isa(WGS84, Ellipsoid) == false

@nicolaspayette
Copy link

#86 (comment) suggests a temporary workaround for users.

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

No branches or pull requests

5 participants