Modify

Opened 4 months ago

Closed 3 months ago

Last modified 3 months ago

#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.

---

  1. This API is disabled by default.
  2. 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.
  3. I think the .osm format will be enough, but if necessary, it will be easy to add parameters to the request.
  4. 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)

Remote_Control__export_data.patch (6.4 KB ) - added by TrickyFoxy 4 months ago.

Download all attachments as: .zip

Change History (10)

by TrickyFoxy, 4 months ago

comment:1 by stoecker, 4 months ago

Milestone: 25.07

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

comment:2 by stoecker, 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...).

in reply to:  2 comment:3 by TrickyFoxy, 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 mmd, 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 TrickyFoxy, 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.

comment:6 by stoecker, 3 months ago

Resolution: fixed
Status: newclosed

In 19425/josm:

add remote control command to export dataset, fix #24385

comment:7 by stoecker, 3 months ago

@TrickyFoxy: Can you update the docs please.

comment:8 by stoecker, 3 months ago

Ah, you already did. Ignore the comment ;-)

comment:9 by stoecker, 3 months ago

Milestone: 25.0725.08

Milestone renamed

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.