Bing imagery is lower quality in JOSM than in iD

[RedAuburn@…]

For some reason, JOSM has a different version of Bing Imagery than iD, and it has bad orthorectification & a worse resolution. by comparison, the iD imagery is well aligned, well orthorectified & higher resolution.

Example location: 51.48586,0.00924

[taylor.smock]

It looks like iD has a specific parameter indicating it is for use with ODBL licensed data.

[taylor.smock]

It looks like the "primary" difference has to do with the metadata api URL we are using.

+ iD
- JOSM
+ https://dev.virtualearth.net/REST/v1/Imagery/Metadata/AerialOSM?include=ImageryProviders&output=xml&key=
- https://dev.virtualearth.net/REST/v1/Imagery/Metadata/Aerial?include=ImageryProviders&output=xml&key=

See ​https://github.com/openstreetmap/iD/issues/9153 .

@RedAuburn: As a temporary workaround, you can set jmapviewer.bing.metadata-api-url to https://dev.virtualearth.net/REST/v1/Imagery/Metadata/AerialOSM?include=ImageryProviders&output=xml&key={apikey} in Advanced Preferences.

We need to figure out where we need to make changes. The problem here is that non-OSM services use our editor such as OpenHistoricalMap (non-ODBL licensed).

Options:

• On OSM server switch, update the jmapviewer.bing.metadata-api-url preference key (if default server, use AerialOSM, if non-default use Aerial)
• Change jmapviewer to use AerialOSM
  • This could have negative consequences for other downstream users of AerialOSM. This is the easiest, but probably not the best, solution.
  • Alternatively we can have a setter for the layer (see ​https://learn.microsoft.com/en-us/bingmaps/rest-services/imagery/get-imagery-metadata#template-parameters )
• Override getAttributionURL in CachedAttributionBingAerialTileSource
  • I think this is the "best" option if we don't make the layer configurable in JMapViewer

[RedAuburn]

Thank you for looking into it! :)

Unfortunately, changing the API URL doesn't seem to fix it, even when flushing tile cache & re-adding the preset etc. is it likely that Bing are serving different imagery to iD based on their API key?

[taylor.smock]

No; I verified the imagery when I had set jmapviewer.bing.metadata-api-url manually. I did have reset cache.bing.attribution.xml, flush the tile cache, and restart JOSM when I was using an existing profile though.

I used ​https://www.openstreetmap.org/way/503581667 for testing.

[RedAuburn]

ah! it's working now! Thank you so much :)

[taylor.smock]

@stoecker: When you closed this as worksforme, was it due to Bing imagery working, not knowing if MS wants us to switch to the different (OSM specific?) layer, or the reporter saying that the workaround works.

@RedAubum: Point of clarification: were you saying that the workaround works or that the default Bing aerial layer in JOSM has the same result as the Bing aerial layer in iD?

[stoecker]

Ah. Overlooked some stuff.

[RedAuburn]

@taylor.smock, to clarify, once I changed the API URL & restarted, I got the same higher resolution imagery as iD 👍

[taylor.smock]

After thinking about it for a bit, I think that the best option is changing jmapviewer to have a setLayer function or equivalent. It is the most flexible option, and there is a Streetside layer which we might be able to use for the MS Streetside plugin. If someone ever gets around to fixing that plugin.

[gaben]

Is it possible to stuff the change in this release cycle?

[taylor.smock]

I've been intending on trying to do that; I need to patch JMapViewer, do a release for JMapViewer (which may require poking stoecker or Don-vip -- I don't think I can start the job that updates JMapViewer in nexus, but that might happen automatically), update the JMapViewer dependency, then (finally) make a change in JOSM to set the layer.

I could do a hack where we call super, but then replace /Aerial with /AerialOSM, but that seems like it could be brittle in the future.

One caveat is that the imagery seems to be older with AerialOSM, even if it is sharper/clearer.

[gaben]

Thanks for the explanation. I've never touched JMapViewer, that's why I'm a bit concerned about the available time, especially because of the

which may require poking stoecker or Don-vip

part 😄

[GerdP]

If the sharper image is older, it would be best to have both layers. Is that possible?

[taylor.smock]

In 36174/osm:

See #23227: Add layer option for Bing Imagery

iD/Rapid use the layer AerialOSM instead of Aerial, and that layer is higher
resolution (but older) in some locations. This adds a method to set the Bing Maps
layer (see ​https://learn.microsoft.com/en-us/bingmaps/rest-services/imagery/get-imagery-metadata#template-parameters )
so that downstream users can decide whether their agreement with Bing Maps allows
the use of AerialOSM. We have not received communication as to which layer Bing
wants us to use for editing OpenStreetMap.

[stoecker]

Why do you remove the second escape here? } is a regexp pattern element and should be escaped. It may work without, but I don't think that's correct.

private static final Pattern subdomainPattern = Pattern.compile("\\{subdomain\\}");
private static final Pattern quadkeyPattern = Pattern.compile("\\{quadkey\\}");
private static final Pattern culturePattern = Pattern.compile("\\{culture\\}");

[taylor.smock]

The } character only has special meaning as the end of a { group. If there is an unescaped { with a following } prior to the actual }, then the first } needs to be escaped with \\.

You can make an argument either way for escaping } versus not escaping }, but it is not a pattern element on its own; it must be used in conjunction with an unescaped {.

This reasoning also applies to ]; it only needs to be escaped inside a character class ([a-b\\]]).

The reason why we can "escape" a character which we don't need to escape can be found in ​Pattern javadocs:

A backslash may be used prior to a non-alphabetic character regardless of whether that character is part of an unescaped construct.

[stoecker]

RegExp in Java us ugly. The only proper RegExp implementation is Perl. There is a reason why it's PCRE. ;-)

[taylor.smock]

Ticket retargeted after milestone deleted

[mbrzakovic]

Hi all and thank you for your patience,

Please use the following guidance ​https://github.com/openstreetmap/iD/issues/9153#issuecomment-1814220682
to resolve this ticket.

Milos Brzakovic | Microsoft

[taylor.smock]

Ticket retargeted after milestone closed

[taylor.smock]

In 36197/osm:

Release v2.18: See #23227: Add layer option for Bing Imagery

[taylor.smock]

Replying to GerdP:

If the sharper image is older, it would be best to have both layers. Is that possible?

Based off of current guidance from MS, no.

[taylor.smock]

In 18912/josm:

Fix #23227: Use the appropriate Bing layer

Microsoft guidance indicates that they do not want us to use the old Aerial
layer. This appears to be due to increasing usage of their API and their desire
to separate free usage from paid usage.