cabennett85/gittest — Issue #1023: add location to import
Author: cabennett85
Created: 2012-03-02 00:31:22+00:00
State: open

Yup I'm fine with this :) Actually I'm not opposed to leaving out the location since all the rest of the data in our db has lat/long and is validated. But I'll leave it up to you to change the import file and code - lemme know if you need anything from me though! Thanks!

Claribel
- Hide quoted text -

On Tue, Mar 29, 2011 at 9:26 AM, Loren Yu wrote:
good call stan. let's defer this. even if we do import we can always ignore location if we wanted to.

On Tue, Mar 29, 2011 at 1:36 AM, stanchovy wrote:
thats a good suggestion, i'll update import and work in tandem with loren. since this release is tight and coming down to the wire, let's defer this work to post 4/4, since i dont believe we're intending to use import in the near future. if you dont mind, claribel, can you file a ticket on me, and just copy-paste this email?

thanks!

let me know if that sufficiently unblocks you to go live with locations. you coded this in lightning time!
stan

On Mon, Mar 28, 2011 at 11:36 PM, Claribel Wang wrote:
Hey Stan,

createNPOUsingObject() and updateNPOUsingObject() both will store new locations in the location table, but I'm not sure how the data in the import file is structured. There's fields like: freebase_location, freebase_geo, etc. If you are able to change the import file, then that's probably best.

And if you do so, I can update Import.php or you can do it while changing the import file structure. Basically a location object expects the following fields: bnid, latitude, longitude, city, region, country. You should at least fill in those except for latitude and longitude. Let me know if you have questions. Thanks!

Claribel

On Mon, Mar 28, 2011 at 4:50 AM, stanchovy wrote:
Cc'ing Loren.

In this case, it sounds like the easiest is to have them as separate fields. I think we can make the import file into whatever is easiest, is that right Loren?

And yes, I believe for at least most of them that we will lack lat/long! :(

Stan

On Mon, Mar 28, 2011 at 3:47 AM, Claribel Wang wrote:
Hey Stan,

To clarify, we usually have the city, region and country separated in our db locations table. Are the locations that are imported able to be parsed - or will they contain garbage in some of them?

Also, it would be great if the location came with latitude/longitude coordinates. But I assume these are a little hard to retrieve? Thanks!

Claribel

On Mon, Mar 28, 2011 at 3:43 AM, Claribel Wang wrote:
Hey Stan,

I modified createNPOUsingObject() and updateNPOUsingObject() to handle the scenario where $obj->locations needs to be saved. I will adjust the import code tomorrow.

As for the location, is there info where they split up the city, region and country? And we also stored the latitude/longitude. Guess we won't have that data right?

Okay... lemme know and I'll wrap this up tomorrow. Thanks!

Claribel

On Mon, Mar 28, 2011 at 1:16 AM, stanchovy wrote:
thanks for catching that! i'd prefer modifying the createNPOUsingObject method, but if its difficult or awkward to do, then you can create a new method and just document the createNPOUsingObject so ppl know that its missing from that function!

stan

On Mon, Mar 28, 2011 at 1:06 AM, Claribel Wang wrote:
Hey Stan,

I realized there's one area I didn't change yet to handle new locations - the autogen/import part. Right now I think it's using the createNPOUsingObject() method to create the NPO. Should I create a new method just to create locations OR modify createNPOUsingObject() to store the locations in the proper table (if the object has locations)? Let me know what you'd prefer. Thanks!

Claribel

--