Dates of imagery about editor-layer-index HOT 13 CLOSED

JSON schema includes a date-time definition already but it's not well-suited for imagery where frequently the only date is a year and we want to allow 2013 as a valid date.

Make it midnight the first day of the year. For computers to interpret the date as anything, they'll turn it into a date object anyway and make that assumption.

from editor-layer-index.

I'm fairly certain that year-only is a valid part of the ISO8601 datetime. e.g. "2013" should validate correctly.

For what it's worth:

Date.parse("2013");

returns 1356998400000 in Chrome at least.

from editor-layer-index.

Make it midnight the first day of the year. For computers to interpret the date as anything, they'll turn it into a date object anyway and make that assumption.

This is a good assumption for start_date, but bad for end_date, e.g. someone looking for imagery to see how an area looked in June 2012 wouldn't see imagery with start_date=2011 and end_date=2012.

from editor-layer-index.

And the alternative is what? Is there some incomplete-date have-it-both-ways representation and ui that I'm missing here?

from editor-layer-index.

And the alternative is what? Is there some incomplete-date have-it-both-ways representation and ui that I'm missing here?

Let's try to keep comments productive here please.

I see two ways to address this, in the data entered here, or with logic in the editor.

The first would have my 2009 imagery with start_date=2009 end_date=2010, the values being converted to the start of 2009 to the start of 2010. This is more work when creating the imagery database but less work to interpret.

The second would have my 2009 imagery with start_date=2009 end_date=2009, but the upper limit not rounded down, the values being converted to the start of 2009 to the end of 2009. This agrees with what people expect, but makes interpreting it harder for the software using the database.

Either works, but we need to make it clear which it is, or we'll end up with imagery entered the first way and interpreted the second way, which is a problem.

I lean towards the first. Intervals, including low accuracy intervals, are covered in ISO 8601 and those in theory should cover this issue, but I suspect support for low accuracy intervals is spotty.

from editor-layer-index.

First - thanks, Paul, for raising this here (it grew out of iD Issue #1929).

Secondly - I'd be tempted not to overthink the requirements too much. Having a start date and and end date doesn't fully describe when attributes of a paper map were updated ** but any attempt to add more detail would surely overcomplicate the decision process that iD (or anything else) has to go through when deciding what to do with the imagery? I'd have thought that just an end date (or "publish date" in the case of paper maps) would be enough in most cases.

** For example, old OS paper maps near me always used to say something like "ground surveyed in 1961, air surveyed in 1971, last revised 1981" or similar. They're not appropriate for an OSM imagery layer, but if they were I'd have said that the most relevant date for an editor to decide where to place it in a list would be either 1981 or 1971 dates.

from editor-layer-index.

I'd have thought that just an end date (or "publish date" in the case of paper maps) would be enough in most cases.

Most of the entries in this index are imagery where you can say it was flown between this date and this date. I'd say they're both pretty important if you know them. I'm also thinking about bing, which will give you a date range if you ask about a tile.

from editor-layer-index.

I would prefer that we keep this as simple as possible and have a single vintage attribute for each layer that gives a four-digit year describing roughly "when" the imagery represents. For example, USGS NAIP imagery for central Minnesota is captured over the course of several weeks of Summer in 2012, but released in 2013 as one large dataset. The vintage should be specified as "2012".

Do we have an existing layers where more precise vintage data would be useful?

from editor-layer-index.

Unless we have a specific use case in mind which requires processing imagery dates programmatically, I'm tempted to punt on this issue right now and just say add the relevant dates to the name or description.

from editor-layer-index.

@jfirebaugh said:

add the relevant dates to the name or description

👍

from editor-layer-index.

Do we have an existing layers where more precise vintage data would be useful?

Yes - my mosaiced layers have a range, as does the Australian and South African imagery @Firefishy hosts, and for landsat the date is very useful. For HOT work in Mali I've prepared landsat imagery where the season was hugely significant and I have a precise date range for the image. I realize that no editor is immediately going to support the attributes or do the type of searching I'd like to do

from editor-layer-index.

The "specific use case" is iD showing the most relevant imagery at the top of the list and the least relevant at the bottom. If the date's part of the name or description we're making the mapper rank imagery by importance, which if they're a newbie iD user, they may not be easily able to do.

On openstreetmap/iD#1929 I listed the available imagery near me in "relevance" order, and that pretty much correlates with date, except in cases where there is no data in a particular imagery layer at a particular location.

from editor-layer-index.

So... we could spend a few more days arguing about the date format so that it might be possible for some future version of iD to sort imagery in date order or we could do something simple like a vintage attribute or put the date in the description of the layer.

from editor-layer-index.