Talk:WIWOSM/Archive 1

Quality assurance

Great project! I'd like to throw some ideas out here for quality assurance. These don't have to be done as part of this project, but for many of them it makes sense. Create a list and/or map of the following conditions:

• Article coordinates don't lie within or near OSM object (error in one or the other)
• OSM objects tagged with articles which don't exist, or are redirects
• Articles which have a high view/edit count and belong to certain categories (e.g. places), but don't have a corresponding OSM object
• Multiple OSM objects with the same article (see One feature, one OSM element)

Also:

• Link to OSM.org page for object, as well as edit links for Potlatch2/JOSM (debug/editor map view)

I think this will help improve the quality of both Wikipedia and OSM; great job! --Joshdoe 22:39, 14 March 2012 (UTC)

To your suggestions:

• In Wikipedia we have a lot of sunken submarines or ancient place. So I'm not sure if this really useful.
• Yes will create such lists or map-application. It's important that other developer are also involved in this process.
• see above.
• That's see not correct or I misunderstand you. One Wikipedia-article can have more than one OSM-object. E.g. the german university TUC has 4 locations.

I see also a problem that it is not easy enogh to add some tags to large relations. Why is this not possible directly on the website? Why I need an editor for this? --Kolossos 17:15, 15 March 2012 (UTC)

A little bit of logging is enabled at the moment. So I have a small krude list with stuff that is not a valid language. Maybe you can look for some of that articles and find the bug in OSM. --Master 08:35, 16 March 2012 (UTC)

Logging is now better: check http://toolserver.org/~master/wiwosmlog/broken.html --Master 21:35, 29 May 2012 (BST)

When relation was shown in a map and language different from RU I tried to heal some erroneous tags. Glad 21:34, 2 June 2012 (BST)

A good example that we should tag relations not elements: Elements of the motorway E50 were tagged sometimes as Goldene Straße or via Carolina. If you check the article in Wikipedia both tags are wrong: the historic route is dated back to 1500... --Glad 21:48, 2 June 2012 (BST)

Attached KML

How will this relate to wikipedia:Template:Attached_KML? WIWOSM overrides KML? KML for historic and other features that don't belong in OSM? --Joshdoe 22:39, 14 March 2012 (UTC)

I would say that we should add the Attached_KML on an different layers. So the user can see where the data come from. I'm not sure if we use this "in the Wiki KMLs", perhaps there is a better way. --Kolossos 21:42, 20 March 2012 (UTC)

WikiMiniAtlas is currently displaying both. That way the wikipedia article can add data on top of the OSM data. But I do not distinguish by data source. I'm thinking of a legend/attribution system, that makes the source more transparent for the user. --Dschwen 16:52, 3 April 2012 (BST)

Simplify, and size.

I tried simplifying the geojson object for Austria from the current resolution to ~665 points and it still looks good. The original was 100KB compressed and simplified was 7kB, as a reference the png overview map on austria article is ~55KB. Then again Openlayers js payload is going to be pretty big as well. Erik Johansson 09:12, 15 March 2012 (UTC)

Yes but we are able to zoom-in. We adjust the simplification to come in a region of 10.000 points. WIWOSM JSON file for Austria is 105 kB in network traffic. OpenLayers come to 216 kB what seems ok for me compared with the traffic of the tiles and the fact that you need to load it only once. --Kolossos 17:26, 15 March 2012 (UTC)

The comparision to a 55kB png is interesting though isn't it? Erik Johansson 09:03, 16 March 2012 (UTC)

Which wikipedia tag?

I see two methods mentioned, including the language in the key (e.g wikipedia:en=United States) or the value (e.g. wikipedia=en:United States). Which is preferred? It would be nice to only stick to one or the other. --Joshdoe 10:46, 15 March 2012 (UTC)

