Opened 7 years ago
Last modified 6 years ago
#16082 new defect
Strange artifacts when warping imagery at South/North Pole
| Reported by: | Don-vip | Owned by: | team |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Core imagery | Version: | |
| Keywords: | template_report projection warping stereographic antarctic south pole polar | Cc: | bastiK, wiktorn |
Description (last modified by )
What steps will reproduce the problem?
- Enable projection
EPSG:3031(WGS 84 / Antarctic Polar Stereographic) - Add Bing layer
- Move to South Pole
- Drag the map around (no change of zoom)
What is the expected result?
Correct imagery displayed.
What happens instead?
Strange artifacts when warping, see below:
Build-Date:2018-03-11 18:28:30 Revision:13515 Is-Local-Build:true Identification: JOSM/1.5 (13515 SVN en) Windows 10 64-Bit OS Build number: Windows 10 Pro 1709 (16299) Memory Usage: 1302 MB / 3634 MB (348 MB allocated, but free) Java version: 1.8.0_162-b12, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM Screen: \Display0 1920x1080, \Display1 1920x1080, \Display2 1280x1024 Maximum Screen Size: 1920x1080 VM arguments: [-Dfile.encoding=UTF-8] Dataset consistency test: No problems found Plugins: + apache-commons (33668) + download_along (34081) + ejml (32680) + geotools (33958) + josm-recorder (3.0.2) + jts (32699) + opendata (34072) + utilsplugin2 (33991) + wikipedia (34079) Last errors/warnings: - W: No configuration settings found. Using hardcoded default values for all pools. - E: org.openstreetmap.josm.io.OsmApiException: ResponseCode=400, Error Header=<The maximum bbox size is 0.25, and your request was too large. Either request a smaller area, or use planet.osm> - E: Bad Request - <html>The OSM server 'api.openstreetmap.org' reported a bad request.<br><br>The area you tried to download is too big or your request was too large.<br>Either request a smaller area or use an export file provided by the OSM community.</html> - E: org.openstreetmap.josm.io.OsmApiException: ResponseCode=400, Error Header=<The maximum bbox size is 0.25, and your request was too large. Either request a smaller area, or use planet.osm> - E: Bad Request - <html>The OSM server 'api.openstreetmap.org' reported a bad request.<br><br>The area you tried to download is too big or your request was too large.<br>Either request a smaller area or use an export file provided by the OSM community.</html> - W: java.io.IOException: Attribution is not loaded yet - W: java.io.IOException: Attribution is not loaded yet - W: java.io.IOException: Attribution is not loaded yet - W: java.io.IOException: Attribution is not loaded yet - W: java.io.IOException: Attribution is not loaded yet
Attachments (6)
Change History (24)
by , 7 years ago
by , 7 years ago
by , 7 years ago
by , 7 years ago
by , 7 years ago
by , 7 years ago
comment:1 by , 7 years ago
| Description: | modified (diff) |
|---|
comment:2 by , 7 years ago
| Description: | modified (diff) |
|---|
comment:3 by , 7 years ago
| Description: | modified (diff) |
|---|
comment:4 by , 7 years ago
comment:5 by , 7 years ago
I don't think so, I wasn't surprised to see a black circle at first. But there are really strange artifacts I don't understand (the circle can become bigger, up to fill the full screen).
comment:7 by , 7 years ago
Replying to Don-vip:
or: we have an actual proof the Earth is flat :D
You mean all the GNSS software including 3D positioning algorithms I write at work is bullshit ;-) I hope not.
comment:8 by , 7 years ago
Hi, this is kind of what I was experiencing also, while experimenting with these projections. The algorithm has to pick a zoom level and if I recall correctly, it simply takes the center of the screen as reference. Given a certain zoom level, as you approach the pole, the tiles get smaller and smaller and you have to stop at some point. So the size of the black circle depends on the location of the screen center and it may appear erratic.
The algorithm was not designed with extreme scale difference on screen in mind. Certainly this isn't great, but I wasn't sure how to improve the situation.
comment:9 by , 7 years ago
| Summary: | Strange artifacts when warping imagery at South Pole → Strange artifacts when warping imagery at South/North Pole |
|---|
comment:11 by , 7 years ago
Did you try with high precision calculations for test?
E.g. BigDecimal or something alike?
That's probably not for production, but at least for test purposes it may help.
After some zooming in and out I got totally distorted images. That reminds me of the days when first implementing projections. There we had similar effects which I mainly solved by adding upper and lower bounds for zooming (which was a workaround and no fix).
comment:14 by , 6 years ago
It not just affect bing imagery, almost all imagery (as far as I tested) have this effect, even if you add an OSM layer and it is still the same (OSM should have certain level of support place to the south of 85 degre)
comment:15 by , 6 years ago
- It is also not limited to EPSG3031, see also https://i.imgur.com/KdRp9dJ.png and https://i.imgur.com/9jeO50k.png for UTM Zone 1N/1S/60N/60S (I mean those artifacts, not the polar circle)
comment:16 by , 6 years ago
Also, note that https://i.imgur.com/pQJ6srg.png the screenshot include a snapshot of navigating around 180 degree meridian in Fiji (See bottom left for coordinate and top left for zoom level), and for all the mapping service selected on the top right, none of them can be displayed correctly here when using either UTM 1S/60S or WGS84. However the display become normal in UTM projection once you move the 180 degree meridian away from the view, no matter toward the east or the west.
comment:17 by , 6 years ago
| Keywords: | polar added |
|---|
Has Bing data higher than 85deg? Normal TMS ends at 85.