search

tomatofj / geoda

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

rate map - catching division by zero #59

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
When an attempt is made to construct a raw rate map for a 
variable that has zeros in the denominator, the error message
says: Base values contain non-positive numbers. Cannot perform
smoothing.
However, there is no smoothing going on, "only" division by zero.
Ideally, we should catch division by zero and insert a NaN, but
in the meantime, a more meaningful error message would be good.

Original issue reported on code.google.com by lanse...@gmail.com on 21 Nov 2013 at 12:40

GoogleCodeExporter commented 9 years ago

Original comment by lanse...@gmail.com on 20 Apr 2014 at 1:42

GoogleCodeExporter commented 9 years ago 
One solution would be to take the same approach as for the isolates in the 
local moran cluster maps. Locations that do not have neighbors are flagged and 
show in gray. Similarly, we could flag locations with division by zero (it's 
usually zero, even though the warning says non-positive) and show them in gray 
+ exclude them from any calculations. This is a common issue in larger data 
sets, hence moving it up to priority high. This should be fixed for 1.6 = I 
need it NOW.

Original comment by lanse...@gmail.com on 20 Apr 2014 at 1:45

GoogleCodeExporter commented 9 years ago 
We are discussing options.  This was entered as a 1.8 issue because it is not a 
trivial amount of work to do this properly everywhere.  We'll come up with a 
design and estimate today, but initially I will guess multiple days or more.

Original comment by mmcc...@gmail.com on 21 Apr 2014 at 6:32

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
We will implement an extra category solution, similar to what was done for LISA 
maps.  However, there is a complication that OGR/GDAL has no facility for 
saving or detecting NaN.  Our testing of double fields on OGR shows that 0 is 
always returned.  GeoDa has an auxillary vector to save defined/undefined in 
memory, but it is only being used for DBF currently since OGR/GDAL doesn't 
support NaN.  One solution might be to store NaN lists in the project file.  
Will at least start with implementation for dBase/Shapefile.

Original comment by mmcc...@gmail.com on 22 Apr 2014 at 4:29

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
We've determined that even the above solution is too involved for 1.6.  We 
might leave this entirely for 1.8, or implement something simpler such as a 
warning when undefined values were created with the offer to indicate which 
values are undefined in a separate column.  The undefined values would be 
stored as zeros, but the user would be able to see which values were undefined.

Original comment by mmcc...@gmail.com on 23 Apr 2014 at 10:02

GoogleCodeExporter commented 9 years ago 
Even the more limited solution is not going to be easy to implement for various 
reasons.  Recommended that this is moved to 1.8.  The error message has been 
updated to simply say "undefined values" rather than "smoothing".

Original comment by mmcc...@gmail.com on 24 Apr 2014 at 12:52