Sorry, the link of attachment (http://1drv.ms/1ZjAiCg) is lost in the previous letter.
> From: [email protected] > To: [email protected] > Subject: RE: How to contribute a spatial module to MADlib manipulating > objects from PostGIS > Date: Wed, 13 Jan 2016 11:09:17 +0800 > > > > Hi ,Caleb and Ivan! > Thanks for your attention and help. I reviewed the previous draft and find > something inappropriate. The archive containing the new draft and example > code > is attached in the letter which would be more reasonable than the earlier > edition. > Please go over the manuscript and give suggestion again . > The following are my answers to Caleb's questions. > - Does this function require PostGIS to also be > installed? If yes, it would be better > if we disable the function if > PostGIS is not present rather than introduce PostGIS > as a dependency. (Similar > to what we do with our requirement on the xml module with our PMML export > functionality). > > > > A:Yes. I am trying to avoid > input any spatial datatypes in the interface of GWR. > But I have no > idea if it is necessary to provide simple alternative when PostGIS is not > available. > > > > - What are the exact datatypes in the function > definition for regression_location > and prediction_location? > > > > > > A:I changed the datatype > to TEXT as the name of POINT or MULTIPOLYGON > (centroid of > each polygon for estimation for GWR). > > > > - In the description it describes > regression_location as "The length of > regression_location must be equal to the length of > source_table", which signals to me that it is likely intended to be a > column of the source table? If not then how is > this length represented? > > > A: In the previous > interface, I was trying to input a geometry field which could be > from another > table having different row number. Now, I alter the argument > definition and make it > to TEXT. It must be the name of geometry field in the > source table. > > > > - You didn't mark regression_location as > (optional). Due to the way Postgres > functions work all optional arguments > must come after all required arguments, > so having a non-optional argument in > the middle of the optional list must be > avoided. > > > > A:Thanks for > reminding me of this mistake. It is really my fault. The order of > argument is changed in this edition. > > > > > - I haven't read through the literature, but it is > not immediately clear to me why > prediction_location is a parameter to > gwregr_train() rather than gwregr_predict(). > Can you provide a brief > description to the way that prediction_location is used in > the model and its > relationship to training and prediction. > > > > A: Actually, > there are three kinds location data including location of sample data, > regression and prediction in the modeling of GWR. > > Locations of sample data indicate where is sample > data. Locations of regression > indicate where regression should be conducted. If > it is identical to data location > (in most instances),diagnostic information can > be calculated. > > Locations of > prediction indicate where coefficients should be predicted. It should be a > parameter for a predict function. Putting regression_location into training > function is just for omitting kernel arguments and maybe not appropriate. In > the process of > training, GWR estimates weight and coefficients with distance > between data_loctions and regression_loctions. Then, diagnostic information > are > estimated when these two locations are identical. We can treat > data_locationas regression_location to simplify the process not taking > different locations from > data location in the training step. > > In the process of > prediction , there are two new information including new > independent variables and new locations. Therefore, coefficients and weight > vector must be estimated > again. GWR can > estimate coefficients in any positions > using independent variables of sample data. > If we also provide independent > variables in any positions,we can also obtain > dependent variable in any position. So if we treat coefficients at > prediction_location as a training result to put > coefficients into prediction > directly, it is reasonable to put it into training function. But if we treat > it as a part of prediction, it is appropriate to set predicton_location > within predict function. And then, prediction function must require kernel > parameters in addition to new data and locations for prediction. Maybe this > way > is more clear > and reasonable, and is similar with others GWR packages in R. > > > > I > rewrote the description of interface taking your suggestion into account. I > moved > prediction_location into predict function and modified > some mistake and > unnecessary arguments. The new draft of interface design is attached in the > letter. > > > Regards, > > ChenLiang Wang > > > > > From: [email protected] > > Date: Tue, 5 Jan 2016 10:31:20 -0800 > > Subject: Re: How to contribute a spatial module to MADlib manipulating > > objects from PostGIS > > To: [email protected] > > > > Hi ChenLiang, > > > > Thanks for taking the next step to flush this out. > > > > As a whole: > > - naming and basic interface seems consistent with existing conventions. > > - names are descriptive. > > - references to the literature is provided. > > - functionality is complementary to the library. > > > > What is not clear to me is: > > - Does this function require PostGIS to also be installed? If yes, it > > would be better if we disable the function if PostGIS is not present rather > > than introduce PostGIS as a dependency. (Similar to what we do with our > > requirement on the xml module with our PMML export functionality). > > - What are the exact datatypes in the function definition for > > regression_location and prediction_location? > > - In the description it describes regression_location as "The length of > > regression_location must be equal to the length of source_table", which > > signals to me that it is likely intended to be a column of the source > > table? If not then how is this length represented? > > - You didn't mark regression_location as (optional). Due to the way > > Postgres functions work all optional arguments must come after all required > > arguments, so having a non-optional argument in the middle of the optional > > list must be avoided. > > - I haven't read through the literature, but it is not immediately clear to > > me why prediction_location is a parameter to gwregr_train() rather than > > gwregr_predict(). Can you provide a brief description to the way that > > prediction_location is used in the model and its relationship to training > > and prediction. > > > > Regards, > > Caleb > ChenLiang 要与你在 OneDrive > 上共享一个文件。要查看该文件，请单击下面的链接。 > gwr4madlib.rar > >
