Opened 13 months ago
Closed 11 months ago
#23227 closed defect (fixed)
Bing imagery is lower quality in JOSM than in iD
Reported by: | Owned by: | ||
---|---|---|---|
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 , 13 months ago
Milestone: | → 23.10 |
---|
comment:2 by , 13 months ago
Keywords: | bing added |
---|
comment:3 by , 13 months ago
Cc: | 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, useAerialOSM
, if non-default useAerial
) - 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 )
- This could have negative consequences for other downstream users of
- Override
getAttributionURL
inCachedAttributionBingAerialTileSource
- I think this is the "best" option if we don't make the layer configurable in JMapViewer
comment:4 by , 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 , 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:7 by , 13 months ago
Resolution: | → worksforme |
---|---|
Status: | new → closed |
comment:8 by , 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 , 13 months ago
Resolution: | worksforme |
---|---|
Status: | closed → reopened |
Ah. Overlooked some stuff.
comment:10 by , 13 months ago
Owner: | changed from | to
---|---|
Status: | reopened → needinfo |
comment:11 by , 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 , 13 months ago
Component: | Core imagery → JMapViewer |
---|
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.
follow-up: 15 comment:14 by , 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.
comment:15 by , 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 😄
follow-up: 27 comment:16 by , 13 months ago
If the sharper image is older, it would be best to have both layers. Is that possible?
comment:18 by , 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 , 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 , 13 months ago
RegExp in Java us ugly. The only proper RegExp implementation is Perl. There is a reason why it's PCRE. ;-)
comment:22 by , 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 , 12 months ago
Cc: | added |
---|
comment:25 by , 11 months ago
Milestone: | → 23.12 |
---|
comment:27 by , 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.
It looks like iD has a specific parameter indicating it is for use with ODBL licensed data.