User talk:RicoZ

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.

• https://github.com/gravitystorm/openstreetmap-carto/issues/1473
• https://github.com/gravitystorm/openstreetmap-carto/issues/115
• https://github.com/gravitystorm/openstreetmap-carto/pull/1497
• https://github.com/gravitystorm/openstreetmap-carto/issues/387
• https://github.com/gravitystorm/openstreetmap-carto/issues/1547

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)

Comments on Hydropower waterways proposal

• I have comments but abstain from voting on this proposal. Abstaining for now but more inclined against, I think this needs more work. Trying to cover natural features in this proposal makes it too complicated, might be better if you would focus on manmade hydropower. Using waterway=pressurised with natural water flows is nonsense. Whether an underwater flow is pressurized depends on whether it is completely full of water and this is naturally changing. Sometime sections of it will be pressurized, sometimes nothing or all. Also the rationale for waterway=pressurised is very weak. Why should be waterway=pressurised mandatory for pipes? Some pipes may not be pressurized. RicoZ (talk) 13:43, 5 March 2018 (UTC)

Thank you for your comments. The proposal is actually focused on hydro power facilities, natural features are here as to show waterway=pressurised may be useful in other context.

You may think that waterway=pressurised in natural caves is nonsense because you associate container and content too much. In both natural and man made environments, when outlet is upper the intake (a siphon), the lowest point necessarily got a positive static pressure when flooded and stay pressurised even if water doesn't come upstream. If stream isn't always present, intermittent=yes do the trick. Keep in mind my goal is to separate content from their containers and the water will be in the same shape filling a pipe or filling a cave.

So what is pressurized? From a certain POV the water at the bottom of a lake is also pressurized but that is imho not a useful definition of pressurized.

For a counter example of a non-pressurized underground waterflow consider a gently sloped natural tunnel which is half-full with water along all of its length. Would you call that pressurized?

waterway=pressurized is suitable for closed space *pipe-flow* situations only. Pressure is uniformly applied on container (tunnel or pipe). Water mustn't share space with air, which exclude lakes and half-full of water caves. Fanfouer (talk) 23:01, 6 March 2018 (UTC)

I would agree with that definition but it can not apply to natural water flows. As the amount of water in natural flows fluctuates most of the underground waterflows would oscillate from waterway=pressurised to something else depending on how much water actually flows there. Also "pressurised" is a word which - as far as I know without exception - is used to describe exclusively technical/man made things. You can have a pressurized bottle but not a pressurised stomach. RicoZ (talk) 00:05, 7 March 2018 (UTC)

Can you provide examples of actual pipes (not tunnel) which are not pressurised in a hydro power plant please ? Tubing/piping is often required by pressurisation Fanfouer (talk) 00:40, 6 March 2018 (UTC)

The fact that pipe is often required for pressurization does not mean that it is the only reason to use pipes. Sometimes water may be piped to avoid pollution or evaporation. RicoZ (talk) 20:52, 6 March 2018 (UTC)

Agreed. This may need a minor adjustment. Main criteria for mappers is to look at pipe/tunnel intake: if air can get in (i.e intake is higher than fluid max level), you shouldn't use waterway=pressurised, no exceptions. Fanfouer (talk) 23:01, 6 March 2018 (UTC)

After more reading I think "pressurized" is not a good word in English, it has some very special meanings and in the context of pipelines it may be ambiguous. I know what you mean and I know some languages have special words for that (eg condotta forzata in Italian) and some don't explicitly name it or possibly have a different classification. In some languages/areas you have even a third variant - https://de.wikipedia.org/wiki/D%C3%BCker - I hope you can recognize what is meant in that article by looking at the pictures. A very special variant of it is the "Luftkissendüker" which I never heard about before.. here the horizontal pipe is partially filled with compressed air so that the water has less space to flow with the purpose to regulate the speed of the waterflow.

Thank you for this. Here are what I understand :

