#14593 closed defect (worksforme)
Can't load more than 3 imagery (background) layers
Reported by: | pbb | Owned by: | team |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Core Webstart | Version: | |
Keywords: | template_report jnlp memory | Cc: | michael2402, wiktorn |
Description (last modified by )
What steps will reproduce the problem?
- Download some area from OpenStreetMap.
- Add three background layers with satellite and other imagery.
- Add a fourth background layer.
What is the expected result?
The last layer should display just as the previous layers.
What happens instead?
While the layer is shown in the Layers window, it is not displayed on the map. Hiding the other layers does not help. But as soon as I delete one of the other background layers, the new one is displayed immediately. This connected to background layers; deleting the data layer does not help.
Please provide any additional information below. Attach a screenshot if possible.
I have this problem on two computers, while a third one (the oldest computer) does NOT have this problem.
System info from one of the computers having this problem:
URL:http://josm.openstreetmap.de/svn/trunk Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b Last:Changed Date: 2017-02-26 23:10:22 +0100 (Sun, 26 Feb 2017) Build-Date:2017-02-26 22:34:39 Revision:11639 Relative:URL: ^/trunk Identification: JOSM/1.5 (11639 en_GB) Windows 10 64-Bit Memory Usage: 197 MB / 247 MB (26 MB allocated, but free) Java version: 1.8.0_121-b13, Oracle Corporation, Java HotSpot(TM) Client VM Screen: \Display0 1920x1080 Maximum Screen Size: 1920x1080 VM arguments: [-Djava.security.manager, -Djava.security.policy=file:<java.home>\lib\security\javaws.policy, -DtrustProxy=true, -Djnlpx.home=<java.home>\bin, -Djnlpx.origFilenameArg=%UserProfile%\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\56\1ee8cfb8-24c94ff3, -Djnlpx.remove=false, -Djava.util.Arrays.useLegacyMergeSort=true, -Djnlpx.splashport=62767, -Djnlp.application.href=https://josm.openstreetmap.de/download/josm.jnlp, -Djnlpx.jvm=<java.home>\bin\javaw.exe] Dataset consistency test: No problems found Plugins: + Mapillary (v1.4.2) + OpenStreetCam (53) + PicLayer (33148) + apache-commons (32994) + apache-http (32699) + gson (32680) + imagery_offset_db (33004) + mapdust (33044) + tag2link (33035) Last errors/warnings: - E: Failed to locate image 'https://dl.dropboxusercontent.com/u/4031522/foto/gst_icon.png' - E: Failed to locate image 'https://dl.dropboxusercontent.com/u/4031522/foto/gst_icon.png' - E: Failed to locate image 'https://dl.dropboxusercontent.com/u/4031522/foto/gst_icon.png' - E: Failed to locate image 'https://dl.dropboxusercontent.com/u/4031522/foto/gst_icon.png' - E: Failed to locate image 'https://dl.dropboxusercontent.com/u/4031522/foto/gst_icon.png' - E: Failed to locate image 'https://dl.dropboxusercontent.com/u/4031522/foto/gst_icon.png' - E: Failed to locate image 'https://dl.dropboxusercontent.com/u/4031522/foto/gst_icon.png' - E: Failed to locate image 'https://dl.dropboxusercontent.com/u/4031522/foto/gst_icon.png' - E: Failed to locate image 'https://dl.dropboxusercontent.com/u/4031522/foto/gst_icon.png' - E: Failed to locate image 'https://dl.dropboxusercontent.com/u/4031522/foto/gst_icon.png'
The following system report is from the computer that does NOT have this problem:
URL:http://josm.openstreetmap.de/svn/trunk Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b Last:Changed Date: 2017-02-26 23:10:22 +0100 (Sun, 26 Feb 2017) Build-Date:2017-02-26 22:34:39 Revision:11639 Relative:URL: ^/trunk Identification: JOSM/1.5 (11639 en) Windows 10 64-Bit Memory Usage: 769 MB / 1794 MB (504 MB allocated, but free) Java version: 1.8.0_111-b14, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM Screen: \Display0 1920x1080 Maximum Screen Size: 1920x1080 VM arguments: [-Djava.security.manager, -Djava.security.policy=file:<java.home>\lib\security\javaws.policy, -DtrustProxy=true, -Djnlpx.home=<java.home>\bin, -Djnlpx.origFilenameArg=%UserProfile%\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\56\1ee8cfb8-52c2697e, -Djnlpx.remove=false, -Djava.util.Arrays.useLegacyMergeSort=true, -Djnlpx.splashport=54866, -Djnlp.application.href=https://josm.openstreetmap.de/download/josm.jnlp, -Djnlpx.jvm=<java.home>\bin\javaw.exe] Dataset consistency test: No problems found Plugins: + Mapillary (v1.4.2) + PicLayer (33148) + apache-commons (32994) + apache-http (32699) + download_along (32946) + ejml (32680) + geotools (33042) + imagery_offset_db (33004) + jts (32699) + log4j (32699) + measurement (33088) + opendata (33156) + utilsplugin2 (33182) Tagging presets: + https://josm.openstreetmap.de/josmfile?page=Presets/LaneAttributes&zip=1 Map paint styles: - https://josm.openstreetmap.de/josmfile?page=Styles/Sidewalks&style&zip=1 - https://josm.openstreetmap.de/josmfile?page=Styles/Lane_and_Road_Attributes&zip=1 Last errors/warnings: - E: Failed to locate image 'https://dl.dropboxusercontent.com/u/4031522/foto/gst_icon.png' - E: Failed to locate image 'https://dl.dropboxusercontent.com/u/4031522/foto/gst_icon.png' - E: Failed to locate image 'https://dl.dropboxusercontent.com/u/4031522/foto/gst_icon.png' - E: Failed to locate image 'https://dl.dropboxusercontent.com/u/4031522/foto/gst_icon.png' - E: Failed to locate image 'https://dl.dropboxusercontent.com/u/4031522/foto/gst_icon.png' - E: Failed to locate image 'https://dl.dropboxusercontent.com/u/4031522/foto/gst_icon.png' - E: Failed to locate image 'https://dl.dropboxusercontent.com/u/4031522/foto/gst_icon.png' - E: Failed to locate image 'https://dl.dropboxusercontent.com/u/4031522/foto/gst_icon.png' - E: Failed to locate image 'https://dl.dropboxusercontent.com/u/4031522/foto/gst_icon.png' - E: Failed to locate image 'https://dl.dropboxusercontent.com/u/4031522/foto/gst_icon.png'
Attachments (3)
Change History (14)
by , 8 years ago
Attachment: | Clipboard Image.jpg added |
---|
by , 8 years ago
Attachment: | Clipboard Image (2).jpg added |
---|
The layer is shown as soon as one of the other layers is removed
comment:2 by , 8 years ago
backlink: https://help.openstreetmap.org/questions/55336/josm-wont-load-more-than-3-background-layers (now closed there)
Sadly, I could not reproduce the problem.
URL:http://josm.openstreetmap.de/svn/trunk Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b Last:Changed Date: 2017-02-26 23:10:22 +0100 (Sun, 26 Feb 2017) Build-Date:2017-02-26 22:34:39 Revision:11639 Relative:URL: ^/trunk Identification: JOSM/1.5 (11639 de) Linux Memory Usage: 290 MB / 1820 MB (117 MB allocated, but free) Java version: 1.8.0_121-b13, Oracle Corporation, OpenJDK 64-Bit Server VM Screen: :0.0 <redacted> Maximum Screen Size: <redacted> VM arguments: [-Dawt.useSystemAAFontSettings=on, -Dswing.aatext=true]
comment:3 by , 8 years ago
Might be a problem of limited memory. You can try to allocate more at start.
follow-up: 5 comment:4 by , 8 years ago
Component: | Core → Core Webstart |
---|---|
Keywords: | jnlp memory added |
Resolution: | → worksforme |
Status: | new → closed |
Replying to pbb:
System info from one of the computers having this problem:
Memory Usage: 197 MB / 247 MB (26 MB allocated, but free)The following system report is from the computer that does NOT have this problem:
Memory Usage: 769 MB / 1794 MB (504 MB allocated, but free)
As you can see the failing computer does not allocate enough memory to JOSM to work properly.
You could customize a .jnlp file to allocate more memory, see:
comment:5 by , 8 years ago
Replying to Don-vip:
Wouldn't it be nice if JOSM would tell the user that there is too few memory to perform an expected action? Or it is actually already doing that (obscured in the terminal messages)? I mean, there even is a info bar that aerial imagery should be aligned before using it for tracing... :-)
Update: now logged as ticket #14730 (currently no action planned by michael2402 - info via mail request).
comment:6 by , 8 years ago
Cc: | added |
---|
This is not so easy. But I believe Wiktor and Michael did work on the subject.
comment:7 by , 8 years ago
Yes, the layer is hidden to avoid a out-of-memory situation that would lead to a JOSM crash (corrupt data, ...). Displaying a warning about this the user worked some time ago. I'll have a look into it.
Currently, we just use a hard limit for all imagery layers (like size of total heap - size of expected JOSM memory usage). Accounting is just a very rough estimate, so we may be off by a lot. This is not optimal.
comment:8 by , 8 years ago
I find it very weird that on a brand-new system with a clean setup, JOSM has less memory available than on an old system with probably many unneeded background processes running. And I can not remember ever having modified the JOSM setup on the old computer so that it would have more memory.
But I see another peculiar difference. The system that is having memory trouble, is running "Java HotSpot(TM) Client VM", while the system with more available is running "Java HotSpot(TM) 64-Bit Server VM". Could that be an explanation? I don't know how those difference are created.
comment:9 by , 8 years ago
Yeap, that was the cause of the trouble; 32-bit vs 64-bit Java. I now specifically installed the 64-bit Java, and now I can have many background layers.
Rant 1:
Java makes it hard to install 64-bit, and almost impossible to afterwards find out which architecture was installed. Just pressing "Download" on their site gives you only 32-bit, and the only place in Windows I was able to discover I have 32-bit Java installed was in Start > Java > Configure Java > Java (tab) > View (button) > Architecture (table column). Not even "About Java" tells you this.
Rant 2:
I am sorry, but I really think "Works for me", therefor -> "Closed" is a very bad way to treat bug reports. I can understand that minute peculiarities in system configurations can make it impossible to find out why things don't work in one out of many systems. But if there is a major dependency on the Java version installed, then that is important to find out.
comment:10 by , 8 years ago
"Works for me" is indeed a strange reason to close a bug report, as it not working on the developer's side was not the reason for complaint. Maybe rename it to "layer 8" or "rtfm"? ;-)
The last loaded background layer does not display