I prefer the latter style you mentioned. Ideally, you should only have 1 wikipedia=* tag and let Wikipedia's interwiki links take care of pointing to the other-language versions. The wikipedia:en=* style seems to invite adding wikipedia:de=*, wikipedia:fr=*, etc. which we don't need. --seav 13:58, 15 March 2012 (UTC)

I'd agree. I suppose criteria for which language to use might be the native language of the country where the subject is located, defaulting to English (e.g. for international subjects). Of course usually will be just whichever one gets tagged first. I wonder if we'll see edit wars with this wikipedia=* like we do with name=*... --Joshdoe 15:31, 15 March 2012 (UTC)

Please use "wikipedia=language:page title". The definition of a language is a must! To catch the interwikilinks of wikipedia we must specify the language and it's not possibble for a small tool to detect what language could be the native language in an area. So to make the Wikipedia-tag easily machine-readable, please specify the language! We support in the moment both ways wikipedia:lang=article and wikipedia=lang:article but the second one seems in the most cases more useful. --Kolossos 17:37, 15 March 2012 (UTC)

Hi, how you connect multiple Wikipedia-Links in a relation like the Danube river? Donau? Smarties 23:42, 21 March 2012 (UTC)

One Wikipedia-Link is enough but it needs a language parameter. For the other languages we use the INterWikiLinks. But in the moment there seems a bug in our osm2pgsql so that we don't have the this relation in the DB. We will looking for a solution. --Kolossos 07:53, 22 March 2012 (UTC)

We had a discussion on maps-l and the problem seems more difficult than I thought, would it be possible to declare that a river line is type=route? Only an idea. I mean the water goes along this route.... Perhaps we can talk for other objects also about a type=wikipedia to know that this relation exist only for this reason. --Kolossos 21:34, 22 March 2012 (UTC)

The other idea is to make it like River Rhine, where all riverbank areas have an Wikipedia-tag and it works fine. --Kolossos 15:24, 23 March 2012 (UTC)

Issues

Tagging Schema and Subkeys

I've encountered some issues with waterway=river relations and various Wikipedia Tagging options described underneath "Filtering by Wikipedia-Tag". For some reason, OSM objects with several wikipedia:* = * tags for different languages don't seem to be recognized at the moment. Here's a short summary with my test results:

OSM Link	Wikipedia Link	OSM Tags	Map in Wikipedia Test Result
http://www.openstreetmap.org/browse/relation/1706112	http://de.wikipedia.org/wiki/Rhein	wikipedia = Rhein	ok
http://www.openstreetmap.org/browse/way/125367290	http://de.wikipedia.org/wiki/Prims	wikipedia = http://de.wikipedia.org/wiki/Prims	ok
http://www.openstreetmap.org/browse/relation/390393	http://de.wikipedia.org/wiki/Saar	wikipedia:de = Saar wikipedia:fr = Sarre_(rivière)	currently with tributories --> mapping issue --Werner2101 08:56, 9 June 2012 (BST)
http://www.openstreetmap.org/browse/relation/410743	http://de.wikipedia.org/wiki/Blies	wikipedia:de = http://de.wikipedia.org/wiki/Blies wikipedia:fr = http://fr.wikipedia.org/wiki/Blies	not found --> moved to WIWOSM/missing list --Werner2101 08:27, 30 April 2012 (BST) seems fine now -- malenki 20:32, 11 June 2012 (BST)

--mmd 08:22, 24 March 2012 (UTC)

Sorry for this problem. We will try to solve this problem. We don't import in the moment relations with type=waterbody. To solve this is will be not trivial and needs time. --Kolossos 15:44, 24 March 2012 (UTC)

Good to know, thanks! As long as waterway=river relations are not yet supported, a workaround might be to add wikipedia-tags to all relevant ways of a relation. --mmd

Please, do not add wikipedia tags to the ways. This will create lot of confusion because a the wikipedia tags are no longer uniq. --Werner2101 12:27, 22 April 2012 (BST)

