Hey,
it would be useful to allow date ranges for observations. It could be useful to prevent people from guessing a date if they are not sure, and in cases when you can’t choose one date, for example because you obtained the specimen from a trap which has been operating for weeks.
Greetings,
Jakob
It’s been to my knowledge that an observation in iNat is also when you choose it to be, ie. maybe you found a beetle in your trap on monday, but you decide to make an observation on tuesday. I think that is still valid because you are recording the existence of that specimen at a certain time and location.
Technically in iNat a picture of the same specimen at two different times count as two separate observations, but its entirely up to the choice of the user to decide what to upload. It can be useful in cases where you might want to document the life history from eg. a caterpillar to a moth.
I would appreciate a range. I have many photos saved and organised on my computer by month, but I don’t do the extra typing to record the day. Generally don’t upload old finds unless I can estimate within a week. But being able to say “August” would help me get more up.
edit: this won’t be an issue for me now that my new camera saves dates and times for me, but I’m sure a lot of people have pre-inat account photos, or their camera doesn’t do that.
I’m in favour of “date accuracy values” similar to what we have with location… Eg a specific date/time with a +/- value to indicate the range.
Welcome to the forum! I would like that. Don’t forget to vote for your own request! (Seen other people say that, so I figured I’d tell you.) :-)
This would also greatly help with observations of the same individual organism over a period of time. This way, we don’t have to make multiple observations, but we can just add additional photos to a single observation and note the date range
I’m not a fan of that idea… if the “individual observations” have accuracy in place and/or time, it seems destructive to be “merging them” and losing that detail. It would be like taking a photo at 20MP and in colour, and then turning it to greyscale and chopping the resolution down to 4MP. Notwithstanding iNat already capping the resolution of images for practicality, it is going to hinder the ability to identify etc. Actually, a better example with photos would be montaging 9 of them into a 3x3 grid and loading them up as one photo, effectively reducing the detail to a 9th of what there was.
A more “real” example… if one of the photos shows the pupation of a lep larvae, that happening at that specific time of year is of interest! To blur it out to being “sometime amongst all these other observations over the whole year” loses that…
I think the accuracy thing is more about when you don’t have the actual date available (some cameras don’t record date, and especially when going back through old photos from the film days)
Might the date be coded into the metadata of the photo? Most cameras and phones will do this - as long as your date is set correctly on the camera. Do you know how to check? (sorry, I just reread your post and you did suggest your old photos don’t have the date on them)
isn’t this ultimately a trivial distinction?
User input: date range
Internal interpretation: middle of date range ± distance to ends of range
User input: date ± accuracy
Internal interpretation: middle of date range ± distance to ends of range
People might prefer one input over the other. I think a date range is more intuitive for most people. But it shouldn’t matter internally, right?
I think it matters…
If you enter two dates, you don’t perceive how “large” the accuracy is (and let’s just use the term accuracy, for simplicity). Mar 1 to Sep 30 at a “casual glance” looks similar in accuracy to Mar 30 - Sep 1… is it twice as accurate? three times? or is it less accurate? For location, the accuracy value inscribes a circle around the pin location, so you can see what effect the accuracy value has, but even outside that, 10000m accuracy value is easily perceived as much larger than 100m accuracy, This encourages people that are setting the value manually to try and get it to as small as they realistically can.
And I am mentioning it as a preference that I personally have, so I wouldn’t agree that it is trivial at all! If it is stored internally and displayed as “date/time +/- accuracy value” and it can be optionally offered as an input format to enter it as two dates of a range, then I am happy for that! For some situations such as when you are on holiday and you know the start and end time of the holiday, then it would be more logical… but if I am aligning it to a “point date” then the other way makes sense, eg I might think “the apricot had not long flowered, so it was around the start of spring, give or take a couple weeks…”
Exports to GBIF use Darwin Core standards. Darwin Core in turn uses ISO standards for date/time. ISO allows for date/time to be represented by fine or coarse information – e.g. “2007-04-05T12:30” is a valid date/time, but “1981-04” (April 1981) is also valid. Many museum datasets in GBIF use vague dates because that was all that was recorded originally. But you can’t use +/- format to specify dates in ISO standards. So February 14 +/- 14 days is not ok, but just February is ok. It also allows intervals to be specified, but with start and end dates, e.g. February 1 to February 28.
Not sure. I know I can check “last modified”, but I never know if that was when it was uploaded to my computer, or when it was taken.
What I do (on Windows OS), is right click on the file and look at properties. (this may be what you’re doing, as well and I’m sure there’s something similar for Macs).
If I look at an old non-modified photo from 2014, I find:
Created: Tuesday, December 10, 2019
Modified: Saturday, April 12, 2014
Accessed: Tuesday, December 10, 2019
This photo was in folders that identified it as being taken on April 12. When I look at a processed photo (one that reflects some cropping and maybe moving an original photo into a new Photoshop file), the Modified date is April 13.
The 2019 dates are when I got my new computer and the file was moved from the old harddrive to the current C drive.
So, I would say, if the modified date is the same month/year as the folder you have the photo in, then it’s fairly likely the day shown is correct as well. Especially if it’s the original photo that was never edited by a piece of software. Although it wouldn’t be a tight reading of iNat’s guidelines, I wouldn’t think being a day or two off would make a difference.
Personally, I do think being off more than a day or two can make a difference. At least where I am, birds can show up for migration in a very tight window of time. If one sees bird species X on April 1st, it would be an aberration. But if one sees bird species X on April 29th, it would be within the known/expected range of time for observing that bird. The same could be true for development of young (hatchlings) or buds on trees or flowers of different plant life.
I’m not sure if that helped any. It’s just something I had to deal with when I wanted to upload old photos here and I’m always eager to offer some solution a person hasn’t thought of. Thankfully, 95% of my old observations were put into folders where I had designated the day/month/year and I had keep detailed notes about where and when I saw birds throughout the year. I knew those OCD tendencies would come in handy someday! I did have to pass over a few photos that I hadn’t keep good enough notes on.
My issue is where my files were copied onto a flash drive at one point so they all have the same dates.
We have much the same issues with fungi. They often are more affected by rain than anything, so knowing the day helps. With a hardy polypore mushroom being a week off wouldn’t hurt too much during the slower/non-growing seasons(birch polypore in spring or early summer), but with finicky fungi like black chanterelles, I wouldn’t want to be off by more than a day.
Long story short, I’d be more likely to upload an old moss picture than a fresh mushroom from a year ago. I do have some OCD tendencies with my personal sorting, but only down to species and genera in each month ;) Only good for a ball park estimate. This new camera is going to spoil me
For me this feature would be most useful for old memories where I can figure out the year and the month, but don’t have photos to find the date. I’d still like to note that I observed the species in a casual observation. Personally I don’t think more than a month would be necessary, but I can see why a season (e.g. summer 2008) would be desirable as well.
It would be useful for time lapse gifs that take place over a number of hours or days, as well. Currently there doesn’t seem to be an accurate and non-confusing way to upload observations like this, as is being discussed here: https://forum.inaturalist.org/t/how-should-i-make-time-lapse-observations-for-molds-growing-over-days-time/14488/6
I would also appreciate being able to select a date range where appropriate rather than guessing when putting in a date to prevent an entry from being relegated to a casual or equivalent observation. It would be helpful in cases of posting old photos when you don;t have an exact date, or when you may want to post a series of photos in a single post showing developmental stages of a single plant over the course of a season. I don’t see how this would detract from the majority of posts that can be entered with known exact dates.
It would be beneficial to me (and possibly to others in a similar situation) to have a date range option available. I have a small collection of lepidoptera I collected in my pre-teen years some 50 years ago. I still have them and would like to add their photos to iNaturalist. I know where they were collected, and the year, and a time frame (i.e. summer months, June thru’ August when I did my collecting) but not an exact day & month. I think this would still be somewhat useful to iNaturalist especially in an historical context.
A conceptually simple solution (if technically challenging) would be for iNat to adopt the DwC ISO date. There are a handlful of use cases folks have identified in this thread, so iNat wouldn’t have to support all the ISO Date variants.