On the question of: "I have no idea if it is necessary to provide simple alternative when PostGIS is not available."
I would suggest that you do not bother to code for the case where PostGIS is not available. I like Caleb's suggestion of disabling the function if PostGIS is not installed (i.e., returning a nice error message that says "you must install PostGIS to use this function") rather than make PostGIS a global dependency for MADlib. Frank On Thu, Jan 14, 2016 at 6:53 PM, Greg Chase <[email protected]> wrote: > We always share the presentation and post the video replay as well. > > You can also drink lots of coffee, and join us if you are crazy enough. > > We like crazy people. > > This email encrypted by tiny buttons & fat thumbs, beta voice recognition, > and autocorrect on my iPhone. > > > On Jan 14, 2016, at 6:35 PM, Kuien Liu <[email protected]> wrote: > > > > Yes, 2AM on Saturday... May you please share Gautam's representation > video after the call? > > > > Cheers, > > Kuien Liu > > > >> On Wed, Jan 13, 2016 at 6:36 PM, Greg Chase <[email protected]> wrote: > >> As I said, our next call is not China-friendly: > http://mail-archives.apache.org/mod_mbox/incubator-madlib-dev/201601.mbox/%3CCAMg1VtnKB-WoyVqCstfMNCcJVOn2HKQQ6wNfqdovhgnB7zd5cw%40mail.gmail.com%3E > >> > >> This is this Friday, 10AM Pacifc Standard Time which is 2AM Saturday > Beijing time. > >> > >> We will arrange a next call in a couple weeks at an Asia friendly time > to support contributors in Asia. > >> > >> However, if you make the next call, we will make time for you to talk :) > >> > >> Regards, > >> > >> -Greg > >> > >>> On Wed, Jan 13, 2016 at 2:18 AM, Kuien Liu <[email protected]> wrote: > >>> Great, I would like to join it, please send me an invitation if > possible. > >>> > >>> Cheers, > >>> Kuien Liu > >>> > >>>> On Wed, Jan 13, 2016 at 6:10 PM, Greg Chase <[email protected]> wrote: > >>>> Perhaps ChenLiang would like to join a call with the MADlib community > and discuss his contribution? > >>>> > >>>> We have a call this Friday 10AM PST which is not a friendly time for > China, but we can schedule a next call at a friendlier time. > >>>> > >>>> This email encrypted by tiny buttons & fat thumbs, beta voice > recognition, and autocorrect on my iPhone. > >>>> > >>>> > On Jan 13, 2016, at 1:53 AM, Ivan Novick <[email protected]> > wrote: > >>>> > > >>>> > Cool! > >>>> > > >>>> >> On Wed, Jan 13, 2016 at 5:52 PM, Kuien Liu <[email protected]> > wrote: > >>>> >> > >>>> >> Got it, I think I can have a (f2f) talk with Chenliang Wang, as he > was > >>>> >> graduated from an institute of CAS which is not far from our > Beijing > >>>> >> office, and I am familiar with his supervisor and lab director. So > I think > >>>> >> it is highly possible to find him directly in Beijing. > >>>> >> > >>>> >> Cheers, > >>>> >> Kuien Liu > >>>> >> > >>>> >>> On Wed, Jan 13, 2016 at 3:05 PM, Ivan Novick <[email protected]> > wrote: > >>>> >>> > >>>> >>> Hello ChenLiang, > >>>> >>> > >>>> >>> I have read your description of the interface and to my > understanding > >>>> >>> this is a supervised machine learning algorithm that supports > geometry > >>>> >>> data. Am I correct? > >>>> >>> > >>>> >>> What could be a good industrial use case for this model for some > >>>> >>> examples? Could you train a system based on locations and > weather to find > >>>> >>> bad signals for cell phone? Can you provide any real world > example > >>>> >>> scenario where this type of model will be useful for end users? > >>>> >>> > >>>> >>> Also I am adding CC to some of my colleagues at work. Kuien, Max, > >>>> >>> Yandong can you provide any feedback on this proposal from your > Point of > >>>> >>> View? > >>>> >>> > >>>> >>> > >>>> >>> > http://mail-archives.apache.org/mod_mbox/incubator-madlib-dev/201601.mbox/%[email protected]%3E > >>>> >>> > >>>> >>> Cheers, > >>>> >>> Ivan > >>>> >>> > >>>> >>> > >>>> >>> On Wed, Jan 13, 2016 at 11:20 AM, WangChenLiang < > [email protected]> > >>>> >>> wrote: > >>>> >>> > >>>> >>>> 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 > >>>> >> > > >
