You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.
Reporter: SomeoneElse [Submitted to the original trac issue database at 7.40am, Monday, 4th August 2014]
The problem with this is that some backgrounds (Bing, OSSV, OS Locator) are more useful and more up to date than others (7th series, the various NLS ones).
New users get no clue from the UI which backgrounds are likely to be a good representation of what's there now (Bing) and which not (NLS Bart's half-inch from when Queen Victoria was on the throne).
We've already had "new user not realising antique map is rubbish" issues in Derbyshire with iD (which suffers from the same problem).
I did attempt (some time ago now) to get agreement on would be a sensible list of backgrounds to offer to new editors (in iD) but got significant pushback on the mailing lists (which might have been because Open Historical Map uses a generic iD instance and the same imagery list) so removing things from the generic imagery list is probably not an option.
That started out as part of openstreetmap/iD#1929 but then was spun off into osmlab/editor-layer-index#29 , which is now closed; so is there a date available in the generic imagery list that could be used to sort available layers by?
The text was updated successfully, but these errors were encountered:
Author: Richard [Added to the original trac issue at 3.23pm, Wednesday, 6th August 2014]
Unlike iD, P2 isn't the principal editor for new users (apart from the minority of unlucky souls using IE) so I don't see that as a hugely significant issue.
If you can find useful, supported fields in http://osmlab.github.io/editor-imagery-index/imagery.json (which is what P2 reads) then I'm open to the list being sorted that way. I won't pretend it'd be a huge priority for me, but someone else might want to do it, of course.
Author: pnorman [Added to the original trac issue at 3.40pm, Wednesday, 6th August 2014]
osmlab/editor-layer-index#35 is probably more relevant was an attempt to sort out the GB imagery and add additional items via a list of historic imagery. The view expressed was that the antique out of copyright maps were still useful. I disagreed, but didn't really push the issue, being non-local.
If some of the imagery layers in editor-imagery-index are not useful for OpenStreetMap editing, they should be removed.
For the discussion of fields for indicating default imagery to show (on a worldwide basis) and the best imagery to show in an area, see osmlab/editor-layer-index#72.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Reporter: SomeoneElse
[Submitted to the original trac issue database at 7.40am, Monday, 4th August 2014]
The problem with this is that some backgrounds (Bing, OSSV, OS Locator) are more useful and more up to date than others (7th series, the various NLS ones).
New users get no clue from the UI which backgrounds are likely to be a good representation of what's there now (Bing) and which not (NLS Bart's half-inch from when Queen Victoria was on the throne).
We've already had "new user not realising antique map is rubbish" issues in Derbyshire with iD (which suffers from the same problem).
I did attempt (some time ago now) to get agreement on would be a sensible list of backgrounds to offer to new editors (in iD) but got significant pushback on the mailing lists (which might have been because Open Historical Map uses a generic iD instance and the same imagery list) so removing things from the generic imagery list is probably not an option.
That started out as part of openstreetmap/iD#1929 but then was spun off into osmlab/editor-layer-index#29 , which is now closed; so is there a date available in the generic imagery list that could be used to sort available layers by?
The text was updated successfully, but these errors were encountered: