Talk:WIWOSM

Leaflet or Mapstraction

Have you considered using the more lightweight Leaflet JavaScript API, or perhaps even Mapstraction, which recently gained support for Leaflet? I much prefer it to OpenLayers in most cases. --Joshdoe 15:32, 15 March 2012 (UTC)

+1 for Leaflet. OpenLayers is one big piece of JavaScript and we should aim to reduce load times. Leaflet is lightweight and is flexible enough to do what I currently see is done by WIWOSM maps. --seav 17:43, 15 March 2012 (UTC)

If somebody write it in Leaflet I would also support it, because Leaflet gives really a little better feeling for users and makes more fun.

But I have really an allergy against coding JavaScript and especially hunting bugs/problems in big frameworks and the map have some more or less comlex features (see options & Layerswitching by Zoomlevel, URL-handling) so it was a hard fight and I'm not willing to start at zero in the moment. The map application was created 2010, so long time before Leaflet. But everyone who is willing to try it is welcome on Toolserver.

BTW: Is it in Leaflet possible to convert WGS84 in Mercator, that what we are doing on some points.

Second point: How is the performance for large geoJSON-geometries (~10.000 points) on older hardware and older browser. Is leaflet there also faster? --Kolossos 17:53, 15 March 2012 (UTC)

I've completed a WIWOSM implementation in Leaflet: Wikipedia:vi:MediaWiki:Gadget-OpenStreetMap.js. It's portable to any other Wikimedia wiki using the importScriptURI() function. – Minh Nguyễn (talk, contribs) 10:07, 24 September 2012 (BST)

Now that Leaflet is used for the main OSM website, it makes even more sense to use it here. Minh Nguyễn, is your script still compatible with WIWOSM? If so, it could be used to replace the current one, but I think the lack of comments in English has put the brakes on the import. Do you think you could translate them maybe? The RedBurn (talk) 08:27, 24 April 2017 (UTC)

As an alternative we have also an Leaflet-implementation from Simon: https://github.com/simon04/osm-gadget-leaflet --Kolossos 08:48, 24 April 2017 (UTC)

Issues

Multi-polygon display problems [fixed]

I found some lakes that have the wiki-tag on a multy-polygon relation. what goes wrong is that all members of the relation that have no tags of their own get ignored. here are two examples: https://nl.wikipedia.org/wiki/IJzeren_Man_(Vught) https://nl.wikipedia.org/wiki/Waterplas_(Rosmalen). I am certain that the first one was displayed correctly before. De vries (talk) 11:00, 19 July 2014 (UTC)

• There was a bug with wrong permissions on the relations table, so all relation processing failed. It is fixed now. --Master (talk) 06:13, 20 September 2014 (UTC)

• Thanx for fixing. Everything works as supposed now. De vries (talk) 21:18, 20 September 2014 (UTC)

Display Problems: Antimeridian

Russia is displayed in an awkward way. A part of Chukotka is cut; if you zoom to that "border" and move the map left and right, different areas become highlighted. --Markhor 07:38, 25 March 2012 (BST)

We know that, it seems a OpenLayers problem with large geometries. --Kolossos 14:00, 26 March 2012 (BST)

Rather, this is a bug/shortcoming of OpenStreetMap. OSM is unable to display ways crossing the 180° aka -180° meridian. If Russia were mapped in one part, the borderlines crossing that meridian would go right to left across the whole map instead, making a large stripe. For that reason, Russia, as well as any land happening to stride that meridian, has been cut in two. And this is why you see these two parts alternate instead of being displayed together. --Papou (talk) 15:12, 31 March 2013 (UTC)

Display Problems: Obtrusive highliting for area

Wnen I click on "(carte)" for this village I find the boundary overlay obtrusive.
For this one, it's even more so because old and new limits with the same name overlay.
I think that the overlay should be lighter, just visible enough to be noticed and maybe in a less harsh color than red.--Papou (talk) 16:12, 31 March 2013 (UTC)

This is not a problem of OpenStreetmap itself, or the interaction between Openstreetmap and Wikipedia in terms of data, it's a specific problem of rendering with the javascript+CSS deployed on a tool server used by some editions of Wikipedia (not all). The CSS style applied may be changed on that server, contact its maintainer !

Anyway you can still hide/show this selection hilite using the option panel that appears on the right of the map panel. You can also use your own private CSS in your Wikipedia account to change the style if you prefer area fills to be more transparent, or use a thinner border — Verdy_p ^(talk) 08:15, 16 October 2015 (UTC)

Permalink

Permalink, the mystery name ;-), is pretty much useless in this window.
I suggest to rename it "enlarge" and to have it do the same as right-click-Open_in_a_new_tab.--Papou (talk) 16:12, 31 March 2013 (UTC)

wikidata?

I don't believe that "name tag" is a good key for OSM and wikipedia article (see comments above: there are about 200 language versions of wikipedia, diacritic letters / utf character sets / non latin character sets).

Wikidata addresses the same problem (but did not solve it in recent years).

It is amazing to see objects highlighted in Wikipedia maps.

An intermediate solution would be fine.

• Should we insert special IDs in OSM entities and Wikipedia articles?
• Is the script sufficiently powerfull to identify all different language versions if one entry is found (eg: start with de:Donau, then -> af:Donau -> als:Donau -> am:ዳኑብ ወንዝ -> an:Río Danubio ...)?

By the way: only now I found out that the link "Karte" is supported in German wikipedia only.

Glad 11:56, 1 April 2012 (BST)

We don't want to wait for Wikidata, which is starting now and needs 1-2 years.

A system of IDs is not good if you want to work with volunteers, so we need a way of human-readable links. We work with interwikilinks as last last step of the process, the idea is now to work with the links on an earlier step to solve the problem of different languages for one object. We will see how long the script needs to run and how good the connection is.

