Geni API not returning fields of Birth / Death

Tag Private User

From a programmers view I would not expect to get anything else than the profile and union id's and how they are connected in a immediate-family request - i.e the description of the immediate-family ;-)

Getting other profile details can however be seen as a bonus and saves you a second request for the profile and union details for the profiles you want to continue on, - like the parents...

This has been fixed -- let me know if you have any other problems. Two things to node:

1. The location hashes now also include country_code which will be the 2-letter country code if a valid mapping exists, or the country string if not.

2. Latitude and Longitude are now floats, rather than strings (as promised in the documentation, so I hope that's not a problem for you)

Great, - a country code means that we now can display the country name in the UI language of the user.

Are there a process going on detecting all variants of a country names to find the country codes?

Of course this will not work where the countries does not exist any more or the are is not within the specific country anymore.

Latitude and Longitude is not a problem because my json parser is automatically converting to the requested type, which is float, independent on how it is stored.

Awesome Mike - Thanks! I can defiantly use the Country Code - I'm doing my own mash up now trying to associate things like US / USA / United States (and that's just in English). I could see this tying into T8rn very nicely.

Ok, getting back to this...

Private User stated in a FB post "For loading an ancestor tree I would however recommend keeping the immediate-family request at a minimum since you are only interested in the parent's, and instead collect the profile-id's for the next generation (the parents) and load those profile details in a separate chunk of profiles."

So you're thinking two requests...
The first one grabs the union like this:
http://www.geni.com/api/profile/immediate-family?ids=profile-897889...

Then process the relationships, identify the parents, then create a second query for their details.

This would result in twice as many queries, but the results would likely be much smaller in size, since I'd be excluding the return details of siblings and children.

So you think this will be faster? It seems like it would, particularly when you get into higher generations.

It depends of course on how many profile id's you apply on your profile and immediate-family requests. If requesting only one per request it will of course be slower.
Collect all parent-ids in one generation, bulk-request the profile details and immediate-family for them and so on.

Right.. So I guess the initial query could be 15 profiles, which produces a query for 30 parent details. Not to exceed 50 profiles in any query.

There is no problems requesting more than 50 id's in one request as long as you are able to handle paged results.

Another nice option that I realized is "only_ids=true", which I think might be better termed as "no_urls=true". The name and the second sentence in the description "Passing only_ids will force the system to return ids only." made me think it would only return ids, not so. I found the first sentence alone better describes the function: "The returned data structures will contain urls to other objects in our system unless the request includes 'only_ids=true.' If you specify fields=birth,death,living,etc.. these fields return fine. I had expected it to only return the field "id". So this is a nice way to reduce the size of the JSON if you don't use the url to the other objects.

I have always used "only_ids=true", because it saves you the work on stripping the path of an api-profile-url when for example you want to load the immediate-family record of the profile. Secondly you can also drop the profile- and similar from the ID when using ids=nn,nnn for bulk-loading records.

Nice - I'll try the removing "profile-" trick as well. :)