User talk:RicoZ

From OpenStreetMap Wiki
Jump to: navigation, search

Reservoir tagging

Hi Rico, I just reverted one of your edits. I's a shame because I actually agree with migrating towards natural=water + water=reservoir. However, I think we have to go about this differently. Right now, the wiki definition does in no way suggest that the tag includes infrastructure, so there's no reason to be confused about anything, except perhaps the status of the deprecation. If you change the definition, then you also change the meaning of all the landuse=reservoir in the database, and therefore invalidate perfectly correct mapping. I'm open to strongly recommending that water=reservoir should be preferred, but please keep the definition intact. --Tordanik 15:16, 11 May 2014 (UTC)

Hm, I don't think that I have changed the definition - I wrote that there is a considerable confusion about the status of this feature. If you look at this http://lists.openstreetmap.org/pipermail/tagging/2013-June/013661.html discussion I think it is fair that there is no reason to doubt that the confusion could be hardly worse and it should be written to the wiki. Also note that the German wiki actually says that the use is deprecated, in addition the link to "Status" links nowhere.
Perhaps we could reinstate my edit as it was except for the first sentence? RicoZ (talk) 11:25, 13 May 2014 (UTC)
Your change to the first sentence is indeed my main complaint, so that would be a big step forward.
I would also like to see "... identical to the water body itself or whether it denotes a larger area/broader concept of an area used ..." replaced with "... whether it should be considered identical to the water body itself or whether it should be redefined to denote a larger area/broader concept of an area used ...", to further emphasize that the latter is not the current definition.
With these two changes, I would be happy with the remainder of your text. --Tordanik 15:40, 16 May 2014 (UTC)
After some thinking I left the "redefined to denote a larger area/broader concept of an area used" part completely away. Even if most people would like to have it, with so many uses of this tag it seems unrealistic that the tag could be redefined so for the other meaning a different tag/value will have to be invented. RicoZ (talk) 17:46, 16 May 2014 (UTC)

Deleting pages

Hi, when tags are still present in the database, it is better to say so on it's wiki page instead of nominating them for deletion. This way, people that stumble upon one of those tags will know what to do. Cheers, Jgpacker (talk) 11:55, 11 August 2014 (UTC)

The problem is https://github.com/joto/taginfo/issues/66 ... and some more. Our search function is not the best one in the world, wikicleanup has way to go, national wikis out of sync. I can understand the desire to keep the old information available but the cost of keeping obsolete misleading pages around is just too much in my opinion. I had not the slightest clue that bridge=swing is not a legal value before the recent ml discussion and I do use the search function as good as I can. Some of the pages were never legal key/value combinations, just informal proposals or not even that. Maybe move them to a special namespace deleted:wiki ? RicoZ (talk) 12:41, 11 August 2014 (UTC)
If the problem is taginfo, just add something like {{ValueDescription |key=bridge |value=swing |description=Deprecated. Use x=y + a=b instead |status=abandoned}} to those pages. The description will appear in taginfo. --Jgpacker (talk) 12:48, 11 August 2014 (UTC)
Have tried that now for bridge=bascule, the result is http://taginfo.openstreetmap.org/keys/?key=bridge#values - there is still this evil "✔" saying the combination has a valid wiki page. Many people after seeing that won't read the fine print on the wiki page. RicoZ (talk) 13:09, 11 August 2014 (UTC)
Now you have to wait until taginfo updates (the wiki info is cached), but you can see an example of what's going to look like here. --Jgpacker (talk) 13:15, 11 August 2014 (UTC)
It does not seem to help the original problem. bridge=bascule will still appear with a wikipage="✔" in http://taginfo.openstreetmap.org/keys/?key=bridge#values . It remains to be seen how many people will actually read the description.
On the other hand what is it good for? The wiki page has zero content apart of the k/v template for a combination which as far as I can see was never approved. I would argue it would be clearly better if it wasn't there because there are too many ways it will pollute the search results, taginfo and who knows what else. Of course it is the first result if you search "bascule" or "bridge bascule". In the second case bridge:movable does not even come up in the first page of results. RicoZ (talk) 13:51, 11 August 2014 (UTC)
You know, it is not only possible for users to create wiki pages for the tags they use, it's actually recommended on the wiki (it's also said they should be prepared for a possible future change of tagging).
It is useful to keep those pages in the wiki (as long as there are instances of those tags on OSM). If someone stumbles upon this tag, he can easily see on the wiki how he should treat this tag (as long as the wiki page is updated). --Jgpacker (talk) 14:33, 11 August 2014 (UTC)
PS: To clear up any confusion, I'm not saying we should keep obsolete information in the wiki. I'm saying we have to update those pages instead of removing them, because they can be useful. --Jgpacker (talk) 15:00, 11 August 2014 (UTC)
It is not really easy to navigate along dozens of abandoned proposals to find the one that is active... had that many times.
Trying to think of some other solutions. Could the pages be renamed in a way so that taginfo would not pick up the entries of obsolete pages? Prepending "abandoned:" or whatever would make it immediately clear in search results and prevent tools from picking up the wrong entry. RicoZ (talk) 16:55, 11 August 2014 (UTC)
You could add a redirect to these pages while keeping the templates KeyDescription or ValueDescription. Taginfo will still read them. See Key:admin_level and it's taginfo page as an example. --Jgpacker (talk) 17:16, 11 August 2014 (UTC)
PS: If you find proposals that are clearly abandoned or discontinued and not in use, you can try to use Template:Archived_proposal. Oh, and if you really think the icon "✔" on taginfo is a problem, then you should ask Joto to change it to another icon. That icon doesn't mean a thing except that there is a wiki page for that key or tag. --Jgpacker (talk) 17:22, 11 August 2014 (UTC)
Yes, I think the "✔" on taginfo is a problem and Joto did already reply on github saying that he would prefer not to add code to taginfo to special case wikipages that are abandoned or scheduled for deletion. Taginfo and the miserable search engine are the main problems and no solution that I can think off will solve those. RicoZ (talk) 20:47, 11 August 2014 (UTC)
I meant the icon ✔ shouldn't be used at all (in no case) if it somehows conveys the sense of "tag approoval" (because that's not what this icon means in taginfo). Also, adding a redirect to the page as I mentioned before does solve the issue with the search engine while keeping the tag description in taginfo, please try it. --Jgpacker (talk) 21:13, 11 August 2014 (UTC)

