I’ll add my thoughts here..
Imagery: The issue of outdated imagery is complicated because: 1. In iD we don't really know the date range that the imagery was taken (Bing is the exception not the rule, and we can get from their API only a range not a hard date) 2. It depends on what zoom the user happens to be looking at, not just the location. And the imagery changes constantly, and can depend on caching and CDN issues. So I don’t see a way for us to provide an automatic solution for this issue. Notes Tag: Yes, notes as a tag do "sort of" work right now. A user can draw an area (closed way with `area=yes`) around the place where the imagery is known to be outdated and add a `note` tag, and iD will show it in the sidebar if someone happens to hover or select the area. Notes are a bit problematic because they only appear in the language that the user created them in, and they can obviously be used for abuse. The idea of having some arbitrary user entered README text popup automatically as the user scrolls around in iD (possibly containing naughty ascii pictures) - this just isn’t going to happen. OSM Notes: You could use OSM notes to warn users about imagery issues, though we don’t currently show them in iD.. But we plan to add this eventually, and it might be a better way to solve this issue rather than using a tag. I like that OSM notes expire and can be marked as resolved. New Tag: Maybe we should define an actual tag for localized situations where you want to warn a future editor about something. Like a `warning=*`, tag that would go on the surrounding area. We could standardize on this so that e.g. `warning=imagery` could display a message (translated for the user) like “Imagery in this area may be outdated. Please do not make changes without local knowledge.” `note=*` could provide more detail, and you could delete the warning eventually after Bing is up to date. Thanks, Bryan > On Jun 11, 2015, at 8:45 PM, Ian Sergeant <inas66+...@gmail.com> wrote: > > Perhaps a nice objective tag, rather than README text. > > If a feature is new, add a start_date tag. > > The editor can then have options.. > > 1, Alert the user if the start date is more recent than the layers currently > displayed. > 2. Visually indicate if the start_date is within a configurable recency (say, > draw a halo around objects constructed in the past two years, or so). > > There is also some scope for automated analysis, rather than depend on free > text. > > Ian. > > > _______________________________________________ > Tagging mailing list > tagg...@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging _______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