condotta forzata (it) = penstock (en) = conduite forcée (fr) which is a special case of pipe flowing situation. waterway=pressurised covers all pipe flowing cases, not only penstocks.

Ducker (de) = Culvert (en) = Ponceau (fr) which is not usually designed for pipe flowing. Some pics on the German wikipedia page for Düker look more like a siphon, which is actually proposed to be tagged with waterway=pressurised as no air is allowed inside.

You could tag it as culvert, but the special point about a Düker is that it has (static) pressure so the water will go up again after passing bellow an obstacle. In a common culvert the water flows more or less level with its natural course and there is no pressure. I am not trying to understand what siphon means in every language so trying to avoid the word here. RicoZ (talk) 19:31, 9 March 2018 (UTC)

More recently today we discussed about splitting tunnel=flooded in tunnel=culvert for open air channels and tunel=siphon on pipe flow channels. This could be a solution eventually. Fanfouer (talk) 21:37, 9 March 2018 (UTC)

Luftkissendüker got air inside as a regulation medium, acting like a diaphragm. Compressed air act like concrete and water applies the same pressure on it as the rest of the building. diameter=* would be variable in such a situation, but water always flows with no open air space. waterway=pressurised is suitable for this.

According to all of these items, waterway=pressurised = pipe flow. I couldn't use waterway=pipe since it's too close to man_made=pipeline (which is a container, not a content).

I see no better terminology I'm afraid, and it's semantically correct: all situations got water flowing at more than 0bar Fanfouer (talk) 21:21, 8 March 2018 (UTC)

Can you elaborate - still do not understand what is the problem with man_made=pipeline? RicoZ (talk) 19:31, 9 March 2018 (UTC)

man_made=pipeline is actually the container. We miss the content, substance=* is not an option. People looking for hydrographic data look for waterway=*. Force them to look at any place water can flow to find water is not very consistent and accessible. Fanfouer (talk) 21:37, 9 March 2018 (UTC)

They still need to look for pipeline&substance because your proposal does not catch non-pressurized pipelines. You solve just a tiny fraction of the problem in the best case. Also, it is not hard to look for pipeline & substance, developers who want seriously use OSM data need to do more difficult things. If your proposal is approved they will still have to look for pipeline&substance and also for the new combination waterway=pressurized. How does that improve anything???? RicoZ (talk) 12:20, 10 March 2018 (UTC)

Proposal mainly covers pipe-flow features, should I have added free flow pipelines with tunels. waterway=canal + man_made=pipeline if and only if intake is upper maximal water level is suitable to split content and containers. Fanfouer (talk) 13:15, 10 March 2018 (UTC)

Would work for this special case.RicoZ (talk) 14:30, 10 March 2018 (UTC)

There are at least 2 systems of classification that I could think of which complement each other: by pressure and whether the pressure is the natural static pressure or manmade pressure (eg pumping stations). For pressure I think there is already the attribute which could be further refined. Some attribute for the manmade pressure would be needed.. and of course both as temporary changing. In theory the values of both attributes could be mostly inferred from the topology, elevation and direction of transport but not reliably. Having two different attributes for this two things would also enable you to map the situation where a pipeline can be used both for power generation or pumping water back to an upper reservoir. RicoZ (talk) 19:58, 8 March 2018 (UTC)

This is more detailed than waterway=pressurised actually. It isn't intended to give information about the cause or the source of the pressure, only that there is static pressure and water isn't moving freely in a closed container which can be a pipe, a tunnel or a cave depending of other keys. If you want to distinguish what causes the pressure, tagging isn't closed and you may define other keys.

Pumping or not,you'll always get static 70bar at the bottom of a 700m high penstock, or building.

My proposal doesn't prevent us to give more details in other keys, but we have to take steps. I think we finally agree, but want to define things at different speed Fanfouer (talk) 21:21, 8 March 2018 (UTC)

In principle I agree, but there is no way to ever convince me to vote for waterway=pressurized :