nudism=* onRelation

Hi, I saw you made a change in the Proposed features/Nudism indicating the key nudism=* could be used on relations. On which kind of relation can this key be used on? If possible, mention it on the proposal. If the only kind of relation nudism=* can be used on is a Multipolygon relation, then it shouldn't be indicated it can be used on relations, because this kind of relation is a special case which represents an Area. See The Future of Areas for more details. --Jgpacker (talk) 13:20, 31 August 2014 (UTC)

The motivation was that it was suggested to use it for resorts among others. I have minimal knowledge how to tag resorts but assumed that some of them may involve relations, not sure about that? Also, taginfo says it has been used on relations, will check what that is. BTW thanks for the areas link but all that I understood from it is that there is a problem and I knew that already. Do you have some favorite solution? RicoZ (talk) 14:55, 31 August 2014 (UTC)
Taginfo says it's used on relations because taginfo doesn't show areas at all, because areas don't really exist in OSM (as an object type). Multipolygon relations are complex areas and closed ways are simple areas. It is an unsolved problem the fact that the wiki differentiates between areas and the taginfo box doesn't (it is a common source of confusion), but I believe the idea is to actually create the area datatype in OSM to solve this. I just verified, and all relations tagged with nudism=* are multipolygons. As far as I know, resorts aren't tagged with a non-multipolygon relation, so we shouldn't classify the key nudism=* as allowed on relations. --Jgpacker (talk) 15:34, 31 August 2014 (UTC)
PS: If there is another kind of relation that can be tagged with the key nudism=*, then it's ok to say it can be used on relations, but I advise briefly mentioning this kind of combination somewhere on the wiki. --Jgpacker (talk) 15:37, 31 August 2014 (UTC)
Yes.. in Europe all the relations are actually multipolygons. Can't check wordlwide because apparently someone somewhere tagged a pretty big (tm) multipolygon (a whole continent?) with nudism so the naive query fails. RicoZ (talk) 16:00, 31 August 2014 (UTC)
Try this query: http://overpass-turbo.eu/s/4Oc . It queries the relations without their members. The relations can't be seen on the map because of that, but can be seen as raw data. --Jgpacker (talk) 16:08, 31 August 2014 (UTC)
That works. They are all multipolygons as expected. Wondering, can't see anything wrong looking eg at http://www.openstreetmap.org/relation/1240845 - is there any way to see which one is causing trouble? It seems that most don't cause any trouble. Or is it expected that any query involving a multipolygon touching a coastline will cause such problems? RicoZ (talk) 16:48, 31 August 2014 (UTC)
Not sure what's wrong, but the overpass query worked for me when looking for relation and it's members (everything loaded). --Jgpacker (talk) 17:19, 31 August 2014 (UTC)


