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

Ripley's K function calculation in PointPats: #67

Open
Maikelmoore opened this issue Oct 17, 2020 · 0 comments
Open

Ripley's K function calculation in PointPats: #67

Maikelmoore opened this issue Oct 17, 2020 · 0 comments

Comments

@Maikelmoore
Copy link

Dear Professor Rey,

Our names are Max Ratzenboeck and Michael Ecker, MA SCM students at WU Vienna University of Economics and Business. Currently we are writing our master thesis about „Open software and open data for geospatial point pattern analysis in Supply Chain Management“ supervised by Prof. Petra Staufer-Steinnocher (Deputy Head, Institute for Economic Geography and GIScience,; Associate Editor, Journal of Geographical Systems). As the focus of our thesis is on open software, we are using Python, especially your packages pysal/libpysal in order to conduct the analysis. Regarding this, some questions occurred during the usage of PySAL which we allow ourselves to ask:

To calculate Ripley’s K function, your script „distance_statistics.py“ (pysal/pointpats, version 2.1.0, also attached to this email, changed/notes inserted at lines 478-482) is used where we got some strange error regarding the output: The values only seemed to be exactly 1/4 of the results of our manual calculations and calculations in R. This lead us to inspecting the code and we changed.

den = pp.lambda_window * pp.n * [2]
distance_statistics.txt

kcdf = np.asarray([(di, len(pp.tree.query_pairs(di))/den) for di in d])

to

note: changed original code

den = pp.lambda_window * pp.n

den = pp.lambda_window * pp.n *2

kcdf = np.asarray([(di, len(pp.tree.query_pairs(di))*2/den) for di in d])

kcdf = np.asarray([(di, len(pp.tree.query_pairs(di))/den) for di in d])

which then delivered exactly the results what we got in other calculations. Our question is: Is our way of thinking correct and/or was there a bug in your source code or is your approach a different? If your approach is different, can you please tell us the literature in order that we understand this issue better?

A second question about KDE will be posted in a different post.

Thanks for your help in advance.

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

No branches or pull requests

1 participant