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

kdtree changes for arc distance #659

Closed
wants to merge 1 commit into from
Closed

Conversation

dfolch
Copy link
Member

@dfolch dfolch commented Jul 10, 2015

This PR applies issue #646 to the entire library, and extends PR #647. It also addresses #652 and does some other stuff.

This PR allows the user to choose euclidean or arc distance (via the kd-tree) when using distance related functions. It does not change the API or reduce documented functionality. However, we might want to think about point handling more broadly in the future (see #651). It also speeds up arc distance queries by using cKDTree under the hood.

Changes:

  1. The default functionality for most distance related functions and classes is to take a kd-tree instead of an array of points. When an array is passed, we convert to euclidean distance kd-tree and give a deprecation warning. The only functions and classes that don't require a kd-tree are those that explicitly take an array or shapefile.
  2. Made the pysal kd-tree accessible at the top level, i.e. pysal.KDTree.
  3. Modified Arc_KDTree to be built on top of scipy.spatial.cKDTree instead of scipy.spatial.KDTree when the user has scipy 0.12 or greater.

Notes:

  1. None of the numeric values in the tests had to change for this PR to pass (on my computer).
  2. Previously, most of these functions accepted lists, even though the docs all called for arrays. Now, if an array is passed it raises a deprecation warning and a list fails. This is an artifact of how the changes were implemented, not an intended consequence.

@ljwolf
Copy link
Member

ljwolf commented Feb 19, 2016

In hopes of getting this merged, I've tried to rebase these changes onto the current pysal/dev branch. It's located in my ckdtree_gc_dist_REBASE branch, and I think I got all the essentials in this PR.

However, I had to conduct some manual merges to incorporate mutual changes. Plus, there are over 250 outstanding commits... So, I can't just PR it to @dfolch and let github take care of the rest 😞

If and when travis tests close successfully, I can submit this in the same fashion as #744.

If only github had an automatic way of tagging something overdue for a rebase...

Any thoughts?

@ljwolf
Copy link
Member

ljwolf commented Apr 1, 2016

merging changes over in ljwolf/pysal/tree/kdtree

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.

None yet

2 participants