#24385 closed enhancement (fixed)
[PATCH] New Remote Control сommand: export data
| Reported by: | TrickyFoxy | Owned by: | team |
|---|---|---|---|
| Priority: | normal | Milestone: | 25.08 |
| Component: | Core remotecontrol | Version: | |
| Keywords: | Cc: |
Description
I suggest endpoint localhost:8111/export, to get the data of the active data layer.
In fact, the indoor= JOSM plugin tried to solve this problem for itself. All it does is provide data from the active layer when accessing the http://localhost:8432/indoorequal.osm and adds a button to open https://indoorequal.org/#url=http://localhost:8432/indoorequal.osm. However, the implementation uses a temporary file and requires clicking a button to export fresh data.
Another use I see is when editing buildings in 3D, to check the render before uploading the data to OSM. The OSM Building Viewer also has the ability to preview the .osm file or via a URL. A PoC video using the current patch is on GitHub
I think other applications can be found, from live rendering of tiles/router, to edit validators.
---
- This API is disabled by default.
- Export is quite fast, I think applications can allow you to frequently poll this endpoint without being afraid to block editing in JOSM. In extreme cases, web applications can check whether the browser window is in focus.
- I think the
.osmformat will be enough, but if necessary, it will be easy to add parameters to the request. - Export occurs only if the active layer is OsmDataLayer.
Bonus: I fixed the calculation of Content-Length for the response. Now it contains the correct length if there are unicode characters in the response.
Attachments (1)
Change History (10)
by , 4 months ago
| Attachment: | Remote_Control__export_data.patch added |
|---|
comment:1 by , 4 months ago
| Milestone: | → 25.07 |
|---|
follow-up: 3 comment:2 by , 4 months ago
P.S. I pretty sure we have a JOSM wiki page documenting the remote control stuff. That needs to be expanded (also for the last change...).
comment:3 by , 4 months ago
Yes, no problem. Information about the previous change has been added to https://josm.openstreetmap.de/wiki/Help/RemoteControlCommands and
https://osm.wiki/JOSM/RemoteControl#(Partial)_List_of_Commands
After applying the patch, I will update them again. I can also make a new screenshot for this page:
https://josm.openstreetmap.de/wiki/Help/Preferences/RemoteControl
comment:4 by , 4 months ago
Maybe you could check if validateRequest() is useful to return more detailed error messages instead of an empty string, in case there's no active layer, or the active layer is not an OsmDataLayer, etc...
How does this code behave, if there's an open dialog window (e.g. during upload)?
In extreme cases, web applications can check whether the browser window is in focus.
Another option could be to have some sort of rate limiting in the code, and reject requests.
comment:5 by , 4 months ago
Maybe you could check if validateRequest()
As far as I understand, it is aimed at checking the input parameters of the request. To signal an error, it is enough to throw an exception from handleRequest(). But I'm not sure if anyone needs to understand the reason /export returned an empty string. And there are few mechanisms for this. For example:
How does this code behave, if there's an open dialog window (e.g. during upload)?
MainApplication.getLayerManager().getActiveLayer() returns null. /export will return an empty string. And now there is no way to find out the null occurred because the layer is not there, or it is in the uploading state.
Another option could be to have some sort of rate limiting in the code, and reject requests.
In fact, this is not necessary. Here is a demo when I poll JOSM without timeouts: https://en.osm.town/@foxy/114814556045773851
While I'll admit that there's no active editing going on here, I did some more metering. I ran ab -n 100 http://localhost:8111/export for the case when the response size is 9 MB and received 9-10 RPS. Again, no noticeable impact on the editing process. I would say that the opposite is happening. When you start moving an object on the map it slows down /export, which is not critical.
I don't expect such aggressive use of this API, but even with it, JOSM does a great job. With large sizes, problems will start at the receiving end, not at the JOSM. This needs to be dealt with by filtering data on the JOSM side. But let's solve problems as needed.



I don't see anything obvious wrong with it, but will let it rest some days...