Patrick Leary

My activity

  • Profile picture of Patrick Leary who took this action.

    Patrick Leary commented on "Patrick Leary":

    This comment was deleted.

    6 months ago • deleted: 6 months ago

  • Profile picture of Patrick Leary who took this action.

    Patrick Leary commented on "Patrick Leary's Watch List":

    This comment was deleted.

    6 months ago • deleted: 6 months ago

  • Profile picture of Patrick Leary who took this action.

    Patrick Leary commented on "Patrick Leary":

    This comment was deleted.

    7 months ago • deleted: 7 months ago

  • Profile picture of Patrick Leary who took this action.

    Patrick Leary commented on "Patrick Leary":

    Hello?

    8 months ago

  • Profile picture of Patrick Leary who took this action.

    Patrick Leary commented on "pleary_test100":

    This comment was deleted.

    11 months ago • deleted: 11 months ago

  • Profile picture of Patrick Leary who took this action.

    Patrick Leary commented on Patrick Leary's newsfeed:

    This comment was deleted.

    about 1 year ago • deleted: about 1 year ago

  • Profile picture of Patrick Leary who took this action.

    Patrick Leary commented on "EOL API Discussion Group":

    @eangeles92: Thanks to Yan there is a response to this question with code samples in our new forum http://eol.org/forums/3/topics/38 . It describes how to fetch data from the API as JSON and turning that into a PHP object that can be worked with

    about 1 year ago

  • Profile picture of Patrick Leary who took this action.

    Patrick Leary commented on "Barb Banbury":

    @Barb Banbury: Hi Barb - your latest comment made it only to your newsfeed but I luckily found it. You differentiate EOL taxon ID from the page number, but we use those terms interchangeably (though there is a different HierarchyEntryID which we use to indicate taxon definitions from provider - e.g. Animalia according to ITIS). You certainly can use this information when searching, but the question I was putting out there is - is this the best way to get around to doing what you want? You say here you wanted a tarball of EOL text, which was indeed not available a few months ago, but I have a prototype now which you can try out. I will email it to you shortly.

    over 1 year ago

  • Profile picture of Patrick Leary who took this action.

    Patrick Leary commented on "EOL API Discussion Group":

    @Barb Banbury: Hi Barb. The highest published page ID (today) is http://eol.org/pages/36680799/overview . I'm curious though how you intend to use this. As Nathan point out IDs are not meant to be used directly, and there are a tremendous number of redirect pages (most of which are never actually published before they are turned into redirects). Nathan suggested an API to return random pages which seems like a reasonable API method. But I'm not sure how reasonable an API to return the highest ID would be since it seems completely arbitrary. Perhaps you have some end goal which might be better approached with a different set of API methods that aren't so dependent on arbitrary page IDs?

    over 1 year ago

  • Profile picture of Patrick Leary who took this action.

    Patrick Leary commented on "Chloropsis":

    @John Wieczorek: Thanks John. That should be fixed now. This page should contain only bird data and the plant has its own page at http://eol.org/pages/36671230/overview

    over 1 year ago

  • Profile picture of Patrick Leary who took this action.

    Patrick Leary commented on Patrick Leary's newsfeed:

    This comment was deleted.

    over 1 year ago • deleted: over 1 year ago

  • Profile picture of Patrick Leary who took this action.

    Patrick Leary commented on Patrick Leary's newsfeed:

    This comment was deleted.

    over 1 year ago • deleted: over 1 year ago

  • Profile picture of Patrick Leary who took this action.

    Patrick Leary commented on Patrick Leary's newsfeed:

    This comment was deleted.

    over 1 year ago • deleted: over 1 year ago

  • Profile picture of Patrick Leary who took this action.

    Patrick Leary commented on "EOL API Discussion Group":

    @Roderic Page: The API changed in that an new optional parameter cache_ttl was added, but that should not have any impact on existing use of the API. The cache_ttl parameter is optional, and the responses from all requests that choose not to use it should not have changed.

    I just tried a few uses of cURL with no problem. On the command line:
    curl http://eol.org/api/search_by_provider/1.0/180542?hierarchy_id=903

    And in PHP (using PHP 5.3.15):
    $ch = curl_init();
    curl_setopt($ch, CURLOPT_URL, 'http://eol.org/api/search_by_provider/1.0/180542.json?hierarchy_id=903');
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
    $result = json_decode(curl_exec($ch));
    echo $result[0]->eol_page_id."\n";

    Can you provide an example where you are seeing a problem? As for announcing API changes I agree we need better communication. This was part of the reason we developed a forum, and that forum does include a post about the new cache_ttl parameter. I realize I did not make a similar post to this group, so I will make sure to share information about API releases more widely next time.

    over 1 year ago • edited: over 1 year ago

  • Profile picture of Patrick Leary who took this action.

    Patrick Leary commented on Patrick Leary's newsfeed:

    This comment was deleted.

    over 1 year ago • deleted: over 1 year ago

  • Profile picture of Patrick Leary who took this action.

    Patrick Leary commented on Patrick Leary's newsfeed:

    This comment was deleted.

    over 1 year ago • deleted: over 1 year ago

  • Profile picture of Patrick Leary who took this action.

    Patrick Leary commented on "Kristen Lans":

    Hello

    over 1 year ago

  • Profile picture of Patrick Leary who took this action.

    Patrick Leary commented on "EOL API Discussion Group":

    @Roderic Page: replacing the end of the file name with _88_88, or _130_130 should always work... for now. How would you prefer to get the list of images sizes? Should they always be returned with the data object, or conditionally based on a parameter, or would you want there to be a separate method just for image sizes?

    We have a set number of predefined image sizes which are generated and saved to disk - we don't offer any dynamic image resizing services. If we exposed all the image size URLs (2 square, 3 proportionally scaled, and the original) do you still think there would be a need for us to offer a service that accepts user-defined image sizes? For our purposes the pre-generated sizes are sufficient for most needs. More advanced users like yourself could generate their own custom sizes, and others could find a close-enough size and use CSS to scale the image (not ideal but since we have a few options hopefully there isn't a huge amount of wasted bandwidth when downloading something slightly larger than they need). I guess I'm wondering if you think this is a service EOL should offer (essentially a hosted imagemagick) or something the user could do themselves by chaining together services.

    over 1 year ago

  • Profile picture of Patrick Leary who took this action.

    Patrick Leary commented on "Cressa":

    @DBvdPloeg: Thanks for the report. The two genera should now be properly separated.

    over 1 year ago

  • Profile picture of Patrick Leary who took this action.

    Patrick Leary commented on "Jeremy Rice":

    This comment was deleted.

    over 1 year ago • deleted: over 1 year ago