Id: Suggest or choose an imagery automatically depending on country

[SviMik]

The problem:
We have a very good imagery provided by Maa-amet in Estonia. It has a high resolution and almost no offset errors. Unfortunately, most iD users start mapping using Bing without even checking if there are alternatives. New objects being poorly mapped is only a minor issue. The worst thing is that they start 'fixing' the existing geometry, which was not only correct, but a very precise. Their actions sometimes are so bad it looks like a vandalism.

Suggestions:

1. Create a list of recommended imagery sources, which would consist of a region (for example, country) and a recommended imagery to use in that region.
2. For new users, set that imagery by default.
3. Alternatively, suggest the user to check that particular imagery if other imagery was chosen before. For example, it can be a message like: "It seems like a better imagery {imagery_name} is available in this country. Switch the imagery?"

The list doesn't have to be an extensive one, and it doesn't have to be filled in one go. New records can be added, for example, by suggestions from local communities.

[quincylvania]

Hi @SviMik, iD gets its imagery through the editor-layer-index project. There's a best property that indicates a source is particularly good for the area it covers. iD defaults to these when possible and prioritizes them in the list.

Luckily this means there's already an easy solution! Try opening an issue or pull request at the index repo to add best=true to the good imagery.

Here's the Estonia directory: https://github.com/osmlab/editor-layer-index/tree/gh-pages/sources/europe/ee

[SviMik]

https://github.com/osmlab/editor-layer-index/blob/gh-pages/sources/europe/ee/EstoniaOrtho%28Maaamet%29.geojson

It already has "best": true since at least 2018. Then I don't understand why it doesn't work.

By 'doesn't work' I mean not necessarily a bug, but the fact that people continue using Bing in Estonia despite the tremendous difference in quality. I can't see any reasonable explanation why someone would deliberately choose Bing, that's seems very unlikely to me. I think it may be either a technical problem or some UI/UX problem.

Is there a way to explicitly tell people to NOT use Bing in our country? Like some kind of warning, which would tell them that they're likely making a mistake.

[BjornRasmussen]

Any mapper who launches iD in another country, and then moves the map over to Estonia to map will have Bing as their background imagery, so maybe that's the issue.

[SviMik]

I've just launched iD probably first time in my life. I did it right away in Estonia. The imagery is Bing, and it does not prioritize Maaamet in the list. Moreover, the one that has best=true didn't even fit in the first page! It's there though, I just need to scroll down. Should I create another, more specific issue?

[bhousel]

https://github.com/osmlab/editor-layer-index/blob/gh-pages/sources/europe/ee/EstoniaOrtho%28Maaamet%29.geojson

It already has "best": true since at least 2018. Then I don't understand why it doesn't work.

iD can not use this source because the only projection available is EPSG:3301

The list of supported projections in iD for WMS sources is:
https://github.com/openstreetmap/iD/blob/7c488d9816119132feac85aa0ebd661186c0f3ba/data/update_imagery.js#L57-L67

[SviMik]

Thanks, now I see the issue. I already noticed that it doesn't work, but thought it's just me, or some temporary issue.
How to solve the issue? Can more than one layer have best=true or what solution can you suggest?
The best option would be to specify a 2nd choice in case of projection is not supported, but I'm not sure if a thing like that is likely to be implemented.

[bhousel]

Can more than one layer have best=true

Yes, there can be several sources that have best=true..
iD will choose as a default the first one it finds, and bump any of them to the top of the "Background" list.

[SviMik]

Any reason why iD is offering that EPSG:3301 imagery in the list while it knows it does not support it? Is it a bug? It creates an illusion that the imagery was successfully added, and was one of the reasons it took so long before the problem was noticed.

[bhousel]

Any reason why iD is offering that EPSG:3301 imagery in the list while it knows it does not support it?

I dont think iD is actually offering the one linked to above in its list. It is showing a bunch of similar ones though.

[SviMik]

I'm not sure what else it can be. At least the name is exact match.

[bhousel]

There are 2 sources with "name": "Estonia Ortho (Maaamet)",:

• the TMS one
• and the EPSG:3301 one

If you move the best:true property to the TMS one, iD will pick it up and use it.

