The main usage of the tool is to add Wikipedia-tags to OpenStreetMap and to make localisation of names with the help of interwikilinks, but parts of the tool can also be used for other jobs. The tool works in three steps, see below.
Take a look to example that works with streets in Dresden (Germany).
- On the left side you have the wikipedia part generated by CatScan in the background so it goes through a wikipedia category also with subcategories. So user can modify in the form project language, category and the depth of searching in category tree. An additional option on the left side is the question if the user wants to use wikipedia interwikilinks for names in different languages.
- On the right side is the OpenStreetMap part which uses code of Query-to-map projects. So the user can choose a bounding box (BBOX), a key-value combination (“*” for values possible) and a types definition.
The types "points", "lines", "areas" will make a request at toolserver database and downloads everything in this area, so it is relatively slow. The types "node", "way", "relation" will make a request at Overpass API and download only the necessary pobjects so it's faster, especially for large objects. Types="no" that the script jumps directly to Nominatim and is so much faster.
The script will use this parameter to find in the next step matching OSM objects where additionally the name-parameter is matching with the Wikipedia article name founded on the left side. (Parts of the Wikipedia article name in brackets will be ignored.)
As result the user get a table with 3 columns:
- Wikipedia-articles: Is a link to Wikipedia-article
- Interwikilinks: Shows the user how many interwikilinks has this article, is interesting if this links are used to generate “name:language”-Tags for OSM.
- OpenStreetMap: Is a link osm-add-tags tool see below.
This script is looking for matching objects with given parameters. Mostly the parameters are generated by the index.php script (see above but it's also possible to use the script for OpenStreetMap outside of Wikipedia content.)
- key, value, types and BBOX: (see above) to specify complex OSM-objects.
- name: to find at best exactly the right complex OSM-object. If this parameter is "*" the user get a list of all objects and also objects without name. This example gives a list of all restaurants of a city and shows if there is a smoking-tag or not. Some restaurants in this example have no name so they are on the end of the list as "node...".
- without-tag: define a key that is missing on the object of search. Useful to find e.g. restaurants without opening hours or so. (coming soon...)
- addtags: different Tags to add to specified objects. Tags written as “key=value”, different tags are separated by “|”
As result the user gets one single object or a list with objects.
This list has links to JOSM/Plugins/RemoteControl with addtags-parameter for JOSM in latest version must run. So it use a local server to control JOSM.
Behind the objects the user can see its size (diagonal length in seconds of degree)
The script works with the toolserver database which is normally used for mapnik, so possibly it is not synchronous or has curious effects. The script finds the nodes, ways and relation numbers in the database and calculates small bounding boxes around each object.
If the result is empty the script asks Nominatim but the users need to be carefully with the results because there is no key-value proving and it gives only the first result back.
For details see: JOSM/Plugins/RemoteControl
With the help of remote control JOSM downloads the area around the defined objects and selects them. In the following dialog box the user can modify selection and tags before applying the changes.
It's helpful to use OSM-tiles (JOSM menue: Imagery) as overview in background.
The idea is to use this Wikipedia-tags later inside the Wikipedia embedded map to highlighting the OSM objects that match to the wikipedia article. So especially complex line and area objects (streets, rivers, districts,...) would be interesting for that. Multilingual maps will profit the translations by interwikilinks, especially city-objects (nodes) should have priority.
The concept behind the tool is also keep the server-side script without graphical map-interface, so it's very easy for other programmers to modify the script and bring there ideas inside the project.