search

gouchangjiang / opengeoda

Automatically exported from code.google.com/p/opengeoda
GNU General Public License v3.0
0 stars 0 forks source link

Standard Deviation and Natural Break Maps: Incorrect! #64

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Start a project with the attached file
2. On the Map View, create choropleth maps for "Food" variable by using 
standard deviation and natural breaks methods 
3.

What is the expected output? What do you see instead?
For standard deviation map, the mean and standard deviation are
254.07969999999995 and 160.63265384911625, which are different from 254.063
and 164.79 from pysal. 
This is related to the issue of whether we need to use n-1 or n as
denominator. 
For natural breaks map, open geoda's classification is significantly
different from pysal and ArcMap. For the same variable, upper bounds for 5
classes in open geoda are 41.148, 404.88, 507.716, 616.517, and 616.913. 
Compared to this, pysal produces 106.364, 183.75, 270.562, 449.31, 666.913.
Which one is correct? 

What version of the product are you using? On what operating system?
Open Geoda 0.9.8.10

Please provide any additional information below.

Original issue reported on code.google.com by mhwa...@gmail.com on 5 Oct 2009 at 9:30

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by jkoschin...@gmail.com on 4 Dec 2010 at 12:50

GoogleCodeExporter commented 9 years ago 
Unique value, equal interval and natural breaks are new maps that aren't in 
Legacy. If it takes too long to fix them, we can bump the fix to one of the 
next versions.

Original comment by jkoschin...@gmail.com on 4 Dec 2010 at 12:53

GoogleCodeExporter commented 9 years ago

Original comment by jkoschin...@gmail.com on 4 Dec 2010 at 12:53

GoogleCodeExporter commented 9 years ago 
Defects in choropleth mapping based on standard deviation and natural breaks 
(jenks algorithm)

Original comment by jkoschin...@gmail.com on 4 Dec 2010 at 1:21

GoogleCodeExporter commented 9 years ago 
This is actually not a problem.  OpenGeoDa is correct and PySal is wrong.  We 
should divide by n-1 when estimating the s.d.

Original comment by mmcc...@gmail.com on 7 Dec 2010 at 2:51