BTW: "Karte" is not only supported in german WP: Also other Wikipedias use it: fr,no,pl,ru, ... . But it's true we are in the moment not in english Wikipedia and yes WIWOSM is only activated in german Wikipedia to get directly user-feedback in the beta-phase. --Kolossos 19:19, 1 April 2012 (BST)

Quick feedback:
Thanks to your initiative now it makes sense to add wikipedia links to OSM (otherwise a map with points for wikipedia articles is sufficient).
It takes hours until syntax errors in OSM wikipedia tags are visible.
So far I have no experience about potential conficts between object tags and relation tag. Example: a trail consists out of several subtrails held togehter by an OSM relation. Will Wiwosm show the relation or only subtrails with identical wikipedia link?
-Glad 09:40, 5 April 2012 (BST)

I think freebase already solves this: http://blog.freebase.com/2009/02/09/mql-monday-querying-for-wikipedia-article-information/ Dbpedia should also be using article IDs, but I could not find a reference to them doing so. --sandos 12:35, 29 May 2012 (BST)

Point Clouds

We have in Germany a lot of wikipedia:Stolpersteine so the map is very slow Stolpersteine-map (Open at your own risk!!!). On the other site is such a map very interessting. The performance problem is not easy to solve. Some solution ideas could be:

• limiting the numbers of object in WIWOSM (makes the map useless)
• clustering (not sure that it help)
• serverside rendering

Any comments to this problem would be nice.

This example is also a good case to see that not in each case a coordinate in Wikipedia is usefull to link at WIWOSM map. --Kolossos 10:04, 17 May 2012 (BST)

What's the problem with redirections?

The main page says that we shouldn't use redirections. I understand why it might be technically difficult, but I think it should be considered whether working with redirections wouldn't be beneficial.

Like I'm currently mapping the river "Vladslovaart", but at a certain point, the river name changes into "Zijdelinggeleed". Because this is essentially the same river, it has the same wikipedia page: [1], with a redirection. So when mapping it, I need to create two multipolygons, one with the name "Vladslovaart", and one with the name "Zijlingeleed", but both should point to the same wikipedia page "Vladslovaart". Now, if some Wikipedia contributor decides that the part of the "Zijlingeleed" deserves a separate page, we also have to adapt our data in OSM.

Ideally, it should be possible to just use the redirection of Wikipedia, and point that part of the river to the "Zijlingeleed" wikipedia page. While the page is handling both, both multipolygons could be shown, when the page is split, only one multipolygon is shown. Without change on the OSM side of the data.

As said, I don't expect a fast solution for this, but while most of the times, not using the redirections is correct, in some cases, using redirections seems to be more correct. It's just something to think about.

Regards, --Sanderd17 14:19, 30 September 2012 (BST)

Internet Explorer 9 Support

I know, ie support is a problem till version 8, but v9 works in my heavy duty (JS, SVG) webapplication exactly with the same code as the other browsers. Could you please test and include v9 in the list of supported browsers? Thanks. --Zuse 07:50, 12 October 2012 (BST)

You can test it with a large polygon like Russia in a version without IE-check: Russia-map. It was relatively easy for me to kill IE9 by zoom-in far enough. --Kolossos 17:54, 18 October 2012 (BST)

You are right. But it works with IE10 (released for Win7 for developers today) :-) --Zuse 22:28, 13 November 2012 (UTC)

Wikipedia tag only at relation level

I've added several similar waterway relations that have been correctly processed by WIWOSM.
The last one is not detected ; names and tags are similar,
one difference : in the last one, there is no wikipedia tag on ways/nodes, except at relation level.
Does it work in this case ?
Could you check if you see something else ? Relation is : 2456454 2456454

--Tbj 09:46, 14 October 2012 (BST)

Confirm the bug: doesn't work here, too. Strange thing. -- malenki 22:06, 17 November 2012 (UTC)

Sorry I can not really see a problem there. The WIWOSM geometry of that river looks like the rendering on openstreetmap. Is it possible, that it had to do with the long lack of updates WIWOSM had since this date? If it is a systematic problem of the WIWOSM processing, please give another example and describe the problem more. (which part is not rendered correctly and so on) WIWOSM checks for wikipedia tags at relation, way and node level.
If it finds a wikipedia tag at a relation it doesn't matter if the members are tagged with wikipedia tag or not. It just collects all members and submembers and so on recursivly and put them together and stores that as the full geometry of the relation. So please check again if it works. --Master 14:16, 9 December 2012 (UTC)

Another example: wikipedia=de:Göttinger Wald.

• multipolygon relation: 4741 4741
• WIWOSM: kml-on-ol-json3.php showing only 52890893 52890893

--Julianladisch (talk) 10:40, 17 October 2013 (UTC)

Wikipedia app

A "show current article on map" feature based on WIWOSM would make a great addition to the mobile Wikipedia app imo. Is that technically feasible? Are the developers of that app aware of WIWOSM? --Tordanik 19:52, 3 November 2012 (UTC)

I hope to meet the developers from the foundation next year. --Kolossos 09:07, 24 December 2012 (UTC)

Any results? --Tordanik 20:48, 21 September 2014 (UTC)

Relation:site

As stated at Relation:site, "Widely used but not unapproved." That being said, does WIWOSM support the site-type relation? Either yes or no, my feeling is that it should look for the "perimeter" role and display that as the polygon on the map in Wikipedia. Example of a United States State Park which was only represented as a POI previous to my creation of a site-type relation; the POI was given the "label" role --> 2656782 2656782. What I'm hoping is that the article W:Worlds End State Park will at some point show the perimeter polygon for the park and not just a POI. --Ceyockey 00:50, 24 December 2012 (UTC)