Mass edits in UK

Please check with talk-gb before making widespread changes to tags in the United Kingdom. I believe this is what is required by the Mechanical Edits Policy. SK53 (talk) 15:52, 1 September 2014 (UTC)

I have not done any mechanical edits in the UK and I have consulted the authors of most of the special bridges by PM. RicoZ (talk) 20:45, 1 September 2014 (UTC)

Reverting of end_date

I reverted your end_date change, while I agree with you to some extent I'm not convinced you should just change it to "unapproved". Erik Johansson (talk) 14:59, 16 December 2014 (UTC)

Please see Proposed_features/Status and relevant discussions (also ml). end_date is not just "unapproved" - it will break stuff really badly. It should be considered rejected per same arguments as the previously mentioned feature.
There are many alternative proposals which do not break anything and work quite nicely in my opinion - see Comparison of life cycle concepts. I hope one of those can eventually make it but end_date=* is not realistic for the next few years. I have quickly reverted some of your change, please add information as you see it fit but for now end_date is in most cases unsuitable.RicoZ (talk) 21:32, 16 December 2014 (UTC)

Re: Lakewalker really dead?

You can download scanaerial from github: https://github.com/jonasstein/scanaerial --katpatuka (talk) 05:51, 26 January 2015 (UTC)

Thanks, I have downloaded it and hope to try it soon. RicoZ (talk) 12:16, 26 January 2015 (UTC)

aerialway=goods

Hi, you deprecated aerialway=goods. Was this discussed before? goods=yes does not really fit, since this is defined as a access restriction "(light commercial vehicles; e.g., goods vehicles with a maximum allowed mass of up to 3.5 tonnes)". Also there is no other aerialway=* type which would fit for the aerialway on the photo at aerialway=goods.--Klumbumbus (talk) 23:29, 17 February 2015 (UTC)

Ok, look like it was not such a bright idea to suggest goods=yes but perhaps foot=no should be good enough?. The photo at aerialway=goods did not match the description on its own page very well - if you think that something is need for such small open-gondola aerialways we can make up some.
The important point for me is to distinguish access (goods only) and type (gondola, carpet..) - many kinds or aerialways can be used to transport goods so it is not so good to have it restricted to aerialway=goods.
What you see on the photo and this is wastly different - and with current tagging would end up mapped as aerialway=goods. RicoZ (talk) 00:00, 18 February 2015 (UTC)
Better now? RicoZ (talk) 13:07, 18 February 2015 (UTC)
Yes, better, but still, I would not call it deprecated in the tables. Since aerialways for goods are only accessible for a handfull of persons, I think for 99,9% of mappers and data users it is completely adequate to tag an aerialway for goods only with aerialway=goods. They don't care how exactly the freight is attached to the aerialway. And they don't care if it looks this way or this way. I also see not that big difference between these both. I even can imagine that such an aerialway can be modifed, depending on the freight. If the freight is a big single block, it is directly attached and if the freight consists of several items, it is put into a basket, which is attached to the aerialway. Why do you think that "The photo at aerialway=goods did not match the description on its own page very well"? I think "A cable/wire supported lift for goods. Passenger transport is usually not allowed."perfectly fits to this photo. --Klumbumbus (talk) 18:17, 18 February 2015 (UTC)
I have started a mailing list discussion in the meantime, lets see if that brings some more insight. The exact type of a freight aerialway may not matter sometimes but because nearly every type of aerialways - from zp-lines over magic carpets, drag lifts and cable cars are used to transport freight (exclusively or mixed mode) I am still convinced it is better to have a way to tag this which is orthogonal to the construction. As far as I can see the access and usage tags are sufficiently descriptive for this purpose. Should we have something like an aerialway=unclassified in addition to that? RicoZ (talk) 16:49, 21 February 2015 (UTC)

Water level - Over,Under,In Between...

Bonjour RicoZ, I've just seen an comment you left on Talk:Tag:natural=bare rock, where you seems to be aware about discussions/problems on natural features rendering around coastlines. It is something (the problem) I'd like to understand since I had to model those things in the past (on a large topographic database). Are you aware about any discussion forum/list that deals with the topic where I might be able to help/understand? --jfd553 (talk) 15:24, 13 May 2015 (UTC)