You can also generate a multipolygon relation with all riverbanks and add the Wikipedia-Tag there. I can't say whats better. --Kolossos 14:03, 26 March 2012 (BST)

Currently there are only few riverbank relations in OSM. Most of them are huge ... and incomplete. It's easier to maintain the center line o the waterways. If you like to see a river on a map, you're usually not interested in the exact shape of the riverbank, but you're interested where a river flows along. see also: Relation:waterway. --Werner2101 12:27, 22 April 2012 (BST)

(You already summarized all problems I encountered and found comments in forum: only one "wikipedia" tag allowed (eg "wikipedia=de:Rom" excludes Italian Wikipedia); tags like "wikipedia:nn=abc" are neither handy nor reliable; it takes time until changes in OSM are visible in Wikipedia maps...).
The idea is great. And it improves OSM (I quickly found missing tags there). -Glad 21:40, 31 March 2012 (BST)

I added tags to OSM several hours ago. How long does it take until it should be visible in Wikipedia? Glad 22:30, 31 March 2012 (BST)

... about half a day. -- Glad 11:56, 1 April 2012 (BST)

We update each night. --Kolossos 11:23, 23 April 2012 (BST)

WIWOSM doesn't show relation with spaces/round brackets in name

wikipedia=* key in http://www.openstreetmap.org/browse/relation/1184564 points to an existing wikipedia page, however WIWOSM doesn't show that relation on the map. This used to work a couple of weeks ago, but now fails. How can this be fixed? --mmd 16:06, 30 March 2012 (UTC)

The problem were not the brackets, the problem was that the Wikipedia-Tag for the relation used the encoded URL and the Tag for the node use the preferred tagging schema. I fixed this and it works now. We have on database-level no function for URL-decoding. We try to merge all objects for one article but this doesn't work correctly in this case and so sometimes win the node and somtimes the relation.

Thanks for bug-report. --Kolossos 21:55, 31 March 2012 (BST)

This is really odd. When I checked the map later that evening, everything looked pretty ok. First thing next morning checking back what the current status is and - surprise - we're back to the old/wrong behavior. Maybe something in the nightly update process screws things up. --mmd 14:33, 2 April 2012 (UTC)

Cannot reproduce the issue at the moment, so I assume it is fixed by now --mmd 22:14, 13 April 2012 (UTC)

Fill area opacity is static

First of all, I believe this is more of a feature request than a bug. When I open up a WIWOSM map in wikipedia, an OSM area/relation is shown as a red solid line with red semi-transparent filling (50% opacity). This looks great as a big picture overview. However, once you zoom in further the red background feels somehow distracting. I would appreciate a less prominent background in that case. How do other users feel about this? --mmd 22:11, 13 April 2012 (UTC)

You can always uncheck the "OSM objects (WIWOSM)" at the selector panel. --seav 03:42, 14 April 2012 (BST)

Overview about existing links

Is it possible to extend the [wiwosm-list] running on the toolserver in a way that shows, which of the listed OSM-Wikipedia links is already in use at Wikipedia (by adding [the Template Coordinate] )? It would help to accomplish the georeference for existing OSM relations. --5erBande 16:01, 21 April 2012 (BST)

E 3 doesn't show up for .de

Fixed (with the multilanguage-fix I assume). -- malenki 07:57, 1 July 2012 (BST) The E 3 (European long distance path) does not show up for all germany although it is mapped quite excellent since a long time: WIWOSM OSM. Why is that so? -- malenki 21:55, 24 April 2012 (BST)

AFAIK osm2pgsql doesn't handle superrelations[1]. Sorry that we don't saw this before we start. It's really a bug but not easy to repair. --Kolossos 17:02, 25 April 2012 (BST)

I know WIWOSM doesn't handle super relations, iirc you told me that. :) (not true anymore) But also every sub relation of E 3 has the WP-Tag (with the complete URL) on it so I am still wondering. -- malenki 04:23, 26 April 2012 (BST)