WIWOSM supports every relation in that way Osm2pgsql on toolserver does. If that creates nice polygons WIWOSM delivers polygons, too. --Master (talk) 13:08, 22 February 2013 (UTC)

Administrative boundaries

My thinking is that these are best dealt with by using Relation:boundary where the administrative border has the role of 'outer' and the (in the United States) GNIS-located label be given the role 'label' and the wikipedia x-ref added to the relation and neither the boundary nor the GNIS-node. I've created two such as an experiment - 2658783 2658783 and 2658774 2658774 . Wondering if this could be written as a best practice into the main WIWOSM page? --Ceyockey 00:25, 25 December 2012 (UTC)

Boundary found not rendered properly?

I found that a relation had the following tag structure, but was not appearing as a boundary element in the Wikipedia mini-atlas

admin_level = 8

boundary = administrative

is_in = New Castle,Delaware,Del.,DE,USA

name = Wilmington

place = city

type = multipolygon

wikipedia = Wilmington,_Delaware

I've now revised the type to 'boundary' and the wikipedia to 'en:Wilmington, Delaware'. Do you think that either of these tags (relation type or specific wikipedia value) would have prevented proper rendering as a boundary polygon? Thanks for the information. --Ceyockey 16:30, 26 December 2012 (UTC)

• Yes, the problem was "wikipedia = Wilmington,_Delaware" which has an ambiguous language. The change to 'en:Wilmington, Delaware' was the right thing to do here. Now it appears in the mini-atlas.

Use of proposed wikipedia:name ~:subject

WIWOSM error-log shows that the proposed wikipedia:name and wikipedia:subject are used recently. Lets get rid of the error-log-entries by not declaring them an "unknown language". Maybe show them in a seperate category in the log? --jjaf.de 13:22, 1 January 2013 (UTC)

• Do you have any idea, what WIWOSM should do with these special wikipedia tags? I could try to code exceptions for a list of wikipedia:<foo> tags. --Master 19:31, 5 January 2013 (UTC)

Usecases of "subject" and other parameters can be found under Key:wikipedia#Proposals. I like the idea to have a map for an architect that shows all buildings of him/her. The handling in WIWOSM should be relative easy so we could use a whitelist and remove the aditional parameter in the database, because it makes no difference for the map in Wikipedia if it was a "subject" or a "name" or whatever. But for the data handling in OSM it can make a difference. So e.g. a street could have his own article in Wikipedia and additionally it can link to a famous person who give the name for the street.... --Kolossos 11:32, 17 January 2013 (UTC)

My thinking was too short. If we have e.g. a street that is not named by a person but by a place, which is really often the case we have a bit problem. In such a case we would show in the article of Berlin all "Berliner Streets" in the world. Without a solution for this problem we cannot support the proposal in WIWOSM. --Kolossos 22:22, 17 January 2013 (UTC)

Wikipedia list articles and WIWOSM

There are _many_ list articles in Wikipedia which contain geographically distinct elements which have representations here. I am wondering how the ability to invoke the wikiminiatlas might be deployed against these articles.

Example: consider the page w:List of rivers of Delaware. I today traced the extent of Tappahanna Ditch and created a relation for it — 2676618 2676618 . In the 'list of rivers' article, Tappahanna Ditch is mentioned. How would I be able to include in the wikipedia article the ability to click to get a wikiminiatlas representation of this waterway? What wikipedia reference would I need to include in the relation? Thanks for considering this. --Ceyockey 01:53, 3 January 2013 (UTC)

In this list I found elements with an own article. For these I would not use WIWOSM to link to the list, but off-course each article should have an entry in WIWOSM. One reason is that Wikipedia will change there list genaration to Wikidata in the future.

Other elements have no own article in the moment because they are to small. But the list also include nearly no additionally information, only that this object exist. In other lists there are such informations, like how long is the river, etc. Such better lists often use also tables and it's possible to use HTML-anchors inside. For such list you can use wikipedia=lang:listarticle#object.

In the other cases you can do this also and WIWOSM should support this but it would have no large benefit in my eyes. --Kolossos 11:45, 17 January 2013 (UTC)

Fat error log

Since "Now all wikipedia tags with undefined language like wikipedia=article are shown, too!" it would be very helpful to add edit links. -- malenki 22:49, 12 January 2013 (UTC)

→ Now there are Edit links to your favorit editors. --Master 09:22, 15 January 2013 (UTC)

To get through the "fat 54k+ error log" we a need a few things:

• For WIWOSM-processing:
  • The list also includes note:wikipedia=* thus maybe *:wikipedia=* as in 158624225 158624225 which are not errors. They should not be shown at this moment but when we get the list significantly reduced.
    • → Now I excluded all *:wikipedia tags from this list. --Master 09:22, 15 January 2013 (UTC)
  • Also we have entries with defunct wikipedia=article and correct wikipedia:lang=article. WIWOSM#Filtering_by_Wikipedia-Tag tells us "If multiple wikipedia tags are found, we use the first we can get." Maybe this could be changed for the case it would generate an error?
    • → This is not easy to do and would decrease the performance of the processing. It would be better to fix the tag in this case, I think. --Master 09:22, 15 January 2013 (UTC)
• Some entries could be corrected semi-automatically in data (not in WIWOSM-processing):
  • By using the WP-(WM)-API to check if the hints on language lead to an actual WP-article or if we have an article in another language, which would be another hint only.
  • 2013-01-30 i sent a message to Chris Lawrence who did US TIGER imports in 2009 to ask him to correct the wikipedia-tagging. No response yet. Maybe it can be included i the TIGER fixup?