(I don't know anything about these sources, maybe they are really the same thing and one can be removed?)

[SviMik]

If you move the best:true property to the TMS one, iD will pick it up and use it.

The problem is that the TMS one is much worse, it looks like jpeg with 0% quality for some reason. It's completely unusable.

I suggest using Esri for Estonia, it looks exactly as Maaamet EPSG:3301, the same high quality. Unfortunately, editor-layer-index developers bumped into a problem:

We can't currently mark one source as 'best' by region - it's all or nothing, everywhere or nowhere, best or not.

Apparently they can't mark Esri as 'best' just for Estonia. Any ideas?

[bhousel]

Apparently they can't mark Esri as 'best' just for Estonia. Any ideas?

I guess reach out to whomever is maintaining that TMS server and work with them to improve the imagery that it serves?

[SviMik]

I guess reach out to whomever is maintaining that TMS server and work with them to improve the imagery that it serves?

Looks like the quality loss is because their primary projection is EPSG:3301, and other projections are converted from that. The difference is because Esri does it a bit better, although you may still notice that it's a bit blurry. The EPSG:3301 is the sharpest and highest resolution one.

From worst to best:

1. http://svimik.com/estonia_maaamet_tms_mercator.png
2. http://svimik.com/estonia_esri.png
3. http://svimik.com/estonia_maaamet_epsg_3301.png

Is it possible to add EPSG:3301 to iD? It would solve all the problems at once.

[bhousel]

Is it possible to add EPSG:3301 to iD? It would solve all the problems at once.

We can't do that, but I will poke through the server metadata for you and see whether they provide the data in a better format.

[bhousel]

ok so far I've found that the TMS proxy only goes up to z18, which explains some of the blurriness.

@SviMik, I'm not sure what those images are that you posted above.. They look like you took screenshots from an app, not actual tiles, so we can't really directly compare the quality. Also it would be great if you shared the location (lat/long/zoom) that you're comparing.

[SviMik]

The screenshots are from JOSM.
Location I'm comparing: https://www.openstreetmap.org/#map=18/59.44016/24.88439

In iD the Maaamet TMS looks even worse:
http://svimik.com/estonia_maaamet_tms_id.png

[bhousel]

OK so anyway, I spent some time on this today and found that the server really only does work in EPSG:3301. It is not easy investigating WMS server capabilities when the documentation is in language I don't speak and the agency publishes their guides in PDF files, but I tried. 🌟

I don't know how difficult getting support for this into iD would be. I looked into libraries like Proj4js and also took a look at how Leaflet supports layers using different projections.

I really know a lot less about maps and GIS stuff than people probably think I do, and that makes me sad. I'm not super involved in iD development anymore, and that makes me sad too. Would love for someone smarter or more motivated than me to step in and solve this issue, but I'm not holding my breath. Sorry!

[quincylvania]

Would love for someone smarter or more motivated than me to step in and solve this issue, but I'm not holding my breath.

Once we do #6483, this is exactly the kind of issue that a 3rd party developer that depends on iD might step in to solve, to the benefit of all iD projects.

[SviMik]

I don't know how difficult getting support for this into iD would be. I looked into libraries like Proj4js and also took a look at how Leaflet supports layers using different projections.

I've used Proj4js once, works like that (don't know if it helps somehow):

Proj4js.defs["EPSG:3301"] = "+proj=lcc +lat_1=59.33333333333334 +lat_2=58 +lat_0=57.51755393055556 +lon_0=24 +x_0=500000 +y_0=6375000 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs";
var p3301 = new Proj4js.Proj("EPSG:3301");
var p4326 = new Proj4js.Proj("EPSG:4326");

var point = new Proj4js.Point(x, y);
Proj4js.transform(p4326, p3301, point);
x=point.x;
y=point.y;

Once we do #6483, this is exactly the kind of issue that a 3rd party developer that depends on iD might step in to solve, to the benefit of all iD projects.

I'm sorry but I don't really understand what you mean. I'd like to see this problem solved on www.openstreetmap.org, not on some third-party project which #6483 is about.

[quincylvania]

I'm sorry but I don't really understand what you mean. I'd like to see this problem solved on www.openstreetmap.org, not on some third-party project which #6483 is about.

I mean that in the future iD could be used by many different projects, so if another developer fixes something for their project it would also be fixed on openstreetmap.org for free. I know that isn't totally helpful right now, so don't worry about it 😅

[jidanni]

Maybe "Editor's choice" https://www.google.com/search?q=seal+of+approval+with+ribbons&tbm=isch could be placed next to items in the imagery radio button list to steer users to them... More colorful than stars...

[quincylvania]

@jidanni I've actually been considering an icon change since star icons often refer to user favorites. A ribbon, crown, or thumbs-up might do. It'd still be monochrome.

[jidanni]

At least I could find a ribbon.

[jidanni]

OK I see many Award-Medal on https://www.unicode.org/emoji/emoji-requests.html