• it must not be applied to natural water courses for the reasons explained above. It was one of the problems of some ancient waterfall and rapid proposals that the waterways changed their value to waterfall or rapids there - and those proposals were obsoleted probably for this reason. In OSM a river is a river even if it flows over a waterfall, or through a natural cave/tunnel - and suddenly it should change to waterway=pressurized just because the water level inside the natural tunnel raises enough that there is no air left? Nonsense
• the fact that there is a pressure is a technical property of the pipe(eline), not a property of the water. Hence it must not be a value of waterway but rather an attribute of the pipe(line). Also "pressurized" pipelines are prevalent for other substances than water, so tying it to waterway or making a special case here makes no sense
• waterways don't change value when they flow over aqueduct, in a tunnel or culvert - why should they in a pipe, and even worse only in some pipes and not others
• "pressurized" is very vague. An attribute key that can have a value (eg 30-90bar) is much better, and then there is no need for waterway=pressurized
• there are other technical attributes of the pipeline which are imho at least equally important as "pressurized". Making it a value of waterway makes it more important than the other technical parameters for no reason or gain.
• I seriously doubt whether water in a pipeline should have the waterway key at all but that is another discussion

RicoZ (talk) 19:31, 9 March 2018 (UTC)

Then, why do we need a waterway=* key if every time there is water, we can tag natural=water? Why do we distinguish streams and rivers if all can be rivers?

Also, get rid of natural=coastline, waterway=ditch and possibly some more values. Waterway=river,stream,canal should stay for now because natural=water requires an area drawn which is not always practicable. Having waterway=pipe (+ pressure=* where applicable) would be more acceptable for me than waterway=pressurized. RicoZ (talk) 12:20, 10 March 2018 (UTC)

Pressure is a water property: pipelines don't change their shape when water doesn't flow. As one of my goals is to make the important split between contents and containers, the pressure goes on the water and we need a waterway value for pipeflow channelized water. If I can't convince you to use waterway=pressurised I couldn't convince no one to use waterway=river on pipelines which is worse.

Well a freeway is still a freeway if it goes through a tunnel. The point for a new waterway value is very weak and especially against waterway=pressurized.

However, we could consider a waterway=artificial with suitable attributes which would encompass man_made canals (with near infinite transition period from waterway=canal), aqueducts and piped flows and whatever else mankind will invent. This would be useful because in many languages a canal can be both artificial or natural. Also it would improve on the mess of using natural=water for artificial waterways. In theory we could make it "perfect" and have waterway=natural with the attributes river or creek but I don't see it as priority and it would take too many years to adopt everything. RicoZ (talk) 12:20, 10 March 2018 (UTC)

This would be ok unless anyone comes and say there are about 4M objects to change and that's no. Even If I personally agree, this have great chances to not be accepted and proposal have to watch the amount of existing objects it impacts (and I don't like this). Fanfouer (talk) 13:15, 10 March 2018 (UTC)

I would try to go this way - with waterway=artificial. Nobody is forced to convert all waterway=canal instances, maybe the combination will get only adopted for things which don't match canal but that would not hurt either. One good rationale for waterway=artificial I see is that artificial waterways are currently split into numerous sections consisting of canals, aqueducts, tunnels and pipes. RicoZ (talk) 14:30, 10 March 2018 (UTC)

VF proposal

Hi, I wonder how long a RFC you are planning to have? Is a month enough? Would you like to coordinate the voting process so people can choose between the two proposals?--PangoSE (talk) 09:53, 4 September 2018 (UTC)

I do not plan any RFC or voting at this time.. see other talk page. RicoZ (talk) 09:55, 4 September 2018 (UTC)

The RFC is already started 2018-08-22 according to the page. Is this an error?--PangoSE (talk) 10:03, 4 September 2018 (UTC)

This was an error, thanks for spotting. There were several rounds of RFCs in the past but certainly none now. Actually don't see it now, maybe you had an earlier version in the browser cache? RicoZ (talk)

