RU:WIWOSM

From OpenStreetMap Wiki
Jump to navigation Jump to search
WIWOSM - Other languages
Скриншот русской Википедии: Статья о Москве с её векторным представлением (красным)

WIWOSM (Wikipedia where in OSM) — это проект, показывающий в статьях в Википедии геометрические объекты из OpenStreetMap. Преимущественно WIWOSM будет использоваться на OSM-картах внутри Википедии. Эти объекты имеют соответствующий Wikipedia-тег.


Страница с примером

http://toolserver.org/~kolossos/openlayers/kml-on-ol-json3.php?lang=en&title=Moscow
такая же как и
http://toolserver.org/~kolossos/openlayers/kml-on-ol-json3.php?lang=ru&title=Москва

Показывает Москву на карте. Параметр title в URL — это название статьи в Википедии. Вместо OSM-связей для Москвы используйте тегирование для русской Википедии: wikipedia=ru:Москва. Существующие интервики-ссылки на стороне Википедии индексируются, так что достаточно одного дополнительного тега на стороне OpenStreetMap, и это может быть любая из статей Википедии на любом из языков.

Преимущества

Objects which can be referred to using WIWOSM don't need to be "hardlinked" anymore. Up to now the only possible way to link a certain object was to refer to its OSM-ID. The problem here is that the ID can change and thus breaks the link.

Преимущества для Википедии

The project will give users of wikipedia with one click a detailed view on complex geographical objects like rivers, streets and districts. So it increases the potential of wikipedias geocoding where an article gets only a point by the possibility to describe additionally complex lines and polygones. The geometry from OSM helps us also to bring the map to the right zoomlevel.

WIWOSM will connect the Wikipedia content with the opportunities of a Geographic information system. So we can say e.g. how large an article object is or which articles are in an other...

Преимущества для OpenStreetMap

OpenStreetMap can show with this project for many people that it is more than a map, instead it's a database with a lot of use cases. OpenStreetMap can win with the wikipedians a lot of new users this will help to ensure the quality. The connection to Wikipedia will also help to translate a lot of objects into different languages.

Other Example: An article about a miniature railway in Germany [1]. It uses points for railway stations, lines for the railway track and polygons for the rail yard.

Типы объектов

OpenStreetMap has different representations for objects. This means a place can be represented by a node (a single point) or a multipolygon (an area). We want the most complex representation for this project. A single node brings us no additional information on the map compared to the usual geocoding in Wikipedia. On the other hand the place node for a city has a lot of additional data so it would be nice to connect it with Wikipedia.

Other use-cases like the usage of waterway=river or waterway=riverbank needs further discussions of the community. Please use the discussion page here.

The project idea is very good and simple to bring many OSM objects to one Wikipedia article. In the reverse it is not possible to tag one OSM object with more than one Wikipedia article. As solution for that we see the usage of relations.

Please have in mind that the scope of Wikipedia and OpenStreetMap differs at some points. So please do not add things to OSM that are out of project scope like historic stuff or ranges of specimen. We hope to solve this problem later with other projects, like http://en.wikipedia.org/wiki/Template:Attached_KML.

You should also respect that the system has limits. So if you want to tag all post boxes in the world for the article "Post Box", it will not work and you will see protest from OSM-community. Please discuses such ideas before. The system seems also not good for collecting articles in Wikipedia like Streets in Oslo. If you want to have maps in Wikipedia for this it's perhaps better to ask the Wikipedia Map workshop.

Техническая процедура

Основа данных

The project use the data of the mapnik-database on toolserver.org. So we depend on it with some disadvantages:

  • Sometimes there is a larger replication delay: munin-stat
  • We don't support things like Super-Relation and Turn Restriction.
    • Yes it's true. We implemented some hacks to fetch relations and there members from the osm2pgsql planet_rels table.
      Now it's possible to render nice superrelations like: Saalekaskade (2088734) --Master 10:32, 16 May 2012 (BST)

Фильтрация по тегу Wikipedia

OSM has a lot of ways to use the wikipedia=* tag, and we try to support most of them. But we believe it would be best to always use the preferred method: wikipedia=lang:article.

Ключ Значение Поддержка
wikipedia lang:article Предпочтительная схема тегирования. Одного тега достаточно!
wikipedia:lang article Тоже работает. Если нашлось несколько тегов wikipedia, то случайным образом берётся первый. Мы берём остальные языки из википедийных межъязыковых ссылок
wikipedia http://lang.wikipedia.org/wiki/Article Парсится (включая https)
wikipedia:lang http://lang.wikipedia.org/wiki/Article Тоже парсится (включая https)
wikipedia article Выкидывается, так как нам нужен точный язык, и мы не хотим гадать


Please make sure you don't use a name which gets redirected in Wikipedia.
Example: http://de.wikipedia.org/wiki/Frasher gets redirected to http://de.wikipedia.org/wiki/Frashër, but Frasher at WIWOSM doesn't work.

Логирование

У нас включено простое логирование для нахождения некоторых ошибок в wikipedia-тегах или в обработке их WIWOSM.
Проверьте этот список всех записей, для которых не указан корректный язык раздела Википедии, и используйте его для отладки проблем.
http://toolserver.org/~master/wiwosmlog/broken.html

Упрощение

For objects with with a lot of points we use the PostGIS-function ST_SimplifyPreserveTopology() to reduce the data we send to the browser. We also reduce the decimal places. The simplify strategy at this moment is this: 

