Template talk:Overpassapi

"External" links to Wiki-internal pages

Why is [{{FULLURL:Special:Target Page|namespace=0}} Link text] used for the "more:" links, thereby creating "external" links, even though the target pages are (Special:) pages of this very Wiki?
--Das-g (talk) 11:31, 29 May 2017 (UTC)

It is used for specifying the namespace to search for (which has no equivalent using only a Special: wikilink which searches in the incorrect namespace). Namespace 0 is used for English, 7 other namespaces (with even numbers 200 and above) are used for DE, ES, FR, IT, JA, NL, RU; all other languages are using namespace 0 (the same an English, but using language code prefixes in their page names). These namespace numbers are determined by {{LangNS}}. There's no way to use something else than namespace numbers (the namespace prefixes are not supported by the "Special:" query page). There's no other way to specify this parameter with a classic internal wikilink.

• This is also true when you want to create an "edit page" link, or "purge page" link, you use "FULLURL:" as well to pass additional parameters not available with the standard internal wikilinks (which only support a default "action=view" for browsing standard pages).
• This is also true when you want to pass additional parameters with Special:PrefixIndex (where you also need a namespace number parameter to add a filter instead of listing only pages in the default namespace 0, or listing other pages in "Template:", "File:", or "Category:").

Don't worry, FULLURL will still generate a correct internal link, with the correct protocol and domain name, for the specified Pagename given exactly like in internal link (it will be properly URL-encoded when needed). — Verdy_p ^(talk) 16:59, 29 May 2017 (UTC)

Well, it works, sure, but it displays the https://wiki.openstreetmap.org//w/skins/Vector/images/external-link-ltr-icon.png?325de icon that is rather misleading if the link keeps you on the same wiki.

--Das-g (talk) 09:40, 2 June 2017 (UTC)

It's not a standard wiki page, but actually a query, these links are for special use but only to complete the links displayed before. If you want, I can suppress the blue arrow icons easily (done!). — Verdy_p ^(talk) 15:09, 2 June 2017 (UTC)

Thanks, looks good!

--Das-g (talk) 21:55, 3 June 2017 (UTC)

This template is fine for Overpass but not for Overpass Turbo

(moving this discussion here as suggested by https://wiki.openstreetmap.org/wiki/Talk:Overpass_turbo )

Someone has suggested there that " The solution could be to have a flag on the template which reverses the order of the rows of links for overpass turbo pages? ".

I've no idea if that's possible (personally I suspect a better solution would be to remove this template from that page and add more appropriate links manually) - is it? SomeoneElse (talk) 21:06, 18 January 2022 (UTC)

Too many items in toolbar

Since a recent update the toolbar looks rather cluttered. Can we reduce this again to the bare minimum, I.e. what is relevant for a user? Links to 'development', a page for brainstorming doesn't belong here at all. Let's keep this all as simple as possible. Mmd (talk) 08:31, 8 July 2017 (UTC)

I had separated Overpass turbo from Overpass API (as they are managed separately), they are cleanly separated. NEw pages were recently created about both that were not easily accessible).

This is not so much "cluttered", and these are also linked from the official websites of both tools (for which I added the URLs).

"Development" is an important link, notably because it links to online support (for bugs, suggestions, versions), or to additional documentation not found on this wiki

I'm talking about Overpass_API/development - this is internal brainstorming, it doesn't have any links to other pages. Please remove it from the toolbar, as it is of limited use for ordinary Overpass API users.

May be some pages on this wiki need refreshes/updates, but these links will allow finding them for performing the corrections (or translating them)

Yes, the language guide is very much outdated by at least a couple of years. I always recommend to use the Overpass QL documentation.

Note that I aslo integrated a tiny "+" link for editing this nav bar (which is also fully translatable). I also checked several links that were no longer working or were redirecting.

There's certainly ways to rearrange things, but it is better than having to scan some links difficult to see in existing wiki pages in their content.

I have to disagree here. If a page is only of limited use for normal users, it shouldn't be in the toolbar.