PS: Since there seem to be some more objects not showing up at WIWOSM I started a list of missing objects. -- malenki 14:42, 26 April 2012 (BST)

Collection

Are Collection recognized? Up to now I tagged all elements, eg different sections of a river.

• Is it possible to collect them all and assign the Wikipedia-tag to this collection? Are collection displayed?

Doesn't seem so; look at the list of missing objects mentioned directly above (and add objects you miss). -- malenki 14:56, 28 April 2012 (BST)

PS (since I read your question only half, sry): It is discouraged to create big relations since they break quite easy and every edit at one part of it gives a new version so that it's history grows fast and the relation itself gets all the worse to handle.

Besides, one is neither encouraged to do so nor is it necessary to add all riverbanks and the river itself to a relation. WIWOSM itself has already stuff in it to reduce the complexity of big objects so that would just double it's work. In case you want to get all the stuff of the river for whatever purpose, just use the API of your confidence or JOSM's "download along" or similar stuff. It is not recommended to put everything of $stuff into a relation just to have quick access for it. -- malenki 15:08, 28 April 2012 (BST)

It seems collections show up (now), too -- malenki 05:09, 29 April 2012 (BST)

• Is it possible to assign to the elements of the collection different Wikipedia tags?

Glad 19:14, 27 April 2012 (BST)

Of course you can give the collection relation the tag wikipedia:de=X and the members of the collection wikipedia:de=1, wikipedia:de=2, and wikipedia:de=3. Though it would become quite messy when an object is e.g. member of three relations and one wants to add to each relation WP-tags and for each (sub)tags to the object itself. You know that there are ways with about six hiking routes on them?. :) -- malenki 14:56, 28 April 2012 (BST)

OK; I'll give tags only to elements (it is quite boring to go along all elements but I understand this is the most reliable way to do). Thanks for reply.

Please have a look at WIWOSM presentation of Rhein. If you go to the beginning in the south you'll find that some parts of the river are missing. Reason: WIWOSM only renders elements containing Wikipedia tags, but not the waterway-relation. And neither the river line through Bodensee is shown nor the delta. Glad

Update: relations (waterways, collection, multipolygon) are supported now.
I add wikipedia tags both to waterway relation and to riverbank relation. In contrary to the advice from some mappers I omit tags on single elements. Glad 18:24, 29 May 2012 (BST)

Relations 3: waterway relations

Up to now (May 2012) the relations multipolygon, boundary und routes are supported. Difficulties encountered so far:

• relation Collection: OSM people don't like it. They argue the maintenance of it is too difficult. An example for Collection is abandonned railroad in Western Germany. route would not fit well because of the many interruptions.
  In Karte the line is shown not because collections are already rendered but because all its elements received appropriate wikitag.
• Rivers with relation multipolygon. Please have a look at Rhein river. Please open Karte and go the river-source in the south. The beginning is missing because only multipolygon + waterway=riverbank is displayed. The relation waterway is ignored. This is why no river line is shown in lake Bodensee as well.
• Bodensee: I have no idea how to show the whole lake. The lake is divided into several sub-lakes like Untersee. These sub-lakes are multipoligons. To represent the whole Bodensee a super-relation would be required, containing all sub-lakes.

Glad 21:28, 3 May 2012 (BST)

• remapped the Bodensee and the Untersee. Now all lakes are multipolygons. Lets hope that the remapping worked. --Werner2101 17:05, 15 May 2012 (BST)

The Rhein contains now also the river Saar, which is too much. We changed also the script to support superrelations so this can also be that reason. --Kolossos 09:47, 17 May 2012 (BST)

