Comments (11)
Offtopic:
I wish iD would remember my choices and other settings across sessions...
FYI: If you use the stand alone version from the readme in GitHub you get proper url parses that store the selected imagery. You can then bookmark that.
from editor-layer-index.
Thank you for that hint. I gather that involves running it locally. I might try that.
No, you can use https://ideditor-release.netlify.app/#background=nrw_ortho_wms&disable_features=boundaries&map=18.14/50.77696/6.08326 (from https://github.com/openstreetmap/id?tab=readme-ov-file#participate)
from editor-layer-index.
Back to the issue at hand: I think @pathmapper it would be best if you took over here since you introduced the data in #2022.
We have a few things fix here, IMO
- there was a "best" flag on a non-aerial imagery, which was already fixed in #2277
- the current "best" flag is not a good pick, because it does not cover the area that is defined, so users see a blank screen
This might be fixed by #2288 - the naming of the layers does not allow users to understand what the differences are
I did no research in this area other than scanning the comments in #2022 (comment) and similar issues.
But I think we have to improve the situation soon by…
- if possible, change the area-definition to the area where images are actually present; your comment above could mean that this might be possible. But should the area change constantly, that would not work.
- we need to pick a "best" layer that shows data for all the area that is defined in the area-defintion. Everything else is just bad UX for users. It is great if there is possibly newer data, but that has to be a secondary step, selected by mappers that know about those things.
Given those constrains, what would you say is the best way forward, @pathmapper
from editor-layer-index.
If there are no other "best" sources, we'd get Bing Maps because it's alphabetically the first.
True, that's also not nice. But at least there's no layer advertised as best
which is outdated for large areas.
I don't have a strong opinion here, go with dop
as best
if you want.
Just keep in mind that it's expecteded that idop
will get 100% coverage this year so you will have two sources covering 100% of NRW but which are each only the most recent for ~50% compared to the other one.
(btw the "blurryness" is due to the fact that idop
has 20 cm ground resolution compared to dop
which has 10 cm)
Also new vdop
will be available soon which then will be ~2 years more recent than dop
.
I really do like the comment from #130 (comment):
best
was a good enough hack when we really only had Bing, Mapbox, and whatever local imagery to choose from. We have so many more imagery to trace from now that we need something a bit more nuanced (this is a great problem to have!)
So it's time for something new, looks like #130 is a good place for anyone who has some suggestions to join the discussion.
from editor-layer-index.
I always understood best as most recent available data, because currentness of data is crucial if one wants to trace things for OSM.
Resolution also matters (extreme example: daily updated satellite imagery with resolution of 100m is worse than aerial with resolution of 1cm updated 6 months ago).
Quality of georeferencing, colours, when it was taken (leafless imagery) may also matter.
from editor-layer-index.
See also #2262
from editor-layer-index.
It's been completely blank for weeks because all the imagery is now in the proper "NRW Orthophoto". They removed "done" areas from vDOP as they worked on them.
Today it's even the default choice. "NRW Liegenschaftsregister" used to be the default but it loads really slowly, so that shouldn't be the first choice either.
"NRW Orthophoto" should be top choice. It loads quickly and it's up to date.
I wish iD would remember my choices and other settings across sessions...
Unless someone else is working on it, I'll swap the "best"
properties of NRW vDOP and NRW Orthophoto, then open a PR.
from editor-layer-index.
Thank you for that hint. I gather that involves running it locally. I might try that. I'm already redirecting tile requests through a local nginx because the NRW WMS tells clients to not cache at all, which I find silly... i.e. I'm already somewhat into running things locally.
I just noticed that this issue here might have been created with the intention of perhaps removing the vDOP entry. I have no strong feelings on that either way.
from editor-layer-index.
I don't have much to add to #2022 (comment):
It all depends on how best is definied, and IMHO there is currently no such clear definition. So this should be resolved.
I always understood best as most recent available data, because currentness of data is crucial if one wants to trace things for OSM.
if possible, change the area-definition to the area where images are actually present; your comment above could mean that this might be possible. But should the area change constantly, that would not work.
The area is changing constantly, e.g. for
https://ideditor-release.netlify.app/#background=nrw_idop_wms&disable_features=boundaries&map=18.56/51.34159/6.33003
nrw_idop_wms
is currently more recent than nrw_otho_wms
(link)
we need to pick a "best" layer that shows data for all the area that is defined in the area-defintion.
Do we really need to pick a "best" layer? For NRW we are having three different aerial sources, and it's constantly changing which source of them is the most recent for a given area.
Given the lack of a clear definition for what is "best", I currently won't assign "best" to any of the three sources.
from editor-layer-index.
I think that casual users, entering the editor, should never be faced with a blank background layer. That is just a bad user experience. And it's annoying to everyone using the editor.
Those vDOP and iDOP layers are "incomplete" and constantly changing. Even worse, the vDOP layer "lost" content over time (as it was done processing and incorporated into "NRW Orthophoto", the normal DOP), so if one saw imagery with the default behavior yesterday, and then opened the editor again today, and it was blank where it showed something yesterday, that is utterly bewildering.
Those should definitely not be the default picks.
They should remain though, with a description of what to expect of those layers, and what not to expect.
One could also "advertise" those layers in the description of the regular "NRW Orthophoto".
I did not expect my PR to be considered controversial.
from editor-layer-index.
Given the lack of a clear definition for what is "best", I currently won't assign "best" to any of the three sources.
What happens if none of the NRW sources are tagged as "best"?
If there are no other "best" sources, we'd get Bing Maps because it's alphabetically the first.
If there are other "best" sources, as happens near the borders and sometimes a sizable distance "inland", then those take precedence, but they're blank in NRW.
A simple and generally beneficial change is to "tolerate" dop
(NRW Orthophoto) as "best". It is the best choice in general, considering the downsides of vdop
(completely blank!) and idop
(blurry, 50% coverage).
from editor-layer-index.
Related Issues (20)
- Oakland County, Michigan Orthoimagery 2023
- Ireland British War Office 1:25k GSGS 3906 bounding polygon is too rough
- King County, WA (Seattle, US) Orthoimagery 2019, 2021 HOT 2
- Add Ljubljana high-res orthophotos HOT 2
- rizwan HOT 2
- France previous IGN Ortho HR are not loading
- TIGERweb
- Change of URL for "IndianaMap Orthoimagery - Latest Available"
- WMS dataset layers of City of Tampere
- Reinstate NRW_Ortho as best for NRW HOT 10
- icon for "LINZ-NZ-Bay-of-Plenty-2014" layer is broken HOT 3
- in some areas vector map, not aerial, is default HOT 4
- Mecklenburg County NC Imagery Not Working
- Update OS OpenMap Local (Great Britain)
- Request: Multiple custom layers HOT 3
- Default imagery doesn't load in JOSM
- au/act urls will need to be updated due to server shutdown 31 May 2024. HOT 2
- South Central Ontario Orthoimagery (2018)
- Imagery layers not working
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from editor-layer-index.