• We would need help from the editor-community to include a validator-test for syntactically wrong wikipedia-usage. So we need a wikipedia-validation-module for JOSM for example.
  • JOSM ticket #8383 new enhancement WIWOSM: Test for 'wikipedia'-tags missing language
    • 2013-01-27: Only a few hours later we have two JOSM-validator-tests to play with: my tagchecker.cfg and JOSM/5683 includes a simpler but public one. Please test!
      • JOSM tagchecker rules are distributed live since 2013-02-06. Reduced my own to informational-message only so it wont display multiple times in validator.
• Since for the most part we need people to look at it we should educate them on the preferred wikipedia=lang:article without urlencoding-usage and the wikipedia-JOSM-plugin and promote this somewhere.
  • If you look at the statistics of errors/country maybe US and Poland need some info. When JOSM/5685 goes public people will be alerted of the errors in these countries. For the other countries, lets make the list shorter from the small numbers.
    • In PL there was an mechanical edit for 12K+ errors, but i doubt the Mechanical Edit Policy was followed. Sent message to editor Zbigniew Czernik.
      • Response: "It was not exactly mechanical edit, because I spent about 6 hours for checking correctness those links of this edit. My description is misleading." So we can leave it and have 12K+ errors less - yeah!
    • For the parts of US that were special Tiger imports there is Mechanical_Edits/jjaf.de now to get down to the real problematic objects.

--jjaf.de 13:21, 13 January 2013 (UTC)

There are a lot of false entries from balrog-kun. 1036297, 4389130 for example, but others, too. I found that they belong to the en: Wikipedia, but some works on pl: and en:, so no mass move to pl: :-) Perhaps an candidate for semi automatic fixing. --Zuse 19:59, 13 January 2013 (UTC)

Today, by correcting all the US Interstates we broke the 5 digit error barrier and now we are below 10k! Imagine we corrected 44k+ errors, that is about 473 corrections/day!

Elements mentioned within article

My question is related to previous one Wikipedia list articles and WIWOSM. I like to give background info in wikipedia about monuments. Usually it is not worth to write a separate article but to mention monuments and their coordinates within a larger articles. How to combine OSM and Wikipedia?

Example:

• OSM
  • monument1 + coordinates;
  • monument2 + coordinates;

• Wikipedia
  • de:Article on area xyz + global coordinates
  • Paragraph on monument1 + its coordinates
  • Paragraph on momument2 + its coordinates

How is it possible to link "momument1" to the paragraph within wikipedia de:Article?

Glad 17:12, 13 January 2013 (UTC)

See the "Example (A church in a list of churches)" in WIWOSM#Filtering by Wikipedia-Tag and use wikipedia=de:Article on area xyz#Paragraph on monument1.--jjaf.de 23:52, 14 January 2013 (UTC)

The church-article did not have an WISOSM entry on OSM (now it has -- because I inserted it).

As far as I understand only the whole article gets a connection to OSM via coordinate but not its paragraphs.

My question: an article has several paragraphs (eg on monument-1 and on monument-2), each paragraph/monument has different coordinates. Is it possible to get a red WIWOSM area for each of the monuments mentioned in paragraphs?

Glad 21:00, 15 January 2013 (UTC)

For the map in Wikipedia we add all OSM-objects with a link to this article. If there are different objects that link to different Paragraphs we simply ignore the paragraph and you should find all OSM objects on the map. Please try it. --Kolossos 11:51, 17 January 2013 (UTC)

Thanks for reply. Unfortunatley the WISOSM service is not available at the moment but I'll test it immediately when it is running again. Glad 20:41, 17 January 2013 (UTC)

Example: http://de.wikipedia.org/wiki/Königsforst

• "Karte" shows one object. In the map there are links to other coordinates, described in Wikipedia (not necessary in this article).
• I understand that it is not possible to show several extended objects in one map. Eg. http://de.wikipedia.org/wiki/Rennweg_(Königsforst). The description of "Rennweg" got its own article in order to benefit from WIWOSM.
• Within the article there is a paragraph on "Hügelgräber im Königsforst" + coordinates in Southwest. The location is indicated in the map. Even a picture is shown -- but unfortunately a wrong the picture from following paragraph.

Glad 12:31, 19 January 2013 (UTC)

Check to see if the Wikipedia article "monument1" is a redirect to "Paragraph on monument1"; if it is, or if you can make it so, link from OSM to the former. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:25, 19 January 2013 (UTC)

Right, my fault. Filled in missing data in OSM and wait for database update. Glad

Wikipedia featured articles

I have occasionally reviewed the OSM status of places which appear as featured articles in Wikipedia. As often as not, I find that the featured article's topic does not in OSM have a wikipedia link. I think that this is something that should be continuously monitored as a way to ensure that the latest articles appearing on the main page of (at least the English) Wikipedia are well represented in OSM. One way to do this would be to keep abreast of http://en.wikipedia.org/wiki/Wikipedia:Featured_article_candidates, as articles which appear on the main page as featured will appear here before their appearance on the main page. I am not myself in a position to _continuously_ monitor this, but it might be useful to indicate in a subpage here what OSM places are in the featured article candidate queue and whether they have been backlinked to wikipedia. If there is a general agreement that this would be a good thing, I could compose the subpage and start it off. Thanks for considering this. --Ceyockey 03:02, 15 January 2013 (UTC)

P.S. My last two edits were related to this matter. See 14656292 and 14656319 . --Ceyockey 03:05, 15 January 2013 (UTC)

I did this job for some time in the german Wikipedia and believe it's a good idea because over 10.000 visitors comes to the "article of the day". But I would say it's easier to handle manually, because lots of the article are about persons or objects without geocoding. --Kolossos 11:07, 17 January 2013 (UTC)

Commons:Geocoding

