User talk:Tordanik

Completed discussion topics can be found in the archive.

current status of 3dmr

You were mentioned concerning the 3dmr. What is the current status of the project? It is not very intuitive. Is it correct, that there are only a few 3d models? --MeastroGlanz (talk) 15:49, 5 May 2019 (UTC)

That's correct, yes. The website is up and running, and there is application support in OSM go as well as the upcoming OSM2World/WebGL client. But very few models have been uploaded so far. There are plans to grow the numbers through imports (we have secured permission to import the data from the defunct OpenBuildingModels project, and there are quite a few models under compatible licenses available on other model-sharing platforms), but whether the project can still become a success depends on people's willingness to create models for it. For now, I'm hoping to keep it alive and use the completion of either the OBM import or the WebGL client as an opportunity for a bit of a marketing push. I continue to believe that such a platform is a good idea. --Tordanik 16:20, 5 May 2019 (UTC)

Thanks so far. How is the licensing model? It would be also interesting how to handle things like 3D-models which are based on OSM-Data (raw shape derived from OSM-data and refined for example). I would be interested in contributing, but I don't know how to use blender (though I have installed it). What is missing imho is an agenda (like focus on sightseeings). It is also not intuitive, how to participate in the project, contribute and use the data. Maybe there are points, which I can do. Another point is, that there should be included some GIT-like fork system (Building A is based on B is based on C, on D; E on C on D). I'm good in creating svg-graphics. Is there any use for this? --MeastroGlanz (talk) 17:59, 5 May 2019 (UTC)

The creator of a model can choose between CC0 (which makes them essentially public domain, with no restrictions on use), or CC-BY (which requires that 3DMR is named as the source when the model is used elsewhere). Models derived from OSM data that you didn't map yourself are ... potentially complicated. I'm honestly unsure whether they would be considered "produced works" per the ODbL, or whether this small amount of data is insubstantial.

You don't necessarily need to know Blender to create models, as other (simpler) modellers can also be used if you prefer. The models on 3DMR are stored in the OBJ format, which almost everything can produce. I agree that the documentation could be better, is 3D Model Repository#Adding a model helpful?