Unfortunately the information is spread around very many places and there is no detailed agreement how it should be modeled. Mappers map it somehow and hope it works, the mapnik team tries to render it.
And we did not start coral reefs and underwater rendering yet..
Other renderers have different problems and frequently need some workarounds to make things work.
What exactly are you trying to do? RicoZ (talk) 21:38, 14 May 2015 (UTC)


Just trying to map areas having a complex mixture of surfaces (sand,mud,grass,...) within a tidal zone!

However, from the links you provided (thank) I understand that ...

  • It is sometime possible depending on the context! And I have just learn that from your links, even if I've looked at the wiki for years to find the proper way to map them.
  • Even if nobody is mapping for the rendering (!-) most cases discussed in the links results from different attempts to map features in intermittent water area, without an adequate guideline.

About these links, in one of them (#1547) imagico lists different options to get the mud rendered properly. My preference would be for (5), but whilst you wait for v3.0, I would leave it as it is today because of the richness of the render (i did not knew about yesterday!) , even if it causes a problem that seems to occur only at river-coastline interface. Furthermore, my preference does not concern only mud but all similar tags used by contributors (sand, pebbles,... even if one could argue they are not really features).

Concerning my preference for option (5), which is related to my experience in modeling topographic features, I would propose (if I may) to use the concept of intermittent water instead of the concept of tidal environment. Tidal refers to the cycle at which an area is covered by water (twice a day) while it is obvious from your links the problem appears in areas where the water cycle is different. For instance, it may affect rivers (flash flood, dried season, ...), lakes (dried season, dam controlled water level,...), all areas that are sometime covered with water because of daily, weekly, monthly, yearly processes - natural or not.

I think that if something can be settled and documented in the wiki - where casual mappers like me could find the information - it will really make mapper's life easier (and the map nicer)! --jfd553 (talk) 17:57, 15 May 2015 (UTC)

Comments regarding #1547 should be attached directly to the ticket.
The whole Key:landcover/natural/landuse modeling requires some good ideas, both land and water features and especially where several properties overlap. Right now we can document that waterway=* is rendered above eg natural=bare_rock and similar but the same does not work for coastline because of an (currently) unfixable mapnik problem. There is no agreement how to do underwater/tidal mapping. The way mapnik handles rendering is pushed to extreme sophistication and therefore fragile and hard to implement by mobile renderers.
I have attempted to gather existing proposals and ideas that are missing here: User:RicoZ#Geologgy.2C_Geopgraphic_landforms_and_vegetation_landcover. RicoZ (talk) 11:18, 16 May 2015 (UTC)

waterway=riverbank and natural=water

Hi, you have changed several pages to state that you can only use one or the other, but never both. This is in direct conflict to the proposal that introduced water=river as a replacement for waterway=riverbank in the first place, which recommends a co-existence until the migration is complete. So what is your reason for the change? --Tordanik 16:23, 1 June 2015 (UTC)

It took me a good hour to find out why some islets in the Isar weren't rendered and this was the solution: https://www.openstreetmap.org/changeset/20291626 . Maybe there were some other problems in the data but adding natural=water (https://www.openstreetmap.org/changeset/18999908) caused the breakage and removing natural=water fixed it. None of the QA tools was able to catch anything:((
So it is asking for trouble and does not solve any problem. The proposal is unnecessarily overcautious here. If someone wants to convert from riverbank to natural=water he can do it cleanly. There is no reason to leave the waterway=riverbank behind once the conversion is done because natural=water has been supported since many years and any data consumer not supporting it has much bigger problems.
I am wondering if the conversion will be ever done or is worth any effort. The old riverbanks method was not ideal but the improvement with the new method is so marginal - if any - and still leaves enough problems that I am not doing it, perhaps there will be some fresh ideas. RicoZ (talk) 21:21, 1 June 2015 (UTC)

class:bicycle:roadcycling

You seem to have created the page http://wiki.openstreetmap.org/w/index.php?title=Key:class:bicycle:roadcycling&action=history yet no-one has ever used it http://taginfo.openstreetmap.org/keys/?key=class%3Abicycle%3Amtb%3Aroadcycling . I'm confused - was there a reason for it? --SomeoneElse (talk) 07:35, 24 August 2015 (UTC)

I was editing the pages related to class:bicycle and may have created it as a redirect to documentation. Not sure why it display that nobody uses it, most likely some stupid typo of mine because this one gets http://taginfo.openstreetmap.org/keys/class%3Abicycle%3Aroadcycling at least some usage.
Got it now I think, key name in description box was wrong (extra ":mtb:").
I know it is questionable if such controversial low-use keys should be documented but given that some bicycle routers refuse to route over paths it might be good idea to add it to those to indicate if they are somehow suitable for this or that type of bicycle. Using "surface" or access might not be sufficient in all cases. RicoZ (talk) 09:48, 26 August 2015 (UTC)
Yes - not sure where the extra "mtb" came from. Do you know of anything that uses (e.g.) class:bicycle:roadcycling ? It's still worth adding of course if it's the best way of expressing the concept; something else can come along and use it later.
Do not know if any router uses it currently. Not sure if it is the best way to express anything either but can well imagine there are plenty of informations which are currently very hard to express in a better way. RicoZ (talk) 10:32, 26 August 2015 (UTC)

man_made=tunnel

Hi RicoZ, some time ago you mentioned that it would be helpful to create a tag that is similar to man_made=bridge. I've started writing a proposal, see Proposed features/man made=tunnel. Please review and comment! --Biff (talk) 19:42, 18 May 2016 (UTC)

JOSM-Validator

Hi RicoZ, zu https://wiki.openstreetmap.org/w/index.php?title=DE:JOSM/Guide&curid=9410&diff=1306650&oldid=1278589 : meiner Erfahrung nach werden aber nur die geänderten Objekte beim Hochladen automatisch validiert. Insofern zeigt es einem potenzielle Fehler, die man evtl (ja, nicht immer) selbst gemacht hat. Wenn man aber alle Daten direkt nach dem Download validiert, dann werden ja alle Objekte geprüft - nicht nur die, die man ändern wird. Vielleicht sollte man das noch etwas deutlicher schreiben? Siehst du das auch so? Ich halte ein validieren nach dem Herunterladen nicht für so sinnvoll (außer man mag auf Fehlersuche gehen) - kann man sich eh nicht merken, wo überall Probleme gemeldet werden. Viele Grüße --Aseerel4c26 (talk) 18:59, 31 May 2016 (UTC)

Da hast Du Recht, ich dachte JOSM tut immer alles checken, tut er nicht. Trotzdem habe ich sehr oft den Eindruck Fehler angezeigt zu bekommen die schon da waren ( https://josm.openstreetmap.de/ticket/12895 ). Also ich denke es würde einem Anfänger bestimmt nicht schaden den Validator vor dem editieren anzuschmeißen um einen Überblick über die Probleme zu bekommen die nur darauf warten den ahnungslosen Neuling zu erschlagen. RicoZ (talk) 20:44, 31 May 2016 (UTC)
Ja, ich denke, wie gesagt, auch, dass JOSM nur die geänderten Objekte beim Hochladen validiert. Das heißt eben, dass wenn man ein Objekt ändert, wo schon ein potenzieller Fehler drin war, er dann eben angezeigt wird – obwohl man ihn nicht selbst reingebaut hat. Man hat nur unglücklicherweise ein solches Objekt angefasst, wo schon ein potenzieller Fehler drin war. Wäre gut, wenn der Validator beim Hochladen automatisch noch einen zweiten Check machen würde: nämlich mit der Ursprungsversion des Objekts, um zu sehen, ob da der potenzielle Fehler auch schon drin war. Dann könnte er das als Hinweis neben der Fehlermeldung anzeigen. Ich hoffe, ich hab das jetzt aus dem Kopf richtig niedergeschrieben.
Ach, und jetzt, klickte ich auch deinen ticket-Link an. Siehst du wohl genauso. Mich als erfahrenen Benutzer von JOSM stört es einfach beim Hochladen oft, dass ich nicht weiß, ob ich etwas "verbockt" habe, oder es schon vorher so war. Beispielsweise irgendwelche Bus-Routen-Roles sind mir herzlich egal, wenn ich eigentlich gerade mit den Gedanken bei Fahrradrouten bin... vor allem, wenn ich den potenziellen Fehler eben nicht selbst verschuldet habe. So, genug für heute, vielleicht kommt mir die nächsten Tage noch eine tolle Idee...
Ich denke auch, dass der Validator sinnvoll auch für relativ neue Mapper sein kann, aber eher in einer eigenen Fehlerbehebungssitzung, als wenn man eigentlich beispielsweise einen neu erkundeten tracktype eintragen will. Das lenkt nur ab (und macht den Changeset-Inhalt vermischter / den Changeset-Kommentar unpassender). :-) --Aseerel4c26 (talk) 21:54, 31 May 2016 (UTC)
Man kann natürlich bevor man ein Objekt anfasst dieses Auswählen und durch den Validator schicken. Oder Alles in einer kleinen rechteckigen Area wo man gerade etwas editieren möchte. Oder alle Objekte von einem bestimmten Typ, user uvm. Vielleicht lohnt sich eine eigene Sektion in dem Guide über den Umgang mit dem Validator, den Fehlermeldungen usw.. zumal dieser imho momentan in fast allen Belangen sehr viel besser ist als keepright. Ich würde einen neuen User schon empfehlen zumindest einmal mit dem Validator "rumzuspielen" bevor er ans editieren geht, wobei ein neuer track da eine eine Ausnahme sein könnte weil man da so viel hoffentlich nicht falsch machen kann und dieser auch trotz vielfältiger Fehler noch nützlich sein kann. RicoZ (talk) 10:45, 1 June 2016 (UTC)
Habe eben angefangen diese Sektion zu schreiben.. dabei ist mir aufgefallen - wenn ich ein/mehrere Objekte auswähle und Validate mache werden anscheinend viele Checks nicht gemacht? Ich kann 2 Wege die sich "falsch" kreuzen auswählen und es wird nichts angezeigt? RicoZ (talk) 13:40, 5 June 2016 (UTC)
Habe das Problem gelöst und gleichzeitig ein neues: offenbar war mein Problem, daß ich durch die Rechteck-auswahl nur die Nodes ausgewählt habe, nicht aber die zugehörigen Wege. Jetzt eine ganz dumme Frage.. wie wählt ein vermeintlicher Anfänger alle Objekte in einem Rechteckigen Bereich aus? RicoZ (talk) 13:52, 5 June 2016 (UTC)

Re: ES:Cave - new proposal to map the interiors of caves

Done Mike95 (talk) 12:38, 26 September 2016 (UTC)

Thanks RicoZ (talk) 13:50, 2 October 2016 (UTC)

bridges vs. keepright

Hi Rico, ich kann verstehen, dass du eventuell etwas über keepright verärgert bist, aber bitte baue doch deine Kommentare in den zugehörigen Abschnitt (es geht ja nur um Brücken) in DE:Keep Right Users Guide ein. Auf Quality assurance habe ich es schon etwas angepasst. --Aseerel4c26 (talk) 09:55, 4 October 2016 (UTC)

Keepright ist auf gutem Wege aber das hier betrachte ich als einen wirklich wichtigen Bug in der grundlegenden Funktionalität und das sollte nicht in irgendeinem Abschnitt verschwinden den vielleicht jeder 20te Benutzer liest. Immerhin haben 25% der Brücken und viele Tunnels keinen expliziten layer und Keepright könnte für diese falsche oder stark irreführende Fehlermeldungen erzeugen. Die angezeigte Fehlermeldung sagt zunächst auch gar nichts über Tunnel/Brücken sondern allgemein so etwas wie crossing ways, so daß es mMn definitiv nicht in den Abschnitt über Brücken/Tunnel gehört. Ich kann im Moment leider nicht genau sagen wieviele tatsächlich diese Fehlermeldung erzeugen - passiert bei der glücklicherweise relativ seltenen Kombination bridge ohne layer crossing bridge mit layer=1 und enstprechend für Tunnel. RicoZ (talk) 10:34, 4 October 2016 (UTC)
Wenn die Kombination, wo es Probleme gibt, so selten ist, dann ist doch das Problem auch nicht so groß. Und außerdem gilt natürlich wie für alle angezeigten potenziellen Fehler, dass es eben nur "potenzielle" Fehler sind. Nunja, von mir aus soll's vorerst dort oben stehen bleiben, wenn es dir wirklich so wichtig ist. :-) --Aseerel4c26 (talk) 10:54, 4 October 2016 (UTC)
Es sind momentan so um die 580 Tsd Brücken ohne layer-tag da und einige Tunnel dazu. Wenn die seltene Kombination in 1% der Fälle auftritt kann es immer noch genug User irritieren. Kann sein, daß es viel seltener ist und ich bin einfach durch einen dummen Zufall nach fünf Minuten auf so einen Fall gestoßen aber ich hoffe es wird trotzdem nicht ewig bestehen. RicoZ (talk) 11:16, 4 October 2016 (UTC)