On the page http://commons.wikimedia.org/wiki/Commons:Geocoding there is no mention of OpenStreetMap in the "Fully Manual Procedure" section. It would be useful to have OSM represented; the resources represented right are GeoLocator Tool, hjl geocoding tool, Wikimapia, Google Maps and Google Earth. --Ceyockey 15:10, 20 January 2013 (UTC)

Wikidata

The comment from Kolossos above about adding content here related to the German Wikipedia got me to thinking about whether we should be linking to a specific language wikipedia or working with the relatively new Wikidata resource to link go to a trans-language resource which would provide language selection from availables rather than resolution to a specific language-pedia's page. One would still need in OSM to use the language tag, but the target rendered in, for instance, details about an object would lead to Wikidata and allow selection of target language. Just a thought, but I think that OSM's interaction with Wikipedia should start to migrate over to interaction with Wikidata as a recognition of the pan-language relevance of geographical information. --Ceyockey 15:17, 20 January 2013 (UTC)

+1. Phase 1 of WikiData is to provide a centralized interwiki database for Wikipedia so that each language's article only needs to link to the central page on WikiData in order to access all other language articles. --seav (talk) 23:14, 11 February 2013 (UTC)

wiwosm down

Unfortunately wiwosm is down again. Is there a page which informs about its status? Is it possible to learn when database is updated? Glad 20:44, 23 January 2013 (UTC)

Yes, I've seen it today, too. Think it only happens on full update on wednesday. When I start it by myself it works as expected, so maybe there is a permission error or something.
Unfortunatally there is no real test at the moment, if everything has worked fine. I think about implementing more error catching logic. At the moment there is no such status page or something. WIWOSM should be back in a few minutes, I think. --Master 15:15, 24 January 2013 (UTC)

WIWOSM-update down again! Broken log does not update since 2013-04-03T05:05:02+02:00. --jjaf.de (talk) 10:31, 5 April 2013 (UTC)

Currently http://toolserver.org/~master/wiwosmlog/broken.php does time out. I updated http://osm.jjaf.de/wiwosm/log/ and http://osm.jjaf.de/wiwosm/log/?stats to catch this error and serve the last cached version so bugfix-work can continue. --jjaf.de (talk) 23:03, 5 April 2013 (UTC)

Delay

Hi, I added wikipedia tags on several relations on Friday, but I still can't see the polygons on Wikipedia. I tried the action=check and I get 0 as a result. I tried forcing update with action=purge but nothing happened. What I understand of the log page is that the database has been updated today, and that my tags have not any problem. If you want to try relation=1566259, tag wikipedia=es:Departamento San Fernando. Any ideas of what is happenning? --Pertile (talk) 21:29, 27 February 2013 (UTC) My experience is that you can see WIWOSM-changes in WP after every thursdays update around 04:00. The other days only the broken language list updates. So now your great work is online!--jjaf.de (talk) 23:17, 28 February 2013 (UTC)

I admit it is a bit confusing. The problem is, that every wednesday I make a full upgrade of WIWOSM. That means I rebuild the directory with the hardlinks completely. There is something wrong with the Sun Grid Engine on the toolserver that I try to discover. So the last wednesdays I changed something and looked if it had run the next wednesday. After I noticed that it didn't work, I ran the updating process manually and so it had worked after that. Depending on when I noticed the error on wednesday and started the updating process again there could be errors during the wednesday.
I think I am not able to discover the problem by myself, because there are no error messages or something usefull to debug the problem. For now I changed the WIWOSM script to not use the Sun Grid Engine and run directly through cron. So it should work every day without problems.
BTW: It is not true that only the broken language list is updated every day. Every new wikipedia-tag should be recognized on every update every day. What I can not get every day but wednesday are deleted wikipedia tags on OSM or new interwiki links. Old objects are still there until wednesday. At the moment I even update the interwiki links by hand. Maybe this can be changed if I switch to wikidata but that is a long way, I think. --Master (talk) 15:00, 1 March 2013 (UTC)

API-bug: check multiple articles delimiter collision

It seems due to Add status check for multiple articles. there is an undocumented API-function that expects a *C*SV-article-list to return a *T*SV. The problem is, that WP-articles can and do include the delimiter (",") even multiple times as in article IG Bergbau, Chemie, Energie and there is no escaping defined in the implementation getGeoJSON.php line 47. The requester of that API is using it in JOSM plug-in wikipedia which fails for those articles. Please communicate with the requester about a change in the API with escaping or think about using *T*SV input to have the WIWOSM-API *and* JOSM plug-in fixed. --jjaf.de (talk) 19:32, 4 March 2013 (UTC)

Lake Nasser broken

Lake Nasser doesn't show up but only some of its islands. Maybe the object is too big? IIRC it has ~8000km outer ways. But it doesn't render on the toolserver, too…
WIWOSM-Link 280282 280282

Wikidata as d: supported?

We discussed that the use of Wikidata should be done via the Prefix d: in the Wikipedia-Tag like (wikipedia=d:Q1017 links to wikipedia:d:Q1017). The main Wikipedia API allowes this. How is WIWOSM handling this data? That should be a requirement for wide use of d: links.--Zuse (talk) 18:33, 24 March 2013 (UTC)

I answer there. --Kolossos (talk) 20:36, 28 March 2013 (UTC)

WIWOSM in it.wp and nl.wp not available

The OSM gadget is activated in it.wp and nl.wp. Until not so long ago WIWOSM was enabled in it.wp, but now it does not work anymore. Could you please re-enable it? With regard to nl.wp, now that the OSM gadget is enabled, could you please also enable WIWOSM? Thanks, Longbow4u (talk) 19:55, 25 March 2013 (UTC)

WIWOSM is working with it.wp and nl.wp. Checked http://it.wikipedia.org/wiki/Hannover using "Mappa" and http://nl.wikipedia.org/wiki/Hannover_%28stad%29 using "Kaart" in the upper right next to the article coordinates.

