IBA errors/inconsistencies

[steffilazerte]

There are some errors/inconsistencies with the IBA metadata.

1. Field names aren't consistent with the rest of the metadata

   • nat_name rather than iba_name
   • iba_site rather than iba_code
   • province rather than statprov (Although these aren't exactly the same because IBA includes "LB" for Labrador)
   • bcr_region rather than bcr_code

2. Some IBAs have incorrect coordinates. For example, NB042, NU101, QC153, QC158, QC160, QC161 all have positive longitudes (I discovered this when working on an article which involved mapping the IBAs, you can see the problem here)

Right now the R package corrects the names (but not the coords), but ideally they would be consistent in the metadata served by the API in the first place.

[denislepage]

1) I have fixed the positive IBA longitudes, but the API was using the version from dendroica. I have now switched this to the bscdata version, which I expect is the master version. Catherine, any reason to maintain the Dendroica copy? We’ll need to see what else refers to the Dendroica version if we plan to remove it.

2) I have also renamed all the fields to be consistent with the names of indexed fields (where are iba_code and iba_name used?):

iba_site iba_name iba_name_fr nearest_town statprov latitude longitude alt_min alt_max area_ha bcr ncc_region status

Let me know if there are remaining inconsistencies.

3) Also worth considering is adding the WMS layer from this service:

https://birdmap.birdscanada.org/geoserver/atlas/wms?service=WMS&version=1.1.0&request=GetMap&layers=atlas:iba&styles=&bbox=-141.23762941099994,41.671768032000045,-52.66697661099994,78.10591341200006&width=768&height=330&srs=EPSG:4326&format=application/openlayers

We haven’t talked about this, but there are a number of layers that should be available from that server. I’m not exactly sure what format you need, etc. If it’s not straightforward

4) not sure how we handle LB codes. I’d be inclined to change the statprov value associated with those to match NL in the database, but I don’t know if that will disrupt something else. The alternative is to do the fix in the API proc. I have gone with the latter approach for now. The site code is still prefixed LB, but the province is now NL. While I was at it, I am also replacing NF by NL and YK by YT, so all the codes should now match the province table.

[steffilazerte]

1. Great
2. iba_code and iba_name aren't used anywhere else, but most of the other metadata (except species) that have fields that refer to meta_code where meta is the type of data. However iba_site will be fine here, if that's best.
3. I'll take a look!
4. It is tricky, but I think that within the API/package at least, it should be consistent, so for me, this is perfect.

[steffilazerte]

Is there any reason why we don't have bcr_code and iba_code rather than bcr and iba_site? This way they're consistent with the other regional specifications (country, statprov, and subnational), but I understand that we still have species_id, and project/collections without any qualifier.

[denislepage]

No particular reason, but some of them would be much harder to change, so we are a bit stuck. Unlike metadata, reading the bmde data table doesn’t rely on a view or proc where we can change the field names, and we’d have to make exceptions in the Java code. That’s somewhat more a risk of inconsistencies.

[steffilazerte]

Okay, and I assume that it's best the R package matches the server database where possible? So I'll leave it as is.