User talk:Tordanik

From OpenStreetMap Wiki
Jump to: navigation, search

Completed discussion topics can be found in the archive.

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:

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:Proposed_features_"Rejected"). 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:

(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:

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:

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)