Since the links itself as the WIWOSM-functionality is JavaScript maybe the problem is in the browser?--jjaf.de (talk) 20:11, 26 March 2013 (UTC)

I checked WIWOSM with Gelderland: w:de:Provinz Gelderland Ok - w:it:Gheldria (provincia) not OK - w:nl:Gelderland - not OK. Since the wikilinks are set, and the OSM database contains the key wikipedia with value nl:Gelderland, it should work at least also in it.wp. WIWOSM for Hannover is working in it.wp for me, too. - strange. Longbow4u (talk) 08:02, 29 March 2013 (UTC)

Yes, it's really strange, "de" and "it" are both in the wikipedia-database (both links are also in Wikidata). So we need to search deeper. --Kolossos (talk) 19:15, 29 March 2013 (UTC)

I get the same results on all three mentioned links so again, i can not reproduce. Is the problem solved now?

I use Firefox, and for me the problem is not solved today for the examples for Gelderland. I checked that I have Javascript enabled while checking. Above wrt Gelderland I meant that I checked if the WIWOSM overlay for Gelderland was shown in the OSM-Gadget-Map (not WikiMiniAtlas-Map). I hope this can be solved. I hope Kolossos and master can find some time to look into this and find a solution. Longbow4u (talk) 21:20, 9 April 2013 (UTC)

The following screenshots show what FF 21.0 (beta) and 20.0 see on WINXP/WINVista: NL OG IT OG] IT WMA] (OG = OSM-Gadget, WMA = WikiMiniAtlas). For me they show everything is working fine - or do i miss something? If your get other result then please try Troubleshoot Firefox issues using Safe Mode --jjaf.de (talk) 20:52, 10 April 2013 (UTC)

There *is* a reproducable incicdent when you choose to use the 'uselang=otherlanguage'-parameter in wikipedia, as WIWOSM uses this setting which is only for user-interface-language to decide which language the article comes from. As with your example "[Provinz] [Gelderland|[Gheldria (provincia)]" there may not be an article with the same name in the other language as with "Hannover" and so a mix of languages like "de:Gelderland" gets requested on [2] which fails. Maybe you have experienced this situation? --jjaf.de (talk) 13:47, 27 April 2013 (UTC)

I'm currently mapping in Portugal and like to contribute also WP backlinks. Unfortunatly, they seem to have no unique geocoordinates schema. Maybe you like to help, to bring OSM geoshapes also to this wikipedia and to promote our project there :) ? [3] --!i! 08:38, 30 September 2013 (UTC)

Waterway relation?

Are there known problems about waterway relations? Example: 3015151 3015151

But on Wikipedia I only see the small part of the river which got the tag wikipedia=de:Dickopsbach additionally, but not the relation.

I assume, the big "W" in key 'Wikipedia' was the bug. I changed it to 'wikipedia' and removed the surplus tags on the segments. Give it some time to update to see an effect.--jjaf.de (talk) 09:04, 25 June 2013 (UTC)

Now it's there. Thanks a lot! I was not aware that capital letters might be a source for problems. Glad (talk) 20:20, 26 June 2013 (UTC)

Utah Data Center only in orginal language

Since the geometry 158898045 158898045 for the Wikipedia:en:Utah Data Center - lately came to fame for the general public - got deleted once and was restored, it is only present in 'en' an no other language as before, e.g. getGeoJSON check EN = 1 but no getGeoJSON check DE = 0. The article name is identical here, it is written differently in 'it'.--jjaf.de (talk) 08:35, 8 August 2013 (UTC)

Unknown error in language 'es' entries

In WIWOSM broken language statistics for 2013-08-08T05:24:34+02:00 'EC' came up with 2, 'AR' with 12 error entries. Both countries use language 'es'. It seems like all entries refer to geometries that have been created or tagged correctly yesterday and most even have no referrers that could interfere, e.g. 2409688060 2409688060 with wikipedia=es:Supercines.--jjaf.de (talk) 08:35, 8 August 2013 (UTC)

The statistic prints the iso2 country code, but says this is the language iso2 code, yes. A 100% exact mapping from the country to the language code is not possible. The wrong description should be fixed.  :-) --Zuse (talk) 11:07, 26 August 2013 (UTC)

Streets?

In DE:Wikipedia articles like Bundesstraße 55 the street in shown in Bing. But there is no link to WIWOSM. In other articles like river WIWOSM extracts its information from infoboxes. Why does it fail in street-articles? Should we add "coordinate" template to street articles? Glad (talk) 20:28, 25 August 2013 (UTC)

Some people removes 0-dimension information (one coordinate) from a line feature (i had a discussion] with an de-admin about wikipedia:de:Kaiser-Route with this topic). The problem could be solved if we could establish an template for a "start" of a feature like the river infoboxes. There hopefully are more resistent to deletion compared to one uncommented coordinate.--Zuse (talk) 11:08, 26 August 2013 (UTC)

I assume that the street-template should be adapted. On top right there are several links to maps already, but WIWOSM is missing. When I insert a "coordinate" template, the map_link_line is positioned above existing link line, and not readable any more. Perhaps it is possible to adapt it as it was done for river template. Glad (talk) 20:01, 27 August 2013 (UTC)

Multilang link detection

Hi, maybe it had been already discussed, but I don't find it anymore:

What if a object has wikipedia articles in multiple languages (maybe with localized names)? The wikipedia=* IMHO just supports refering one article? So is there currently a check to detect all the remaining language-versions in different wikipedias automaticaly and to embedd the shapes there, too? --!i! 19:19, 30 September 2013 (UTC)