ST_AsGeoJSON(
  CASE
    WHEN ST_NPoints(ST_Collect(way))<10000 THEN ST_Collect(way)
    WHEN ST_NPoints(ST_Collect(way)) BETWEEN 10000 AND 20000 THEN ST_SimplifyPreserveTopology(ST_Collect(way),(ST_Perimeter(ST_Collect(way))+ST_Length(ST_Collect(way)))/500000)
    WHEN ST_NPoints(ST_Collect(way)) BETWEEN 20000 AND 40000 THEN ST_SimplifyPreserveTopology(ST_Collect(way),(ST_Perimeter(ST_Collect(way))+ST_Length(ST_Collect(way)))/200000)
    WHEN ST_NPoints(ST_Collect(way)) BETWEEN 40000 AND 60000 THEN ST_SimplifyPreserveTopology(ST_Collect(way),(ST_Perimeter(ST_Collect(way))+ST_Length(ST_Collect(way)))/150000)
    ELSE ST_SimplifyPreserveTopology(ST_Collect(way),(ST_Perimeter(ST_Collect(way))+ST_Length(ST_Collect(way)))/100000)
  END
,9) AS geojson

If you have a good idea to optimize it, let us know, please.

GeoJSON и сжатие

We transfer the geometry to GeoJSON with a PostGIS function and put the files compressed on the server. The projection of the files is Google mercator.

Интернационализация;

We use the InterWikiLinks of Wikipedia to create hardlinks in the file system.
The filesystem structure is based on a hashing algorithm called FNV.
The process is as follows:

 1. build a String with the language followed by article with underscores replaced by spaces
 2. compute the fnv hash of this string for example 1A00A138 in hexadecimal format
 3. build the file path like /1A/1A00/1A00A138_lang_articlename.geojson.gz (with forbidden chars removed from lang and articlename and cropped at 230 chars)
 4. write the gzip compressed GeoJSON to that file
 5. for every other language found for an article by Interlanguag links do 1-3 and create a hard link in the filesystem to that file

The advantage of this procedure is a fast access to the right geojson file, if you know language and article, without database queries or such stuff. Also we are able to support simpler update strategies by only updating one file without lookup on interwiki links.

Клиентская сторона

On clientside we load the geometry in OpenLayers. If the geometry is loaded and it's not only a point, we zoom to it.

Обновление

  • We will try to update each night. I optimized the procedure a little so there is a smart update (>34min) each day but wednesday. Wednesday the whole directory is thrown away and completely new generated (>84min). The smart update doesn't check if an OSM-object or its wikipedia tag was deleted or if new languages in inter language links in wikipedia were added. This is only done on full update.
  • If you add a new Wikipedia-Tag and can not wait, you can update with (URL:+"?...&action=purge"). This procedure is relative expensive for us and needs 30-60 sec to be finished, because we have to look up this article in the hstore of the mapnik db on toolserver.
    So if you can, please wait to next day and be careful with this feature (Don't send the URL to a mailing list.). Have also in mind that the toolserver database has a replication lag of some minutes, so please wait after your edit at least 5 minutes.

API

You can get the geojson file content of an article directly by calling: 

 http://toolserver.org/~master/osmjson/getGeoJSON.php?lang=de&article=Dresden

With a lang and article parameter. If it does not exist you get 404 Not Found.

If you want to explicit check if an wiwosm object is there without fetching its content you can use the action=check parameter for example 

 http://toolserver.org/~master/osmjson/getGeoJSON.php?lang=de&article=Dresden&action=check

gives 1 on existing objects and 0 otherwise.

If you explicitly want to regenerate a single WIWOSM-Object before the nightly update process you can use action=purge but use with care!

Исходный код

WIWOSM together with POIs from Wikipedia

Списки для тестирования

Примеры от автора

At the following list you can find some links to example maps:

Прочие примеры

Тулсервер Википедия Wikipedia tag in: Relation link
[2] Strategischer Bahndamm relation type=collection
[3] Residenzenweg relation type=superroute [4]
[5] Rhein relation type=waterway [6]

Известные ошибки

  • if there are multiple Objects in OSM tagged with the same article but in different languages they are not grouped correctly and one group overrules the other

Example: 

 SELECT osm_id, article, lang FROM wiwosm WHERE article='Auvergne';
 --
 -8638 Auvergne de
 1251610255 Auvergne fr

The first row is a polygon and the second is a point. Which one is taken is random.
This bug is not easy to fix in our actual process, because we need to know which different languages of an article belong together before grouping them.
Maybe the solution is a cached Interlanguage lookup table or something.
Now this bug is fixed and osm-objects of articles in different languages that are linked in interwikilinks were combined and appear now in Wiwosm.
See for example Jakobsweg --Master 19:10, 25 May 2012 (BST)

Список дел

A lot of things are in the moment (April 2012) not in WIWOSM.
Help to bring more Wikipedia-Tags inside OSM.
WIWOSM in Europe (April 2012)
  • fixing the known bugs above
  • IE-support
  • testing, testing, testing

Создатели / Контакты

События

  • 10.07.2012 WIWOSM is now running in all Wikipedia versions (not running in Internet Explorer)
  • 21.03.2012 WIWOSM starts it beta-phase and going live in German Wikipedia
  • after OSM license-change WIWOSM will go live in other Wikipedia

См. также

  • Add-tags - web service to assist in adding wikipedia tags to OSM objects with the use of JOSM's RemoteControl feature
  • OSM-Wikipedia place name tool - on Toolserver
  • WikiMiniAtlas - Map widget based on OpenStreetMap data, active on many wikipedia sites; displays WIWOSM data
  • JOSM Wikipedia Plugin - A JOSM plugin which shows a list of Wikipedia articles regarding the area in which the user is mapping (by position or by category). It lets the mapper to add the wikipedia tag by a simple double click, and it also indicates the objects already delivered by WIWOSM server.
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=RU:WIWOSM&oldid=2396598"