[patch] Malformed URLs

[pnorman]

When issuing a query for ways with particular tags on them the mirrored_download plugin mangled the URL and added syntax that is not part of the XAPI syntax.

The URL it attempted to fetch was ​http://192.168.1.5:8080/xapi/api/0.6/way[bbox=-126,47,-122,49][@meta][boundary=administrative][admin_level=4]

The only valid values beginning with @ are @user, @uid, and @changeset, as documented at ​http://wiki.openstreetmap.org/wiki/Xapi#Tags

[pnorman]

Patch to fix bug 7660

[bastiK]

The plugin does not support XAPI syntax, but a variant used by the Overpass API (​Overpass XAPI compatibility layer).

If you want to add support for (J)XAPI, you are welcome, but keep the current functionality intact.

[anonymous]

Can you suggest a name for a plugin to download data from servers that support the XAPI syntax then? I could base it on existing code

[bastiK]

No, please extend the existing plugin (or give a better reason, why this isn't possible). Maybe I exaggerated, according to the docs, there is only one difference, namely the @meta tag.

I think a good solution would be to have a "/capabilities" call, which would return some useful info on the server. (Similar to the OSM API, the WMS API, etc.)

Anyway, please give Roland time to answer, before making any decisions.

[anonymous]

The problem is that overpass does not support the xapi syntax in several ways. The overpass compatibility layer does not provide full xapi compatibility and this plugin is currently useless for tag-based queries from a server implementing the xapi syntax, not the overpass variant.

[bastiK]

Replying to anonymous:

The problem is that overpass does not support the xapi syntax in several ways. The overpass compatibility layer does not provide full xapi compatibility

What features are is missing exactly? Roland is usually pretty fast with updates, so maybe full XAPI compatibility (except @meta) isn't so far away? :)

and this plugin is currently useless for tag-based queries from a server implementing the xapi syntax, not the overpass variant.

The GUI currently suggests full XAPI support, so maybe we can automatically switch to one of the "true" XAPI servers, if a feature is detected in the request that is not (yet) supported by Overpass?

An alternative to the "/capabilities" call would be, to extend the format for the ​list of publicly available servers to include some meta-info.

[stoecker]

Replying to bastiK:

An alternative to the "/capabilities" call would be, to extend the format for the ​list of publicly available servers to include some meta-info.

You should have used XML there from the beginning. Didn't you learn from maps definitions? :-)

[pnorman]

Replying to bastiK:

Replying to anonymous:

The problem is that overpass does not support the xapi syntax in several ways. The overpass compatibility layer does not provide full xapi compatibility

What features are is missing exactly? Roland is usually pretty fast with updates, so maybe full XAPI compatibility (except @meta) isn't so far away? :)

The lack of meta-data from the Xapi compatibility layer results is the biggest difference between the xapi syntax and overpass' emulation of it.

All of the other implementation differences between either overpass xapi compatibility or jxapi and the xapi syntax are fairly minor and don't have much impact for josm. The calculation of the bounds by the plugin is the only other feature where the differences matter and I believe the calculation is in such a way that it won't calculate if the <bounds> element is present, which it is in jxapi output.

I've added a section to the wiki page to place these implementation-specific differences in.

and this plugin is currently useless for tag-based queries from a server implementing the xapi syntax, not the overpass variant.

The GUI currently suggests full XAPI support, so maybe we can automatically switch to one of the "true" XAPI servers, if a feature is detected in the request that is not (yet) supported by Overpass?

The issue is this plugin is currently useless for tag queries against any server that implements the xapi syntax, not the overpass variant. It doesn't have to do with non-standard features which are present in only some implementations of the xapi syntax, it has to do with the most basic tag queries.

[pnorman]

Replying to stoecker:

Replying to bastiK:

An alternative to the "/capabilities" call would be, to extend the format for the ​list of publicly available servers to include some meta-info.

You should have used XML there from the beginning. Didn't you learn from maps definitions? :-)

#7661 is about some issues with the selection of mirrors so that part of the code needs some bug fixes anyways so that custom servers can be properly added. It'd also be good to have a better configuration dialogue for the plugin.

[bastiK]

Replying to pnorman:

Replying to bastiK:

Replying to anonymous:

The problem is that overpass does not support the xapi syntax in several ways. The overpass compatibility layer does not provide full xapi compatibility

What features are is missing exactly? Roland is usually pretty fast with updates, so maybe full XAPI compatibility (except @meta) isn't so far away? :)

The lack of meta-data from the Xapi compatibility layer results is the biggest difference between the xapi syntax and overpass' emulation of it.

All of the other implementation differences between either overpass xapi compatibility or jxapi and the xapi syntax are fairly minor and don't have much impact for josm. The calculation of the bounds by the plugin is the only other feature where the differences matter and I believe the calculation is in such a way that it won't calculate if the <bounds> element is present, which it is in jxapi output.

I've added a section to the wiki page to place these implementation-specific differences in.

and this plugin is currently useless for tag-based queries from a server implementing the xapi syntax, not the overpass variant.

The GUI currently suggests full XAPI support, so maybe we can automatically switch to one of the "true" XAPI servers, if a feature is detected in the request that is not (yet) supported by Overpass?

The issue is this plugin is currently useless for tag queries against any server that implements the xapi syntax, not the overpass variant. It doesn't have to do with non-standard features which are present in only some implementations of the xapi syntax, it has to do with the most basic tag queries.

Do you agree, that the following distinction would solve all the current problems?

• server is overpass xapi compatibility -> add [@meta]
• server is normal xapi -> don't add anything

If that is the case, then I would say, it is a minor technical problem that can be solved in various ways. Certainly not a reason to create a new plugin with almost identical code. The simplest solution (but also the worst) would be to hardcode your URL. Another pragmatic approach would be if you simply ignored the @meta tag for your xapi server. (I'm aware that XAPI is the main-line stable API and Overpass sort of "violates" it, so this is maybe to much to ask.) Other solutions I have indicated above (/capablities or info in the server list).

[bastiK]

Replying to pnorman:

Replying to stoecker:

Replying to bastiK:

An alternative to the "/capabilities" call would be, to extend the format for the ​list of publicly available servers to include some meta-info.

You should have used XML there from the beginning. Didn't you learn from maps definitions? :-)

#7661 is about some issues with the selection of mirrors so that part of the code needs some bug fixes anyways so that custom servers can be properly added. It'd also be good to have a better configuration dialogue for the plugin.

I agree, you are welcome to improve it!

[bastiK]

Replying to stoecker:

Replying to bastiK:

An alternative to the "/capabilities" call would be, to extend the format for the ​list of publicly available servers to include some meta-info.

You should have used XML there from the beginning. Didn't you learn from maps definitions? :-)

Yes, and I knew exactly it would happen, but was to lazy at the time. :)

[roland.olbricht]

Ok, the issue is fixed now as follows:

• an extra setting allows to choose whether to add or not to add "[@meta]"
• the setting is controlled by a checkbox in the settings and is checked by default

[pnorman]

Replying to roland.olbricht:

Ok, the issue is fixed now as follows:

• an extra setting allows to choose whether to add or not to add "[@meta]"
• the setting is controlled by a checkbox in the settings and is checked by default

Would switching to the xapi_meta endpoint be a better option? It would keep the strings consistent.

[pnorman]

Any comments on switching to xapi_meta? If not, I'll prepare a patch doing so. This will allow the search string to be the same for both options.