Yes, it uses language-links, see Internationalization in WIWOSM#GeoJSON_.26_compression. Thats the reason why only one single wikipedia=* is sufficient.--jjaf.de (talk) 07:30, 2 October 2013 (UTC)

Ah brilliant! So will just continue my work that way :) --!i! 09:13, 2 October 2013 (UTC)

wikidata 35k fat error log

... and we have a fat error log again:

03.03.2014: Now we use wikidata to get all associated languages! You see all articles here that were not found in wikidata.

As for the last one with 54k errors which we got down to about 4k until today we need some plan to get through these one too.

1. classify the errors, especially as we have the old 4k in there too. Like a changed hyphen gets redirected [4] and leads to wikidata [5] not found.
2. have a plan what to modify. Are we adding wikidata=* to the existing wikipedia=* to leave them for running applications?
3. build a bot like Mechanical_Edits/jjaf.de for errors classified to be correction assist able to focus the contributors on the real bad ones where we need human interaction.
4. improve the tools like the JOSM wikipedia plug-in to include the wikidata=* and have some bugs like multiple entries fixed.
5. make contributor sized packages of errors for them to correct and see a result.[6]

--jjaf.de (talk) 09:51, 3 March 2014 (UTC)

Hi Jjaf, your work on analysis of the WIWOSM error log is awesome! Thanks. I wrote some notes at the new wikidata processing of WIWOSM. You may noticed, that there are some problems on updating WIWOSM at the moment, but I'll fix it the next days, so it will be stable again. I just want to note, that some of the bugs in the error log could be problems of WIWOSM at the moment. I found some bugs in processing languages with hyphen "-" in its name, but that will be solved in the next days. A full WIWOSM run that updates every table takes a whole day now, so we have to wait a little. Fortunately that is not needed very often and I can cache much of the wikidata language links, so that a normal data update of the OSM-data just tooks 1 to 2 hours. I have to rebuild the whole stuff just in case of finding a bug in WIWOSM.
Another new source for errors could be wikidata. I don't know if every article has its own wikidata-id now and if all language links are present there. I think we'll have to fix some bugs there, too. Your analysis could be very usefull for that. --Master (talk) 10:14, 6 March 2014 (UTC)

classification

classification of errors

type	name	sample	possible correction	approx. ocurances	bot candidate?
name change	char	[7] the char ASCII 0x93 "-" got replaced by Unicode 0x80E2 "–". redirects.		246	yes
name change	clarification	Wikipedia:de:Alter St. Nikolai Friedhof, redirects to " (Hannover)" appended.			yes
name change	de-clarification	Wikipedia:es:Illano (Asturias), redirects to article with " (Asturias)" removed.			yes
name change	acronym to text	Wikipedia:de:IHK Hannover, redirects to "IHK" written in full.			yes
name typo	white space	Wikipedia:de: Augsburger Rathaus, leading white space removed by wikipedia without notice, same for trailing.		206	yes
format error	URL	Wikipedia:de:de.wikipedia.org/wiki/Wehre, got reduced to "Wehre" by old WIWOSM algorithm but apparently not for new wikidata lookup. Also full wikipedia URL.		367	yes
format error	double language	478613616 478613616 has superfluous language in wikipedia:de=DE:Witznautalsperre.			yes
format error	1+ entries	796757274 796757274 has 1+ entries comma separated in one tag like wikipedia=en:Kadkan, fa:کدکن, also 248901619 248901619 having URL and correct format wikipedia=http://es.wikipedia.org/wiki/Cigüela;es:Cigüela.The URL gets reduced to article in the log.		243	yes
format error	illegal char	25433720 25433720 has an illegal char in wikipedia:es=[[Tag:wikipedia:es=Mu�orrodero (Cantabria)|Mu�orrodero (Cantabria)]]. The char can represent different es special chars. Also place_name=* is affected.		30
semantic error	Commons link	"Datei:SchmelzDickeEiche.jpg", prefixed "File:", "Datei:", "Fichier:", "Plik:", "Файл:" and maybe more are [Wikimedia Commons] and link to images. Also with full Commons URL in different flavours.		98	yes
semantic error	website	2677011526 2677011526 has something like wikipedia=en:http://example.com, seems also be common. wikipedia=* used as website=* but easily parse able.			yes
missing data	deleted entry	Wikipedia:de:Löbschütz (Zwenkau)
missing data	no wikidata entry for wikipedia article	Wikipedia:lt:Joniškėlio Švč. Trejybės bažnyčia apparently has no wikidata entry?!

update problem may 2014

The processing seems to have problems updating. For example the log in germany has 47 entries "DE-Schutzplanke http://en.wikipedia.org/wiki/Crash_barrier", but they are fixed 2 weeks ago. --Zuse (talk) 07:11, 7 May 2014 (UTC)

display problem on opera@linux (solved)

Furthermore the buildin-map in wp-de is working from the aachen university (labs server is used), but not from my home DSL where it tries to load from the toolserver.org. I observe this problem since a few weeks. --Zuse (talk) 07:11, 7 May 2014 (UTC)

oh, its not university vs DSL, but opera vs Chrome/Firefox at my DSL Linux Desktop. Chrome/Firefox works without problems, opera did no a connection to https://toolserver.org/. I have no idea what happend, but after connect to https://www.tooolserver.org the browser is happy with the https://toolserver.org connection. case closed :) --Zuse (talk) 08:30, 10 May 2014 (UTC)

Wikipedia JOSM plugin is not working

And it's because https://tools.wmflabs.org/wp-world/ shows that there is no service, so no data is fed to plugin. Probably there is a flood of these kinds of news, but I add note here just in case anyway. Jaszczur666 (talk) 08:51, 30 June 2014 (UTC)

Ok so for sake of completness, it's working again. Jaszczur666 (talk) 21:31, 30 June 2014 (UTC)

