open Location; "no suitable download task is available"; documentation at point of error message.

[brycenesbitt]

Use of "Open Location" works for XAPI:
​http://open.mapquestapi.com/xapi/api/0.6/node[radar=NEXRAD]

But not for overpass:
​http://www.overpass-api.de/api/xapi?node[radar=NEXRAD]
​http://www.overpass-api.de/api/xapi?*[radar=NEXRAD]

See attached screenshot.

[brycenesbitt]

(It may be the <note></note> tag in the returned XML from overpass?)

[Don-vip]

Meta data are required, you need to add additional [@meta] at the end of your request to make JOSM accept it, see ​http://wiki.openstreetmap.org/wiki/Overpass_API/XAPI_Compatibility_Layer#Meta_Data

​See accepted patterns here.

[brycenesbitt]

Hmmm. "no suitable download task is available" was supposed to tell me that the lightly documented [@meta] qualifier was missing?

[Don-vip]

I agree the message can be improved.

[brycenesbitt]

Patch to document acceptable patterns

[brycenesbitt]

The patch makes the error message pretty geeky: but maybe that's OK in this case.
To get it to work you have to supply a URL in one of a few very specific formats.

[stoecker]

Ticket #8813 has been marked as a duplicate of this ticket.

[brycenesbitt]

Post-patch version of error message

[skyper]

Replying to brycenesbitt:

The patch makes the error message pretty geeky: but maybe that's OK in this case.
To get it to work you have to supply a URL in one of a few very specific formats.

A Help or More Info button leading to the wiki would be nicer and would help to keep the documentation in sync. The documentation within the code does not help normal users and the wiki is better accessible.

[brycenesbitt]

Is there anything I can do, to help get this patch into the codebase?
A test case? Flowers? Thanks?
It should be reasonably shovel-ready.

[akks]

Maybe, automate adding <ul> / <li> /etc. and leave only patterns in Download*Task and also add a "help" button?

[stoecker]

Returning the patterns instead of whole doc and auto-generate the message looks much nicer to me also. Also the task name is not really an information for the user. A link to the wiki could help the user to understand the pattern.

[brycenesbitt]

Modified version. Drop the number in front of the task. Give each task a "friendly" name. I think the task name helps group the patterns which otherwise would be overwhelming.

[brycenesbitt]

Out of scope of this ticket: why restrict to these URL patterns at all? How about if in a future revision any URL is loaded, and the resulting blob is passed to each download task. If the GPS task sees GPX, it can claim it. In other words switch based on content received, not URL input.

[akks]

I had a look at the patch. Could you please introduce some "getPatterns" methods or something like this?

Pattern checking logic (url != null && url.matches(PATTERN1) ||url.matches(PATTERN2) ||...) seemes to be the same for all types,
acceptsDocumentationSummary() logic body - too. Maybe it it better to introduce base class (something like PatternBasedDownloadTask) with universal methods?

[brycenesbitt]

My goal in this simple documentation patch is to expose the current behavior, so the user can understand what URL's are acceptable. Right now that's not possible without reading the source code.

My proposed acceptsDocumentationSummary() returns plain text in case someone writes a task that does not use a simple set of regular expressions. The author of a task thus has a free-form ability to describe what their task supports.

---

Comment 13 is about one possible way to completely eliminate regular expressions.
If that were done in the future, acceptsDocumentationSummary() might return something like "Compressed .osm files (bzip, bzip2, gzip or zip format)" or "GPX files", instead of a regular expression.

[skyper]

Replying to brycenesbitt:

Out of scope of this ticket: why restrict to these URL patterns at all? How about if in a future revision any URL is loaded, and the resulting blob is passed to each download task. If the GPS task sees GPX, it can claim it. In other words switch based on content received, not URL input.

Please open a new ticket for that. Thanks

[Don-vip]

Replying to skyper:

Replying to brycenesbitt:

Out of scope of this ticket: why restrict to these URL patterns at all? How about if in a future revision any URL is loaded, and the resulting blob is passed to each download task. If the GPS task sees GPX, it can claim it. In other words switch based on content received, not URL input.

Please open a new ticket for that. Thanks

I don't plan to implement such a change. This is much more complicated for no real gain, the pattern approach allows us already to open a wide variety of links.
I'm ok with the pattern refactoring and the documentation patch though (they're not incompatible, I just lack of time right
now).

[skyper]

Replying to Don-vip:

Replying to skyper:

Replying to brycenesbitt:

Out of scope of this ticket: why restrict to these URL patterns at all? How about if in a future revision any URL is loaded, and the resulting blob is passed to each download task. If the GPS task sees GPX, it can claim it. In other words switch based on content received, not URL input.

Please open a new ticket for that. Thanks

I don't plan to implement such a change. This is much more complicated for no real gain, the pattern approach allows us already to open a wide variety of links.
I'm ok with the pattern refactoring and the documentation patch though (they're not incompatible, I just lack of time right
now).

I see -> wontfix.

I can try to get a proper documentation in the wiki, if I find the time and power. Sorry, do not have that much time right now and I feel sometimes quite lonely as writing the wiki in two languages is often exhausting and not always fun.

Are there any stats how often the help buttons are used and/or wiki pages are browsed ?

[brycenesbitt]

Replying to skyper:

I'm ok with the pattern refactoring and the documentation patch though (they're not incompatible, I just lack of time right now).

Correct: this patch is meant as a useful step in any future direction.

By documenting the patterns right on screen, and drawn from the code, it won't get out of date or be a maintenance burden like a help page or wiki.
If the next step of refactoring to a single pattern method is done, the on-screen documentation and code function will be even more tightly bound (but given the stability of this section of code, that too has limited gain).

[akks]

In 6031/josm:

see #8809: [patch by brycenesbitt, reworked] detailed documentation for "no suitable download task is available" error (Ctrl-L)

[akks]

I tried to do the technical job of eliminating duplicate code in the patch (no help button for now, feel free to add it), keeping the plugins compatible with existing code. Please have a look at the result and suggest future improvements.

[Don-vip]

In 6032/josm:

see #8809 - Add Help button to "open location" error dialog + javadoc fixes in download tasks

[Don-vip]

Plugins updated in [o29706], [o29708], [o29710], [o29711].

That makes a very long list that barely fits on my screen. Any idea how to reduce its size ?

[Don-vip]

Very long message

[Don-vip]

In 6033/josm:

see #8809 - Use table in "open location" error dialog to reduce its size

Result:

[Don-vip]

Shorter message

[Don-vip]

Looks ok to my eyes now :)
Thanks all of you for ideas and patches !

[brycenesbitt]

Thanks all!
I had no idea JOSM could import so many things!!