This bar is not so big, and nothing was removed. We have all the features linked from one place (so it's simpler to update only this bar instead of updating various pages, and keep all pages in sync from a single place: pages can be simplified).

The issue is that it has been extended by so many items. Permanent ID is almost not used at all in real life and could probably be removed. Advanced examples is another bad example, as it should really be moved to Query examples in some way. Having several overlapping / similar example pages is confusing. Also Public transport sketch lines is such a case. Although an interesting application, it doesn't cover the latest PTvX changes and people started creating bug reports for it. As it has fallen out of focus and not developed any further, that situation is not ideal.

Technical terms (Overpass_API/Wording) was once used to coordinate translation of error messages, also not a very good candidate for the toolbar in its current form. Then "Technical details" is probably too much detail for normal users.

I think it would be best to have larger building blocks for this:

Normal users who just want to use the API and are looking for examples and syntax description

People looking to set up their own instance, checking recent changes affecting their own installation.

Tech savvy people who are looking for implementation details

... etc.

There are still works to do on this wiki.

Fully agree.

Notably Overpass API templates no longer work, probably because there was a change on the Overpass API servers, that are no longer compatible with Mediawiki syntax but use the template syntax of the OSM.org website: this affects templates that were using the undocumented "[out:custom]" format) and I still don't know how to make "[out:custom]" working from this wiki (Overpass API "custom" output apparently requires the support of the syntax {{node:id}} which is impossible to implement with MediaWiki, except by installing a "custom tag" hook in the local MediaWiki configuration: the problem is the colon ":" that would have to be replaced by a "|" before the id parameter, and possibly template names would need to be tunable, passing the element type "node/way/relation" also as a parameter of another template instead of being the name of the template itself because Template:Node has a different syntax of use on this wiki). Only Overpass turbo templates are working for now.

This could be a server issue. Can you report this on Overpass API/status so that Roland can fix it? BTW [out:custom] is not undocumented: see http://overpass-api.de/output_formats.html#custom

Both kinds of templates are mixed togetherin the same category, that should probably be separated, as they won't support exactly the same syntax, and Overpass aPI or Overpass Turbo use different versions and are not exactly in sync for the syntax they support in queries. This was the motivation why I separated both. Many users will will focus on Overpass Turbo, when other users will focus on Overpass API for building their own apps.

The separation looks good. I'm having more trouble with the large number of items for Overpass API.

Overpass Turbo also requires additional documentation (notably for its alternate "wizard" syntax for queries).

Both tools require their own support pages. There's been confusion between both tools since too long (they are not exactly equivalent even if Overpass Turbo internally uses the Overpass API). — Verdy_p ^(talk) 09:48, 8 July 2017 (UTC)

Well, the one is a web frontend, the other a backend service. Yet, there's frequent confusion. Mmd (talk) 10:11, 8 July 2017 (UTC)

Not really, BOTH have a front end (though the front end of API server is extremely limited and underdevelopped).

Not exactly, Overpass Turbo doesn't have a backend in the sense that is has its own data persistency. Overpass Turbo does not store or manage any OSM data on its own, all data is effectively coming from Overpass API via HTTP request.

And osm.org itself also has its own frontend (supporting also its own specifications for templating the search results, not based on MediaWiki, but I don't know how it works, or if it's still working, may be it has been disabled so this could be the actual cause why API templates no longer work as intended as they are supposed to render the result in the osm.org site, not on this wiki).

I'm not sure I'm following your example on osm.org here.

Overpass turbo includes effectively a front end but it has also its own backend (converting queries and running them to an API instance, and performing its own transforms, or converting the returned data to another downladable format: this is not just about rendering the data on the web, so Overpass Turbo has its own distinctive API, supporting yet another query language for its "wizard").

Converting queries is done by Overpass API. Overpass turbo just calls and HTTP endpoint on Overpass API. Also, requests are send from your browser to Overpass API, so Overpass turbo has no server side component. You can run it on your local laptop, it needs just very little memory to store HTML, JS and CSS files, etc. It's really all running on your local browser!

There is also the XAPI query language::: , so in summary we have 4 distinct query languages (in addition to the core OSM API), some of them with several syntaxes (XML, JSON, or CSS-like for Overpass QL)... The core OSM API also has its own extensions on some data mirrors (some of them allowing proxing the data submissions, but most of them working in read-only mode).

I guess you're talking about the French proxy here?

This proliferation is not a bad thing (this is a good sign that these tools are in active development and use, with more needs to cover), but we need to better distinguish the cases (so that we will be able to cleanup or deprecated one of the existing alternatives and swithc more easily to another one, with better documentation of compatibility and capabilities, just like what was done when deprecating the XAPI (removed from the core OSM servers and only supported now by a conversion layer working on some Overpass API servers or running externally from other servers using an Overpass Turbo instance). — Verdy_p ^(talk) 14:25, 8 July 2017 (UTC)

Overpass Turbo really is just HTML, Javascript and CSS. As said before it all runs in your browser. It has no own database for OSM data and just sends requests to Overpass API. Conversion to images, GPX, KML, GeoJSON, etc. all runs inside your own browser, never on any server. There's a tiny layer to store shortlinks on the server, but that's about it. XAPI conversion is also done exclusively via a script on Overpass API server. Overpass Turbo has no idea at all about XAPI, nor provides any conversion for it in any way. Mmd (talk) 17:02, 8 July 2017 (UTC)