No update since march 2015

http://tools.wmflabs.org/wiwosm/wiwosmlog/broken.html says it has not been updated since a few weeks. The stats page is not working, too. 8-( --Zuse (talk) 12:46, 21 May 2015 (UTC)

That is still the case. Any plans to fix this? --Gormo (talk) 09:59, 5 June 2015 (UTC)

Could this still be the problem in Nov 2015? I have tried to add coordinates to a couple of linear (river/highway) articles in Wikipedia (usually to match one end), and added wikipedia=en:<name> to the relevant relation in OSM (that contains all the segments). So far, none of these seem to show the OSM line on the WikiMiniAtlas. Do I need to do something else, wait longer than 24 hours, or alert someone to something being down? Thanks. --Sbdavis (talk) 12:48, 7 November 2015 (UTC)

Edits made in OSM are imported in the Wikimedia copy of the database after long delays and the tools that generate the index for includion in Wikimedia pages frequently take weeks (if not months) to reflect the changes.

Yes the way to go is to use "wikipedia=lang:Pagename" tags (or "wikipedia:lang=Pagename" for other languages than the default language used in the geographic region of the tagged object). Be patient, they'll be visible after some time.

If you don't see those links in Wikipedia-hosted slippy maps aftger a couple of months, may be there's a problem in the data import tools used in Wikimedia. This is not a problem of OSM itself unless the tags are wrong or ambiguous. The WIWOSM project on Wikimedia has tons of bugs/feature requests to act on, and some of them may be blocking/hiding the visibility of some data on Wikimedia sites. Most of these problems are caused by ambiguity problems, or the wikipedia links in OSM data are in fact directing to a double redirect, or a disambiguation page, and those links can't be visible.

Also in some cases you'll need to check the interwiki links in Wikidata (many Wikipedia pages are not correctly linked in Wikidata: the job does not stop here in OSM database, you have to check the coherence).

Cooperation work between OSM and Wikimedia is a lengthy and neverterminated task, and it is complicated by the need to work across multiple Wikimedia wikis, not just Wikipedia editions; most of the work to do is lots of "minor" edits and those needed changes are frequently invisible or not understood by most users here on OSM or there on Wikimedia, that are not interested in fixing other places than their own local wiki or a few pages; this is a work for ants, often not gratifying because we almost never receive any thank you about them. Some irritating users don't understand why those minor edits are made because they have a limited view of the project and think "why changing something that works (for them only because they did not check other uses and don't care about these)"...). — Verdy_p ^(talk) 13:57, 7 November 2015 (UTC)

Thank you. I am much more active as a Wikipedia editor than an OSM editor (but have done a bit here too). I only noticed a few days ago that the WikiMiniAtlas on some rivers showed the route, and set about working out why they did and others didn't. I tried making some changes and waiting a day for the toolservers to catch up, then looking further for explanations of what I hadn't done right. Thanks for confirming that I'm on the right track. I think this is a great way of projects sharing work that is quite tedious to do more than once. --Sbdavis (talk) 21:52, 7 November 2015 (UTC)

The text says "The project use the data of the mapnik-database on toolserver.org", but that server has been gone for some years already, hasn't it? New articles created recently in the Swedish Wikipedia are not visible in WIWOSM. This is a problem. --LA2 (talk) 17:05, 26 January 2016 (UTC)

We use the mapnik-database on WMFlabs, that's correct. Sometimes the server has an lag but we should update on an daily basis. If you have an actual example of objects in OSM with an Wikipedia-tag older than a week that are not on the map, please give it to us. --Kolossos 18:47, 26 January 2016 (UTC)

Hi, I think there is some problem with this relation http://www.openstreetmap.org/relation/2631216 --Wizzard (talk) 10:06, 1 June 2016 (UTC)

query only for polygons possible?

• The result of http://tools.wmflabs.org/wiwosm/osmjson/getGeoJSON.php?lang=wikidata&article=QXXX delivers for places in some cases points/multipoints/linestrings, in other cases polygons/multipolygons (or a mixture of both/geometry collection). Is it possible to query only for polygons/multipolygons (items with an area)? Right now I have to filter the GeoJSON results on the clientside, but it would be better to do this already on serverside.
• Another question: Is it possible to get the result in SRID 4326 (WGS84) instead of GoogleMercator projection?

--ArchINFORM (talk) 11:37, 21 December 2015 (UTC)

In the moment it's not possible to get an specific type of objects. For performance reasons, your request is only a file request without any database usage.

It's a good point that we also should provide SRID 4326, it's now the standard of geojson. As we started it was more or less undocumented. --Kolossos 15:57, 22 December 2015 (UTC)

Location of object location

Hello, there is related discussion at https://meta.wikimedia.org/wiki/2016_Community_Wishlist_Survey/Categories/Multimedia#View_object_location_of_all_images_with_coordinates_on_a_map --Snek01 (talk) 15:58, 29 November 2016 (UTC)

commons-on-osm.php source code?

I was interested in helping make some improvements to the 'commons-on-osm.php' map tool. I'm a bit confused about where the source code actually is though. I see this wiki talk page seems more lively, but... well I wrote my question here -- Harry Wood (talk) 01:18, 27 January 2017 (UTC)

No updates since July 2018

Hi, on http://tools.wmflabs.org/wiwosm/wiwosmlog/broken.html Timestamp is 30. Jul 18. Is something with WIWOSM wrong (or is the project dead :( ) All my recent Wikidata/wikipedia tags are not represented in WIWOSM output... --ArchINFORM (talk) 21:47, 19 December 2018 (UTC)

Continued major errors with WIWOSM

Please refer to this discussion on Wikipedia. Sdkb (talk) 21:14, 3 December 2020 (UTC)