Oh, and SVG skills could be very useful for texturing 3D scenes! For example, the net and the pitch markings here (similar image in case the link doesn't work) were created as SVGs. In many cases, such features don't even need a 3DMR model because the geometry is really simple: Just a "wall" with some partially-transparent image placed on it. There are quite a few features that could be displayed in 3d that way – fences, common road surfaces (e.g. paving stone patterns), more sports markings, and so on. If you're interested, I'd be happy about some good-looking textures! --Tordanik 17:36, 6 May 2019 (UTC)

Mixed Material for poor housing

You just deleted makeshift from the building:material page, which I think is correct. I dont think for houses [ https://commons.wikimedia.org/wiki/File:Woman_In_Door_Of_Makeshift_House.jpg like these] we should list all actual materials but we do need a word/tag for it.

Can I propose 'patchwork' (or mishmash, mixture, hodgpodge)? --Batje 16:00, 22 November 2015 (UTC)

It would at least be a better term, but one problem remains: The building:material tag was introduced for the purpose of 3D rendering, so there should be enough information to render the house. In this case, there are a roof and two of the visible walls made from corrugated sheet metal, and one wall made from textile material. That information is taggable and actually conveys meaningful information. --Tordanik 16:45, 22 November 2015 (UTC)

This house in its current form of course has a very specific material. Due to the nature of the house and the environment they house might change when the rains come or a bit of money is made. We could almost go for the option 'random'. Really mapping these houses as-they-are today is (still) possible, but does not reflect the changing nature they have. Without this tag, the only option would be to really map every side of the house (or part of the side of the house) differently, and then go back every month to look for changes. On another level, while it is great that 3D renderers use this tag, ultimately OSM is trying to describe the world as it is. And this house (and the samples below) are called (in East-Africa) 'makeshift'. For generalisation purposes I think we will start tagging with 'patchwork' for now on Zanzibar, and adept if/when this discussion goes a different route.

Sample 1 Sample 2 Sample 3 --Batje 23:27, 22 November 2015 (UTC)

I fully understand that you don't want to map the actual building materials used, given their temporary nature. But isn't building:material simply the wrong key when you're not mapping materials? Perhaps using something like building=makeshift_house or simply makeshift=yes would cover the information you want to express just as well or even better? --Tordanik 11:18, 23 November 2015 (UTC)

I think you have rightfully pointed at the fact that the structure is temporary and we need to find a way to tag that fact. We'll discuss that internally. However, we do like to tag the :material though, and I still thing that would be valuable for the 3D engines. They could for example decide to render buildings semi-randomly or with a mix of plastic, wooden boards and iron sheets (Which would be the most common materials used in the mix.) --Batje 18:04, 25 November 2015 (UTC)

Well, I don't fully understand your preference for adding a generic makeshift :material, but of course there is some potential for 3D rendering here – no matter whether the information is found in building:material or some other tag. Just keep in mind that your new :material value will be lost if anyone decides to add details about the actual materials currently used in the building. So be prepared for that. --Tordanik 17:18, 25 November 2015 (UTC)

Need help against unapproved changes on highway key

Hi Tordanik,

I know you oppose tags with subjective values. Please help me to avoid the recent changes by Dieterdreist on the description on the highway tag. (change from physical to importance) http://wiki.openstreetmap.org/index.php?title=Key:highway&action=history

Thanks. --Lulu-Ann 12:40, 12 August 2009 (UTC)

Hello Lulu-Ann,

it should be noted that

• the change was in fact discussed on the talk mailing list
• other pages (e.g. DE:Key:highway) have been using importance before
• the original text wasn't introduced by proposal either, but simply an attempt to describe practical usage
• there were no objective definitions for the highway values before the edit, either - this would have required an indication of the relevant physical characteristics

So: Yes, I want roads to be described by well-defined tags. However, the highway key wasn't objective before the edit and never was used as reliably I wish it was, so diederdreist's edit unfortunately does describe tagging reality correctly.

I therefore won't personally intervene here. If you want support by others, you should post your objections on the mailing list where this whole thing started. However, I think that a real solution would only be possible with add-on tags for highways each stating exactly one type of property, thus making the highway values less relevant. Highway itself never was clearly defined and it most probably will never be. --Tordanik 11:44, 13 August 2009 (UTC)

Sorry, I have a full time job, I simply can not read talk and talk-de. If there never was a proposal about highway, then we should start one, to have the arguments in the wiki. *sigh* --Lulu-Ann 12:13, 13 August 2009 (UTC)

Softwareübersicht

Hallo,

ich habe gerade die Mac-Software "myTracks" in deine Tabelle eingefügt und dabei in Unkenntnis einen Zeilenvorschub vermasselt. Ich habs leider nicht mehr hingekriegt, bitte bau den Umbruch zwischen My Tracks und myTracks wieder ein.

Danke & Grüße ... Gerd

Hallo Gerd, hab ich gleich behoben. Aber gerade weil die Tabellen so umständlich von Hand zu bearbeiten sind, ist eigentlich eh nicht vorgesehen, dass man dort Einträge direkt vornimmt - deine Änderung wird daher das nächste Mal, wenn mein Bot vorbeikommt, automatisch überschrieben. Bau doch besser die Vorlage Template:Software2 in die Seite deiner Software ein, dann wird der Eintrag in allen automatisch generierten Tabellen im Wiki in regelmäßigen Zeitabständen eingefügt und aktualisiert. Du kannst auch einfach den Codeabschnitt, der mit "{{Software2" beginnt, von der Seite einer anderen Software kopieren und mit passenden Werten ausfüllen. --Tordanik 12:46, 17 October 2010 (BST)

Comparison of editors ‎ (updated auto-generated tables)

http://wiki.openstreetmap.org/w/index.php?title=Comparison_of_editors&diff=prev&oldid=624719

JOSM is present in the table twice. --Dnikitin 17:45, 20 April 2011 (BST)

That's because there are two instances of Template:Software2 for JOSM: The one on JOSM, and another one on Zh-hans:JOSM. --Tordanik 18:06, 20 April 2011 (BST)

Wikipedia-Tag

Der revert ärgert mich. Dazu gibt es auch gerad eine Disk. auf talk-de [1]. Können wir da was machen, um auf einen einheitlichen Stand zu kommen? --Kolossos 22:18, 21 March 2012 (UTC)

Hat sich inzwischen ja zum Glück erledigt. Ich verfolge die Diskussion aber auch, das Thema interessiert mich schon eine Weile. --Tordanik 21:23, 22 March 2012 (UTC)

Tag:railway=platform

Thanks for your effort. It is sometimes difficult to argue with close-minded people. --Pieren 08:57, 8 May 2012 (BST)

Änderung von 'footway=' zu 'sidewalk='

Hallo Tordanik. Spricht etwas dagegen in der OSM-Datenbank bei den Highways den Zusatztag 'footway=' durch 'sidewalk=' zu ersetzen? Ich bin dafür, um den Datenbestand etwas zu vereinheitlichen. Riskiere ich da Ärger von der Mapper-Community? --Rudolf 14:45, 20 July 2012 (BST)

Hallo Rudolf! Zu diesem Thema solltest du, wenn du die Seiten noch nicht kennst, als erstes Automated Edits code of conduct und Mechanical Edit Policy lesen. Da steht drin, wie man Ärger vermeidet. ;)

Gegen die Vereinheitlichung an sich spricht aus meiner Sicht nichts. Ich vermute allerdings, dass es manchen zu früh sein wird, weil das ganze Thema Gehsteigmapping ja noch sehr im Fluss ist - mit mindestens drei in Frage kommenden Varianten (sidewalk-Tags am Highway, separate Ways oder Spurlisten) und keinem eindeutigen Bild bei der auswertenden Software. Das kannst du aber natürlich herausfinden, indem du das Thema zunächst einmal auf einer Mailingliste oder im Forum zur Sprache bringst. --Tordanik 05:41, 21 July 2012 (BST)

Vielen Dank für die zwei Links. Die kannte ich noch nicht. Ich werde meinen Vorschlag wohl zunächst im Forum zur Diskussion stellen. --Rudolf 12:03, 21 July 2012 (BST)

Danke für deinen Beitrag im Forum. Vielleicht könntest du mal einen Blick auf DE_talk:Key:footway werfen. Ich überlege, ob ich nochmal einen Vorschlag wagen soll. Aber bevor ich wieder Prügel beziehe, hätte ich gerne deine Meinung gehört. --Rudolf 07:17, 24 August 2012 (BST)

Hallo, du weißt ja, dass ich dein Vorhaben inhaltlich unterstütze. Die Form der Dokumentation, die du auf DE_talk:Key:footway entworfen hast, finde ich auch sauber und gut begründet.

Die Diskussion könnte trotzdem recht hart werden. Zumindest einen Teil der Forendiskussion scheinst du ja schon mitbekommen zu haben: Es gab erst einige Beiträge in "Kleine Fragen" ab hier, danach wurde das in einem eigenen Thread weiterdiskutiert [2]. Vielleicht wäre es gut, dich zumindest im Forum (auf der ML war es glaube ich noch kein Thema) bei der Vorstellung deines neuen Vorhabens auch dafür zu entschuldigen, dass es beim letzten Mal viele nicht mitbekommen hatten.

Eine Frage, mit der ich in dieser oder ähnlicher Form rechne, ist "was bringt es, ein weltweit verwendetes Tag nur in Deutschland zu vereinheitlichen". Dafür gibt es natürlich gute Gründe (gerade vor dem Hintergrund der fehlgeschlagenen Kommunikation beim letzten Mal wäre einer davon, dass es bei Beschränkung auf ein Land viel leichter ist, die Betroffenen mit den vorherigen Ankündigungen zu erreichen), aber eine Antwort darauf solltest du parat haben.

Also, ich denke es könnte klappen, aber sicher ist es nicht und du solltest dir im Klaren sein, dass es mit etwas Pech durchaus auch wieder mit zumindest verbalen "Prügeln" enden kann. --Tordanik 14:41, 24 August 2012 (BST)

Delete of Sidewalk

Hallo Tordanik. Könntest du mal einen Blick auf Sidewalk werfen? M.E. kann diese Seite gelöscht werden, da sidewalk=* alle notwendigen Informationen enthält. Ich bin leider nicht mit allen Wikikonzepten vertraut. Liege ich hier mit meiner Meinung völlig daneben? --Rudolf 13:29, 6 August 2012 (BST)

Ist wohl eine Ansichtssache: Man kann die Position vertreten, dass Inhalte, die mehrere der Tagging-Varianten betreffen, auf eine gemeinsame Überblicksseite ausgelagert werden sollten - dann würde man Sidewalk behalten und z.B. die Vor- und Nachteile der verschiedenen Methoden dort statt auf Key:sidewalk beschreiben. Man kann das aber natürlich auch in gesonderten Abschnitten auf Key:sidewalk, Tag:footway=sidewalk und ggf. weiteren Tag-Seiten unterbringen. Bin mir selber nicht ganz sicher, was ich besser finde. Möglich ist beides, aber man sollte sich halt für eine Option entscheiden, denn momentan ist die Sidewalk-Seite wirklich inhaltlich redundant. --Tordanik 15:58, 6 August 2012 (BST)

relation type=bridge

Funktioniert diese relation schon? (wenn ja -> bitte Beispiel) Ich krieg das nicht hin.--LordOfMapping 15:08, 9 August 2012 (BST)

Wenn du mit "funktioniert" meinst, dass man sie dann auch in den gängigen Karten erkennt: Geht leider noch nicht. Ich kenne keinen Renderer, der heute schon Brückenrelationen beherrscht. --Tordanik 15:23, 9 August 2012 (BST)

Schade! Wäre sehr nützlich.--LordOfMapping 16:28, 9 August 2012 (BST)

Translations

Hello, as you're part of the Wiki team you should be interested: I think that translation on this wiki would use some improvement and I've proposed a new system at Talk:Wiki Translation#Translate extension. I hope you can provide some feedback and thoughts (and help if we decide to go that way). Thanks, Nemo 10:38, 16 August 2012 (BST)

Waterway=riverbank

Hi, I see you reverted my edit. I'm just trying to clarify the page. Before you blatantly revert my change, you could also give me a sign. Anyway, if you look in the default (old) multipolygon case, the text says that ways 1 to 6 are tagged as waterway=riverbank. So it was already used on ways, a long time before the new style.

Now, I only saw you reverted my edit because I wanted to revert it myself (I'm not happy with the ambiguity). So I'm gonna mention natural=riverbank in the main article now. I hope you're ok with that? --Sanderd17 19:50, 13 September 2012 (BST)

Isn't it pretty normal in wikis that you are allowed to do any edit without asking first - precisely because if anyone objects, they can easily revert it and you start discussing with them? I feel that neither your edit nor my revert thereof were blatant, but maybe we have different expectations how wiki editing works. If it came across as an act of aggression, I apologize.

You are also right that the documentation suggests redundant tagging on both the relation and the outer ways. I actually didn't notice that before, and don't think it makes sense, but yes, that's what the text says for some reason. I'd prefer to figure out why that's the case and maybe update that section of the documentation though.

I don't see any problem with you mentioning and linking to a proposed natural=riverbank tag, as long as its status as a proposal, rather than established tag, is clear. --Tordanik 20:39, 13 September 2012 (BST)

Escape lane

Because I have seen most opposed voters for the proposed highway=escape were against the same type=* tag, I have decided to change it. This mistake is now corrected. Maybe now you are interested in changing your vote ;) --Schumi4ever 14:34, 5 November 2012 (UTC)

Done. --Tordanik 20:42, 5 November 2012 (UTC)

Archived proposal

Hi,

You use Template:Archived proposal. But when you delete content of the proposal, a Mediawiki search can't find this former proposal (i think). --Manu1400 (talk) 23:10, 4 May 2013 (UTC)

If you know what you are looking for, then searches like "proposed features wilderness hut" still deliver the expected result. It's true that you cannot do a full text search for content replaced with the template. However, that full text search will usually turn up the key/tag page for the proposed feature (as these will have nearly identical content), and that should ideally have a link to the proposal in the "See also" section for those who are interested in that. A big benefit is that the proposal, which is only of interest for "historical" purposes at that point, will not be mistaken for current documentation by potentially inexperienced users - and users' complaints about the large number of wiki pages with similar-but-not-identical content (and remains of proposals are one, even though not the only, cause of that) were actually a major reason for creating the template. Do you have use cases in mind where a full text search in archived proposals is necessary? --Tordanik 01:21, 5 May 2013 (UTC)

I don't think if i have a use case. But if i want to create a new proposal, i need to find ALL proposals (depreciated proposals, ...). --Manu1400 (talk) 16:47, 5 May 2013 (UTC)

Aren't links are better suited for that task than a full text search? Even deprecated tagging schemes can usually be found though links because they are (I assume) mentioned in the proposals that replaced them. Still, I admit that the ability to do a full text search is lost because of the archive, and even though I think that the benefits outweigh this drawback, there may occasionally be situations where the search would be helpful. Do you think we should stop the roll-out of the template and look for some other solution? --Tordanik 22:08, 6 May 2013 (UTC)

Accessibility Tabelle

Hi,

hier gibt's ne Tabelle, kannst Du mir vielleicht helfen, die zu automatisieren?

https://wiki.openstreetmap.org/wiki/Android#Accessibilty

Hast Du schon eine 3D-Datei für mich?

LG Lulu-Ann

Hi, ich schau's mir mal an. Die 3D-Datei ist noch nicht fertig, hab die Tage einige wichtige Termine und generell leider auch viel zu tun. --Tordanik 09:31, 25 September 2013 (UTC)

please archive measurement_station/ monitoring_station

Hi Tordanik,

since you seem to know how to archive proposals (and I don't) it would be nice if you could put these two to rest:
Proposed_features/measurement_station
Proposed_features/monitoring_station

Thanks in advance
-- malenki 18:43, 14 November 2013 (UTC)

Done. But there are a few tags in the approved proposal that haven't made their way to man_made=monitoring_station yet, such as monitoring:water_level and a few others. Since you appear to be familiar with the subject matter, please work these into the tag documentation as appropriate. --Tordanik 10:42, 15 November 2013 (UTC)

Thanks for archiving.

For the tags: could you maybe have a second look and tell what exactly is missing? -- malenki 13:58, 15 November 2013 (UTC)

Translation of main wiki menu?

Hi,

thanks for this: Syntax for internal category link on mu User page, didn't know that. However I hope this was just a cosmetic (not really important) change, no?

Do you know how to do this [3]? Chrabros (talk) 04:05, 22 February 2014 (UTC)

Hi Chrabros, the link change was just a minor improvement. If you don't like it, you can revert it and I will not be interested in starting a big discussion about it. ;) One small, but tangible advantage would be if the Special Pages of MediaWiki such as "what links here", "orphaned pages" etc, did only work with internal links. I was under the impression that this was the case, but I'm not sure whether that's (still?) true.

As for your translation question, there is a MediaWiki documentation page on how this usually works: [4]. But unfortunately I have no idea about the procedure in our OSM wiki. So I hope that you get a response to your track item. If you don't, try Talk:Wiki. --Tordanik 15:39, 22 February 2014 (UTC)

Thanks for both Tordanik. Chrabros (talk) 03:26, 23 February 2014 (UTC)

building:levels

Hi Tordanik, just a suggestion, and I am not sure if it is really a good practice, but maybe when you change the page considerably, as you did with building:levels=*, then it might be a good idea to add Template:Translation out of sync to the each of translated pages where you can see reference to the tags you have removed from the main English page. This way someone has a better chance to spot the change and adapt his/hers translation accordingly. Chrabros (talk) 05:43, 24 March 2014 (UTC)

Hi Chabros, that's actually a reasonable idea and I could imagine myself doing this in the future. Meanwhile, I'm still hoping for that MediaWiki extension that would do this automatically... --Tordanik 13:05, 24 March 2014 (UTC)

reorganisation of this wiki's navigation

Hi Tordanik, I just wanted to inform you that I want to restart the discussion to get a decision. Thank's for your feedback so far! Here's an overview again:

Hello, I write to you because you are part of the Wiki Team. I would like to establish a navigation concept for this wiki, lead by use cases. I wrote an example main page and an example navigation page (for the use case 'contribute map data'). In January, I wrote a correspendent proposal on Talk:Wiki_organisation, with some but not much feedback. I would be happy if you could add your feedback in order to decide either to refuse the proposal or to proceed. In the latter case I will incorporate all feedback, write the two missing navigation pages ('about' and 'use') and finally I would like to change the main page. Best wishes, --Cantho (talk) 07:26, 8 April 2014 (UTC)

Now I proposed to apply the proposed changes to the main page. Your feedback/ vote is welcome. If you want to respond but don't have the time right now, please give a notice about when you think you can respond. Have a nice day --Cantho (talk) 10:17, 23 May 2014 (UTC)

Deprecated features?

May you have a look at Talk:Deprecated features? --Rudolf (talk) 05:25, 26 May 2014 (UTC)

Pl:Tag:bicycle=use_sidepath

@ Tordanik,

in that article some aspects had been forgotten. I've been able to add them in the English and German versions, gut I'm unable to add them in Polish.--Ulamm (talk) 13:43, 28 September 2014 (UTC)

So am I, as I don't speak Polish. --Tordanik 15:20, 28 September 2014 (UTC)

Verstecken von Radwegen als highway=path

Hallo Tordanik,

du bist ja ein sehr langjähriger Mapper und hast auch an der Diskussion zur Einführung von highway=path teilgenommen.

Darum belästige ich dich jetzt mit folgendem Probelem:

• User talk:U715371#Du weichst aus.
• Bremen/Veranstaltungen#Themenspeicher
• User talk:Bremen/Lokalitäten des Bremer Verkehrsnetzes#Zerstörungswut

Gruß, Ulamm (talk) 18:05, 29 September 2014 (UTC)

Hat sich erledigt: Auf einmal erkennen die Renderer auch path/bicycle=yes.--Ulamm (talk) 17:19, 30 September 2014 (UTC)

Relation:street

@ Tordanik, bist du nicht als alter OSM-Hase prädestiniert, das Tag in den Voting-Prozess zu bringen, mit Schwergewicht nicht auf Adressen, sondern zur Zusammenfassung getrennt gezeichneter Verkehrsflächen ?!--Ulamm (talk) 11:45, 3 October 2014 (UTC)

Die Relation ist in letzter Zeit leider auch im Zusammenhang mit dem Getrenntmapping von Fuß- und Radwegen trotz fehlender physischer Trennung ins Gespräch geraten. Da 3D-Rendering einer der Anwendungsfälle ist, der besonders unter dieser Form des Mappings leidet, bin ich zumindest von dieser Art, die street-Relation zu nutzen, kein großer Fan. --Tordanik 23:29, 3 October 2014 (UTC)

Im Vorschlagstext steht doch vorne an die Verwendung für Straßen mit mehreren Wegelinien – wie Richtungsfahrbahnen, Straßenbahnen, Radwege, seltener (aber gerade an prominenten Stellen, z. B. Prager Altstadt) auch Gehwegen.

 

Bei der derzeitigen Leistung gängiger Renderer

• bewirkt die Notierung von Fuß- und vor Allem Radwegen mittels eigener Linien
  • als einzige eine brauchbare Darstellung großer und komplizierter Straßenknoten
  • als einzige die Darstellung der vorgeschriebenen Fahrtrichtung.
    • Bekanntlich dürfen (unter anderm aber nicht nur) in Deutschland Radwege nur dann in beiden Richtungen befahren werden, wenn dies durch entsprechende Beschilderung ausdrücklich erlaubt ist. Ebenso sollte bekannt sein, dass das Unfallrisiko beim Fahren auf einem Radweg links der Fahrbahn ein Vielfaches höher ist als auf der Fahrbahn oder einem rechten Radweg.
    • Darum ist jede Notierung und Darstellung von Radwegen ohne deren vorgeschriebene Fahrtrichtung bei großen Maßstäben ("Stadtplan") unzureichend.
• werden mittels Fahrbahnzusatztags dargestellte Radwege
  • von mehreren gängigen Renderern gar nicht dargestellt (Mapnik, OSM-de, HikeBikeMap)
  • von OSM-CycleMap nur dargestellt, wenn sie nach Idiotenmethode als cycleway=track (offiziell für RW beidseits vorgesehen, tatsächlich auch nicht selten für einseitige RW verwendet) notiert sind, undzwar mit Strichen beiderseits auch an Richtungsfahrbahnen (Idiotenrendering, die meisten gedruckten Fahrradstadtpläne sind da besser).
  • jede differenziertere Darstellung wie cycleway=:right, cycleway=:left und cycleway=:both, für die Routenwahl innerorts dringend erforderlich, wird derzeit von keinem gängigen Renderer erkannt.
    • Laut Legende soll VeloMap sie darstellen, aber mit einem Missverständnis: cycleway:left=track als Gegenverkehrsradweg (Stand August 2014, ich habe daraufhin ausführlich mit Felix Stratmann telefoniert).
  • Mit den beim Fahrbahntagging zur näheren Beschreibung erforderlichen Schachteltags tun sich Renderer insgesamt schwer. Wie Routingprogramme sie verstehen, weiß ich nicht.
  • An großen und komplizierten Knoten können Routingprogramme bei Notierung von RW mit Fahrbahnzusatztags keine Hilfe leisten.

 

• Rendering ist eine genauso wichtige Auswertung des OSM Datensatzes wie Routing.
  • Es ist auch zur Wahrung der eigenen Autonomie jedes Nutzers wichtig. Wer sich ohne Kartenstudium auf Navis verlässt, macht sich zu deren Sklaven.
• Das Verdikt von "Mapping for the renderer" bezieht sich auf die falsche Deklaration von Objekten mit dem Ziel, entgegen der vorgesehenen Funktion eines Renderers ihre Darstellung zu erzwingen oder zu verhindern.
  • Demgegenüber ist es nicht nur das Recht sondern geradezu die Pflicht jedes Mappers, darauf zu achten, dass von ihm notierte Objekte und Eigenschaften von Renderern, die für deren Darstellung vorgesehen sind, auch erkannt werden.--Ulamm (talk) 01:57, 4 October 2014 (UTC)

Nachtrag zum Thema 3D-Rendering:

• 3D-Rendering ist eine nette Sache und ich habe auch schon Einträge für die 3D-Darstellung eines Gebäudes gemacht.
• Trotzdem ist es verglichen mit 2D-Darstellung von Verkehrsnetz und Topografie eine Spielerei.
• Wenn es gelingt, Relationen für differenzierte Gebäudedarstellungen ("type=building"), differenzierte Darstellung von Straßen ("type=street") und Plätzen, die diffenzierte Darstellung anderer Objekte, sowie die Vereinfachung der Adressennotierung ("Type=associatedStreet") sauber auseinander zu halten, dürfte die Gebäudedarstellung nicht leiden.--Ulamm (talk) 02:18, 4 October 2014 (UTC)

Auch Berührungspunkte wie ein Gebäude mit Kolonnaden in einer als Fläche gezeichneten Fußgängerzone mit Straßenbahn sollten für die programmierfreudigen 3D-Fans eher ein Zuckerl sein.--Ulamm (talk) 02:46, 4 October 2014 (UTC)

maxspeed JOSM

Hallo, bzgl. diese Änderung. Kannst du bitte sagen, was genau bei JOSM nicht der Dokumentation entspricht? --Klumbumbus (talk) 21:04, 25 January 2015 (UTC)

Na ja, Verkehrsschilder für Höchstgeschwindigkeit mappt man mit traffic_sign=maxspeed + maxspeed=*, nicht nur mit maxspeed=*. Reines maxspeed wird eigentlich nur an Ways und Areas verwendet. Der JOSM-Validator warnt daher auch vor maxspeed an Nodes. Aber andererseits "belohnt" JOSM maxspeed an Nodes mit der (wirklich sehr hübschen) Optik. --Tordanik 16:32, 26 January 2015 (UTC)

Habe ein Ticket erstellt. --Klumbumbus (talk) 22:01, 26 January 2015 (UTC)

Link to tag/key page was invisible/unclickable on purpose

from Template:Proposal Page:

| {{#switch: {{Proposal_Status|{{{status}}}}} | Approved={{tag|{{{key|}}}||{{{value|*}}}}} | Post vote={{tag|{{{key|}}}||{{{value|*}}}}} | {{{keys|{{{key|<key>}}}{{=}}{{{value|<value>}}} }}} }}

key-value combination will be visible only if community will approve feature (status=approved/postvote), it was done on purpose on the template. Text key=value is not clickable untill everyone agrees with proposal.

There is no need in Template:No vote feature link.

See also Category:Proposed features. Xxzme (talk) 12:56, 23 April 2015 (UTC)

It is a generally accepted fact, though, that proposal votes are not the only path towards an established tag. Sometimes a proposal author will not open a vote, but simply wait for the community to adopt that tag on their own. The template is intended for such situations where there *is* a Key/Tag page that reflects a wide use among mappers. In those cases it does make sense to alert a visitor of the proposal that the Key/Tag page exists. --Tordanik 13:12, 23 April 2015 (UTC)

Then we can fix Template:Proposal Page. Well personally I don't want to maintain multiple templates. I'm fine whatever link present or not at proposal pages. We can modify Template:Proposal_Page. Right now it will display tag similar to Template:Tag. See:

Proposed_features/animal=horse_walker

Proposed features/PipelineExtension

Xxzme (talk) 15:29, 23 April 2015 (UTC)

What do you mean with "fix"? To me, adding a clickable link to Template:Proposal Page would not automatically make Template:No vote feature link obsolete, as the latter is designed to be immediately obvious. It is a direct counterpart to the (more frequently used) Template:Approved feature link which serves a similar purpose. --Tordanik 16:02, 23 April 2015 (UTC)

"immediately obvious", well if there were no "Voting" the proposal page, then you just follow links specified in Template:Proposal Page. Previous Template:Proposal Page was limiting proposal to single tag. In practice this is somewhat wrong, we have quite complex proposals. Proposed_features/PipelineExtension - there too many tags to specify both in Template:Proposal Page or to spam Template:Approved feature link. Do you agree with that?

Also, new Template:Proposal Page is color-coded by its status (it will be red in Category:Proposals with "Rejected" status). And Template:Approved feature link is actually misleading when it refers to never-actually-formally-voted-proposal as "Approved". Xxzme (talk) 17:38, 23 April 2015 (UTC)

Well, I created the new template specifically because Template:Approved feature link is not appropriate for never-actually-formally-voted-proposals, so I don't understand your criticism here. The links in the proposal infobox are not in-your-face enough to serve the purpose imo. --Tordanik 09:16, 28 April 2015 (UTC)

Well my idea: if it is done by using templates, then templates use each other as parameters. Nothing special here, I just want to minimize unnecessary work for creating and maintaining proposals.

I found example from pre-Proposal Page era: Approved_features/Tag:historic=memorial. Here is multiple issues at this page [5]:

1. ValueDescription used at proposal page (I should be moved to actual key/tag page at main namespace)
2. status is not specified and thus it is not clear what you are looking at (Template:Description now will be dark green background if "approved", definitely visible IMO)
3. No clear info about voting dates and status
4. No link to other proposals (text link or category)

For me: 1. it makes no sense to add Template:Proposal Page for features approved before Proposal process. 2. BUT: we can add link to old-style proposal using |status= and |statuslink= (even to voting at talk pages!) using real tag/key description pages 3. we should remove Template:Description and variants from old-styled proposals to avoid confusion 4. we shouldn't use Template:Proposal Page and Template:Approved_feature_link together for proposals after proposal process was established

>The links in the proposal infobox are not in-your-face enough to serve the purpose imo we can solve this by changing alpha colour of "tagging" section in Template:Proposal Page. Should it be brighter or darker than template? Xxzme (talk) 16:18, 28 April 2015 (UTC)

Your revert on stats page

http://wiki.openstreetmap.org/w/index.php?title=Stats&diff=1177339&oldid=1177138

The history is not so big (and my comment and the talk page already showed that the two pages were merged), and that page was ALREADY "moved" this way in the past. I just restored its older name because - it is unabbreviated, because "stats" means two distinct things in English! "statistics" or the plural of "status") - it matches the category name - the older name "statistics" has MORE pages referencing it since very long (the other pages referencing "stats" are just unmaintained translations or talk pages)

The bad renaming was made by overwriting the content of "statistics" with a redirect to "stats" without prior discussion. I have just reversed it because it was not made in the correct direction.

Note: I cannot just rename the page because they have distinct histories since 2007 too (there's no simple way to swap pages without using a deletion first.

— Verdy_p ^(talk) 08:50, 13 May 2015 (UTC)

Hello Verdy_p, thanks for starting this discussion. I hope that we can find a consensus on this matter.

While it's true that the move in the past wasn't clean either, that was in 2007(!), so the time to use that as a justification to reverse the move is long gone imo. Note that the Stats page has multiple pages of history, while Statistics has only 2 edits before being turned into a redirect. So the page has spent almost all of its history as "Stats", and I cannot really see how it could be called "not so big".

I also want to maintain that there are probably lots of external links to the Stats page. (With external, I don't mean the ones you can find with the "Links to this page" feature, but links from other websites, scientific papers and so on.) Sure, you are right that they were not "broken", but I never claimed that. Sending external visitors to a redirect is not a deal breaker, but avoiding it is nicer where possible. To me, that would have a higher priority than matching the category name, which I consider pretty unnecessary. I also believe that external links are more relevant than links from inside the wiki, as we can change the latter much more easily.

I'm surprised to hear that "stats" is ambiguous, by the way. My dictionary only mentions it as a shorter version of "statistics", but my English skills are limited, so I believe you. I also agree that "Statistics" is a better name, and if I were creating the page today, I would likely call it "Statistics". However, it's not that much better in my opinion. --Tordanik 12:05, 13 May 2015 (UTC)

Well, noboday is then opposed to what I attempted to do. The fact remains that both pages have existed and have an histpry, and that the simple overwriting of one by a redirect has already been used (but in the wrong page in my opinion), or that it was not properly renamed.

The other fact was that both pagenames had references to them, sometimes via double redirects and I just wanted to cleanup all this.

"stats" is not a correct word in English and given the page has to be the main page associated to its category (correctly named "Statistics") it just remains an informal word.

In my opinion the 2007 page named "Statistics should have been renamed, but it was kept (with its history, even if it was only redirecting to "Stats" (all other contents blanked).

The 2007 page is now in "Statistics/old" instead of "Statistics". The current "Statistics" page only contains redirects created only by me and nothing else (and I absolutely don't care if it gets deleted with the history about me, as it has no value. I will be happy when the current dummy "Statistics" will be effectively deleted so that "Stats" (the page and its talk page and all its history) can be renamed to it.

It is also a fact that "Statistics" had collected many more links to it than "Stats" (we can ignore links on old unmaintained translations, and the links used in various user talk pages).

What I just wanted to solve is to reduce the maintenance by merging all incoming links so that they will use only one name, not too, and if possible the best one "Statistics", without any redirect.

For now there is no more any broken links, even if there are lots working via *simple* redirect (there's no more any double redirect).

And I have still not seen any discussion about the arbitrary choice in 2007 of the worst name instead of doing the actual cleanup.

Also I don't know if keeping "Statistics/old" (the 2007 version of "Statistics" that was blanked by overwriting a redirect on it) gives really any benefit, I don't care if it is deleted as well.

I would prefer the current "Stats" to become the redirected alias to "Statistics, but visibly it was refused nit because it was not the best name, but only for preserving a direct access to its edit history without looking to the history of its aliased page. If "Statistics" is deleted, and "Stats" immediately renamed to restore the name it had before 2007, I will applaude. Separate decisions have to be made if we need to keep the redirected alias from Stats to Statistics, or if we need to keep also the current "Statistics/old" of 2007 !

However I was concerned by the way you reverted my change: you just blanked it and reverted "Stats" to its old version that did not contain any one of my recent fixes and work (this was a pure blanking decision that also wanted to ignore the history of my own work to fix this page (which is also not very critical on this wiki for the OSM service, given that it just brings to other servers for getting updated statistics or more detailed results).

I did not want to start an edit war, but I thought that you had not understood my reasons, and that's why I contacted you. Thanks for your patience. — Verdy_p ^(talk) 12:52, 13 May 2015 (UTC)

NB: you think that "Statistics" is not much better because it could be used for describing usage unrelated to the OSM database itself. For example there's an evident need of cartographic data for representing statistical data on a map or on derived maps, or to use OSM data to perform searches, compute some statistical measurements on the represented geographic features themselves.

For such as case, the current page should have been "OSM service statistics" (not limited to database statistics, but also to registered users, participants to its documentation such as this wiki, or to experimentation with developping softwares using OSM data and reporting results, or about financial reports of the Foundation, or statistics on raised fundings, or statistics on its usage in third party systems, or about awareness to the project collected from various sources (including press articles and TV/radio reports, or use in artistics creations or in administrations, or statistics about legal issues where the OSM project was involved and some external decisions were made where OSM was cited even indirectly)... — Verdy_p ^(talk) 13:00, 13 May 2015 (UTC)

Löschung eines Abschnitts von DE_talk:How_to_map

Den folgenden Abschnitt habe ich gelöscht, weil er Benutzersupport war https://wiki.openstreetmap.org/w/index.php?title=DE_talk:How_to_map_a&diff=1178376:

Off-Topic: identifiable users without user-page ?

From time to time I found in version pages or talk pages links to non-existing userpages. I assumed that those users had been part of the OSM-WIKI-community and left it and hat their user-page deleted. Now I find more and more those non-existing userpages. Here I found the latest one - maybe someone can tell me how someone can contribute with identification without being identifiable (without user-page)? Some examples:

• Walterschloegl in here on the main page on 17:36, 24. Nov. 2012: DE:How_to_map_a (History)
• Viking81 14:20, 16 September 2012 (BST) in Talk:Proposed features/Stable

(In such cases it is not possible to get into contact with the contributors if necessary.)

--Rennhenn 09:48, 25 November 2012 (UTC)

As soon as you register a wiki account, you can edit the wiki and edits will be associated with that account. But a user page only exists if the user chooses to manually create it (which is optional). So these users probably just didn't see a reason to create a user page for themselves.

There are several options to contact users who don't have a user page:

• E-Mail, if they have set an address for that purpose in their user preferences (see the entry "Tools"/"Werkzeuge" in the navigation column on the left when you are on the nonexistent user page)
• The talk page associated with the user page (you can add a comment to a talk page even if the main page does not exist, as far as I know). The user will be notified about your comment when they log in for the next time.
• If all else fails, you can check whether an OSM user with the same name exists. Mappers will often use the same name in both OSM and the OSM wiki.

--Tordanik 19:07, 25 November 2012 (UTC)

Thanks - I could use the first advice already twice (and successfully). --Rennhenn (talk) 07:04, 23 June 2013 (UTC)

Straßen als Flächenbegrenzung (landuse=* als Multipolygon)

Zu deiner Zusammenfassung zu diesem Edit: Wo kann ich diese Kontroversen mal nachlesen? Ich mappe noch nicht lang mit und lerne daher immer gern was dazu, halte aber Multipolygone bislang für die eleganteste Methode, landuse=* zu definieren, da fast immer physische Linien (Wege, Zäune, Wasserläufe) vorliegen, die sich als Element nutzen lassen. So, wie es hier auch empfohlen wird. Bislang hab ich nur einen Nachteil dieser Praxis erkannt: Wege müssen dafür immer dann geteilt werden, wenn rechts oder links der Wert von landuse=* wechselt, was dazu führt, daß Relationen von Fernwanderwegen, in denen diese Wege enthalten sind, mit der Zeit sehr viele Elemente bekommen. --Kreuzschnabel (talk) 16:21, 1 July 2015 (UTC)

Uff, das wird öfters im deutschen Forum diskutiert. Die Haupteinwände gegen das das "Ankleben" von Flächen an Straßen über gemeinsame Knoten oder MP sind die (subjektiv) schlechtere Wartbarkeit und die Tatsache, dass viele Flächen in der Realität nicht bis zur Straßenmitte (Flussmitte etc.) gehen. Hier einer der vielen Threads zu dem Thema: http://forum.openstreetmap.org/viewtopic.php?id=22554 --Tordanik 16:50, 1 July 2015 (UTC)

Danke, das hilft weiter, meine Methoden zu überdenken :-) Mein bisheriger Standpunkt folgt vor allem dem Argument der Abstrahierung im Eingangsposting: Wenn in der Realität der Acker bis an den Wegrand reicht, soll er das auch in der Karte tun, also bis an den Way, der nach meinem Verständnis nicht nur die Mittellinie der Straße darstellt, sondern auch deren Ränder, die Straße ist auf Breite Null reduziert. Die im Renderer dargestellte Straßenbreite entspricht ja sowieso nicht der Realität, sondern ist nur Symbol. Das erreiche ich entweder über viele shared nodes über den Wegverlauf oder darüber, daß ich den Weg als outer ins Multipolygon nehme. Aber das (ja auch von mir schon erkannte) Problem der Zersplitterung von Wegen ist tatsächlich eines. Wenn ein tracktype=grade2 asphaltiert wird und dann erst mal 23 Streckenabschnitte auf grade1 geändert werden müssen … gut, in JOSM läßt sich das leicht selektieren, aber wir müssen ja auch an iD-Nutzer denken :-) ich werde mich mit Multipolygonen in Kuhzunft mal etwas zurückhalten. Aber wenn jemand einen 100 Meter langen Waldrand mit 80 Nodes gezeichnet hat, also fast jedes Blatt einzeln, dann werde ich mir weiterhin erlauben, diesen Weg als outer für meine angrenzende Wiese mitzunutzen, statt ihn nachzumalen. --Kreuzschnabel (talk) 18:36, 1 July 2015 (UTC)

Merge of Names#Notes and Editing_Standards_and_Conventions#Street_Names

this revert wasn't so useful Content is still overlapping, we have to write dedicated page "Naming conventions" and transclude it as many times as we want.

I suggest to use following points from Names#Notes:

• Names#Abbreviation_.28don.27t_do_it.29
• Names#Name_is_the_name_only
• Names#No_name

Other topics should be left at Names as "more detailed description" of Names and mentioned from Editing_Standards_and_Conventions only as link.

I.e. Editing_Standards_and_Conventions should contain:

• transcluded points Naming conventions
• link to full page about "Names"

What do you think about it? Any suggestions? Xxzme (talk) 11:43, 3 September 2015 (UTC)

ATM you can observe current version of Naming conventions in 2 places: Editing_Standards_and_Conventions#Street_Names_and_naming_conventions and Good_practice#Naming_conventions

Third page will be Names (transcluded again or just linked). Xxzme (talk) 14:04, 3 September 2015 (UTC)

Proposal Link in See Also

Hello Tordanik, you restored the proposal link in See also on man_made=bridge. I thought I gave reason why I removed it, but I didn't - sorry. Here it is: The proposal is already linked in the statuslink of the infobox. No need to duplicate the information - especially if only the link is duplicated without more information. I also edited Proposal Process to use statuslink instead of See also.--Jojo4u (talk) 14:29, 26 October 2015 (UTC)

Thanks for the explanation, I understand your reason now. I'm still not sure if I agree, though. The link in "See also" has been a standard for years, whereas the infobox entry is a relatively new idea. Was abandoning the practice of the "See also" proposal link discussed anywhere? One concern I have is that the link in the infobox is only represented as a very generic icon, so unless you already know where it is, it's hard to find. --Tordanik 14:57, 26 October 2015 (UTC)

I'm not aware of any disussion. After some thought I say: If there is more than one proposal put the main proposal from the statuslink also in "See also", so man_made=bridge is good now. I'm thinking about designing an example page with section headings and some guidlines (e.g. here Wiki_guidelines), this is currently missing in the wiki.--Jojo4u (talk) 18:19, 30 October 2015 (UTC)

Example in website=*

I think a correct example for the website=* tag is necessary, as the "raw" URL format, while necessary, can be too abstract for not-so-technical users.

You're right that website=https://www.openstreetmap.org should not be tagged on any object on the map, but it is a neutral website which is known by all wiki readers and get the point across. Could you put back this example or propose a better one please ?

By the way, I like how you turned the pitfalls section into a more positive "best practice" section :) --Gileri (talk) 20:48, 17 December 2015 (UTC)

Hi! I've restored the example section as you asked. At the same time, I've bolded the "official website" part, which should hopefully discourage incorrect tagging further. --Tordanik 09:12, 18 December 2015 (UTC)

Sidewalk

You've made the change http://wiki.openstreetmap.org/w/index.php?title=Key:sidewalk&diff=0&oldid=1287333 with the comment "The statement never described predominant usage, but preferred usage. That hasn't changed.". In OSM predominant usage _is_ preferred usage. Other than you, who is it preferred by? Taginfo has "none" as more popular by 2 to 1. Realistically data consumers will process both, but we should always be careful to try and make the wiki descriptive and not prescriptive. --SomeoneElse 10:10, 6 April 2016

I'm unsure how to respond to this, because you seem to consider it a given that the wiki is supposed to be purely descriptive. But let me try. In my opinion, the primary role of the wiki is to tell the reader how they should tag something. That's why we have lots of discussions in the wiki about the relative benefits of different tagging styles, and even proposals and votes: Because whe want to figure out how we should tag things. Otherwise, all that would be unnecessary and looking at Taginfo would suffice to resolve any disagreement.

Specifically regarding the no vs. none debate, there is an approved proposal which states that "yes" and "no" should be preferred over any alternative values with the same meaning. With this to guide us, we don't have to rely on my preferences here. We have a documented, clear majority among those who cared enough about this issue to cast their votes.

As for my revert and the comment, I realize that it was perhaps too harsh, so please have my apologies. I'm not a master of the English language by any means and was aiming for brevity, when I should have started a discussion. As for the statement in question, though, I still prefer that sidewalk=none be explicitly discouraged. I would hope that we, too, can come to an agreement on this topic. --Tordanik 18:11, 15 April 2016 (UTC)

I notices that "yes" is deprecated as it doesn't work well with multiples. "none" also seems to work better with multiples than "no". IMO... --Deanna Earley (talk) 23:13, 15 April 2016 (UTC)

Thanks for the reply. With regard to "boolean values", both/left/right/no or none clearly isn't a boolean value. With regard to "yes" (mentioned by Dee above) I'd still use that if I knew there was a sidewalk on one side of the road or the other (i.e. I remember walking down there not on the road itself, but can't remember which side), so I'm not sure that "deprecated" is ideal for it, but it's certainly "not a preferred value" and "better replaced once more information is known". On the more general question of whether the the wiki should "tell people to map in a different way to what they are currently doing", we'll have to agree to differ. I've seen quite a few examples where well-meaning wiki discussions about changes to tagging schemes haven't been discussed with the wider community, and well-meaning editors without any local knowledge have made incorrect edits as a result because they were not able to sanity-check the previous (to them incorrect) tagging. "power" tagging is an example of this, as are many other wide-ranging "I'll just make this tagging match the wiki" edits that anyone can see if they look for large-area changesets in OSM's history view. Personally I don't care much whether no or none is "better" for indicating the absence of a sidewalk (perhaps a slight preference for "none" to make clear it's not a boolean value); the main point is the only evidence we have is that, of 350k sidewalks mapped by OSM mappers 250k of them were "none" rather than "no", and that of the 4 people who commented on the "no vs none" wiki discussion 3 preferred "no" rather than "none". I'll take 250k over 3 any day. The wiki works best when it can point to evidence where the community decided that something should be done a certain way. That really doesn't seem to be the case here. --SomeoneElse (talk) 11:47, 17 April 2016 (UTC)

Thanks for the explanation of the "yes" issue. I agree with you that it should not be considered deprecated, and "better replaced once more information is known" is a great way to describe it.

As for the "boolean values", I admit that the proposal used the term incorrectly. However, all of the examples in the proposal (bridge, oneway, electrified, lit) are keys with possible values beyond yes and no. So I think it's clear that the sidewalk key is comfortably within the scope of this proposal, despite its mix of yes/no and left/right/both values.

A few quick words on the describe vs. prescribe debate: I feel that with the ubiquity of editor presets, the tagging numbers are far less useful than they used to be. The most popular OSM editor doesn't show tags at all unless you ask for it. Even mappers who add tags manually do not necessarily intend their choice of tags as a vote of sorts, but simply as a means to an end. Add imports into the mix, and the signal of conscious tagging choices is hidden in a lot of noise. Thats a big reason why I'd rather ask people for their opinion directly instead of interpreting tagging statistics, even with the known problems of our wiki.

Now, we probably aren't going resolve the philosophical differences here (although it's an interesting topic!), but I still hope that we can come to a conclusion regarding the sidewalk key. --Tordanik 12:54, 17 April 2016 (UTC)

Re "I still hope that we can come to a conclusion regarding the sidewalk key" I don't believe that we can, since we would still only be two voices among the many thousands mapping sidewalks. --SomeoneElse (talk) 15:45, 19 April 2016 (UTC)

Relation:restriction

Thanks for the edit! It's much more understandable now :) --Kakurady (talk) 21:43, 14 March 2017 (UTC)

You're welcome! :) And thank you for the original edit, that bit of information was sorely missing from the page! --Tordanik 22:18, 14 March 2017 (UTC)

Not everyone agrees it should be there though. Greeting a new user with a revert without even leaving a message is not the most polite way. :) (I haven't had the time to ask the tagging mailing list whether conditional restrictions for turn restrictions is widely adopted; I left the other revert alone from an abundance of caution.) Kakurady (talk) 23:11, 14 March 2017 (UTC)

Well, I have made a mistake to revert it so quickly. Sorry for that. Chrabroš (talk) 12:29, 14 May 2017 (UTC)

Why are you removing wikipedia links?

Hello Tordanik, what is the purpose of this change? Why are you removing links to Wikipedia? I think they are useful. Chrabroš (talk) 15:10, 8 May 2017 (UTC)

As per the wiki guidelines, Wikipedia links should be used sparingly: Wiki guidelines#Wikipedia linking. In general, the meaning of a tag should be clear from reading the OSM wiki, and if that's not the case, the wiki should be expanded. Linking to Wikipedia (especially prominently in the introduction) gives mappers the impression that the Wikipedia article's content is what the tag is about, which might be subtly different from the OSM definition – either now or in the future, as Wikipedia articles can change at any time. Therefore, inserting a Wikipedia link has the potential to muddle the meaning of a tag. If you believe that there's a reason why amenity=arts_centre, in particular, needs a Wikipedia link, I'm happy to discuss that. However, Wikipedia links should certainly not be added to pages by default. --Tordanik 16:19, 8 May 2017 (UTC)

Language information

Hello Tordanik. As the voting for “language information” has yet started, I was reluctend to change the text itself, but I have made at least the word “not” bold (and “most” italic), so it stands outs more that “it is not nesessary to add language information to most objects” – and it would be up to the mappers to judge when it’s worth to use it and when it’s not worth…

Hi Sommerluk, I fully understand that updating the proposal after the vote has started isn't an option. "It's not necessary" is not quite what I had in mind, though – what I would like to see is more a "you should not". The problem with leaving this as a case-by-case decision is that 20 mappers deciding not to add it and 1 mapper deciding to add it will still end up with the object carrying the tag.

Unrelated to this point, though, I'm sorry about how the voting for your proposal has turned out. Some of the no votes strike me as rather unhelpful. --Tordanik 12:43, 9 September 2017 (UTC)

Re: Simple 3D buildings software list

Oh, I hadn't realized the table was also intended to be a sort of "history of simple 3D software", but that would be useful – your OSM2World renderer is a pioneer and it should get credit for that. In general, I've found that alphabetical software listings are easier for people to use. (There are other examples of this approach in Frameworks and Rendering.) Since I couldn't find very specific release dates for some of the software, I've added a brief history section to the top of the section that gives OSM2World more prominence. Hope this helps! – Minh Nguyễn (talk, contribs) 15:49, 2 September 2017 (UTC)

The introductory paragraph is a good compromise. I've got two corrections, though: Unless I'm mistaken, the honor of being the first complete implementation of Simple 3D Buildings goes to Kendzi 3D rather than F4 Map. Also, OSM-3D.org predates Simple 3D Buildings – the latter didn't exist in 2009 yet. --Tordanik 19:32, 10 September 2017 (UTC)

Adopting Wikibase discussion

Hi Tordanik,
thank you for adding your thoughts to the Wiki talk.

Since the adoption of such a complex tool like Wikibase it's an important and wide decision, what can we do now to make a serious proposal and start a debate about it?

I'm thinking about a place where people can discuss pros and cons and also the technical facts about installing it. Both for the community and for the OSM staff. I think it's a wide range improvement that can be used by the wiki and also by the data consumers then, if possible, we can also involve them. --NonnEmilia (talk) 17:56, 7 September 2017 (UTC)

Hi NonnEmilia, I expect that the main challenge isn't going to be strong opposition to the idea, but rather indifference. Ultimately, you have to convince volunteers to put in their spare time. That particularly applies to the wiki server admins, who tend to be rather conservative when it comes to additional features that will need extra maintenance efforts.

The single most helpful thing would probably be a demo installation somewhere, with the current content imported to demonstrate the benefits. With something to actually show to people, it would be far easier to advertise the idea and convince people that it's worthwhile.

And yes, we would need to involve the data consumers who currently parse the wiki templates. The most prominent user of this data is probably Taginfo. In fact, I doubt this idea will go anywhere if it were to break Taginfo functionality, given the critical role of that tool in the OSM community.

All this is of course a lot of work, and we pretty much would have to put it in before we know whether it will work out. I'm afraid I don't know much about MediaWiki administration (I'm pretty much a frontend user, with a little bit of bot writing experience), but I'd be glad to help here and there if you want to go that route. --Tordanik 19:48, 10 September 2017 (UTC)

Examples for pedestrian roads

I will make a proper reply, but I am between two trips without access to a PC. Can you wait with removal (that example was on that page for a long time, and I think that it can wait one week more) Mateusz Konieczny (talk) 19:40, 30 April 2018 (UTC)

• I think that we should create page comparing our approach to mapping, for now I hunt for a good images to illustrate some examples (I may need to make some, as I failed to find good examples for some cases). Mateusz Konieczny (talk) 09:12, 14 May 2018 (UTC)

Examples for things that should not get a building tag

I’ve seen you have put bridge piers again on the example list for non-buildings, referring to the don’t tag for the rendering dogma, but I believe they don’t make a good example because they are an edge case. As it is not completely clear where the border for building in OSM is, and as there are piers that probably most people would see as buildings, eg these :

—Dieterdreist (talk) 16:18, 5 May 2018 (UTC)

It's not yet completely clear where the border is. But I believe the goal of documentation should be to make such borders progressively clearer. That isn't achieved by staying safely away from that border and only mentioning extreme examples (which are clearly buildings, or clearly non-buildings). Instead, it requires tackling the potentially ambiguous cases.

In this case, we have an approved tagging (bridge:support=*) specifically intended for bridge piers. To me, that's a strong argument to consider them non-buildings. --Tordanik 16:30, 5 May 2018 (UTC)

The fact there is an alternative tag for these with some usage doesn’t mean anything for the tag building, it is an almost common situation. There is also man_made=tower for towers, but it doesn’t mean those objects can’t get a building tag nonetheless. The problem with edge cases can be that the rule applies to some and not to others, which doesn’t make them good examples all together. —Dieterdreist (talk) 22:50, 5 May 2018 (UTC)

You have also restored “sockets”, can you give an example what kind of objects these refer to? —Dieterdreist (talk) 23:04, 5 May 2018 (UTC)

I assumed that the word "sockets" referred to e.g. the bases of statues or obelisks. It may not be a good word, though, and I wouldn't object you removing it on those grounds.

As for the bridge piers, it's true that dual-tagging certain features with building/building:part plus some other tag does occur. It would also at least give data consumers a chance to do something sensible with these bridge piers, compared only using a building tag. However, this kind of dual-tagging generally strikes me as undesirable if we have other options, and it seems to be mostly the result of evolved tagging systems, not something that should serve as an example for how to best do things. Do you disagree with that? What's the benefit of adding building=* to an element that already has bridge pier tags? --Tordanik 05:35, 8 May 2018 (UTC)

WRT sockets, I also believe it is not a good term here, because we both don't know exactly what is meant, or if the term is good for what we suppose might be meant (e.g. wikipedia:en doesn't even mention this use on their socket disambiguation page). According to my dictionary, socket refers to a hollow, which indicates there might be instances where building is OK, clearly there are bases of monuments and sculptures which are meant to be accessible, e.g. to hold a small exhibition. Examples must be clear, not raise more questions than they answer, and this was my motivation to remove these 2 words, both of them have issues and are not always clear cases. I didn't want to advocate mapping any pier as building, but there are cases where it can apply. I wouldn't have added piers as positive examples for building values either, obviously. If you could agree with the removal of the 2 terms, based on the outcome of this discussion, I would appreciate if you could remove them again. --Dieterdreist (talk) 11:32, 11 May 2018 (UTC)

StreetComplete's offline editing

Is there some fundamental difference between StreetComplete and Vespucci/JOSM offline editing that makes SC worse?

As far as I am aware all can fetch data (easily in case of OSM data for editing, fetching background map is more irrritating - JOSM has some way to prefetch background tiles, but getching data by panning map is available also in Vespucci in StreetComplete).

All can be easily used to edit.

All can upload modified data.

All can to an extent handle edit conflicts (JOSM has quite good conflict resolution, Vespucci has horrible conflict resolution, and StreetComplete just discards conflicting data that sounds like a horrible idea but in practice works quite well due to type of editing and low risk of conflicts).

it is reply to https://wiki.openstreetmap.org/w/index.php?title=Using_OpenStreetMap_offline&diff=1608122&oldid=1606742&rcid=&curid=23561

Mateusz Konieczny (talk) 10:23, 12 May 2018 (UTC)

entrance=emergency

Hi, habe gesehen dass Du die Verweise zum exit tag entfernt hast beim tag entrance=emergency und darauf bestehst, es sei ein Notausgang, davon kann man aber nicht grundsätzlich ausgehen, nur weil das in Deutschland so gemacht wird/wurde, andere Mapper haben mir davon berichtet, dass sie das für Eingänge zu Notaufnahmen verwendet haben. Grundsätzlich ist es klar, dass es immer zu solchen Mehrdeutigkeiten kommen wird, wenn man die Semantik ignoriert und z.B. „Eingang“ dort verwendet, wo es nur einen Notausgang gibt, und das Wort Ausgang aber fehlt (gemeint ist damit, dass exit=emergency oder notfalls auch entrance=emergency_exit klar verständlich sind, während entrance=emergency eine semantische Katastrophe ist, sofern das Notausgang bedeuten soll. Als Randbemerkung, es gibt in Deutschland auch mind. ein Projekt namens Noteingang:

—Dieterdreist (talk) 01:41, 11 July 2018 (UTC)

Hi, die Bedeutung von entrance=emergency steht aus meiner Sicht nicht ernsthaft in Zweifel, da es sich um ein abgestimmtes Tag handelt und sich die Editoren, das Wiki und die Auswerter bei der Bedeutung einig sind. Ich sehe bei dem Thema zwei Probleme: Dein Vorgehen bei der Änderung einerseits und der konkrete Alternativvorschlag exit=* andererseits.

der tag "exit" ist allerdings nicht von mir, der ist nur naheliegend und wird daher auch weltweit verwendet. Die Änderung vor einem Jahr bezog sich vermutlich auf eine Diskussion auf [tagging], ganz sicher bin ich mir da allerdings nicht ;-)

Zum ersteren Punkt: Dass entrance=emergency unglücklich gewählt ist, will ich nicht bestreiten, und entrance=emergency_exit wäre beispielsweise eine eindeutig bessere Wahl, die ich auch sofort unterstützen würde. Trotzdem bin ich nicht damit einverstanden, dass diese per Proposal abgestimmten und von Anwendungen unterstützten Werte im Alleingang durch einen Wikiedit als veraltet erklärt werden.

Was nun deinen konkreten Alternativvorschlag Key:exit angeht, halte ich ihn (anders als z.B. das o.g. emergency_exit) nicht für eine gute Lösung: Der Grund ist, dass es m.E. einen gemeinsamen Schlüssel oder "Haupttag" für Ein- und Ausgänge geben sollte. Einmal ist für manche Anwendungsfälle die Unterscheidung zwischen Ein- und Ausgängen nicht interessant. Vor allem aber ist es der mit Abstand häufigste Fall, dass eine Tür sowohl als Eingang als auch als Ausgang dient. Das sollte daher mit einem einzigen Tag ausgedrückt werden können - nicht mit entrance=yes + exit=yes.

entrance=emergency_exit löst zwar das Problem, dass der tag nicht sagt was er meint, es suggeriert aber dennoch eine Art von Eingang. Ausgänge können aber durchaus so gestaltet sein, dass man sie nur als Ausgang verwenden kann, z.B. durch Vereinzelungsanlagen / mannshohe Drehkreuze und entsprechende Zäune.

Der Tatsache, dass vermutet die meisten Eingänge auch als Ausgang genutzt werden können, könnte man dadurch Rechnung tragen, dass man exit=yes als default für entrance=* sieht, und empfohlen wird, nur Fälle wie exit=only, exit=no und exit=emergency zu taggen.

In diesem Zusammenhang bin ich übrigens auch mit deinem Revert von Zveriks Warnhinweis auf Key:exit nicht ganz glücklich, denn soweit ich sehe sind beide Aussagen ("nicht approved" und "kaum unterstützt") faktisch korrekt. --Tordanik 20:05, 12 July 2018 (UTC)

"kaum unterstützt" halte ich für ein seltsames Argument, da Ausgänge nur für indoor-Routing relevant sind, und dafür allgemein weder Daten noch Nutzer vorhanden sind. M.E. definieren wir in dem Bereich vor allem für die "Zukunft". Mit "nicht approved" ist gemeint, dass es bisher keine explizite Abstimmung gab? Knapp 10.000 Verwendungen sind m.E. de-facto Nutzung. --Dieterdreist (talk) 10:23, 13 July 2018 (UTC)

Ausgänge sind keineswegs nur für Indoor-Routing relevant. Mit entrance getaggte Ausgänge werden beispielsweise schon heute in zahlreichen Nicht-Indoor-Karten gerendert (meines Wissens sogar in openstreetmap-carto). Mit exit getaggte Ausgänge hingegen nicht – dieser Schlüssel ist eben "kaum unterstützt".

Und ja, mit "nicht approved" ist gemeint, dass es keine Abstimmung gab. Das wäre verzichtbar, wenn der Tag de facto etabliert wäre, dem ist aber nicht so: 10.000 Verwendungen sind im Vergleich mit den eineinhalb Millionen entrance=* eher ein Beleg für die geringe Verbreitung des exit-Taggingschemas.

Zu den Punkten weiter oben: Ich halte Missverständnise bei entrance=emergency_exit für ausreichend unwahrscheinlich, dass ich das zwar als ästhetisch etwas unbefriedigend empfinde, aber nicht für ein praxisrelevantes Problem halte. Am schönsten fände ich einen gemeinsamen Oberbegriff für entrance und exit, den man dann als Schlüssel verwenden könnte, aber da ich dafür kein gutes englisches Wort kenne, halte ich die aktuelle Verwendung von entrance als Schlüssel für ok.

Die Idee, dass man exit nicht für normale Ein- und Ausgänge, sondern nur für only/emergency/no benutzt, fände ich übrigens zumindest vertretbar. Allerdings reden wir dann von derzeit 250 solchen Werten in der DB – fast alles andere sind ja exit=yes. --Tordanik 18:20, 17 July 2018 (UTC)

Towards a better use for OSM.ORG

Hi, I see that you started Osm.org page, so inviting to discuss something related to it at Talk:Osm.org. --Krauss (talk) 15:40, 26 August 2018 (UTC)

aerialway=zip line status

If its not approved, then what makes its status "de facto" instead of just "in use"? De facto sounds like approved to me, vote or not. Otherwise, what does "de facto" mean exactly and what is the point in it?

I would only use "de facto" when a tag is widely accepted by both mappers and data consumers, and there are no credible alternatives. Something like highway=*, for example.

The zip_line tagging does not meet this high standard. Therefore, I wouldn't have set its status to "de facto". I might not even have set "in use", labeling it as "proposed" instead. But I don't know enough about the subject matter to comfortably make that call. --Tordanik 16:20, 13 September 2018 (UTC)

Zebra crossings

(response to https://wiki.openstreetmap.org/w/index.php?title=User_talk:Mateusz_Konieczny&diff=1676015&oldid=1634033 )

"Using crossing=zebra only makes sense in countries where there are both zebra and non-zebra crossing variants, with a legal difference between their meaning."

In Poland there is a legal difference between zebra crossings and unmarked crossings and pedestrians still must yield way to cars before entering a zebra crossings as of 2018 (and cars are supposed to yield way to pedestrian on a crossing). Mateusz Konieczny (talk) 11:48, 7 October 2018 (UTC)

Discussion on the meaning of crossing=zebra now seems to be happening on the talk mailing list. --Tordanik 21:46, 29 October 2018 (UTC)

Demolished vs note

I think this needs more explanation because I don't get the meaning of it. If you use note instead of demolished the building will be still rendered as a building? RicoZ (talk) 21:10, 18 February 2019 (UTC)

You remove the building=* in both cases. But you can either replace it with demolished:building=* or with note=building demolished. The latter has the benefit (imo) of using a tag that's intended strictly for internal communications, and therefore stays clear of the "Don't map historic events and historic features" rule. --Tordanik 21:18, 18 February 2019 (UTC)

That description makes sense:). I would probably still prefer demolished but that is just my personal preference.. I think my brain is quicker understanding demolished:building than the note variant. RicoZ (talk) 22:53, 18 February 2019 (UTC)

Revert of building:colour required

Hi, I reverted the [6] because it seems like a mistake and a frequent contributor on Slack confirmed this. Please let me know if I made a mistake. It seems wrong to require building:part for building:colour -- there are 135,775 cases when both are present, and 386,217 when there is colour without the part. --Yurik (talk) 22:15, 8 April 2019 (UTC)

What I wanted to express was that building:colour=* requires either building=* or building:part=*. (You can see from Taginfo that roughly 75% of building:colour=* are used with buildings, and 25% with building parts.) I tried to imitate the approach used by Item:Q687 (service=*) as an example for a tag which requires one of several possible "parent" tags. Is there a better way to do this? --Tordanik 13:56, 9 April 2019 (UTC)

@Yurik:, any solution for this? The data item's current statement that building:colour=* requires building=* is definitely incorrect, as it can also be used on building:part=* areas. So if we cannot express the situation properly, we should at least remove this incorrect statement imo. --Tordanik 15:53, 5 August 2019 (UTC)

@Tordanik:, there is currently no structured way to express complex requirements -- A or B; (A and B) or C etc. While we could come up with some complex structure to describe those, I would only want to codify it if we have a lot of such cases. Otherwise it might be better to just add to the item's description that it requires A or B. We may also want to add those As and Bs to the combination (P46) instead. If we do end up with a lot-of OR-s, I can think of these solutions:

• create a "OR" facet property. Usage example: item requires A, with A having a facet "OR B". A would be the most common value.
• create a magical "OR" data item, and use facets to list values. Example: item requires Qxxx (OR), with the Qxxx having several facet values like "requires A", "requires B".

Neither of those paths are that great because every system using data items (including the description-generating Lua module) will have to understand this syntax. Also it does not solve the (A and B) or C, but that can be solved by requiring only A or C, and A itself requires B... something like that? --Yurik (talk) 16:29, 5 August 2019 (UTC)

Dein Revert meines Edits zu barrier=entrance

Hallo Tobias, Du schreibst: "The original picture is fine: barrier=entrance are usually purposefully built, and even a gap in a wall still limits the maximum width compared to a complete absence of a wall". Ob ein barrier=entrace absichtlich und offiziell gebaut wurde, oder nicht, spielt für den tag keine Rolle, er gilt für beides. Klar begrenzt auch eine Unterbrechung in der Wand, wie in dem früheren Bild dargestellt, die Durchgangsbreite. Ich sage ja auch nicht, dass dieses Bild eine Situation darstellt, für die die Leute den tag nicht verwenden, sondern, dass es nicht das bestmögliche Bild als Repräsentation des tags ist, meiner Meinung nach, weil es eine Situation abbildet, die man anders (sogar besser) darstellen kann, also ohne den tag, und dass es in dem Beispiel diese alternative Möglichkeit grundsätzlich als Option gibt. Bei der Situation in dem Bild das ich als Ersatz verwendet hatte gibt es keinen alternativen etablierten tag. Stört Dich an dem neuen Bild, dass es vermutlich eine informelle oder vielleicht gar illegale Öffnung ist? Man könnte auch ein anderes Bild verwenden, wo es klarer ein offizieller, geplanter Durchgang ist, und trotzdem die Option des Lückelassens nicht besteht, z.B. ein offener Torbogen in einer Mauer. --Dieterdreist (talk) 19:33, 29 November 2020 (UTC)

Ja, ich fände in der Tat einen "offizielleren" Durchgang als Beispiel besser, und falls du ein entsprechendes Bild hast wäre ein offener Torbogen in einer Mauer denke ich ein gutes Beispiel. --Tordanik 19:44, 29 November 2020 (UTC)

Das Problem der meisten Bilder die ich finde (auch schon vor meinem ersten Edit), das sind meistens Stadttore (also eher ungeeignet, weil es da auch bessere tags gibt), oder irgendwo am Rand sieht man doch noch ein Tor oder das Bild ist sonst nicht auf den Durchgang fokussiert oder irgendwie mehrdeutig. Vorschlag --Dieterdreist (talk) 09:14, 30 November 2020 (UTC)

Finde ich einen guten Vorschlag. --Tordanik 17:44, 30 November 2020 (UTC)

'far-reaching speculation'

(https://wiki.openstreetmap.org/w/index.php?title=Wiki_content_license&oldid=prev&diff=2084725) Which part of the edit do you disagree with, that the server is in NL as reported on the hardware and munin pages, or that knowing where the server is indicates / doesn't indicate which government is concerned with the server's operation, or that it does / doesn't affect content on the wiki, or that people should / should not be aware of such facts, or that wiki content license is / isn't the proper page for such? Arlo James Barnes (talk) 23:28, 6 January 2021 (UTC)

I'm not convinced that the physical location of the server is the definitive jurisdiction for copyright purposes. To my knowledge, this was at the very least not the intent when operations decided to locate our wiki on that server. You may nevertheless be right, of course. But wiki content license is the page you arrive at when you click the license link in the footer below every wiki page, so it has a somewhat official character. As such, I would prefer to only add such a potentially far-reaching statement with the blessing of the LWG (or at least a broad community discussion). --Tordanik 10:06, 7 January 2021 (UTC)

That's fair. Do you mind if I email the workgroup to ask what they think? I agree that ops likely didn't have jurisdictional issues at the front of their minds versus, say, load-balancing (and for context https://osmus.slack.com/archives/C1R62SM9T/p1602155648006900 on https://slack.openstreetmap.us is the conversation I had immediately prior to my edit), but that's probably because they expected that the rules by which the wiki is governed would be copasetic with most jurisdictions if properly abided by and maintained by the wikizens -- an expectation for which that page is one of the pillars. My thoughts about the connection between location and jurisdiction are simply that authorities have physical access to the server for evidence-gathering, but as you say I am no lawyer and would be happy to defer to some. Arlo James Barnes (talk) 23:15, 9 January 2021 (UTC)

Thanks for sharing the slack context! And sure, I don't mind, feel free to ask them. --Tordanik 15:13, 10 January 2021 (UTC)

proposed features/Goods conveyor

Are you still interested in proposing this? If so, what do you think about tagging for mass tolerances? Arlo James Barnes (talk) 23:15, 9 January 2021 (UTC)

I don't think I'll return to work that proposal – I have too many other projects occupying my OSM time. User:Fkv tried to revitalize the proposal at some point, so you might have more luck with him. --Tordanik 15:09, 10 January 2021 (UTC)

(I was automatically notified of my name mentioned here.) Please use the proposal's talk page to discuss that, and explain what you mean by mass tolerances. --Fkv (talk) 16:33, 11 January 2021 (UTC)

Osm2world: building outline is not completeley covered by building parts

How do you interprete in OSM2World the case when a building outline is not completely covered by bulding parts? Is it like Mateusz Konieczny wrote:

Building may be tagged with building:part=* areas in places where properties from building=* are overwritten, for example lower building part having building:levels=1 supposed to overwrite building:levels=10 on building=* outline and no other building parts.

Or is it something else? --vvoovv (talk) 07:54, 26 January 2021 (UTC)

With this example, OSM2World would only render that building part with building:levels=1. The rest of the building would not be visible.

In older versions of OSM2World, I attempted to subtract the building parts from the outline and render the left-over area using the tags on the building itself. I stopped doing that partly to conform more closely to the S3DB standard, and also because intentional use of this approach is hard to distinguish from various classes of widespread mapping errors. (One example would be building parts that are just a tiny bit smaller than the building, resulting in a thin wall appearing between the part outline and building outline.) --Tordanik 05:55, 27 January 2021 (UTC)

Proposed features/Add Translate extension to Wiki

Proposed features/Add Translate extension to Wiki - you may be interested, it is repeat of https://wiki.openstreetmap.org/wiki/Talk:Wiki#Add_Translate_Extension where you commented Mateusz Konieczny (talk) 08:05, 29 March 2022 (UTC)

incline

re https://wiki.openstreetmap.org/w/index.php?title=Key:incline&oldid=prev&diff=2410960

In this case

• meaning of value is quite clear
• I asked top users of that tag what they meant while adding it

Would it be considered as good enough by you and solving "no evidence of claimed meaning was provdied"?

I know that it was not part of approved proposal but we have ATYL, tag was used 400+ times with this meaning and there is no known alternative to it.

And incline tag anyway requires obnoxious parsing, it is not some nice tag with yes/no values anyway

Mateusz Konieczny (talk) 12:14, 30 September 2022 (UTC)

Ok, asking users of the tag what they meant does take care of the lack of evidence. And it does show impressive dedication on your part and a desire to do the right thing. I'm actually impressed!

I still feel that 440 uses are a poor justification for altering the definition of a tag used almost a million times. ATYL is fine when you invent new keys, not when you change existing ones.

But as usual, I don't have the ability to fight you on this. You have just that much more time and energy than me to invest on wiki changes and you'll be able to establish the tag through the StreetComplete back door anyway, so ... well, do what you want. I guess it doesn't do any serious harm. --Tordanik 12:50, 30 September 2022 (UTC)

Just in case you would want to run such checks and can use Python: I found this people via https://codeberg.org/matkoniecz/who-added-this-tag.git (checking history of 400+ objects also would work but would take absurd amount of time) Mateusz Konieczny (talk) 12:55, 30 September 2022 (UTC)

And for this tag: I honestly do not care at all how this would be tagged. But if I invent a brand new tag then people will also complain that StreetComplete is inventing a new tags, if I will just ignore discussions completely then it is even worse (and was tried and confirmed to be a bad model). I guess that "never add any new quests to StreetComplete" is also an option, but would be a bit sad. And making tag proposals takes monstrous amount of time. Mateusz Konieczny (talk) 12:59, 30 September 2022 (UTC)

If you have any specific idea for replacement tagging I can try to make deprecation proposal for it Mateusz Konieczny (talk) 06:34, 13 October 2022 (UTC)