• unfortunatly the french mapppers have added the tributories to the waterway relations. Thus you don't get the river, but the whole river basin / watershed. see [2]. I've to discuss with the french mappers about that mapping scheme again. I've always voted against that mapping. see Talk:Relations/Proposed/Waterway#tributary_vs._tributary_of_relation_role. The Rhine has some tributaries in it's relation. --Werner2101 21:53, 19 May 2012 (BST)

Solved! I got a hint and copied the relation. Now we have a waterway relation tagged wikipedia=de:Flusssystem des Rheins and another one without further relations tagged wikipedia=de:Rhein. Glad 09:28, 23 May 2012 (BST)

• This is mapping for the renderers and will produce confusion in osm. We should try to find "the right" solution". Rendering whole watersheds will never be possible. e.g. the Mississipi River has about 70000 ways in the watershed. --Werner2101 18:04, 24 May 2012 (BST)

Right. Even Rhein is a good example: too many tributaries, impossible to maintain it manually.

How should I proceed with rivers: should I wait until the relation type = waterway is supported or add Wikipedia tags to all river elements? Glad 15:39, 12 May 2012 (BST)

For rivers we do this for years. So it schould be no problem. The type = waterway is now supported. --Kolossos 09:50, 17 May 2012 (BST)

Well done! Super relations as well. Glad

+1 -- this is exactly what I was looking for confirmation of. --Ceyockey 00:05, 24 December 2012 (UTC)

Relations 4: Train related relations

Just now I learned that Train-People in German Wikipedia don't like WIWOSM. Their argument: coordinate creates a point, and a railway is larger than that; the link to Karte/map should be added without a link to a point only.

I don't like to argue and accept the deletion of my coordinate-tags in eg de:Sülztalbahn by them. Glad 15:39, 12 May 2012 (BST)

Yes, I realized on my own that railway people at least in WP are kind of "special" with several reverts without comment not only on railways but also on hiking routes (one now refers again to a hardlinked, none-existent OSM relation).

Not only to pleasen this people (whats the sense of giving a coordinate for e.g. a country?) I'd like a template at WP like {{WIWOSM}}, which puts the map link with WIWOSM to the articles page. -- malenki 08:02, 28 May 2012 (BST)

Showing a coordinate at a country makes sense; it can be used to mark the capitol of the country. What do you mean by the template? It's already possible to show the map in the article - just place the {{coordinate}} in the article (eg http://de.wikipedia.org/wiki/Gaisbergbahn). But the feature not showing the marker for relations would be great... --Tunnelbauer 10:47, 29 May 2012 (BST)

See here: http://de.wikipedia.org/wiki/Diskussion:Sülztalbahn
There you find the map link only on discussion page... Glad 18:27, 29 May 2012 (BST)

Because the map link was reverted by user Gamba for the main article - this is no WIWOSM related thing - kolossos also talked to them on Portal:Bahn in this topic (no marker, just the relation - and maybe a little bit more tolerance... ;) ) --Tunnelbauer 10:35, 30 May 2012 (BST)

At Tunnnelbauer: Maybe I chose a bad example. So I choose some other like: what's the sense of adding one coordinate for a pilgrimage way, a railway, [...]?

Template: I am quite aware that there is a template which shows the map when one adds a coordinate (even if the coordinate is on the other side of the world). Since when there is a WIWOSM object for the article the map shows up for, the map gets auto-centered and -zoomed to that object - where is the sense in using a coordinate (especially when it is quite useless as the train people complain)? -- malenki 13:51, 3 June 2012 (BST)

If the coordinate-template isn't inserted into the main article there is no map shown - for example: http://de.wikipedia.org/wiki/Kasern_%28Salzburg%29 - no map; Kolossos-Server: http://toolserver.org/~kolossos/openlayers/kml-on-ol-json3.php?lang=de&title=Kasern_%28Salzburg%29 - WIWOSM-Object is existing. The only thing that should be fixed - but it's not a WIWOSM thing - is to not show the marker, everything else is already fine (so this discussion should be moved to the coordinate:template disussion page) --Tunnelbauer 20:21, 4 June 2012 (BST)

