GWT reader

[GoogleCodeExporter]

The values in the last column of the GWT files generated from GeoDa are 
distances used to define contiguity and not weight values. Currently our reader 
is returning the distances as the weights in the W object.

Since the GWT output from GeoDa reflects "the distance on which the contiguity 
definition was based" we should probably change the API of the reader to 
support different use cases:

1) The user wants contiguity weights based on the GWT file
2) The user wants a hybrid where w_{i,j} = d_{i,j}^{\alpha}  where d_{i,j} is 
the value in the GWT file and \alpha is the distance decay parameter.{
3) Instead of d_{i,j} in the third column of the GWT the user has specified the 
values of w_{i,j}

3) might break the API for GWT so perhaps that case should be treated in a 
different generalized reader?

Original issue reported on code.google.com by sjsrey on 13 May 2011 at 4:47

[GoogleCodeExporter]

since the reader should read the file and not transform the contents and 
because those contents do not directly map to give us a meaningful W,  why 
don't we have the GAL reader just return the i,j, distance as a numpy array.

other userland or dev methods/classes could be constructed to call the GAL 
reader but then further process the information to generate say distance based 
weights.

Original comment by sjsrey on 13 May 2011 at 9:47

[GoogleCodeExporter]

We changed the GWT reader to set the transform on the W object to 'b', so the W 
object returned to the user will be binary.

Original comment by schmi...@gmail.com on 19 May 2011 at 4:23

• Changed state: Accepted
• Added labels: Component-Logic, Milestone-1.2, Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

In order to support option #2 above we could add either a transform or method 
to W to create inverse weights.  We might need some kind of flag to identify 
that the 'O' data are distances.

Original comment by schmi...@gmail.com on 19 May 2011 at 4:26

[GoogleCodeExporter]

Currently when we read a GWT:
-w.transform = 'o': whatever was in the third column of the GWT
-automatically convert to binary

Will remove writing of GWT until a new solution is found.

If user wants inverse distance (or something else from a GWT) they can create 
it manually from w.transform = 'o'.

Original comment by dfo...@gmail.com on 19 May 2011 at 4:47

• Added labels: Milestone-1.3
• Removed labels: Milestone-1.2

[GoogleCodeExporter]

Turned gwt writing back on, see r1001.

Ok if 3rd column are weights instead of distances. GeoDa ignores them.

Original comment by schmi...@gmail.com on 29 Sep 2011 at 10:01

[GoogleCodeExporter]

research how gwt is dealt with by other packages. then make a decision

Original comment by sjsrey on 7 Oct 2011 at 7:49

[GoogleCodeExporter]

Original comment by schmi...@gmail.com on 9 Jan 2012 at 9:12

[GoogleCodeExporter]

We've circled back around to where we started on this issue...

Currently no transforms are set by the GWT driver on read or write.  This would 
seem to be the most logical behavior. This allows users to write a GWT file 
with a transform applied. The third column of the GWT file is interpreted as a 
float in all cases. 

Redefining the problem:
     While GeoDa writes the actual distance in the 3rd column we write the actual value of w[i,j].
     What problems does this cause?

For 1.3 leave it as is. Applications using GWT should be aware that we read the 
3rd column as is and should set the transform accordingly.

Original comment by schmi...@gmail.com on 30 Jan 2012 at 4:38

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by schmi...@gmail.com on 30 Jan 2012 at 4:38

• Changed state: WontFix