非常感谢您的代码,我已经用在了自己的项目当中
给两个小建议,提升gbif_occurrence_query.py模块的稳健性:
-
建议在get_species_geolocations()中对get_dataset_info()使用并发。目前它是使用的for-in循环来执行,速度非常慢。我已经在自己的代码中实现了,并且顺利运行,不会出现429错误。
-
建议把那些请求失败的species_key,额外记录,而不要直接记录在 progress_*.csv 文件中,否则在下次运行时,这部分请求失败的species_key同样会被忽略。
-
我个人认为没有必要把已经处理过的species_key作为一个list又被传到process_species()中。其实完全可以在主函数中,用这个list,先对 DF 进行去重,这样你可以得到一个 “干净” 的speckes_key数据框,这样逻辑会相对简洁一点,而且也没有必要在终端控制台中迭代打印哪些species_key被跳过了。
-
建议用logging来打印,而不是print。当然这个是我个人习惯而已
Anyway,你的代码已经非常健壮,我拿到以后配好环境就能跑起来了,非常方便。
BTW,我是复旦环境系的一年级博士生,最近也在使用GBIF API,如果您有进一步交流的意愿,可以Wechat: tydf86
非常感谢您的代码,我已经用在了自己的项目当中
给两个小建议,提升gbif_occurrence_query.py模块的稳健性:
建议在get_species_geolocations()中对get_dataset_info()使用并发。目前它是使用的for-in循环来执行,速度非常慢。我已经在自己的代码中实现了,并且顺利运行,不会出现429错误。
建议把那些请求失败的species_key,额外记录,而不要直接记录在 progress_*.csv 文件中,否则在下次运行时,这部分请求失败的species_key同样会被忽略。
我个人认为没有必要把已经处理过的species_key作为一个list又被传到process_species()中。其实完全可以在主函数中,用这个list,先对 DF 进行去重,这样你可以得到一个 “干净” 的speckes_key数据框,这样逻辑会相对简洁一点,而且也没有必要在终端控制台中迭代打印哪些species_key被跳过了。
建议用logging来打印,而不是print。当然这个是我个人习惯而已
Anyway,你的代码已经非常健壮,我拿到以后配好环境就能跑起来了,非常方便。
BTW,我是复旦环境系的一年级博士生,最近也在使用GBIF API,如果您有进一步交流的意愿,可以Wechat: tydf86