Wikivoyage:Maptool

This is a map-based JavaScript gadget that helps finding POIs for the article as well prepare dynamic maps. In its most basic use case, it will query Wikidata and/or OpenStreetMap for various data around the current article, and return both map and a table containing the results.

The expected workflow is to have the current article open in two tabs: one for the maptool, and the other one for editing the article to add the found POIs. Often it's enough to just copy the generated template, such as

{{listing | name = Loket Castle | wikidata = Q1013039}}

add a bit of content, and paste it into the article:

{{see | name = Loket Castle | wikidata = Q1013039 | content = A 12th-century Gothic castle, located on a massive rock. | url = https://www.hradloket.cz/en/}}

No need to even retrieve coordinates, search for the image etc.

Basic Functions

By clicking on the tool icon () the main query dialog will be open, which is split into a few base groups:

Show: The options on that line pick the results to be shown after the query is performed. Map is always shown, with the resize handle optionally enabled in the bottom right of the map. This allows preparing mapframes with the specified dimensions. Finally, by default also a table with the query results is enabled.
Query area: Allows choosing either a circular area around specified coordinates, or an rectangular area specified by its SouthWest and NorthEast corners. The maximum allowed size is 100km radius or 200km diagonal distance respectively, to limit the server load. However do mind the queried area size - for some countries, there may be lower tens of returned POIs even in the maximum sized area, while in others thousands.
Wikidata and OpenStreetMap: checking either of them will enable the respective query, using the respective parameters. See below.
Query and show will query the servers for the POIs and after the data is returned, present them. Next to the button, the current {{mapframe}} parameters is printed as template source, that can be pasted into the article.

Note: all the communication is done by the user browser, so you (as the user) are responsible for not causing extreme overloading of the respective servers. Please try to minimize the query sizes to necessary minimum and in general, query with care.

After the query finises, the map and/or result table are shown.

Moving around the map automatically fills the SW/NE corners in the Query area, as does resizing the map. Clicking into the map sets the center in the Radius option of the Query area.

Wikidata

Querying wikidata is the easiest way of adding POIs. The following options are available:

Wikipedia language: By choosing a language, it's possible to find only POIs with wikipedia articles in that language. Entering an empty string will search for all wikidata entries (with or without wikipedia articles). This may be more or less advantageous, depending on the area coverage with wikipedia. The most results are usually returned in the local languange - just mind that wikipedia doesn't use the same 'shortcuts' as internet domains. E.g. Czech is not 'cz' but rather 'cs', Denmark is 'da' rather than 'dk' etc.
Sort by wikipedia viewcount when the found WD POI has a wikipedia article (in the specified language), the average monthly number of views of that page will be retrieved (for the past year). This number is used to sort the results by relevancy. This simplifies finding relevant POIs - typically the main sights have much more views than e.g. various local natural features.
Filters: The wikidata result are obtained by means of a SPARQL query. To avoid common Boring places, by default some results are filtered out. The default SPARQL manual filter will remove all results that (in short) have type or subtype disaster. Much more complex queries are possible, just keep in mind that esp. the recursive part '/P279*' may significantly prolong the query.

After the query is finished, the map will contain the found POIs - the ones with more views will be more 'pink', gradually fading into grey. Clicking the POI shows the Wikidata ID/name, Wikidata short description, Wikipedia article link and images - all depending on the respective data presence in the Wikidata item. The icons of the POIs are manually picked to somewhat match the Wikidata 'instance of' (P31) property of the POI. It's not complete nor necessarily accurate.

The generated table is generally a textual representation of the map. In addition it contains the number of views of the article, as well as a prepared {{listing}} template text ready to be pasted into the article. Likely, type=see, type=do or some other argument will be needed, as well as description etc.

OpenStreetMap

At the moment, this is mostly useful for areas with worse Wikidata coverage. Even in those areas, OSM usually still has plenty of available using the Overpass query language. Due to that, the queries need to be even more careful, esp. since there's no sorting criteria used at the moment.

The provided filters apply on both OSM 'nodes' and 'ways' (aka single points and lines and areas). In addition to the provided (hopefully obvious) categories, the AUX field allows adding one additional filter. The default ['tourism'~'attraction'] will search for all OSM POIs that have 'tourism' tag set to 'attraction'. To search for all POIs that have any tourism tag, just specif ['tourism']. At the moment, this is about the maximum complexity of queries expected.

The resulting map contains the name of the POI in OSM, as well as generated {{listing}} template, and textual form of all the POIs tags.

The resulting table mostly contains only POI's name and template listing.