Modify

#23227 closed defect (fixed)

Bing imagery is lower quality in JOSM than in iD

Reported by: RedAuburn@… Owned by: RedAuburn@…
Priority: normal Milestone: 23.12
Component: JMapViewer Version: latest
Keywords: bing Cc: stoecker, spiregrain

Description

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

Attachments (0)

Change History (28)

comment:1 by taylor.smock, 13 months ago

Milestone: 23.10

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

comment:2 by taylor.smock, 13 months ago

Keywords: bing added

comment:3 by taylor.smock, 13 months ago

Cc: stoecker added

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
  • Override getAttributionURL in CachedAttributionBingAerialTileSource
    • I think this is the "best" option if we don't make the layer configurable in JMapViewer

comment:4 by RedAuburn, 13 months ago

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?

comment:5 by taylor.smock, 13 months ago

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.

comment:6 by RedAuburn, 13 months ago

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

comment:7 by stoecker, 13 months ago

Resolution: worksforme
Status: newclosed

comment:8 by taylor.smock, 13 months ago

@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?

comment:9 by stoecker, 13 months ago

Resolution: worksforme
Status: closedreopened

Ah. Overlooked some stuff.

comment:10 by stoecker, 13 months ago

Owner: changed from team to RedAuburn@…
Status: reopenedneedinfo

comment:11 by RedAuburn, 13 months ago

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

comment:12 by taylor.smock, 13 months ago

Component: Core imageryJMapViewer

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.

comment:13 by gaben, 13 months ago

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

comment:14 by taylor.smock, 13 months ago

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.

in reply to:  14 comment:15 by gaben, 13 months ago

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 😄

comment:16 by GerdP, 13 months ago

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

Last edited 13 months ago by GerdP (previous) (diff)

comment:17 by taylor.smock, 13 months ago

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.

comment:18 by stoecker, 13 months ago

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\\}");

comment:19 by taylor.smock, 13 months ago

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.

comment:20 by stoecker, 13 months ago

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

comment:21 by taylor.smock, 12 months ago

Milestone: 23.1023.11

Ticket retargeted after milestone deleted

comment:22 by mbrzakovic, 12 months ago

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

comment:23 by spiregrain, 12 months ago

Cc: spiregrain added

comment:24 by taylor.smock, 11 months ago

Milestone: 23.11

Ticket retargeted after milestone closed

comment:25 by taylor.smock, 11 months ago

Milestone: 23.12

comment:26 by taylor.smock, 11 months ago

In 36197/osm:

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

in reply to:  16 comment:27 by taylor.smock, 11 months ago

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.

comment:28 by taylor.smock, 11 months ago

Resolution: fixed
Status: needinfoclosed

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.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain RedAuburn@….
as The resolution will be set.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.