So guess why I proposed to create WIWOSM-only template which shows the map. GOTO 10 -- malenki 23:52, 8 June 2012 (BST)

selective traversal of nested relations

Complex relations are currently not displayed correctly. What different posibilities are there to prevent that?

In the first step there was no traversal of nested relations --> some members of super-relations are missing

In the next step WIWOSM fully traversed all childs of the relations. --> to much is shown of waterway relations.

Possible solution: Add extra rules when traversing the different relation types? For waterway relations you could exclude all members (ways and relations) with the relation role tributary before creating the WIWOSM representation.

--Werner2101 18:17, 24 May 2012 (BST)

This sounds to me more like a tagging problem. If I add a wikipedia-tag to a relation the meaning should be: All children belonging to that relation should be shown in the context of this article.
The specific problem for waterways should be solved in my opinion by having a relation containing only the main part of the river which can be tagged with the wikipedia-article and a superrelation containing that relation and all the tributary members.
I don't like to add to much content specific "extra rules" to wiwosm processing because it blows the whole thing up and is not so easy to maintain, especially if I am the only one who has to maintain these rules. --Master 12:27, 25 May 2012 (BST)

In my point of view the discussion about Tributary is solved: it is not possible to add and maintain all tributary-river-relations by hand. Werner has a solution in mind how to get the information about river systems by asking the database. Glad 12:37, 25 May 2012 (BST)

I second not to map all tributaries in relations. If one really needs to know them he just should query the data for all (water)ways connected with the waterway in question -- malenki 08:08, 28 May 2012 (BST)

I'm fine with that, too. Here is my listing of connected waterway relations: [3]. --Werner2101 08:35, 9 June 2012 (BST)

Relations and Superrelations

Example: Jakobsweg

The Jakobsweg is composed out ouf many routes. Example: [4]. Its name is "Jakobs-Pilgerweg Marburg-Köln" but its Wikipedia tag is "wikipedia=de:jakobsweg". We will fail to create an article in Wikipedia which points to this subroute only.

From a hierarchical point of view there should be subroutes which are collected in one super-route called "Jakobsweg". But there is no instance which maintains the super-relation.

A better approach is the idea suggested for waterways: including a tag like "destination_route=Jakobsweg". A script could collect all database entries including this tag and generate the whole Jakobsweg.

Glad 19:45, 27 May 2012 (BST)

A missing tag to a non-existing wikipedia article shouldn't hinder people to create such a one. When there will be a wikipedia article about "Jakobs-Pilgerweg Marburg-Köln" it can get tagged this way with the matching wikipedia tag. -- malenki 13:57, 3 June 2012 (BST)

Circuit de Montjuïc - Bug?

From the raceway Circuit de Montjuïc we have only the small roundabout in the WIWOSM-DB. The relation 1147249 seem ok and the last edit was 22th may. So I don't know the reason. --Kolossos 19:05, 5 June 2012 (BST)

This is not a bug in WIWOSM, but in tagging. The raceway was of type multipolygon, but without outer and inner role. So no polygon was build therefore. So I fixed the type of the relation to type=route because I think this was the intention of the mapper. --Master 23:12, 5 June 2012 (BST)

Partially not working on cs wiki

Following article does not show the relation in a map (you need to be logged in and turn on gadget called "Možnost zobrazení mapy z OpenStreetMap kliknutím na zeměpisné souřadnice.") - Adršpašsko-teplické skály even though the corresponding relation has "cs:" wikipedia tag: http://www.openstreetmap.org/browse/relation/2075806. Seems like "en:" wiki links work (see Česko and http://www.openstreetmap.org/browse/relation/51684). Please help! Thanks!

The reason is the temporary database problem on the toolserver. See the notice at the begin of WIWOSM-page. --Kolossos 23:03, 8 August 2012 (BST)

Data base problem

