#13195 closed defect (fixed)
[PATCH] plugin "continuousDownload" runs away and begins downloading nonstop
| Reported by: | Sunfishtommy | Owned by: | team |
|---|---|---|---|
| Priority: | major | Milestone: | 19.02 |
| Component: | Core | Version: | tested |
| Keywords: | template_report continuosDownload | Cc: |
Description
What steps will reproduce the problem?
- Download initial layer with GPS and Open Street map enabled.
- move to area that is not downloaded.
- turn on "continuousDownload"
What is the expected result?
OSM will download the area within the view screen and add it to the layer.
What happens instead?
OSM will download first area and then automatically slew to areas not originally intended to be downloaded and begin downloading them as well. This will continue indefinitely.
Please provide any additional information below. Attach a screenshot if possible.
URL:http://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2016-07-11 23:04:49 +0200 (Mon, 11 Jul 2016)
Build-Date:2016-07-12 01:31:48
Revision:10526
Relative:URL: ^/trunk
Identification: JOSM/1.5 (10526 en) Mac OS X 10.10.5
Memory Usage: 1301 MB / 3641 MB (928 MB allocated, but free)
Java version: 1.8.0_101-b13, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
VM arguments: [-Djava.security.policy=file:<java.home>/lib/security/javaws.policy, -DtrustProxy=true, -Djnlpx.home=<java.home>/bin, -Djava.security.manager, -Djnlpx.origFilenameArg=${HOME}/Desktop/josm.jnlp, -Djnlpx.remove=true, -Dsun.awt.warmup=true, -Djava.util.Arrays.useLegacyMergeSort=true, -Dmacosx.jnlpx.dock.name=JOSM, -Dmacosx.jnlpx.dock.icon=${HOME}/Library/Application Support/Oracle/Java/Deployment/cache/6.0/16/47ee53d0-5ee98c81.icns, -Djnlpx.jvm="<java.home>/bin/java", -Djnlpx.vmargs=LURqYXZhLnV0aWwuQXJyYXlzLnVzZUxlZ2FjeU1lcmdlU29ydD10cnVlAA==]
Dataset consistency test: No problems found
Plugins:
- OpeningHoursEditor (32583)
- SeaMapEditor (32311)
- apache-commons (32584)
- buildings_tools (32639)
- continuosDownload (53)
- ejml (32639)
- geotools (32584)
- imagery_offset_db (32528)
- jts (32539)
- opendata (32584)
- reverter (32584)
- terracer (32426)
- utilsplugin2 (32584)
Tagging presets:
- http://www.freietonne.de/ft_icons/josm/FreieTonne_rules_presets_zip.php
- https://josm.openstreetmap.de/josmfile?page=Presets/Diving&zip=1
- https://josm.openstreetmap.de/josmfile?page=Presets/OpenSeaMap-PresetForSeamarks&zip=1
- https://raw.githubusercontent.com/OpenSeaMap/josm/master/INT-1-preset.xml
- https://raw.githubusercontent.com/OpenSeaMap/josm/master/Presets_Sport.xml
Map paint styles:
- https://josm.openstreetmap.de/josmfile?page=Styles/Cycleways&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/LessObtrusiveNodes&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Lit&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Maxspeed&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/SlovakiaBicycleRoutes&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Surface&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Surface-DataEntry&zip=1
- https://raw.githubusercontent.com/OpenSeaMap/josm/master/INT1_Seamark.mapcss
Last errors/warnings:
- W: java.net.SocketException: Socket closed
- E: java.net.SocketException: Socket closed
- W: java.net.SocketException: Socket closed
- E: java.net.SocketException: Socket closed
- E: java.io.IOException: Stream closed
- E: org.openstreetmap.josm.io.OsmApiException: ResponseCode=400, Error Header=<You requested too many nodes (limit is 50000). Either request a smaller area, or use planet.osm>, Error Body=<Reading error text failed.>
- 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: java.io.IOException: Stream closed
- E: org.openstreetmap.josm.io.OsmApiException: ResponseCode=400, Error Header=<You requested too many nodes (limit is 50000). Either request a smaller area, or use planet.osm>, Error Body=<Reading error text failed.>
- 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>
Attachments (2)
Change History (13)
comment:4 by , 5 years ago
I think this was caused by this change in r10432:
https://josm.openstreetmap.de/changeset/10432/josm/trunk/src/org/openstreetmap/josm/actions/downloadtasks/DownloadGpsTask.java
by , 5 years ago
| Attachment: | 13195.patch added |
|---|
comment:5 by , 5 years ago
| Milestone: | → 19.01 |
|---|---|
| Summary: | plugin "continuousDownload" runs away and begins downloading nonstop → [PATCH] plugin "continuousDownload" runs away and begins downloading nonstop |
Please review: The attached patch for core fixes this endless loop. The "zoom to" triggered in these lines is obviously also done somewhere else, because I did not find a difference when the plugin is not active.
I think there is another problem in the plugin. It sometimes downloads areas again, but only for the GPX data. I did not yet find out where this is caused.
by , 5 years ago
| Attachment: | improve-gpx-downloads.patch added |
|---|
comment:6 by , 5 years ago
| Milestone: | 19.01 → 19.02 |
|---|
The patch improve-gpx-downloads.patch includes 13195.patch and adds two further improvements:
1) BoundingBoxDownloader: Reduce number of gpx api calls: If a call returned less than 5000 points there is no need to request another page. This improves all routines which download raw GPX data from the server.
2) GpxImporter: Create a new GpxLayer even if the area contains no GPX data. This allows to keep track of the already downloaded boundaries. Without this change the continuosDownload will try agaian and again to download data from this area because the GpxLayer will not contain the information that the corresponding bbox was already downloaded.
With this patch I see no more problems in the continuosDownload plugin. If I hear no complains I'll commit it after release of 19.1
comment:7 by , 5 years ago
| Component: | Plugin continuosDownload → Core |
|---|---|
| Keywords: | continuosDownload added |
comment:8 by , 5 years ago
I'm waiting for the fix. It's the only thing which blocks me of using GPX tracks.
comment:10 by , 5 years ago
Please try r14761 or later and check if an empty GPX layer causes trouble. Maybe we have to disable some options which make no sense when there is no GPX data.
I have the same problem.
I have also noticed that if the "download raw gps data" in the initial download is NOT checked, the "continuos download" does exactly what it is supposed to. But if the "raw gps data" is checked, the "continous download" goes bananas! It seems that the "continuous download" follows the gpx-tracks in some way...
/Tomas