Page move Proposed features/Climbing

Hi RicoZ,

you recently moved this page which resulted in so-called "double redirects" (i.e. a redirect linking to a redirect). This does not work.

I am also a bit stunned regarding this move, because we usually keep the original proposals for documentation purposes. Why did you not archive them? The whole procedure is explained at Proposal process.

Currently, there are also links in the moved page pointing back to it like climbing:rock=* which points to the tag redirected to the proposal and again redirected to Climbing. I do not know if that happend during your edits, but as you seem to be focusing on this topic I would like to ask you to fix that as well.

Thank you. --Tigerfell  (Let's talk) 12:36, 13 September 2018 (UTC)

PS: You may find a list of those 'double redirects' at Special:DoubleRedirects. As far as I see, you created three of those. Tigerfell  (Let's talk) 12:38, 13 September 2018 (UTC)

Sorry for the mess, my wiki capabilities suffered after a longer vacation from the project. I think I have fixed the double redirects, is it still possible to archive the proposal even though I moved the page?RicoZ (talk) 09:22, 14 September 2018 (UTC)

I would say, I found a good solution, but have a look. I will continue with cleaning up Climbing and removing the voting content. --Tigerfell  (Let's talk) 08:43, 15 September 2018 (UTC)

Nonsense, why did you not simply integrate this content into Tag:sport=climbing? The current situation is simply duplication which has no use. --Tigerfell  (Let's talk) 08:49, 15 September 2018 (UTC)

sport=climbing should be about that particular tag so I am not sure it is a good idea to merge description of the climbing*=* tags into it. Perhaps there could be really short pages describing the main keys and one merged page describing all the details? RicoZ (talk) 08:57, 17 September 2018 (UTC)

Sorry, I got a bit confused. I now added a merge request on page Tag:sport=climbing. That basically follows your idea, but I would not create new pages named "Tag:Climbing:a=b" and content like "Tag Climbing:a=b is used to mark xyz (End of page)" because I think this is more useful if explained together. As far as I understand, a single climbing:orientation=N without sport=climbing would not be useful anyway. --Tigerfell  (Let's talk) 09:28, 18 September 2018 (UTC)

Ok, I did the English version. You can review it and move the other languages. --Tigerfell  (Let's talk) 19:20, 21 September 2018 (UTC)

Thanks for the work. The merge is not a trivial one, with very many details to look at. I considered it easier to start from climbing and add everything that was in sport=climbing, see also Talk:Climbing#Merge_with_.7B.7Btag.7Csport.7Cclimbing.7D.7D

One reason I wanted the "Tag:Climbing:a=b" pages was because I like the quick way to get at taginfo statistics and also taginfo gives the short description if the wikipage exists. Is there some template like "Feature" that would allow to specify multiple tag combinations and have the stats visible? RicoZ (talk) 11:01, 22 September 2018 (UTC)

To be honest I feel somewhat betrayed. First, I tried to clean up after your page move. Then, I hoped that you would do the merge (I probably should have said that more directly to you). Lastly, I did the merge, invested about 2 hours 30 minutes, and you undid it, because you thought it should have been done differently. I mean, obviously I have not sufficient knowledge of climbing. I could not do anything more than pasting it together and checking that the ordering was logic, but I invested a lot of work in the top part (what the page is about) and the section about applications, rendering, additional links and photos. You did not even see that apparently! Now, there are too many (partially duplicated) pictures with some German subtitles, spelling errors, some references to "this proposal" even though it is not a proposal any more and so on... --Tigerfell  (Let's talk) 18:13, 22 September 2018 (UTC)

Sorry, I was very rarely online in the last weeks to keep up with your pace and was too late there when the merge already happened.. I should have told you that 2 hours 30 is not enough for this. It was not my plan to do a quick merge but as it happened I want to clean it up. The top part of the page as it was before and after the merge was unwieldy and misleading wording ("The Infrastructure"). The page structure logic needed some larger changes because the page now covers two fairly different things - mapping climbing sites and mapping single climbing routes, plus a set of (largely) shared attributes to both of the approaches. My preference was to explain the two basic approaches somewhere on top and all the details like climbing style, grading, rock type should follow. Some features like crags and boulders are conceptually somewhere inbetween climbing sites and routes. Previously in the merged page the climbing routes were too far down, breaking the logic of the page and much of the information in the tables duplicated. Sure, I broke many things, 3-way merges aren't my strong point. I will try to fix the points which you mentioned. RicoZ (talk) 10:56, 23 September 2018 (UTC)

Had another look at it today and think it is about as good as I can make it. Let me know if you see some problems. RicoZ (talk) 18:42, 7 October 2018 (UTC)

Blow hole propsal revert

There's already a tag page for it that provides the necessary information. The proposal page doesn't have anything unique that it doesn't, or really anything for that matter.

Also, you can't just revert someone on a whim because you feel like it. There has to be a better, more valid reason. Along with a discussion and actual evidence. I'm fine with a page staying if it has unique content, but you have to support it with something more then "because there's some tags in the database." There's plenty of tags being used that don't deserve essentially blank pages about them. Its not a valid reason. I've already been through this before and disscussed it with admins who agree with me. There's also been plenty of other pages with more content that were deleted by said admins. So next time feel free to discuss it with me on my talk page or on the pages discussion page, instead of just reverting me. I'm pretty resonable and it helps things to not esculate uncessarily or lead to an edit war. Thanks.

Please use discussion pages for discussion. Now that you mention the existence of natural=blowhole it looks different. However I think the proposal should be simply archived as is. There is no reason to delete old proposals. RicoZ (talk) 19:27, 31 January 2019 (UTC)

Mapofix Kulturhauptstadt Kosmos Rendering Rules Revert

Is there a reason you couldn't have waited until the discussion on deletions was done and talked about it on the articles disccussion page in the mean time if you had a problem with it like Lyx said to do? Also, if you think it should have a {{Delete proposal}} do it your self instead of telling me what to do. I think it was fine how it was and you zero authority to tell other editors how they should do things. If you don't like something, its your thing to deal with. Not mine.

Folks, I moved this page to the User space, where it clearly belongs. Mmd (talk) 08:40, 5 February 2019 (UTC)

Thanks, I vaguely remmeber there were more pages with similar names which should be probably handled in a similar way? RicoZ (talk) 20:05, 5 February 2019 (UTC)

@Adamant1:: Yes, there is a reason. If a page is tagged with "delete" it could be removed in any instant without further notice - irreversibly. The discussion will be probably ongoing for a few more weeks and I am not taking the risk that the page disappears before it was discussed. Please use signatures on talk pages. Also moderate your style, it is no joy to deal with you. RicoZ (talk) 20:05, 5 February 2019 (UTC)

"Also moderate your style, it is no joy to deal with you" – you're asking for it, buddy. Get ready for one adamant sea of fire (pun 100% intended :P). — EzekielT (talk) 05:09, 6 February 2019 (UTC)

I hope your username is not your program and wondering why you would explain me the meaning of adamants username? RicoZ (talk) 22:20, 10 February 2019 (UTC)

What do you mean by “I hope your username is not your program”? And I wasn’t explaining anything, it was just a joke. — EzekielT (talk) 00:44, 11 February 2019 (UTC)

I was just (in a humorous way) warning you about saying something like that to Adamant1. Since I was expecting Adamant1 to get furious over what you said. Fights can happen by saying such negative things about people, even if they are true... — EzekielT (talk) 00:49, 11 February 2019 (UTC)

EzekielT, don't expect people around here to have a sense of humor or more often then not you'll be let down. I thought it was funny though. I do get long winded sometimes. Often times its a combination of to much coffee and writing messages in between working on unnecessarily long winded college papers. People on here can be pretty unnecessarily negative also. Which tends to set me off more then it probably should. I'm an internal optimist though. Maybe its my American, western grit.

RicoZ, as far as my user name goes, its a double (or really triple) entendre. In case you were wondering. Btw, no one on here is pleasant to deal with. Its not just me. You aren't either. It goes with the turf though. Everyone is understandably really passionate about this. As they should be. I wouldn't want it any other way. With great things comes great responsibility and all that. So don't think i'm ignorant to what rests on our shoulders here or don't care. We just have a difference of opinion and that's OK. Your not my enemy. Even if I am a little patronizing and hard to deal with sometimes. I deal with a lot of uncalled for and completely unnecessary bad attitudes from people on here though. Which puts me on the defensive more then it should. Plus, unfortunately this has been a two year thing that you jumped into at the last minute. So my testiness about it at this point is to be expected. It's really not personal. Except in the case of your search engine comment ;) P.S. sorry about the signature thing. I was replying on mobile and it didn't have the signature button for some reason. --Adamant1 (talk) 11:50, 15 February 2019 (UTC)

@Adamant1: It is not that I jumped into this, one of your less lucky edits alerted me. Of course after checking I see that others have complained long ago. RicoZ (talk) 21:35, 18 February 2019 (UTC)

Deletion policy

Dear RicoZ,

We would like to invite you to voting in the case of the proposed Deletion policy for wiki pages and files. Based on the input of several contributors, we drafted a deletion policy over the span of two and a half months. Among other things, the policy proposes a centralised discussion page for all cases which are not mentioned explicitly.

Kind regards, EzekielT

PS: I wrote this message on your talk page, because you were involved in a long dispute about deleting in 2018 and 2019 which now led to this policy draft. — EzekielT (talk) 18:05, 16 April 2019 (UTC)

How to map waterway=riverbed

Hi Rico.

You asked me to rework the wording for the How to Map section of the riverbed proposal. This is what I've come up with so far. If it's still not clear, please get back to me. We can work on other details together.

Draw the waterway=riverbed as an area (or polygon) that covers the complete extent of the riverbed using waterway=river for the actual river. If there are vegetation patches or areas having a different surface within the riverbed that need special descriptive tagging similar to an island inside a riverbank, then you will need to create a multipolygon. Areas of natural=wood, or landcover=grass, for example, are "islands" in the riverbed and would become the inners of the multipolygon. In addition, if the river is wide enough to require waterway=riverbank to describe it, draw it "on top" of the riverbed as another area-polygon.

In complex cases both riverbed and riverbank will require polygon-areas within them, islands of natural=wood or natural=sand, for example. In such cases two multipolygons will be required. Conceptually, the riverbed multipolygon would be below the riverbank multipolygon because the riverbed always covers the full extent of the river but at present there is no provision to use layer tags to indicate this. Note that in certain situations a wooded island might be part of either the riverbed or the riverbank multipolygon but not both.

Long riverbeds may be broken into smaller sections and joined in the same manner as riverbanks. When connecting two such multipolygons please use the proper technique where they join, i.e., use a shared outer way for the junction rather than simply sharing nodes.

AlaskaDave (talk) 00:15, 13 July 2020 (UTC)

Thanks for the text.. makes the problem much clearer to me.

• "If there are vegetation patches or areas having a different surface within the riverbed that need special descriptive tagging similar to an island inside a riverbank, then you will need to create a multipolygon" - this is almost the opposite of what was intended:
  • instead : "If there are vegetation patches or areas having a different surface within the riverbed that need special descriptive tagging just draw them as polygon on top of the riverbed area and tag with natural, landcover or similar.
  • multipolygon - inner in riverbed areas should be used only for areas that are never flooded, such as very high rocks or islands within the riverbed

RicoZ (talk) 20:49, 15 July 2020 (UTC)

Different types of "crater"

Hi, you were involved in the September 2015 discussion regarding natural=volcano. Any thoughts about a namespace harmonization ? Rtfm (talk) 13:49, 11 January 2023 (UTC)