It's real pity that database is down.

I only write this remark in order to highlight that people like me miss the service heavily.

Glad 21:01, 13 August 2012 (BST)

Which object is chosen?

Sometimes, different osm objects can point to the same wikipedia article. I'm thinking about administrative boundaries on different admin levels, but with the same name. See f.e. 562654 562654 and 2375259 2375259. In those cases, what boundary will be shown on Wikipedia? I would think it's best to show the biggest boundary. --Sanderd17 09:20, 28 August 2012 (BST)

Both are shown. See wikipedia:de:Rheinland Raffinerie (two Areas, both tagged separately with no relation) and wikipedia:de:Aachen (relation + place Node) --Zuse 09:47, 30 August 2012 (BST)

With Chrome?

The example links do not work for me (Chrome on Windows). Regards, YannFo 11:12, 11 September 2012 (BST)

wikipedia:de:Aachen works with no problem here with chrome on windows (highlights the admin-Area and the center of the city). What is "do not work" for you? --Zuse 11:36, 11 September 2012 (BST)

Problems at the edge of the earth :-)

The map on wikipedia:de:Fidschi highlights the left or the right part of the island, depending which side is in the center of the map. No real problem, but amusing :-) --Zuse 10:12, 14 September 2012 (BST)

Yeah, it's funny that in modern Geo Information Systems the earth is a flat square instead of a globe. --Kolossos 20:25, 24 September 2012 (BST)

Dutch Wikipedia problems?

Some weeks ago, I could see all the boundaries I added on the Dutch Wikipedia. But now I only see a node anymore. The data is still present, and I can see the boundaries on other wikipedias, such as the German one. To see it, compare [5] with [6]. Could someone check what's wrong with it? I don't think it's a data problem, but it might be a template problem. --Sanderd17 14:26, 21 September 2012 (BST)

Repaired. Problem was parameter "pagename" instead of "title" inside the URL, I made a special exception for dutch wp but lost it at updating process. --Kolossos 20:15, 24 September 2012 (BST)

Thanks a lot --Sanderd17 07:49, 25 September 2012 (BST)

Problem with proper invalidation after data updates, or just >2 week lag?

Hello. Back in August/September I was completing Slovak railroad network top-level relation. That time, the corresponding WIWOSM entity was updating fairly frequently (~ once per 2 days). Then, there was longer outage, due to this announced maintenance works. In the meantime, I was continuing with relation/subrelations updates. These were reflected properly after outage, on the begining of October. But since that moment (2-3 wk. ago), no further updates to the relation seem to be appearing on the WIWOSM outline map.

Specifically, these sub-relations were added into network (and are not reflected yet by WIWOSM after 2 weeks):

• http://www.openstreetmap.org/browse/relation/2448612 (new)
• http://www.openstreetmap.org/browse/relation/2417421 (expanded, but reflected is just previous revision)
• http://www.openstreetmap.org/browse/relation/2320049 (expanded, but reflected is just previous revision) (sub-sub- relationship)

Any ideas, why? Thanks in advance. --Teslaton 23:07, 17 October 2012 (BST)

Teslaton,

You're not alone. I'm busy at making WIWOSM for many italian lakes and waterbodies, and noticed the same bad behaviour. Since I'm an OSM novice I thought it was my fault, but all I made up to 30 sept. is up and running, and what I did after that date is not. I suppose there is an outage problem on server, as you pointed out.

Hope it will be solved soon.

Best Regards, --ffla 11:13, 19 October 2012 (BST)

It seems that WIWOSM works again properly. Relation 2448612 works correctly.

You can check the date of the last update in the Error-log --Kolossos 19:58, 25 October 2012 (BST)

Thank you! Keep up this good work! --ffla 23:08, 25 October 2012 (BST)

WIWOSM objects not updated in Wikipedia maps

Dear Kolossos, dear master, the addition of WP-tags in the relations since approximately more than two weeks are not reflected in the Wikipedia-Maps anymore. Is there a technical problem, or is the updating switched off on purpose? When will the WIWOSM objects updated again? I know you work on this in your spare time (thank you for that!). Perhaps you could give a brief feedback, though, what is going on. Longbow4u 08:33, 21 October 2012 (BST)

Thank you for the update of the database. Longbow4u 18:51, 25 October 2012 (BST)

Please update WIWOSM database again

Dear Kolossos, dear master,
the additions of WP-tags in the relations since approximately six weeks (28/10/2012) are not yet reflected in the Wikipedia-Maps in OSM-Gadget. Since last time I have added a lot of county boundaries (England, Ireland complete). Could you please perform another update of the database? It would be ideal if the update could be made automatic again, even if only on a once a week basis. Beste Grüße, Longbow4u 18:06, 10 November 2012 (UTC)

Perhaps the update time on the page should be corrected? The last update is not hours ago but from 25th October. I'm also waiting for some updates - but if I know it will take a few more days or perhaps two weeks, it's ok for me. It only should be mentioned in the description of WIWOSMM. Greetings, -- Schusch 10:32, 12 November 2012 (UTC)

I added a note to the article, that the updating process only works every few weeks -- Schusch 09:00, 21 November 2012 (UTC)

WP-language "fiu-vro"

WIWOSM error-log has errors for "fiu-vro" which happens to be a valid WP-language by now although there is discussion to transition the language-code to an ISO one. Lets get rid of the error-log-entries. --jjaf.de 13:23, 1 January 2013 (UTC)

• Damn shit - thanks for reporting! Problem is that a hyphen in a language needs to be replaced by underscore to find the right database table. I fixed the bug and tonight it should work well. --Master 19:55, 5 January 2013 (UTC)

Error Log

For the meantime errors being displayed unsorted in the WIWOSM error-log i created a user-script WIWOSM-broken-log sortable working for Mozilla Firefox Add-On Greasemonkey which allows you to sort the table colums - especially 'language' - client-side. This also works for the fiu-vro-language-problem above. --jjaf.de 23:56, 4 January 2013 (UTC)

• Hey, cool idea. I included that sorting stuff directly in the broken.html file, so you don't need that Greasemonkey scripting anymore. Thank you. --Master 19:31, 5 January 2013 (UTC)

False Positives in error log?

Yesterday I spent hours to fix ~1000 WP-Tags only to see them show up as still erroneous today. Examples: [7], [8], screenshot. What is wrong with them? -- malenki 06:06, 11 February 2013 (UTC)
PS: In case someone needs to check: I (though I) fixed all WP tags of Alaska and Michigan. After updating the log they showed up with "language en" on them. And yes, I checked for every object if there is an article in WP -- malenki 06:35, 11 February 2013 (UTC)
Seems fixed now [9] -- malenki 06:08, 12 February 2013 (UTC)

OSM collection does not work

Is there something wrong with this collection: http://www.openstreetmap.org/browse/relation/2724073 ? WIWOSM in Wikipedia resists on showing a single point instead the relation. Glad (talk) 20:27, 31 January 2013 (UTC)

It was just a problem of the updating process. I think it is fixed now. --Master (talk) 23:32, 3 February 2013 (UTC)

Thanks! The service is quite new and I test the options it offers. Glad (talk) 18:16, 5 February 2013 (UTC)

Toolserver problems

Hello, on toolserver we loose our user-store, so WIWOSM is down. I hope we are soon back. --Kolossos (talk) 18:48, 11 February 2013 (UTC)

user-store is back! --Dschwen (talk) 16:09, 12 February 2013 (UTC)

Tiny Typo

For the edit link of the error log: It is Merkaartor, not Merkaator. . -- malenki 20:17, 17 February 2013 (UTC)

Thanks, fixed. --Master (talk) 12:47, 21 February 2013 (UTC)