Vorlage Diskussion:Infobox Berg/Archiv/2

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Vorlage Diskussion:Infobox Berg/Archiv/2#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Vorlage_Diskussion:Infobox_Berg/Archiv/2#Thema_1

Karte bezeichnen

Es wäre wünschenswert, wenn man die Karte beschriften könnte, sodass klar wird, was man sieht. Auf die Idee komme ich wegen den auf der Landesgrenze liegenden Gipfel des Rätikon: man sieht dort die Karte von Vorarlberg, eine Form, welche dem Schweizer Benutzer zurecht sehr unbekannt vorkommt. Stünde nun unter der Karte z.B. "Karte Vorarlberg", wäre der Ort sofort -mehr oder weniger- klar.Caumasee 11:03, 22. Mär. 2011 (CET)

Ja, das ist wirklich nicht immer sofort laienverständlich was da auf der Karte abgebildet ist. Langfristig gesehen wäre wohl diese Initiative von Herzi Pinki die optimale Lösung. --Svíčková na smetaně 20:50, 22. Mär. 2011 (CET)

Nachweis Berghöhe

Meines Erachtens fehlt in der Infobox Berg der NACHWEIS-HÖHE, ähnlich wie bei Infobox Fluss, in der NACHWEIS-LÄNGE eintragbar ist.
MfG --TOMM 09:13, 21. Mai 2011 (CEST)

du kannst HÖHE-ANMERKUNG dafür verwenden. lg --Herzi Pinki 18:19, 30. Jun. 2011 (CEST)

Parameter Schartenhöhe-Bezug

Der Vollständigkeit halber falls es jemand noch nicht mitbekommen hat, auf Diskussion:Schartenhöhe#.C3.9Cberarbeitung_vom_18._Oktober_2011 läuft eine Diskussion die auch diese Infobox betrifft. lg, --Svíčková na smetaně 19:25, 22. Okt. 2011 (CEST)

Erklärung zu Dominanz

Ist die Erklärung des Parameters DOMINANZ= in der Vorlage wirklich so gewollt? Dort steht Die Dominanz gibt die Distanz (in Kilometern) zum nächst höheren Berg an. Die Dominanz beschreibt jedoch nicht die Distanz zum nächst höheren Berg, sondern zum nächsthöheren Punkt seiner Umgebung (und ist somit meist kürzer als die Distanz zum nächsthöheren Berg). Sollte man das in der Beschreibung der Vorlage nicht auch so schreiben? --Capricorn4049 19:33, 27. Okt. 2011 (CEST)

da steht nicht zum Gipfel des nächsthöheren Berges. Aber etwas präziser könnte es schon sein. --Langläufer 17:29, 28. Okt. 2011 (CEST)

das Problem wie immer ist die Eruierbarkeit dieses Punktes. Die genaue Definition braucht mathematische Modelle (= Quellen), die schlampige kommt mit der Karte aus. Dazu kommt, dass zwar die Entfernung (=DOMINANZ) zu jedem Punkt messbar ist, ein solcher Puntk als DOMINANZ-BEZUG aber nur über Koordinaten, nicht über seinen Namen angegeben werden kann. lg --Herzi Pinki 19:14, 19. Nov. 2011 (CET)

Vorschlag: Parameter für einschlägige topografische Karte hinzufügen

Wie wäre es, wenn man noch die Möglichkeit hätte, eine topographische Karte anzugeben, auf der der Berg verzeichnet ist? Allerdings besser nur auf amtliche Karten beschränken, also keine Wanderkarten o.ä. sonst gibt es schnell eine ziemliche Liste, die in der Infobox sicher nicht gut aufghoben wäre. Bitte um Kommentare und Meinungen. --Isjc99 21:58, 13. Nov. 2011 (CET)

Zum Verlinken von Kartendiensten sollte ausschließlich die Koordinaten-Einbindung mit Absprung auf die zentrale Geohack-Seite dienen (swisstopo ist darüber ebf, eingebunden). Siehe auch Wikipedia:Weblinks#Einzelrichtlinien Punkt 11. Sonst gibt es im nu wieder Zank - der eine möchte den Weblink lieber nach Google-Maps der andere nach SwissTopo, OpenStreetMap und so weiter. --alexrk 22:44, 13. Nov. 2011 (CET)

Sorry, ich habe mich nicht deutlich ausgedrückt. Ich wollte eine Nennung des gedruckten topografischen Kartenblatts vorschlagen, auf der der Berg verzeichnet ist. Für viele Alpinisten ist die gedruckte Grundkarte immer noch der beste Wegweiser. Es geht also nicht um eine Darstellung auf einer Karte oder einen Link zu dieser. Gerade bei Schweizer Bergen ist z.B. die gedruckte Grundkarte 1:25000 die meistverwendete Wanderbegleitung (auf der auch die online-Darstellungen bei swisstopo basieren). Beispiel wäre: Karte: Swisstopo Landeskarte 1:25000 Blatt 1252 "Ambri-Piotta" --Isjc99 23:27, 13. Nov. 2011 (CET)

Hm, ich bin auch ein Freund von Kartenhinweisen, weiß aber nicht ob die IB dafür der richtige Ort ist. Schon allein weil es (auch bei Beschränkung auf amtliche Karten) mehrere sein können (etwa bei Grenzgipfeln) und dann die Ib ziemlich voll wird. Grundsätzlich bietet sich der Literaturabschnitt an, darüber hinaus kann man Karten auch als Einzelnachweise (z.B. als Beleg für die Höhe, aber auch für Beschreibung von Lage und Umgebung) verwenden. lg, --Svíčková na smetaně 19:06, 14. Nov. 2011 (CET)

Voll ist glaube ich nicht so ein starkes Argument, wenn man sich z.B. die möglichen Parameter der Infobox Hütte anschaut. Es gibt ja selten Fälle, wo bei einer solchen Infobox wirklich alles ausgefüllt wird. Mir ist aber aufgegangen, dass das wohl eine Schweiz-spezifische Diskussion ist; in der Schweiz sind die Swisstopo Karten 1:25000 das A und O; die lokalen Blätter gibt es in jedem Supermarkt und Andenkenladen, während es Wanderkarten anderer Verlage in der Schweiz selbst nur wenig gibt. Die Karten sind auch die einzigen, auf die in den SAC-Führern eingegangen wird; teilweise machen die Führerautoren auch Namensvorschläge für Orte auf Karten oder kommentieren Fehler. Die 1:25000 ist also quasi ein Standard in der Schweiz. Da wird mir sicher jeder mit den schweizer Verhältnissen vertrauter zustimmen. Überlappungen gibt es bei diesen Karten ebenfalls nicht. Es würde m.E. also für Schweizer Berge recht viel Sinn machen, in anderen (Alpen-) Ländern ist es vielleicht nicht so informativ, da es dort diese "Alleinstellungskarte" so nicht gibt, wobei man evtl. sagen könnte, dass in D und Teilen von A die AV-Karten eine ähnliche Stellung haben. Ich ändere meinen Vorschlag daher ab: Parameter "CH-LANDESKARTE" nennen und nur in CH verwenden. Oder "AV-KARTE" nennen und in der CH dafür die Landeskarten nehmen. Beispiel bleibt: Karte: Swisstopo Landeskarte 1:25000 Blatt 1252 "Ambri-Piotta" (nicht signierter Beitrag von Isjc99 (Diskussion | Beiträge) 07:50, 16. Nov. 2011 (CET))

Man könnte das Kartenblatt doch automatisch aus der Koordinate bestimmen! Wäre das was für eine neue Vorlage? Oder bei geohack? --Langläufer 09:51, 16. Nov. 2011 (CET)

Keine Ahnung ob das geht; auf Anhieb sehe ich da keinen Layer mit den Kartengrenzen. Das wäre natürlich ein dolles Ding. (nicht signierter Beitrag von Isjc99 (Diskussion | Beiträge) 20:34, 16. Nov. 2011 (CET))

Diese Möglichkeit (siehe Vorlagendoku) gibt es schon seit Anbeginn der Zeitrechnung (Entstehung der Infobox) mit dem Parameter TOPO-KARTE. Genutzt wird sie bisher fast nur bei der Übernahme von Daten aus :en. Aber ich sehe das so wie Svicko, hat für mich wenig Bedeutung. WP ist kein Wanderführer, wenn die falsche Karte irgendwo eingetragen ist, und du fährst mit der ins Wochenende, wer hat dann das Problem? Dazu kommt, dass ich gerade in AT die Erfahrung machen musste, dass das Bundesamt für Eich- und Vermessungswesen aus kommerziellen Gründen die Karten so neu geschnitten hat, dass ich die Lücken meiner alten Karten nicht mehr füllen kann. Auf der anderen Seite, sollte eine Ableitung aus den Koordinaten nicht möglich sein, hat natürlich die länderspezifische Nummer immer im gleichen Maßstab schon einen gewissen Charme (dazu würde es strukturiertere Parameter brauchen). Aber mal ehrlich. In der WP klicke ich auf den Geohack und sehe die Welt aus Satellitenaugen mit Höhenschichtslinien, Suchfunktion, Wanderwegen, was immer mein Herz begehrt. Also zum Lesen der WP würde ich keine Karte her nehmen, zum Schreiben auch nicht. D.h. die Karte hätte nur für den Ausflug in die reale Bergwelt eine Bedeutung. Macht das wirklich Sinn? lg --Herzi Pinki 19:27, 19. Nov. 2011 (CET)

Ich hab gerade nochmal nachgesehen; bei TOPO-Karte steht in der Erläuterung "Link zu topografischer Karte". Den wiederum hat man ja nun schon automatisch mit den Koordinaten. Ich gebe Herzi Pinki reicht, dass die WP kein Wanderführer ist (... obwohl es einen Parameter "Normalweg" gibt). Ich verwende aber definitiv beim Lesen, Schreiben und Ändern von bergbezogenen Artikeln hauptsächlich gedrucktes Material wie (schweizerische) Gebietsführer und Topografische Karten. Aber zum Thema: wenn Einigkeit herrscht, dass man "TOPO-KARTE" mit der Angabe des Kartenblatts der topografischen Karte füllen kann (was für mich mehr Sinn macht als der Link, den es eh schon gibt), ist die Diskussion ja abgschlossen. --Isjc99 19:47, 19. Nov. 2011 (CET)

Ich habe die Legende in der Vorlage entsprechend dieser Diskussion angepast. --Isjc99 22:45, 30. Nov. 2011 (CET)

Vorlagenanpassung Schartenhöhe/Bezugsberg

Ergebnis dieser Disk. war, den Bezugsberg (SCHARTE-BEZUG) zur Schartenhöhe nicht mehr in der Infobox derzustellen (v.a. da uneindeutig ist, welche Def. zugrundegelegt wird (Island Parent, Prominence Master, Line Parent) und da die Def. von Schartenhöhe und Bezugsscharte ohne konkrete Festlegung des Bezugsbergs auskommt. Neben der Entfernung des Parameters aus der Vorlage schlage ich vor, auch alle Verwendungen zu entfernen. Ich werde alle bisherigen Verwendungen dieses Parameters in einer Liste sammeln, die ich auf einer Unterseite dieser Seite zur Verfügung stelle.

Im Zuge dieser Aktion ließe sich gleich auch "LEICHTESTE ROUTE" in "NORMALWEG" umsetzen. Gibt es weitere Wartungsaktionen, die man miterledigen könnte?--Cactus26 07:28, 4. Nov. 2011 (CET)

Scharte-Bezug sollte als Hinweis darauf, wie die Schartenhöhe ermittelt wurde erhalten bleiben - braucht jedoch nicht dargestellt werden. Mir ist nicht klar, warum ihr da unbedingt einen genauen Berg benennen wolltet. Es kommt doch lediglich darauf an ein höheres Gebiet zu benennen, welches über die Scharte verbunden ist. --Langläufer 09:14, 4. Nov. 2011 (CET)

Um Missverständnisse auszuschließen: SCHARTE-BEZUG ist der Bezugsberg, nicht die Scharte (für die gibt es den Parameter SCHARTE). Die Bezugsscharte soll natürlich drin bleiben, nur diese ist für die Ermittlung der Schartenhöhe nötig (siehe "Meeresspiegeldef." in Schartenhöhe), den Bezugsberg braucht es nicht. Allein schon diese etwas unglückliche Benennung der Parameter ist mMn ein Grund, den Bezugsberg aus den Artikeln zu entfernen.--Cactus26 09:27, 4. Nov. 2011 (CET)

Kein Missverständnis. Es geht mir darum zu belegen, dass über diese Scharte tatsächlich ein HÖHERES Gebiet verbunden ist, welches das ist ist letztendlich irrelevant (hier reicht der Beweis durch irgendein Beispiel). Wenn es keinen eindeutigen Berg in der Nähe gab, hab ich daher auch ganze Höhenzüge oder Gebirge eingetragen. Das hilft ungemein, wenn man versucht diese Angabe zu überprüfen. Versuche doch mal die Schartenhöhe für den Brocken zu ermitteln, wenn du nicht weist, ob du ein Scharte Richtung Erzgebirge, Thüringer Wald oder was auch immer suchst. --Langläufer 09:30, 4. Nov. 2011 (CET)

(BK)Dein Vorgehen mag praktisch sein, allerdings ist ein solches Verfahren mW nicht etabliert und wäre so als TF zu werten. Es geht eben genau darum, dass unklar ist, welcher Berg genau dort einzutragen ist, da es dafür unterschiedliche Verfahren gibt und für diese teils wieder unterschiedliche Varianten. Meiner Meinung nach braucht es bei der Meeresspiegeldef. keinen Bezugsberg: Man hebt den Meeresspiegel so lange an, bis der Berg der höchste seiner Insel ist. Die letzte im Meer versinkende Scharte ist die Bezugsscharte. Welche Berge vor Versinken der Scharte die höheren waren, ist nebensächlich. Dass es irgendwo höhere Berge gibt ist für alle Berge außer den höchsten der Kontinente selbstverständlich.--Cactus26 09:44, 4. Nov. 2011 (CET)

Die Idee der Umbenennung leichteste Route->Normalweg finde ich gut, da es durchaus Fälle gibt wo der Normalweg nicht die dem Grad nach leichteste Route ist. --Svíčková na smetaně 19:45, 6. Nov. 2011 (CET)

LEICHTESTE ROUTE und NORMALWEG erzeugen dieselbe Ausgabe (solange sie nicht beide vorkommen), d.h. es handelt sich nur um eine Vereinheitlichung der Parameter, die außen nicht sichtbar ist. Aber es ist gut, wenn diese Doppelgleisigkeit wegkommt. SCHARTE-BEZUG würde ich auch löschen wollen (obwohl da grade noch das Gegenteil gestanden hat) lg --Herzi Pinki 18:55, 19. Nov. 2011 (CET)

Ich habe dann mal SCHARTE-BEZUG aus der Box entfernt. Möge der Bot sie auch aus den Artikeln entfernen. lg --Herzi Pinki 19:34, 19. Nov. 2011 (CET)

Ich habe diesen Beitrag übersehen. Na dann. Sicherheitshalber werde ich die existierenden Parameter für SCHARTE-BEZUG aufheben, für alle Fälle....--Cactus26 14:47, 4. Dez. 2011 (CET)

Fehler bei Koordinaten in Dezimaldarstellung

Werden die Koordinaten dezimal (statt in Grad, Minuten, Sekunden) angegeben, so scheint es nicht zu funktionieren. Ein Programmierfehler? --Klaron 08:17, 9. Nov. 2011 (CET)

hast du ein Beispiel? Ich habe einen beliebigen Versuch gestartet, und da hat es funktioniert. lg --Herzi Pinki 18:57, 19. Nov. 2011 (CET)

Hier ist ein Beispiel. Werden die Koordinaten dezimal angegeben, erscheint rechts oben im Artikel die Meldung "Koordinaten fehlen". --Klaron 12:19, 30. Nov. 2011 (CET)

Es liegt an was anderem, die Vorlage erwartet groß geschr. Parameter. Viele Grüße --Cactus26 12:48, 30. Nov. 2011 (CET)

Ok. Wobei man meiner Meinung nach in der Vorlage die Flexibilisierung der Klein-/Großschreibung ermöglichen sollte. --Klaron 14:29, 1. Dez. 2011 (CET)

Eine Flexibilisierung ist meiner Meinung nach keine akzeptabele Lösung, da der Komplexitätszuwachs in der Vorlagen-Implementierung in keiner Relation zum Nutzen steht (die Möglichkeiten der Vorlagensyntax sind zu bescheiden, als das so etwas sinnvoll lösbar wäre). Insofern wäre das einzige, was ich hier für akzeptabel halte würde, die Umstellung aller Parameter auf Kleinschreibung.--Cactus26 09:12, 2. Dez. 2011 (CET)

Einheitlich sollte es schon sein, andernfalls führt es zu Fehlern, wie man sieht. Von mir aus alles auf Kleinschreibung. --Klaron 16:41, 3. Dez. 2011 (CET)

Da hat einer einmal einen Fehler gemacht, ich glaube nicht, dass deswegen 7000 Artikel umgestellt werden sollten. Und dann kommt der andere und macht den spiegelbildlichen Fehler. Als ob wir keine anderen Sorgen hätten. lg --Herzi Pinki 19:15, 3. Dez. 2011 (CET)

Na ja, aus Nutzersicht ist das natürlich irgendwie verständlich, das eigentliche Problem liegt aber mMn (neben dem Groß-Kleinschreibungs-Problem) daran, dass die Vorlagen-Technik keine sinnvolle Möglichkeit bietet zu diagnostizieren, wenn ein angegebener Parameter von der Vorlage nicht verarbeitet wird. Das lässt sich aber nicht ändern, außer man verpasst der Wikipedia eine neue Template-Sprache.--Cactus26 14:46, 4. Dez. 2011 (CET)

Ich finde, es sollte ermöglicht werden, einen Wikimedia-Programmierer mit der Anpassung der Vorlagen-Sprache zu beauftragen. Es kann nicht sein, dass letztlich alles an den Autoren oder an den Vorlagen-Experten hängen bleibt. Für den Programmierer muss es ein Leichtes sein, programmtechnisch die Klein-/Großschreibung der Parameter zu ignorieren. Gibt es keine einfache Möglichkeit, sich hier an einen Wikimedia-Programmierer zu wenden? --Klaron 18:43, 7. Dez. 2011 (CET)

Hier hast du eine Liste der verwendeten Parameter der Infobox Berg, auch der falschen. Aktualisierung erfolgt allerdings in unbekannten Intervallen. Mithilfe ist willkommen. Ein Feature kannst du über bugzilla einkippen. Generelles Ignorieren der Groß- und Kleinschreibung bei Parameternamen führt vermutlich anderweitig zu Problemen, da WP generell case sensitive aufgebaut ist. Hier ist jedenfalls der falsche Platz das zu diskutieren, du kannst dich als erstes vielleicht an WP:Vorlagenwerkstatt werden. lg --Herzi Pinki 23:16, 7. Dez. 2011 (CET)

Wer entscheidet, welches Feature umgesetzt wird? Wikimedia? Die Autorengemeinschaft? Übrigens bin ich der Meinung, dass ggf. tatsächlich 7000 Artikel umgestellt werden sollten. Es muss ja wohl möglich sein, einen Bot mit dieser Aufgabe zu betrauen. --Klaron 16:51, 23. Dez. 2011 (CET)

Vorschlag: Einzeinachweise einführen für die Höhenangaben

Hallo zusammen,

ich hatte mal hier angeregt, für die Höhenangaben analog zur IB-Fluss die Angabe von Einzelnachweisen möglich zu machen. Das hat den Vorteil, dass man die Herkunft der Werte zusammengefasst dokumentiert. Da damit die Einzelnachweise innerhalb des Fließtextes reduziert werden, wird der Quelltext desselben lesbarer (Nebeneffekt).

Gruß --SteveK ?! 21:58, 21. Dez. 2011 (CET)

Sehr gute Idee!
MfG --TOMM 22:06, 21. Dez. 2011 (CET)

Kleingt plausibel, [x] make it so. --h-stt !? 11:18, 23. Dez. 2011 (CET)

Änderungen vom 7. Januar

Begründung für meine Änderungen an der Box:

1. Ausblendung. Es ist für den Parser viel einfacher, wenn es nicht so viele "noinclude" etc. gibt. Ich habe die Box daher ausgeblendet und dafür das Beispiel von der Dokuseite nach oben geschoben. Das ist bei Infoboxen viel eleganter. Ein schöneres Beispiel wäre hier ganz nett.
2. Syntax funktionsgleich vereinfacht. Mit Hilfe einer Switch-Anweisung und anderem habe ich die Verschachtelungstiefe verringert und damit den Quelltext einfacher gemacht. Das entlastet die WP-Software und ist sicherer. Den "Höhentest" (falscher Punkt) habe ich treffsicherer gestaltet.
3. Ein Pixel weniger Padding bei Bildern. Je nach Browserereinstellungen verhindert das unterschiedliche Breiten bei den Bildern wegen der Border-Werte. Gilt besonders für den IE6 mit seinem Box-Modell-Fehler.
4. Beim ersten Bild ein leichtes Höhenformat standardmäßig erlaubt. Es liegt in der Natur von Bildern eines Bergs, dass sie oft hochkant sind. Da ist es nur unnötig mühsam, wenn man jedesmal einen Wert für die Breite angeben muss, damit es anständig aussieht.

Alles andere ist unverändert. Gruß von ÅñŧóñŜûŝî (Ð) 19:05, 7. Jan. 2012 (CET)

Hallo Antonsusi, schönes neues Jahr. Funktionsgleich nennst du das?

• Bei Schartenhöhe und Dominanz sind die unicode Pfeilchen verschwunden. Welchen Editor verwendest du. Solltest ihn wechseln.
• Die Box beginnt jetzt mit einer Leerzeile, ist unschön und absolut ungewollt.
• Die Änderung in der Höhe der Bilder ist Geschmackssache und als solche vorher zu diskutieren. Es gibt auch keinen Grund, die Höhe zu ändern. 300px ist auch für hochkant groß genug. Viele Berge haben wenig Text, dann dominiert das Bild unnötig. Noch dazu, wo du das für alle Bilder und die Poskarte geändert hast. Kommt bei Bergen in Chile, etwa Aguilera (Vulkan) besonders toll.
• leere Parameter DOMINANZ, SCHARTENHÖHE, DOMINANZ-BEZUG, SCHARTE erzeugen jetzt einen Parsererror.
• die geänderte Prüfung auf abs(HÖHE) <10 wird jetzt nur mehr im ANR durchgeführt. Es war Absicht, dass das immer durchgeführt wird.
• Den Rest habe ich jetzt nicht gecheckt, du aber auch nicht, oder?

• generell schreiben wir hier nicht für den Parser, oder. Maximal gegen ihn. :-)
• Danke für den Hinweis auf den IE6, aber der ist wohl die Mühe nicht mehr wert.
• die vielen <nocinclude>-</nocinclude> hat auch einer hineingemacht, der genau wusste, wie die Boxen auszusehen haben. Ist auch gut wenn sie ein ebensolcher wieder wegnimmt.

Generell würde ich einen größeren Abstand zwischen Diskussion und Umsetzung für angebracht halten, Minuten scheinen mir da doch etwas wenig, mindestens 3 Tage bei so häufig verwendeten Boxen. Besser diskutierst du sowas überhaupt im Portal.

Ich mach das mal alles zurück, du kannst aber gerne in deinem BNR einen Vorschlag entwerfen, testen und zur Diskussion stellen. lg --Herzi Pinki 02:25, 8. Jan. 2012 (CET)

1. Die unicodespezifischen Pfeilchen habe ich übersehen und deshalb nicht einen neuen, sondern einen alten, aber besser handhabbaren Editor verwendet, in der Annahme, es seien nur Zeichen, welche er kapiert im entsprechenden Teil des Quelltextes.
2. Die Leerzeile ist leicht zu beheben.
3. Bilderhöhe
   1. Die Bilderhöhe ist zwar für Fotos m.E. bei Bergen eine naheliegende Anpassung, aber wenn das andere für diskussionswürdig halten, dann kann ich das auch tun.
   2. Die Poskarte kann auch bei Chile nicht größer sein als bei NNNNxMMMM der zweite, angegebene Wert. Ein Seitenrand ist hier aber nicht so tragisch. Chile ist sowieso ein geografischer Sonderfall. Da liegt es beim Positionskartensystem im Argen (benötigt m.E. eine Aufteilung).
4. Weitere Bilder gehören eigentlich gar nicht in die Box, sondern außerhalb, denn es ist doch nur Bequemlichkeit, wenn alle Bilder "in die Box geklatscht" werden, nur weil man keine Lust hat, sich eine gute Platzierung zu überlegen. Aber das ist wirklich eine ausgiebig zu diskutierende Frage.
5. Parsererror habe ich bei meinem Stichprobenaufruf (ca 10 Seiten) nicht entdeckt, aber das ist auch reparierbar
6. Der Ausschluss anderer NRs ist nur ein umhüllendes If, das wäre auch änderbar.
7. Doch, wir schreiben hier immer unter der Prämisse, dass der Parser mit allem was anfällt klarkommt. Häufig eingebundene Vorlagen müssen(!) vom Parser möglichst schnell verarbeitet werden, denn das ist für die Serverlast erheblich. Aufwendig zu parsende Einbindungen sorgen im erheblichen Maße für das häufige Schneckentempo hier.
8. Wer viele Noinclude einbaut, hat nicht verstanden, worauf es beim Erstellen einer derartigen Vorlage auch ankommt: Übersicht über den Quelltext, auch für Andere und Geschwindigkeit beim Parsen. Es ist daher nicht anzunehmen, dass ein solcher User das wieder entfernt. Auch die vielen Noinclude bremsen den Server.
9. Das Portal kannte ich noch gar nicht. Werde mich mal dort melden.

ÅñŧóñŜûŝî (Ð) 13:55, 8. Jan. 2012 (CET)

Ich weiß schon, dass das alles kein Drama ist, ich hätte es auch beheben können. Habe ich dann auch, auf die einfache Variante, es war schon spät. Warum kann man Fixes nicht auf konkrete Probleme beschränken? Wo sind deine Messungen, die das Performanceproblem nahelegen? Das Grundproblem sprichst du nicht an, es kann nicht sein, dass Änderungsankündigung und Änderung gleichzeitig erfolgen, nicht bei häufig verwendeten Vorlagen. Und was dazu passt, ein Wort der Entschuldigung für dein funktionsgleich kommt dir auch nicht über die Finger. lg --Herzi Pinki 14:05, 8. Jan. 2012 (CET)

Und es geht nicht darum, die Poskarte bei Chile noch größer zu machen, sondern wieder auf das kleinere abgestimmte Maß zurück. Die Karte kann man doch sowieso nicht sinnvoll anzeigen, wie du oben schreibst, trotzdem hilft ein roter Klecks auf der Karte, ein Gefühl für die Lage zu bekommen. Mehr können Poskarten ohnehin nicht leisten. Zu weitern Bildern, die Anzahl der Bilder wird per Wartungskat. überwacht, insoferne auch gelegentlich reduziert. Es gibt nur ganz wenige, die mehrere Bilder drinnen haben. Aber die Disk ist müßig, es geht um die max. Höhe der Bilder, die nicht geändert werden sollte. Was die noincludes angeht, hast du meine feine Spitze nicht verstanden. :-) lg --Herzi Pinki 14:14, 8. Jan. 2012 (CET)

Lieber Antonsusi, ich würde Dich bitten, sachlich zu bleiben ("Wer viele Noinclude einbaut,....") und Änderungen an der Vorlage nur mit Rücksprache und Einverständnis von HP vorzunehmen. Ich bin (offensichlich Im Ggs. zu Dir) davon überzeugt, dass HP die Vorlagenprogrammierung bestens beherrscht, denn er betreut die Vorlagen des Portals sein langer Zeit und die Portalmitarbeiter sind mit seiner Arbeit in diesem Zusammenhang mehr als zufrieden.--Cactus26 14:22, 8. Jan. 2012 (CET)

@Herzi Pinki: Ich habe doch zugegeben, dass ich Fehler eingebaut habe: Pfeile, Parserfehler, Leerzeile, Ausschluss anderer NRs. Meine Entschuldigung war insoweit indirekt. Die von mir beabsichtigte funktionsgleiche Vereinfachung ist eindeutig erstrebenswert, auch wenn mir das nicht ganz gelungen ist. Ich habe allerdings hervorgehoben, dass einige Fehler (Pfeile, Leerzeile, andere NRs) leicht behebbar sind. Das Thema Bildhöhe ist Geschmackssache und daher in der Tat diskussionswürdig. Da erscheint es mir wenig sinnvoll, wenn ein Hochformat hässliche Seitenränder generiert, was bei Bildern von Bergen häufig sein dürfte. Bei der Karte und den weiteren Bildern ist das nicht so dominierend.

@Cactus26: Da wundert es mich aber, dass er den Quelltext so unnötig komplex gelassen hat. Er sollte ihn selbst vereinfachen. Insbesondere folgende Änderungen wären gut:

• Die Noincludes wegnehmen. Aha, bereits erledigt, Danke.
• Die inneren Includeonly um die Wartungslinks durch eine Abfrage des Namensraums (Kein Link im VNR) ersetzen und die ganze Box per umfassendem Includeonly verstecken.
• Im Gegenzug die Darstellung auf der Dokuseite verbessern.
• Die Verschachtelung mit den Höhenkategorien durch ein #switch ersetzen und hinter die Tabelle verschieben. "Das macht dem Parser besonders viel Freude ..."
• Wartungslinks sollten möglichst auch am Ende stehen, so z.B. der Check auf falsche Tausenderpunkte. Wenn ein "Else-Zweig" nur wegen eines Wartungslinks existiert, dann kann man ihn oft auch weglassen und stattdessen am Ende ein logisch umgekehrtes If platzieren, ohne dass der Parser mehr Arbeit hat. Besser lesbar ist der Quelltext dadurch allemal.

Ein paar auskommentierte Zeilenumbrüche würden den den Quelltext besser lesbar machen.

Gruß von ÅñŧóñŜûŝî (Ð) 15:15, 8. Jan. 2012 (CET)

dann geb ich dir mal indirekt Recht. Die von dir geänderte Dokuseite habe ich nicht angegriffen. Allerdings gibt es da jetzt einige überlappende Boxen … zum Rest: if it aint broke dont fix it. Aber die Vorlage ist relativ alt, natürlich ist auch alter code drinnen. Ist ja auch gut, wenn jemand wie du drüber schaut, aber mehr Behutsamkeit wäre halt angebracht. Komisch, das mit den Unicode Pfeilchen ist vor einiger Zeit auch Flominator passiert - auch ein erfahrener Programmierer.

Sonst gilt noch immer, dass die Serverlast das letzte Problem ist, um das es bei Vorlagen, die einmal pro Artikel eingesetzt werden, geht (dafür habe ich auch gerne den Banner ertragen). von #ifexist vielleicht mal abgesehen. Ausnahmen gestehe ich nur bei vielverwendeten Vorlagen a la Coordinate zu. Aber ich werde mir deine Anregungen mal ansehen. lg --Herzi Pinki 16:41, 8. Jan. 2012 (CET)

Es ist sowieso noch ein Syntaxfehler bei fehlendem Bild drin gewesen. Den habe ich jetzt mal - zumindest provisorisch - mit #switch repariert und dabei auch die ganze Box ausgeblendet, da sonst die Bild-Syntax auftaucht. Zumindest auf 20 aufgerufenen Seiten, in meinem BNR sowie bei V-Expandieren funktioniert es. Jetzt gibt es keine Überlappung mehr und wir brauchen nur noch ein besseres Beispiel auf der Dokuseite. Du kannst ja mal auf Benutzer:Antonsusi/Infobox Berg nachschauen, ob dir an meiner Version etwas zusagt. Besonders die Berechnung der Kategorien und die Wartungslinks am Ende solltest du dir mal anschauen. Bildhöhen etc. sind da bisher unverändert. ÅñŧóñŜûŝî (Ð) 17:11, 8. Jan. 2012 (CET)

Danke für die Fehlerkorrektur. --Herzi Pinki 22:13, 8. Jan. 2012 (CET)

Interwiki-Links funktionieren nicht mit aktueller Infobox Berg

Hallo, ich habe gerade festgestellt, dass die Interwiki-Links nicht mehr richtig dargestellt werden, wenn die obige Vorlage zu Infobox Berg verwendet wird.--Slimguy 20:48, 1. Feb. 2012 (CET)

Seite mit einem Beispiel ? ÅñŧóñŜûŝî (Ð) 21:30, 1. Feb. 2012 (CET)

Jetzt passt es wieder. seltsam. Nun ist mir aber etwas anderes aufgefallen: Expression Error in Artikel:Mount Rogers (British Columbia) - in der Infobox Berg wegen Dominanz/Dominanzbezug.--Slimguy 22:18, 1. Feb. 2012 (CET)

Das ist kein Problem dieser Vorlage, sondern es wird gerade (bzw. wurde heute schon ein paar mal) an den Servern herumgebastelt und eine Synchronisation der "Updating interwiki caches" durchgeführt. (warum auch immer) Dabei kommt es projektweit zu einigen 10min langen Ausfällen die von selber wieder verschwinden (sollten). Mehr hier.--wdwd 23:33, 1. Feb. 2012 (CET)

"Expression-Fehler: Unerwarteter Operator <"

Dieser Fehler tritt hier auf. Diskussion. Was kann die Ursache sein? --Daniel Mietchen 15:18, 6. Feb. 2012 (CET)

behoben. --Fomafix 20:53, 6. Feb. 2012 (CET)

Danke! --Daniel Mietchen 22:43, 8. Feb. 2012 (CET)

Bild nicht da-Hinweis in der Vorlage

Grüßt Euch! Ich finde es gut, dass dieser Hinweis im Artikel erscheint, aber im Buch oder der Druckversion macht sich das nicht gut. Da müßte der Hinweis rausgefiltert werden. Beispiel Paitchau. Schönen Gruß, --JPF just another user 18:36, 18. Feb. 2012 (CET)

Ich habe es gerade eingebaut. Leere deinen Browser-Cache und probiere es mal aus. Gruß, --Flominator 19:21, 18. Feb. 2012 (CET)

Klappt! Danke! --JPF just another user 22:07, 18. Feb. 2012 (CET)

macht bei mir eine leere Tabellenzeile, statt keiner (FF 11 auf OS X). lg --Herzi Pinki (Diskussion) 21:10, 8. Apr. 2012 (CEST)

Bitte schwarzes oder so dreieck

das rote dreieck ist auf den meist bräunlichen karten schwer zu erkennen und bei rot-grün ist es für viele gleich ganz weg. --88.77.190.111 03:35, 18. Mär. 2012 (CET)

erscheint mir plausibel, früher hatten wir weiße Karten, aber mit den grün-braunen Reliefkarten ist der Kontrast des Icons massiv reduziert worden. Werde mich drum kümmern. lg --Herzi Pinki (Diskussion) 21:38, 8. Apr. 2012 (CEST)

Besonderheiten

Bspw. bei Küppel, Stüppel oder Schomberg (Lennegebirge) wird der Parameter Besonderheiten Aussichtssturm nicht mehr korrekt wie gewohnt angezeigt. Oder ist das nur bei mir so? --84.178.49.152 17:35, 27. Jun. 2012 (CEST)

Meinst du die Zweispaltigkeit bei diesem Parameter ? Die habe ich in einspaltig umgeformt, weil da auch mal langer Text drin steht. Die Box wird dann aberwitzig lang, weil dabei - nur in der rechten Spalte (!) - 20 Worte auf ca. 15 Zeilen umgebrochen werden. Das war kaum noch lesbar. ÅñŧóñŜûŝî (Ð) 18:03, 27. Jun. 2012 (CEST)

Ja. Bei nur einem Eintrag wie in meinen Beispielen ist die Einspaltigkeit übertrieben und ungünstig, zumal nicht zentriert. Wenn es insgesamt mehr kurze Einträge gibt als lange wäre ich für eine Rückkehr zur Zweispaktigkeit. So viel ist durch die Einspaltigkeit doch auch gar nicht gewonnen. Ich find´s irritierend, wenn innerhalb einer Box die Spaltigkeit wechselt. --84.178.31.87 19:38, 27. Jun. 2012 (CEST)

Ich finde die einspaltige Umsetzung optisch wenig gelungen. Ggf. muss man sich bei den Besonderheiten halt kurz fassen. Daher mein Vorschlag: Zurück auf die alte Version.
Watzmann ^Disk. 20:06, 27. Jun. 2012 (CEST)

Besonderheiten

Der Monte Schlaraffenlandus ist ein besonders aktiver Vulkan, welcher alle 87,5 Minuten ausbricht und dabei Gold, Silber und Edelsteine in der Landschaft verteilt.

Test Spaltenbreiten
Höhe	4810 m (4792 m ohne Eiskappe)
Lage	Frankreich und Italien
Gebirge	Mont-Blanc-Gruppe
Dominanz	2812 km → Kjukjurtlju
Schartenhöhe	4697 m ↓ Beim Kubenasee
Koordinaten	45° 49′ 57″ N, 6° 51′ 52″ O45.83256.86430555555564810
Infobox Berg/Archiv/2 (Alpen)
Gestein	Granit
Erstbesteigung	8. August 1786, Jacques Balmat und Michel-Gabriel Paccard
Normalweg	Der Monte Schlaraffenlandus ist ein besonders aktiver Vulkan, welcher alle 87,5 Minuten ausbricht und dabei Gold, Silber und Edelsteine in der Landschaft verteilt.
Besonderheiten	Der Monte Schlaraffenlandus ist ein besonders aktiver Vulkan, welcher alle 87,5 Minuten ausbricht und dabei Gold, Silber und Edelsteine in der Landschaft verteilt.

f

pd3

pd5

Infos weglassen, damit es schöner aussieht ? Das ist die flasche Priorität. Die Box muss dem Zweck dienen, nicht umgekehrt. Da es Bedarf an längerem Text als Parameterwert gibt, braucht man bei diesem Parameter die ganze Boxenbreite, um überhaupt brauchbare Zeilenlängen zu erhalten. Eine Tabellenzeile wie z.B. rechts dargestellt, sieht total bescheuert aus und verschwendet links wertvollen Platz. Den Style der Zellen kann man ja noch anpassen, aber die vertikale Anordnung von Parametertitel und -inhalt ist dringend notwendig. ÅñŧóñŜûŝî (Ð) 20:44, 27. Jun. 2012 (CEST)

Wie wäre es mit »Speit Edelmetall und - steine«. Wenn es viel länger wird, gehört der Text nicht in die Infobox sondern in das Lemma.
Watzmann ^Disk. 06:16, 28. Jun. 2012 (CEST)

zustimmung. Langläufer (Diskussion) 12:11, 28. Jun. 2012 (CEST)

Eine vertikale Anordnung ist bereits ab einer vierten Zeile vorteilhaft. Diese kommen schnell zusammen (Bei meinen Browsereinstellungen im Beispiel rechts beginnt die 4. Zeile mit "aktiver"). Die vertikale Anordnung ist auch wirklich nicht ungewöhnlich oder "hässlich". Das gibt es bei mehreren Boxen, besonders bei einem Feld wie "Besonderheiten", "Anmerkungen" o.ä. Insgesamt ist die Ästhetik der durchgehenden Doppelspalte zu unwichtig, um auf die von mir genannten Vorteile zu verzichten. ÅñŧóñŜûŝî (Ð) 17:56, 28. Jun. 2012 (CEST)

In deiner Tabelle sind es bei mir 7 Zeilen, die vierte beginnt mit „welcher“.

Habe mir erlaubt, mal eine „echte“ Infobox Berg unter dein Beispiel zu montieren. Bei mir ist da die rechte Spalte deutlich breiter als bei dir, insofern erscheint mir deine Tabelle etwas - nennen wir es wohlwollend - geschönt. In der Infobox benötigt dein ultralanger Text in der rechten Spalte (unter „Normalweg“) bei mir 6 Zeilen, wobei in der 6. Zeile lediglich das Wort „verteilt“ steht. Wie dem auch sei, ich bleibe dabei - lange Texte gehören nicht in die Box. Vielleicht warten wir noch ein paar Tage und zählen dann mal, wie sich die Votes verteilen. Derzeit sehe ich ein 3:1 für ein Zurück auf die alte Version.

Als Anregung: Platz könnte man schaffen, wenn man in der linken Spalte den langen Text „Geographische Lage“ einfach durch „Koordinaten“ ersetzen würde.
Watzmann ^Disk. 19:01, 28. Jun. 2012 (CEST)

Das wäre sogar präziser, denn die "Lage" ist auch Geographisch. --Langläufer (Diskussion) 17:30, 29. Jun. 2012 (CEST)

Ich kann die Argumentation von Antonsusi nachvollziehen, finde aber, dass sie die Änderung der Infobox nicht rechtfertigt und bin da bei Watzmann. Wie viele Artikel haben denn unter Besonderheiten so viel Text? Bei denen mit wenig Text wirkt sich die Änderung negativ aus. IMHO dient die Infobox einem schnellen Überblick. Was sich da nicht stichwortartig und knapp zusammenfassen lässt, sondern langatmig ausformuliert werden muss, gehört nicht in die IB sondern in den Artikeltext. --Milseburg (Diskussion) 09:45, 30. Jun. 2012 (CEST)

ich erhöhe auf 4:1 zugunsten des alten Formats und mache rückgängig. Antonsusi findet es nicht mal der Mühe wert, ein Beispiel zu bringen, das Fantasiebeispiel ist definitiv nicht realitätsnah. lg --Herzi Pinki (Diskussion) 18:49, 10. Jul. 2012 (CEST)

Neuer Parameter: Touristische Erstbesteigung

Ich möchte die Einführung des Parameters Touristische Erstbesteigung anregen. Bei vielen Bergen (etwa besonders in den Nördlichen Kalkalpen) ist ihre Erstbesteigung auf Grund ihrer relativ einfachen Erreichbarkeit nicht dokumentiert, wohl aber ihre touristische Erstbesteigung. In solchen Fällen hat es sich es eingebürgert diese Daten dennoch in die Zeile Erstbesteigung einzufügen. Vielfach geschieht dies ohne jeglichen Zusatz (z.B. Habicht, Drei Schwestern und Birkkarspitze), sodass diese die verkürzte Darstellung zu einer Falschinformation führt. Dies ist meiner Meinung nach prinzipiell abzulehnen. Bei anderen Artikel werden die Eintragungen mit erklärenden Zusätzen versehen, die jedoch alles andere als einheitlich formatiert sind (z.B. äußerst lang Höchkönig, etwas kürzer Bosruck, noch kürzer Hoher Göll). Einen eigenen Parameter halte ich für die beste Lösung, da er am schnellsten und am prägnantesten diese Information präsentiert. -- Gurpitscheck (Diskussion) 17:41, 17. Jul. 2012 (CEST)

Länder-Kat Zuweisung

Bei einigen Bergen Neuseelands wird automatisch die Kategorie:Berg in Australien zugewiesen, obwohl der ISO-Code korrekt mit Region, z.B. NZ-TAS oder NZ-WGN, eingetragen ist. Wenn ich die Region entferne (also nur noch NZ), unterbleibt diese Zuordnung. Wo liegt der Fehler? --Sextant (Diskussion) 21:22, 27. Aug. 2012 (CEST)

Repariert ([1], [2]). --тнояsтеn ⇔ 14:34, 18. Okt. 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: тнояsтеn ⇔ 14:34, 18. Okt. 2012 (CEST)

Falscher Infotext Schartenhöhe.

Wenn ich über die Einheit m bei Schartenhöhe gehe, erhalte ich als Infotext Meter über Meeresspiegel. Das ist falsch! Die Schartenhöhe bezieht sich wie der Name schon sagt auf die Scharte und nicht auf den Meeresspiegel! --Langläufer (Diskussion) 11:24, 31. Jul. 2012 (CEST)

done --darkking3 ^Թ 08:49, 19. Okt. 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --darkking3 ^Թ 08:48, 19. Okt. 2012 (CEST)

Skalierung Positionskarte

Aufgrund der Restultate beim Einsatz der {{Infobox Gletscher}} würde ich auch bei dieser Infobox eine entsprechende Skalierung der Positionskarte vornehmen. Bei hochformatigen Positionskarten ergibt sich sonst eine unangebracht große Karte (vgl. Pösche-Berg und Monacobreen bzw. Nalumasortoq vs. Jakobshavn Isbræ.--Cactus26 (Diskussion) 16:09, 22. Feb. 2013 (CET)

umgesetzt, siehe [3].--Cactus26 (Diskussion) 12:06, 28. Feb. 2013 (CET)

Kein Lage-Fallback in Nebenbox

Beim Arbeiten an der Gletscher-IB, die ich ja aus der IB-Berg abgeleitet habe, ist mir beim Beispiel Schneeferner aufgefallen, dass es ungünstig ist, in Nebenboxen die Lage aus der Region-ISO abzuleiten, da man sie dort typischerweise nicht will. Vielleicht könnte man das in der IB-Berg analog ändern: [4].--Cactus26 (Diskussion) 09:32, 20. Dez. 2012 (CET)

umgesetzt, siehe [5].--Cactus26 (Diskussion) 12:06, 28. Feb. 2013 (CET)

Hallo Cactus, hab's übersehen, sorry, bin zu stark mit den Denkmälen beschäftigt. Beides hat sein für und wieder. Die Lage muss ja in der NEBENBOX nicht gleich zur Hauptbox sein und insoferne ist die Lage auch in der NEBENBOX eine wichtige Info. So muss sie halt händisch eingetragen werden. Was war der Grund, dass du den Vorlage:Infobox Berg/Wartung/Lage fehlt aber Region-Wartungslink gleich mitentsorgt hast? lg --Herzi Pinki (Diskussion) 00:07, 10. Mär. 2013 (CET)

Spaltenpräfix für Koordinaten ("Geografische Lage" ändern in "Koordinaten")

Auf Initiative von Benutzer:Watzmann habe ich für die {{Infobox Gletscher}} den Text entspr. umgestellt. Ich schlage vor, hier ebenfalls das Spaltenpräfix entspr. zu setzen (analog zu {{Infobox Pass}}, {{Infobox Gebirgsgruppe}}, {{Infobox Naturraum in Deutschland}}, ...).--Cactus26 (Diskussion) 13:45, 8. Mär. 2013 (CET)

ok --Herzi Pinki (Diskussion) 00:23, 10. Mär. 2013 (CET)

danke für die Rückmeldung. Habe es umgesetzt.--Cactus26 (Diskussion) 07:47, 11. Mär. 2013 (CET)

Genauigkeit Höhe

In der Beschreibung steht für den Wert der Höhe: Angaben mit Nachkommastellen dürfen nicht erlolgen. Diese Werte sind auf den nächsten ganzzahligen Wert zu runden. Ein genauerer Wert kann im Fließtext erwähnt werden.

Gibt es dafür eine besondere Begründung, die technischer Art ist? Offenbar werden aber Angaben mit Nachkommastellen korrekt angezeigt. Falls das weiterhin nicht zulässig sein sollte, soll dabei immer abgerundet, aufgerundet oder kaufmännisch gerundet werden? Besten Dank für eine Auskunft! --Comanderkeen (Diskussion) 13:44, 8. Nov. 2012 (CET)

Ich kenne jetzt zwar nicht die ursprünglichen Überlegungen, die zu dieser Richtlinie geführt haben, aber ich denke mal, der Grund auf Nachkommastellen zu verzichten, ist einfach der, dass man die Höhe von Bergen meist nicht auf Zentimeter genau messen kann. Zum einen hat das mit der Oberfläche des Berges zu tun (Eiskappe, hügelige Waldlandschaft oä.) zum anderen kommen vor allem in höheren Gebirgen auch vermessungstechnische Probleme bei der Bestimmung der Bezugsfläche (des Geoids) ins Spiel. Sollte eine Quelle trotzdem die Höhe bis auf Dezimeter oder gar Zentimeter angeben, ist das mE. nur eine vorgespiegelte Scheingenauigkeit. Abrunden dann natürlich einfach kaufmännisch. --alexrk (Diskussion) 17:17, 1. Dez. 2012 (CET)

Hallo Alexrk2, ich hatte bereits eine längere und sehr interessante und aufschlußreiche Diskussion mit einem langjährigen WP-Mitarbeiter, der diese Regelung initiiert hatte. Und auch genau da ging es in die gleiche Kerbe, wie Du sie ansprichst: Höhere Berge (Himalaya, Anden, Alpen), Schnee, Eis, ect. wo man eben halt nicht mit einem Präzisionsnivellement hinkommt. Und aus dieser Erfahrung heraus einigte man sich auf die Metergenauigkeit. Aus meiner Sicht machte man dabei allerdings den kapitalen Fehler, diese Einschränkung auf alle Berge und Höhen zu extrapolieren und ignorierte man, daß es sowohl möglich ist, Berge, Kuppen, oder andere Höhen mit einem Schleifennivellement exakt auszumessen. Im ganzen Ing.-Wesen ist das gängig, um z.B. Bauwerke zu erfassen und Setzungen zu überprüfen, z.B. Dämme. Ich bilde mir aus meinen 2 Semestern Geodäsie für dumme Ing. wie mich aber nichts ein, über die Genauigkeit von Höhenangaben im Hochgebirge kann ich deshalb dazu nichts sagen. Aber wenn irgendwo ein Höhenfestpunkt in ein Bauwerk/Felsen, ect. auf einer Bergkuppe (oder woanders) angebracht worden ist und die Höhe durch ein Präzisionsnivellement bestimmt wurde, dann stimmen die Millimeter für diesen Punkt. (Unter der Prämisse, daß diese Messung fachlich ok ist). Beispiele:

http://www.bezreg-koeln.nrw.de/brk_internet/organisation/abteilung07/produkte/raumbezug/festpunktdaten/hoehenfestpunkte/index.html

https://www.geobasis-bb.de/geodaten/hoefepu.htm Diese Punkte sind exakt kartographiert und können in Datenbanken nachgeschlagen werden. Dort stehen für Deutschland dann die Genauigkeiten auf den Millimeter in NHN drin, inkl. einer Abweichung. Mich würde die Reaktion eines Vermessungsing. interessieren, wenn man ihn vorwerfen würde, daß sein Messteam nur eine vorgespiegelte Scheingenauigkeit ermittelt hat, seine Millimeter, gar Zentimeter oder gar Dezimeter nicht genau sein können. Nebenbei: Das bayerische Landesamt hat es offenbar geschafft für die Zugspitze einen Punkt auf den Zentimeter genau zu bestimmen. Sind das Spinner?

Deshalb wäre jede Rundung für diesen Punkt auf den Meter genau eine fatale Interpretation für die WP, da dabei um bis zu einem halben Meter gerundet werden müsste. Nennt man das in der WP nicht Theoriefindung? Die Richtlinien sind deshalb aus meiner Einschätzung fatal, wenn ich nicht für einen Hügel oder Bergkuppe irgendwo in Deutschland nicht den Dezimeter genau angeben darf, der höchstwahrscheinlich sogar auf den Zentimeter genau bestimmt wurde und ich mit einem revert rechnen muß, weil die Regel für die Infobox Berg das so besagt und eine größere Genauigkeit nicht erlaubt. Irgendwann werde ich deshalb den Antrag hier in der WP stellen, dieses "Muß" auf "sollen" umzustellen (oder so ähnlich). Im Moment habe ich dazu keine Lust, ein Vermesser auf einer Baustelle lachte mich schon deshalb aus und fragte mich, warum ich mir überhaupt solche Mühe für die WP machen würde. Recht hat er eigentlich... Vielen Dank für Deinen Kommentar! --Comanderkeen (Diskussion) 19:44, 1. Dez. 2012 (CET)

Noch ein paar Gedanken dazu von mir. Ich hatte darüber schon einmal eine Diskussion, finde sie aber nicht wieder. Das Fazit daraus war in etwa: Man kann die Höhe eines Messpunktes millimetergenau bestimmen, aber fraglich ist, ob sich der Messpunkt auch tatsächlich am höchsten Punkt eines Berges befindet. Gerade auf breiten Mittelgebirgsgipfeln habe ich Messpunkte schon irgendwo im Gipfelbereich entdeckt, aber nicht am tatsächlich höchsten Punkt. Dieser ist ja auch durch kleinere Erdbewegungen im Dezimeterbereich (Windwurf, etc...) variabel. Im Dezimeterbereich könnte ich ja sogar mit bloßen Händen was verändern. Fester Fels liegt ja dort immer unter einer mehr oder weniger dicken Erdschicht verborgen, die fortwährend Veränderungen unterzogen ist. Höchste Punkte sind oft auch lose herumliegende Steine und Felsen. Die Frage "Was gilt als höchste Punkt?" lässt sich also gar nicht mit solcher Genauigkeit und Beständigkeit beantworten wie sich messen ließe. Das spricht gegen die Angabe von Nachkommastellen. --Milseburg (Diskussion) 23:49, 1. Dez. 2012 (CET)

Du solltest bitte den Aspekt nicht vernachlässigen, daß auch der umgekehrte Fall eintritt. Es liegt ein Höhenfestpunkt vor, der an einem Turm (oder ähnliches) angebracht ist und durchaus dann einige Zentimeter höher sein könnte. Aber Du hast schön beschrieben, daß es keinen Sinn macht irgendwo im Dreck seine Nivelierlatte nach Augenmaß aufzustellen und zu sagen: Das ist der höchste Punkt. Aus diesem Grund nimmt man Festpunkte, die die Kriterien wie z.B. Setzungssicherheit erfüllen. Das machen auch nicht irgendwelche Wald- und Wiesenvermesser, sondern wir reden in Deutschland von amtlich, durchgeführten Messungen. Jede Rundung wäre somit eine Interpretation. Beispiel: Ein FP hat die Höhe von 1256.639 m NHN. Dieser FP sei sogar an einem Turm angebracht, der ggf. sogar etwas höher liegt, als das Niveau der umliegenden Bergwiese, Geröll, ect. Es wurde ganz oben in der Disk selbstverständlich postuliert, daß kaufmännisch gerundet werden soll. Damit wäre laut Regularien die Angabe in der WP sogar noch höher, als die Wirklichkeit: 1257 m. Das ist ein gängiges Beispiel, daß eine kaufmännische Rundung das Gegenteil bewirken kann. Willst Du also bei Deiner wertvollen Arbeit für die WP für jeden Einzelfall den Berg besteigen, die amtlichen Angaben vor Ort nach Augenmaß auf, bzw. abrunden? Wenn also die WP meint, amtliche Messergebnisse könne sie ignorieren, begibt sich sich nicht nur Glatteis, denn das führt auch dazu, daß nicht amtliche, beinahe willkürlich gerundete Werte für die Allgemeinheit als enzyklopädisches Wissen verkauft werden. --Comanderkeen (Diskussion) 12:51, 2. Dez. 2012 (CET)

In topografischen Karten ist eine Nachkommastelle, also eine Genauigkeit im Dezimeterbereich üblich. Daran sollten wir uns auch halten. --Rolf-Dresden (Diskussion) 08:03, 2. Dez. 2012 (CET)

Geht es um die Höhe von Messpunkten oder um die von Bergen? Das in den Karten sind Messpunkte irgendwo auf Bergen. --79.216.218.67 09:37, 2. Dez. 2012 (CET)

Wenn du belegte Daten einfügen willst, kannst du nur die offiziellen Meßpunkte verwenden. Zudem gibts genügend Berge, die keinen höchsten Punkt mehr haben, ganz einfach weil da eine Überbauung mit einem Aussichtsturm, einer Bergbaude oder einer militärischen Anlage stattgefunden hat. Wo willst du da messen? Auf der Aussichtsplattform? --Rolf-Dresden (Diskussion) 09:45, 2. Dez. 2012 (CET)

Eben, deshalb ist die Dezimetergenauigkeit ja Pseudogenauigkeit. --79.216.223.17 12:38, 2. Dez. 2012 (CET)

Siehe dazu auch:

• Benutzer_Diskussion:Herzi Pinki#Genauigkeit Höhenangaben bei Infobox Berg
• Portal Diskussion:Berge und Gebirge/Archiv/2010#(sinnvolle) Genauigkeit von Höhenangaben

Ich selbst habe da derzeit keine Eisen im Feuer. Ob ich am Ende zehn Zentimeter mehr oder weniger gestiegen bin, um einen Berggipfel zu erreichen, ist mir letztendlich wurscht. Ich habe aber den Eindruck, dass Comanderkeen durchaus gute Beweggründe für eine Änderung der Praxis hat.
Watzmann ^Disk. 11:43, 2. Dez. 2012 (CET)

Fichtelberghaus, die Höhenangabe bezieht sich auf die eine Gebäudeecke

Ob man nun die Messung auf einen Höhenbolzen oder irgendwo in der Landschaft aufsetzt, ist letztlich dasselbe Problem. Denn den Höhenbolzen musst Du ja auch wiederum irgendwo anbringen - da stellt sich die gleiche Frage: wo? Der gesunde Menschenverstand sagt einem doch, dass man einen natürlichen Geländepunkt maximal auf 10-50 cm genau einmessen kann. Wenn auf der Kuppe eine feste, ebene Schotterschicht liegt, geht es vielleicht auch im Dezimeterbereich, aber normalerweise, wenn sich dort eine Wiese, Waldfläche oder Geröllfeld befindet, logischerweise weitaus weniger genau.

• Beispiel Brocken: Siehe diese Geschichte. Da hatte man die Höhe erst fälschlicherweise lange Zeit auf die Oberkante eines uralten Granit-Meßpfeiler bezogen, ohne es zu wissen und musste später wieder einen Meter abziehen. Auch der große Granitblock, den man dann dort hingelegt hat, ändert daran nichts. Und jetzt kommt das Lustigste: in den verschiedenen amtlichen TK's hat der Brocken ebenfalls leicht unterschiedliche Höhen: 1140,7 1141,2 1140,9 ...da sieht man ja schon, was es mit der Belegbarkeit auf sicht hat. Ich kann mir das nur so erklären, dass man für die verschiedenen Karten, verschiedene Geländepunkte aufgenommen hat.

Man sollte auch die Meßhistorie berücksichtigen. Wenn nach dem Rückzuck des Millitärs einige Dinge zerstört wurden, die Kuppe abgetragen wurden, ect. Und man sollte überprüfen, ob die Angaben über SNN76, DHHN85 oder DHHN92 sind. In der Infobox kann man sehr wohl auch die Quelle mit Datum angeben und bei Strittigkeiten ein gesondertes Kapitel dazu erstellen.

• Beispiel Fichtelberg: hier wird im Artikel mit stolzer Vermesserbrust eine Höhe von "1214,79" angegeben. Also da geht die Genauigkeitsversessenheit doch wirklich über alle Tische und Bänke. Die Messung bezog sich wohlgemerkt auf eine Gebäudeecke des Hotel Fichtelberghaus! So ist es auch auf der amtlichen TK eingezeichnet. Natürlich kann man auf dieser betonierten Oberkante bis auf den Millimeter die Messlatte aufsetzen. Aber was hat man denn da gemessen? Eben nur die Höhe dieser überbauten künstlichen Fläche, nicht die eigentliche "Höhe des Fichtelberges" (ohne menschengemachte Bebauung oder Fundamente)

Ich habe es oben bereits erklärt. Es macht keinen Sinn seine Latte irgendwo in das Gelände zu setzen, man braucht definierte Festpunkte. Diese sind z.B. gegründete Bodenfestpunkte oder Höhenbolzen.

Was lernen wir daraus? Erstens fehlt mir eine Definition, wie sich genau die Höhe eines Berges bemisst. Also eine Eiskappe zählt da sicher nicht dazu. Aber wie steht es mit küstlichen Aufbauten, Asphaltschichten, Fundamente etc.? Zweitens bezeichnen die Höhenpunkte in einer TK immer einzeln aufgemessene Geländepunkte, die eben immer nur eine Einzelaufnahme darstellen aber nicht die exakte Höhe des Berges beziffern können. Wird ein zweiter Vermesser unabhängig eine Woche später das Experiment wiederholen, wird er ganz sicher einen anderen markanten Geländepunkt auswählen, der sich dann je nach Oberflächenbeschaffenheit um wenige Zentimeter bis mehrere Dezimeter von der vorherigen Messung unterscheidet. --alexrk (Diskussion) 14:57, 2. Dez. 2012 (CET)

Ein Vermesser wird sich immer auf kartographierte Festpunkte beziehen. Er wird nicht einen beliebigen markanten Geländepunkt dafür nehmen, das ist doch eine Unterstellung. Macht Euch doch bitte einmal schlau, wie ein Präzisionsnivellement gemacht wird und daß man einen Schleifenendpunkt nicht beliebig in den Sand setzt. Die Definition habe ich Dir indirekt schon gegeben: Man findet oder fand geeignete Punkte, um dort z.B. einen Höhenbolzen oder anderen Punkt zu setzen. Im Laufe der Geschichte (Brocken) muß das ggf. wiederholt werden und damit sind in der Historie auch verschiedene Werte vorhanden und somit in den Karten verzeichnet. Vielleicht gibt es auch im Laufe der Zeit geologische Veränderungen. Evt. ändert sich mit der Zeit auch das Höhenbezugssystem. Diese Punkte sind sorgfältig mit Datum kartographiert und bei den Vermessungsämtern in den Datenbank gespeicher und jederzeit abrufbar. Diese Meßergebnisse dienen als Grundlage der Karten. Irgendwelche anderen Phantasiewerte zu nehmen, weil ja da irgendwo eine Grasmulde gewachsen ist, oder Geröll abhanden gekommen ist, im Glauben das sei der höchste Punkt ist reine Kaffeesatzlesere. Diese amtlichen Werte sind somit die einzige, brauchbare Quelle. Und was passieren kann, wenn man meint auf den Meter runden zu müssen, habe ich bereits erörtert--Comanderkeen (Diskussion) 16:48, 2. Dez. 2012 (CET)

Volle Zustimmung mit einer Ausnahme: Eiskappen bzw. Firnbedeckungen werden üblicherweise sehr wohl mitgezählt, ganz einfach weil die Höhe des darunter liegenden Gesteins gar nicht bekannt ist und sich dort ev. sogar überhaupt kein Gipfel befindet. Siehe dazu z.B. auch Mont Blanc, der höchste Felspunkt unter dem Eis befindet sich deutlich vom höchsten und überall als Gipfel eingezeichneten Firngipfel entfernt, der MB ist einer der Ausnahmefälle wo man das vermessen hat, aber irgendwo am Grönländischen Eisschild z.B. sind diese Werte völlig unbekannt.

Beim üblichen Fall (wie z.B. Fichtelberg) ist die zentimetergenaue Angabe zwar keine TF, aber halt irreführend, weil der OMA-Leser die Höhe des Berges und nicht eines Gebäudeecks sucht. In diesem Sinne müsste man dann konsequenterweise in der IB den Parameter "Höhe" durch "Höhe des Vermessungspunktes am Gipfel" ersetzen ;-) --Svíčková na smetaně 16:15, 2. Dez. 2012 (CET)

Reinquetsch:Der Höhenbolzen befindet sich üblicherweise an einem Gebäude/Topographischen Punkt, aber das ist nur der Bezugspunkt für die Vermessung, auch für den "höchsten Punkt". --Alma (Diskussion) 08:46, 14. Dez. 2012 (CET)

Ich war bzgl des Eiskappenproblems vom Mt. Everest ausgegangen, siehe Mount Everest, Höhenangaben und -messungen. Da wurde mittels Radarmessung auch die Dicke bis zum Felsgrund ermittelt, da diese wohl je nach Jahreszeit auch um mehrere Meter schwankt. Im antarktischen oder grönländischen Eisschild mag das vielleicht wieder anders aussehen. Wobei dort vermutlich zumindest die höchsten Berge auch alle aus dem Eisschild emporragen. --alexrk (Diskussion) 16:46, 2. Dez. 2012 (CET)

Macht aus einer Mücke keinen Elefanten. Wenn man nur eine dezimetergenaue Quelle hat, muss man deren Angabe übernehmen. Da sollte man nichts runden. Hat man alternativ auch eine metergenaue Quelle zu Hand, würde ich deren Angabe den Vorzug geben. Die gängigen amtlichen Onlineviewer bieten ja beides an und beides findet auch in den Infoboxen Verwendung, ohne dass es groß zu stören scheint. Da es sowieso seit Längerem nicht konsequent praktiziert wird, kann der Passus «Angaben mit Nachkommastellen dürfen nicht erlolgen. Diese Werte sind auf den nächsten ganzzahligen Wert zu runden», auch aus der Vorlage raus. Aktionen, bei denen jetzt überall Nachkommastellen eingetragen werden, weil jemand denkt, er hätte die bessere Quelle, hielte ich für übertriebene Kleinigkeitskrämerei, Zeitverschwendung und Verumständlichung. Niemand will Phantasiewerte nehmen, und die Genauigkeit der Messungen steht auch außer Frage. Da hier Veränderungen auf dem Gipfel nicht berücksichtigt werden oder gar nicht so genau klar ist, was als höchster Punkt gelten soll, sind die Zahlen auf die tatsächliche Höhe des Berges bezogen gar nicht so genau wie sie aussehen, und müssen IMHO auch nicht so genau angegeben werden. --Milseburg (Diskussion)

Hallo mitsammen, dachte immer ich hätte das mit den ganzen Metern geschrieben, weit gefehlt. Der technische Grund dahinter ist, dass die Vorlage {{Coordinate}} tatsächlich Meter will und das auch so bleiben sollte, die Höhe wird an die Coordinaten weitergereicht (bin mir zu 98 % sicher). Das ließe sich aber beheben, wenn der auf ganze Meter gerundete Wert an die Coordinate weitergereicht wird. Keine Hexerei. Dann kann jeder wieder nach Lust und Laune und Quelle die Höhe auf Meter, auf Zentimeter oder auf galaktische Genauigkeit eintragen. Was haltet ihr davon? Die konkreten Werte sind mE eh wurscht, aber es ist doch schön, wenn man sie hinschreiben kann. Ob der Höhenbolzen sich jetzt in Augenhöhe befindet, tut nichts zur Sache, weil der die amtliche Höhe angibt (und was anderes werden wir in den Karten nicht finden). Zusätzlich bekommt die Infobox Berg einen Parameter, mit dem die Quelle für Höhenwert und -bezug angegeben werden kann. Dies kann auch ein deep-Link in eine Karte, auf den entsprechenden Punkt sein, aber kein Link auf die Einstiegsseite eines GIS-Anbieters. Was meint ihr? Wer Zentimeter eintragen will, soll Zentimeter eintragen. Weiß jemand, ob eruierbar ist, welche Höhenkoten durch einen Fixpunkt und Schleifennivellement ermittelt wurden und welche Werte durch herkömmliche Triangulation? Ist das aus den Karten zu lesen? lg --Herzi Pinki (Diskussion) 23:53, 9. Mär. 2013 (CET)

Im deutschen DGM25 (siehe AX_MarkanterGelaendepunkt) kann man theoretich die Metadaten auch zu den (in der TK verzeichneten) markanten Geländepunkten abfragen. Dort steht neben der Genauigkeit auch die Messmethode (also terrestrische Vermessung, Laserscanning, photogrammetrische Datenerfassung oä). - Höhenfestpunkte und Lagepunkte sind wie bereits ausgeführt ein anderes Thema. Heute dürfte der Großteil der DGM-Informationen aus Laserscanning (also Befliegungen) abgeleitet sein. Ist aber letztlich auch relativ Schnuppe, da aus besagten Gründen die markanten Geländepunkte eben naturgegeben maximal auf Dezimeter bestimmbar sind. So steht dann in der TK auch nur eine Angabe wahlweise im Meter- oder Dezimeterbereich. Also genauer geht's eh nicht, bzw es macht keinen Sinn. Man kann auch nicht die Fläche des Atlantiks bis auf den Quadratzentimeter genau angeben. Ich sehe ein, dass das ein generelles Problem in der Wikipedia ist, dass in weiten Teilen der Sinn für realistische Genauigkeiten im Umgang mit Zahlen fehlt. Und ich sehe ein, dass man dies auch nicht durch Vorlagenbeschränkungen erzwingen können wird. Von daher ist es in der Tat auch egal. Gesunden Menschenverstand kann man nicht erzwingen. --alexrk (Diskussion) 00:38, 10. Mär. 2013 (CET)

Hallo, die Änderung der Doku die #herzi pinki beschrieben hat habe ich damals gemacht. Es war und ist (teilweise) so, dass Artikel mit Höhenangaben im Dezimalbereich in der Kategorie:Wikipedia:Koordinaten-Parameterfehler eingetragen sind. Es sind seit meiner Änderung der Doku umfangreiche Änderungen an der Infobox vorgenommen worden, auch in Bezug auf die Höhenberechnung. Im Artikel Schilthorn habe ich in der Vorschau als Höhe mal 99.270 eingeben - führte zu keinem Eintrag in der Kategorie, eine Höhe von 99.273 hingegen schon. Siehe auch →Linkliste:Eventuell ungültige Höhenangabe. Woran das liegt kann ich nicht sagen, da seit Dezember 2011 34 Änderungen vorgenommen wurden und ich von Vorlagenprogrammierung nur wenig verstehe. In der Vorlagenwerkstatt könnte das Problem sicher behoben werden. Wozu die Vorlage:Coordinate allerdings die Höhe (ohne Dezimalwert) gebraucht kann ich nicht sagen. Das wäre sicher eine Frage die bei WP:GEO zu stellen wäre. Vor einer Änderung dieser Vorlage um einen Eintrag in der Wartungskategorie Koordinaten-Parameterfehler auszublenden, sollte mMg nach dort vorher gefragt werden. Grüße --Knochen ﱢﻝﱢ‎  20:04, 10. Mär. 2013 (CET)

Danke für den Senf, Knochen. Hab zwar jetzt den Code nicht gefunden, kann mich aber dunkel erinnern, es wird langsam heller, dass die elevation bei {{Coordinate}} max zwei Nachkommastellen zulässt (also nicht wie oben keine Nachkommastelle) und ich habe das jetzt auch schnell ausprobiert. Die Beschränkung auf zwei Nachkommastellen entstand damals in der Abwägung zwischen einer Genauigkeitsanforderung, die so nicht für soooooo wichtig gesehen wurde (auf mm), und dem sicheren Erkennen von Dezimalpunkt- und Tausenderpunktfehlern: 1.234 mit falschem Tausenderpunkt (gemeint 1234 m) ist ein wahrscheinlicherer Wert als 1.234 mit richtigem Dezimalpunkt (gemeint 1,234 m). Da die {{Coordinate}} zwei Dezimalstellen ohne Fehlermeldung akzeptiert, und eine darüberhinausgehende Genauigkeit derzeit noch nicht gefordert ist (aber warten wir mal noch 5 Jahre) muss an der Infobox nichts gedreht werden, sondern nur die Doku angepasst werden. Aus der aktuellen Beschreibung für den Parameter HÖHE
Höhenangaben als Zahl ohne Tausendertrenner, also z. B. 4321. Die Formatierung mit Tausendertrenner, also 4.321 erfolgt über die Vorlage selbst. Angaben mit Nachkommastellen dürfen nicht erlolgen. Diese Werte sind auf den nächsten ganzzahligen Wert zu runden. Ein genauerer Wert kann im Fließtext erwähnt werden.
wird dann (gleich ein paar andere Sachen mit erledigt):
Höhenangaben als Zahl ohne Tausendertrenner, also z.B. 4321. Dezimaltrenner ist der Punkt (z.B. 220.5). Die Formatierung erfolgt über die Vorlage selbst. Falls das als Quelle benutzte Kartenwerk Höhen im Dezi- oder Zentimeterbereich angibt, so sollen diese Werte 1:1 übernommen werden. Das Kartenwerk ist möglichst nachvollziehbar als Quelle anzugeben. Gibt es widersprüchliche Angaben in unterschiedlichen Kartenwerken, so ist das im Fließtext abzuhandeln. In der Infobox steht dann der neuere Wert, so dieser nicht nachweisbar strittig ist. Grundlage sind immer amtliche Kartenwerke, private Höhenmessungen sind unzulässig, sollte diese mangels anderer Messungen herangezogen werden, so sind sie immer auf Meter zu runden. Das gleiche gilt bei Umrechnungen aus nicht metrischen Systemen.
Zufrieden? --Herzi Pinki (Diskussion) 23:10, 10. Mär. 2013 (CET)

Die Diskussion hier (tut mir leid, gelesen habe ich nicht alles) ist doch nicht ernst gemeint? Ich empfinde Höhen, die auf einen Meter genau angegeben sind, schon als lächerlich. Berge sind Natur und Natur ist nichts Statisches. Die wenigsten Berge haben eine markante Felsnadel als Spitze, die man entsprechend genau vermessen könnte, und selbst solche Felsen bröckeln. Meine Meinung: In der Infobox einheitlich in Metern. Eine genauere Zahl kann im Text angegeben werden, aber auch nur dann, wenn sich das eindeutig belegen lässt und allgemeinverständlich erklärt wird, was für ein Punkt damit gemeint ist. In der Infobox wäre dafür gar kein Platz. --TMg 01:30, 11. Mär. 2013 (CET)

Da wir selten einer Meinung sind, melde ich mich hier mal zu Wort. Auch ich muss gestehen, die Disk. nur überflogen zu haben. Ein Beispiel, das mir in diesem Zusammenhang einfällt ist der Mönch. Dort war eine Höhe von 4099 jahrelang Gesetz. Man hat sich dort offensichtlich nicht nur um ein paar cm vertan, und die Ausrede mit der Firnkuppe kann ich hier nicht so ganz glauben. Und das bei den präzisen Schweizern, bei einem alles anderen als unbekannten Berg, direkt neben dem nicht gerade unerschlossenen Jungfraujoch... --Cactus26 (Diskussion) 07:32, 11. Mär. 2013 (CET)

ich habe die Diskussion eher satt, danke dass ich euch mit meinem Statement aus der Reserve gelockt habe :-) Primär klärt mein Statement die technischen Fragen, die Entscheidung welche Genauigkeit wir wollen, ist vmtl. eine politische Frage, wie mir aber scheint nicht abstimmungsgeeignet. Allerdings sind Fehlmessungen wie beim Mönch kein Gegenargument, die sind ja auch mit bestem Wissen und Gewissen gemacht worden, auch wohl mit Angabe eines Fehlerintervalls, dass sicher nicht ±8m groß war. Mir scheint dass sich die gewünschte Genauigkeit indirekt proportional zur Höhe der Berge in der Gegend verhält, dort wo es keine Berge gibt, also die Genauigkeitsansprüche am ausgeprägtesten sind. lg --Herzi Pinki (Diskussion) 20:25, 11. Mär. 2013 (CET)

Dass im eher flacheren Land die Zentimeter wichtiger werden, ist eine Beobachtung, die sich mit meiner Erfahrung deckt. Beim Schönbuch habe ich auch aufgegeben, mich gegen eine Nachkommastelle zu wehren. Wobei ich bis heute nicht weiß, wo und wie bei einem bewaldeten Bergrücken eigentlich gemessen wird, zählen Ameisenhaufen eigentlich mit? Ich kenne das Bromberggebiet recht gut und weiß bis heute auch nicht, wo bei diesem riesiges bewaldeten Hochplateau genau der höchste Punkt ist.--Cactus26 (Diskussion) 07:07, 12. Mär. 2013 (CET)

Zurück zur fraglichen Textstelle: «Angaben mit Nachkommastellen dürfen nicht erlolgen. Diese Werte sind auf den nächsten ganzzahligen Wert zu runden.» Wir wissen jetzt, dass dieser Passus aus einem technischen Grund geschrieben wurde, der nicht mehr besteht. Also kann der Passus raus. Viele haben sich ohnehin nicht daran gehalten. Er wurde von der gängigen Praxis überholt. Die Werte sollen wie sie sind einer nachvollziehbaren Quelle entnommen werden und fertig; dann stellt sich auch die Frage, wie gerundet werden soll, nicht. Die Entscheidung, ob Nachkommastellen genannt werden, sollte man den Autoren im Einzelfall überlassen. Von daher finde ich HPs Formulierungsvorschlag gut. --Milseburg (Diskussion) 10:46, 13. Mär. 2013 (CET)

Übung

Könnte jemand von den zwei-Stellen Genauigkeitsbefürwortern die Höhen folgender Berge aus den üblichen Quellen ermitteln? Nur so als Test:

• Bierberg (Dassel)
• Bierberg (Kalefeld)
• Rösteberg

lg --Herzi Pinki (Diskussion) 00:10, 10. Mär. 2013 (CET)

• Bierberg (Kalefeld) ...hab dort grad nen kleinen Fernsehturm mit Höhenbolzen an der Kuppel aufgebaut und mit Niv vermessen ...835,34 Meter. Laut DGK5 allerdings 267,5 Meter. Pff. --alexrk (Diskussion) 01:08, 10. Mär. 2013 (CET)

also wenn ich auf http://geoportal.geodaten.niedersachsen.de/harvest/srv/de/main.home Bierberg eingebe, bekomme ich null Treffer. ?? --Herzi Pinki (Diskussion) 01:17, 10. Mär. 2013 (CET)

Nimm doch den Geohack - dort ist der NiedersachsenViewer ja neuerdings mit verlinkt ;) ps: musst dan dort noch die 1:5000 unter Geobasisdaten manuell anhaken und reinzoomen --alexrk (Diskussion) 01:22, 10. Mär. 2013 (CET)

das ist vielleicht ein Tool! Ich komm damit nicht zurecht, gut die 5000 reingehakt geht noch, aber die Seite bleibt entweder weiß oder zeigt mir die Höhe nicht an. Bei 1:10000 bleibt sie überhaupt immer weiß. Und langsam, … Aber das der NiedersachsenViewer verlinkt ist, ist trotzdem ein echter Fortschritt. --Herzi Pinki (Diskussion) 09:23, 10. Mär. 2013 (CET)

Du musst dann nach dem Du die Karte 1:5000 angehakt hast noch unten irgendwo auf Aktualisieren klicken. Ja, die offiziellen Seiten sind alle irgendwie noch ziemlich pre-Web20. --alexrk (Diskussion) 11:49, 10. Mär. 2013 (CET)

gescheitert, entweder sehe ich den Berg 1:41000 (direkt vom Geohack kommend) ohne Gipfelkote, mit der 3. Höhenlinien nach 200 mit 220 beschriftet und noch weitere 4 Höhenlinien (was soll das sein, 3 Höhenlinien auf 20 Meter?, alle 6,67 Meter?) oder 1:5000 ohne Höhe, 1:8000 auch ohne Höhe und bei 1:10000, 1:20000 nur weiß, keine Karte. Deine 267,5 m halte ich aufgrund der Höhenlinien im Maßstab 1:41000 für übertrieben, max 250. lg --Herzi Pinki (Diskussion) 16:41, 10. Mär. 2013 (CET)

Ähm, ich hab mal nen Screenshot gemacht. In der TK100 ist die Kuppe mit 268m angegeben. In der TK50 hast du die 220er Höhenlinie plus 4x10 also 260-270m (die kurz-gerissenne "3. Höhenlinie" zw 200 und 220 ist eine 5er Hilfslinie, dünn und durchgezogen sind 20m, dünn und lang-gerissen sind 10m) --alexrk (Diskussion) 17:38, 10. Mär. 2013 (CET)

ach so, unter farbig verbirgt sich die Auswahl der Auflösung, was für ein Kraut raucht ihr denn da oben? Danke für den Screenshot, war hilfreich. Jetzt sehe ich es auch. lg --Herzi Pinki (Diskussion) 22:13, 10. Mär. 2013 (CET)

Gibt es eine Möglichkeit, einen Direktlink auf diese Kartenansicht, so man sie mal hat, zu speichern? lg --Herzi Pinki (Diskussion) 22:21, 10. Mär. 2013 (CET)

damit sollte es gehen ..die zusätzlichen URL-Parameter (&LAYERS=map_618%2Clayer_3710&STYLES=%2Cstyle_layer_3710) hab ich rausbekommen, indem ich über rechte Maustaste auf dem Kartenbild mir die URL angeschaut habe. --alexrk (Diskussion) 16:42, 11. Mär. 2013 (CET)

auf diese genial einfache Möglichkeit bin ich wieder mal nicht gekommen. danke, voll zufrieden. Bleibt zu hoffen, dass die das Interface nicht ändern. lg --Herzi Pinki (Diskussion) 20:08, 11. Mär. 2013 (CET)

Rätsel

 Karte mit allen Koordinaten des Abschnitts Rätsel: OSM

Ich habe ein Rätsel für alle Nachkommastellenfreunde gefunden. Bitte um Lösung. Die beiden Kartenwerke TIM und BfN unterscheiden sich im Detail in ihrer Höheninformation. Ich bin auf der Suche nach dem Rösteberg drüber gestolpert. Es gibt auf TIM und BfN zwei Hochpunkte, die sich jeweils auf der anderen Karte nicht finden lassen und die überdies unterschiedliche Höhen ausweisen, obwohl beide Karten HNH Bezug verwenden. Der Abstand der beiden Punkte beträgt 195m, die Höhendifferenz 1 m, immerhin das Zehnfache der verwendeten Genauigkeit von 1 dm.

• BfN: Höhe 95.3, BfN Karte (Rösteberg (BfN)?52.0172397.52532995.3) Ausgabe 2011
• TIM: Höhe 94.3, TIM, DGK5 dazuladen, auf Kartenmittelpunkt 7,526334;52,018863 zoomen (Rösteberg (TIM) ?52.0188847.52630594.3)

• Der erste Punkt hat auf TIM eine Höhe von rund 90.8 (zwischen 90.5 und 91m), Höhenabweichung 4.5 Meter.
• der zweite Punkt hat auf BfN eine Höhe von rund 90 m, Abweichung 4.3 Meter

Erschreckend ist v.a. der sehr unterschiedliche Verlauf der Höhenlinien. Beide Karten können nicht Recht haben. lg --Herzi Pinki (Diskussion) 23:04, 14. Mär. 2013 (CET)

Nachtrag: Google Relief hat etwas weiter westlich (Rösteberg (Google) ?52.0183817.518504100) noch eine geschlossene 100m-Höhenlinie, wo TIM gerade mal 91,5 m angibt. --Herzi Pinki (Diskussion) 23:12, 14. Mär. 2013 (CET)

Ja, schaut auch etwas merkwürdig aus. Muss aber nicht unbedingt ein Fehler in der Karte sein. Könnte auch einfach auf schlechte (ältere) Höhendaten beruhen, oder der Generalisierung oder Ausgleichungsmethode geschuldet sein. Man darf wohl (zumindest den älteren klein/mittelmaßst. TKs) nicht so stark trauen, was die Höhen angeht. Vergleich mal mit der aktuellen DTK25, dort fehlen die ganzen (in der BfN-Version noch zahlreichen) Höhenpunkte an den Straßenrändern. Ich schätze, die stammen noch aus älteren Zeiten und wurden in den letzten Jahren durch das mittels Laserscanning geschaffene Digitale Geländemodell (DGM) ersetzt. mW. haben die meisten Bundesländer die genaueren Laserscan-Daten erst in den letzten Jahren komplettiert. Die Höhendarstellungen in der 1:5000 sollten also mittlerweile größtenteils (wenn nicht gar vollständig) auf neuzeitliche genauere DGM's beruhen und sind daher mE. immer vorzuziehen. --alexrk (Diskussion) 16:38, 15. Mär. 2013 (CET)

Bin kein Freund von Nachkommastellen sondern von einer Liberalisierung. Dass sich in Karten unterschiedliche Werte finden, ist ja nichts Neues. Beim Rösteberg würde die Ganzahlregel auch nichts helfen. Beim Großen Feldberg sind die Abweichungen in den Quellen noch größer. Noch zwei Gegenbeispiele: Der Erbeskopf wurde mit Aufwand und Medienecho auf den Zentimeter genau vermessen. Warum sollte man das nicht im Artikerl angeben dürfen? Oder: Bei Dammersfeldkuppe und Kreuzberg (Rhön) entscheidet ein Dezimeter die Frage, welcher der zweithöchste Berg der Rhön ist. Für Geographen eine möglicherweise irrelevante Frage. Es zeigt sich aber immer wieder, dass sich normale Leser durchaus für ein solches Ranking interessieren. Ich lehne daher eine einheitliche Regelung weiterhin ab und plädiere für Einzelfallentscheidungen. --Milseburg (Diskussion) 11:30, 17. Mär. 2013 (CET)

Auto-Kat

Ponta do Pico enthält (vermutlich via Infobox) die Kategorie:Berg in Europa. Das ist falsch, da die Azoren keinem Kontinent zugeordnet werden. Es müsste deshalb die Möglichkeit geschaffen werden, dass auch in Kategorie:Geographisches Objekt ohne Kontinentalbezug bzw. Unterkategorien automatisch einsortiert wird. 213.54.150.74 15:10, 31. Aug. 2013 (CEST)

Die Azoren wurden in der zugehörigen ISO-Vorlage mit Kontinent "Europa" geführt. Ich habe das jetzt mal geändert. die Kategorie:Geographisches Objekt ohne Kontinentalbezug wird nicht automatisch durch die Box gesetzt. --SteveK ?! 20:05, 31. Aug. 2013 (CEST)

Das gleiche Problem besteht auch bei Indonesien, wo einige Flüsse auf Neuguinea fälschlicherweise Asien zugeordnet werden. Könntest du das auch korrigieren? 213.54.150.73 20:54, 31. Aug. 2013 (CEST)

Die Flüsse hast du ja jetzt korrigiert, aber es gibt noch Fehler bei Bergen: Carstensz-Pyramide und auch das Maokegebirge liegen nicht in Asien. 213.54.166.169 14:22, 1. Sep. 2013 (CEST)

NAME: Schriftgröße

Seit ein paar Tagen ist die Schriftgröße, die durch den Parameter „NAME“ in der Infobox erzeugt wird, viel zu groß!
--TOMM (Diskussion) 10:12, 16. Aug. 2014 (CEST)

Ist mir auch schon aufgefallen, weiß jemand, warum? --Dampftrain (Diskussion) 10:28, 16. Aug. 2014 (CEST)

Habe Tschubbys unabgestimmte Änderung rückgängig gemacht.
Watzmann ^Disk. 15:02, 16. Aug. 2014 (CEST)

OK --Dampftrain (Diskussion) 16:09, 16. Aug. 2014 (CEST)

Danke!
--TOMM (Diskussion) 20:31, 16. Aug. 2014 (CEST)

Normalnull vs. Normalhöhennull

Warum wird in der Infobox Berg bei der Höhe von bergen in Deutschland immer noch NN angezeigt statt NHN (gültig seit 1992) und auch dahingehend verlinkt? Siehe z.B. Grünten. Gruss --Schofför (Diskussion) 00:42, 30. Dez. 2014 (CET)

Weil dort HÖHE-BEZUG = DE-NN statt HÖHE-BEZUG = DE-NHN als Parameter angegeben ist.
Watzmann ^Disk. 00:47, 30. Dez. 2014 (CET)

Ach sooo! Werde das dort jetzt ändern. Danke für den Hinweis und Gruss --Schofför (Diskussion) 02:15, 30. Dez. 2014 (CET)

Gerne.
Watzmann ^Disk. 13:23, 30. Dez. 2014 (CET)

Habe unterdessen noch weitere Berge im Allgäu mit dem „neuen“ Parameter versehen. Dabei ist mir aufgefallen, dass es Berge gibt, die auf der Grenze zwischen Bayern und Tirol liegen (dass es solche Berge gibt, habe ich natürlich schon vorher gewusst Vorlage:Smiley/Wartung/;) ). Bei einigen ist dann kurz DE (ergibt; m - mit Link zu Höhe über dem Meeresspiegel), bei den anderen AT (ergibt; m ü. A. - mit Link zu Meter über Adria) eingetragen. Wobei mir ersteres irgendwie neutraler erscheint, mindestens für den Leser des Artikels. Gibt es hierfür Richtlinien, wie bei „Grenzgängern“ vorgegangen wird? Gibt es eventuell einen neutralen Parameter? Gruss --Schofför (Diskussion) 23:34, 30. Dez. 2014 (CET)

Es können mehrere Höhen angegeben werden, wie z.B. beim Funtenseetauern. NN und NHN sind nicht dasselbe und du solltest deshalb nicht ungeprüft einfach das alte durch das neue ersetzen. Schau nach, auf welchem Beszugssystem deine Quelle basiert und gib diese dann als Beleg mit an. Dazu auch Wikipedia Diskussion:WikiProjekt Geographie/Quellensammlung#Höhenbezugssystem. --Milseburg (Diskussion) 23:51, 30. Dez. 2014 (CET)

Danke für diese Infos. Werde mir die Diskussion bezüglich Höhenbezugssystem einmal zu Gemüte führen. --Schofför (Diskussion) 01:30, 31. Dez. 2014 (CET)

Das mit mehreren Höhen war mir vorher noch gar nicht aufgefallen, danke für die Info. Ich habe gedacht, wer zuerst kommt, mahlt auch zuerst. Wenn da bei einem Grenzberg bereits eine „österreichische“ Höhe eingetragen war, war das bislang für mich ok. Da muss ich nicht unbedingt eine „deutsche“ Höhe dazuschreiben. Allerdings wird man m.E. in den meisten Fällen kaum Quellen finden, welches System der angegebenen Höhe jeweils zu Grunde liegt. Gruß und guten Rutsch wünscht
Watzmann ^Disk. 15:18, 31. Dez. 2014 (CET)

Karte in der Box

Mir ist nicht klar geworden, welche Karte sich automatisch aus der Position bzw. Region ergibt. In der Schweiz erscheint jeweils eine Kantonskarte (wo ein Kanton markiert ist), doch zahlreiche Berge liegen auf der Kantonsgrenze. Das schwarze Dreieck ist gut, doch ist es leider nicht zu sehen, wenn man die Karte vergrößert; denn dann erscheint die Datei, welche ja nicht die Position enthält.

Wählt man eine andere Karte, erscheint auch in der Box kein Positions-Dreieck. Dies sollte verbessert werden.

--Friedo (Diskussion) 16:03, 31. Jan. 2015 (CET)

Ich habe gerade beim Aletschhorn die Alpenkarte als Positionskarte eingetragen. Das schwarze Dreieck ist da. Es müssen aber Karten sein, die in Kategorie:Vorlage:Positionskarte zu finden sind.
Watzmann ^Disk. 20:09, 31. Jan. 2015 (CET)

Sicher, in der Box erscheint das Dreieck; doch um die Lage genauer zu sehen, klickt man auf sie und es öffnet sich der Viewer, dann ist das Dreieck nicht mehr sichtbar, weil nur das Kartenbild betrachtet, die Position aber nicht übergeben wird.

In Ihrem Beispiel würde standardmäßig als Region Kanton Wallis übernommen werden. Die Alpenkarte ist in Ordnung, aber besser wäre eine Positionskarte der Gebirgsgruppe, die ja hier eingetragen ist. Doch die gibt es derzeit nicht. Leider enthalten fasst alle Positionskarten politische Grenzen. So habe ich festgestellt, dass bei Eintrag zweier Kantone, nur die Fläche des zuerst genannten umgrenzt wird. Bei "Berg" (wie hier) oder "Gebirgsgruppe" sollte also nicht die politische Region (ISO), sondern die geografische Verwendung finden.

--Friedo (Diskussion) 19:29, 2. Feb. 2015 (CET)

Wie man das technisch realisieren sollte, den Positionsmarker an den Viewer zu übergeben, weiß ich nicht. Das müsste auch an anderer Stelle diskutiert werden, da es ja alle Infoboxen mit Positionskarte betrifft.

Gebirgsgruppenkarten wären als Ergänzung in der Tat schön, aber irgendjemand muss die ja auch alle entwerfen und anfertigen. Und dafür wird hier ja keiner bezahlt, sondern wendet jeder seine Freizeit auf. Im übrigen kann man ja oben rechts immer noch zum OSM-Kartenausschnitt wechseln oder über den Positionslink zu weiteren Kartenangeboten wechseln.
Watzmann ^Disk. 20:54, 2. Feb. 2015 (CET)

Thumbtime für Videos

Ohne thumbtime.

Mit thumbtime.

Bei Bild1, Bild2 oder Bild3 kann man ja auch Videos einbinden. Gibt es jedoch auch die Möglichkeit die thumbtime einzustellen? Bei thumbs geht das wie links dargestellt. Gibt es auch eine Möglichkeit das in der Infobox Berg zu machen? Im englischen Wikipedia gibt es folgende Vorlage:

| photo = {{#invoke:InfoboxImage|InfoboxImage|image={{{image|Piz Campagnung, aerial video.webm}}}|thumbtime={{{image_thumbtime|0:15}}}}}

gibt es so was ähnliches auch bei uns?--Capricorn4049 (Diskussion) 19:27, 24. Feb. 2015 (CET)

Koordinaten

Ist es sinnvoll, die Koordinaten eines Berges auf Bruchteile einer Bogensekunde anzugeben? Immerhin sind Berge ja doch etwas ausgedehnter und nichts punktuelles. Bei Gebirgen ist es meiner Meinung nach noch unsinniger überhaupt auch Bogensekunden anzugeben. --87.163.77.70 14:51, 12. Mai 2015 (CEST)

Siehe die Tabelle "Rundungswerte" unter Vorlage:Coordinate#Ausgabeformate. Ganze Bogensekunden oder vier bis fünf Nachkommastellen bei Dezimalgrad halte ich für sinnvoll, wenn ein expliziter Gipfelpunkt vorhanden ist. --тнояsтеn ⇔ 14:57, 12. Mai 2015 (CEST)

Gebirge

Wie an anderer Stelle mal diskutiert wurde: Höhenzüge unterhalb eines Mittelgebirges sind ja nicht als Gebirge zu verstehen. Berge des Flämings beispielsweise. Könnte man entsprechend den Parameter nicht anpassen? Gebirge/Höhenzug oder dergleichen? Haster (Diskussion) 08:32, 23. Nov. 2015 (CET)

Welchen Parameter meinst du? Man kann {{Infobox Gebirgsgruppe}} und {{Infobox Berg}} doch auch bei niedrigen Höhenzügen verwenden, vgl. z,:b. Baumberge mit dem 187 m hohen Westerberg. --Watzmann ^praot 17:22, 23. Nov. 2015 (CET)

Ich eine Diskussion mit einem (selbsterklärten) Geologen hier, der unter dem Parameter "Gebirge" einen Höhenzug unterhalb eines Mittelgebirges nicht gelten lassen wollte, zu dem der Berg gehörte, weil solche Höhenzüge definitionsgemäß keine Gebirge sind. Für mich ist der Parameter ja eigentlich rein zuordnend, aber wenn man pingelich ist, hat er ja Recht. Es ging um den Berg Götzer Berg, der zur Zauche gehört, einer eiszeitlichen Hochfläche. Und auch den Hohen Fläming wollte besagter Jemand nicht für gewisse Berge gelten lassen. Ist für den Hagelberg und andere brandenburgische Berge von Relevanz. Haster (Diskussion) 18:35, 23. Nov. 2015 (CET)

Ok. Jetzt habe ich dein Problem verstanden. Es geht demnach um diesen und ähnliche Edits. Ich persönlich finde es ok, wenn man beim Parameter Gebirge auch Höhenzüge nennt, denen man üblicherweise keinen ausgesprochenen Gebirgscharakter zuspricht. Dadurch geht auch nichts in die Wicken (z.B. Autokategorisierung). Weitere Meinungen? --Watzmann ^praot 20:34, 23. Nov. 2015 (CET)

Finde die Einordnung in einen größeren Zusammenhang auch richtig und wichtig. Aber ideal ist es sicher nicht, wenn beim Parameter "Gebirge" Naturräume (z.B.Ebberg (Balve)) oder Hügelländer bzw. Tourismusregionen (z.B. Bungsberg) geführt werden. Eine bessere Lösung fällt mir gerade nicht ein. Gehen Alternativnamen für Parameter? --Milseburg (Diskussion) 15:23, 24. Nov. 2015 (CET)

Nicht dass ich wüsste. Da muss man ggf. die Parameter-Dokumentation entsprechend klar abfassen. --Watzmann ^praot 17:30, 24. Nov. 2015 (CET)

Ich teile die Auffassung, dass eine Einordnung in einen größeren Zusammenhang sinnvoll ist. Den Parameternamen müsste man nicht unbedingt ändern (steht ja nur im Quelltext), man müsste nur dafür sorgen, dass das Präfix, das in der IB dargestellt wird, parametrisierbar wird. Hier sehe es zwei mögliche Strategien: 1. Man gibt eine feste Auswahl vor; 2. Man ermöglicht eine direkte Angabe des dargestellten Präfix. Für eine solche Anpassung spricht auch, dass z.B. häufig hier Gebirgsgruppen oder Untergruppen angegeben werden und "Gebirge" hier genaugenommen auch nicht stimmt.--Cactus26 (Diskussion) 08:53, 25. Nov. 2015 (CET)

Also dass unter "Gebirge" auch Höhenlage unterhalb eines Mittelgebirges aufgeführt werden dürfen, scheint mit ja Konsens. Könnte man also technische bewerkstelligen, dass man den Punkt "Gebirge" bedarfsweise auch namentlich anpassen kann? Haster (Diskussion) 15:14, 5. Dez. 2015 (CET)

Wikidata

Was haltet ihr von einer Integration von Wikidatadaten in die Vorlage? Idee: Wenn lokal ein Wert vorhanden ist wird dieser verwendet, sollte das Feld aber in der Vorlage leer sein wird ein Wert aus Wikidata bezogen(bei Bedarf auch nur wenn dort ein Beleg dafür hinterlegt ist). Wenn ein Wert bezogen wurde könnte man auch als Anmerkung oder Kommentar im Quelltext einen Hinweis einbinden der darauf verweist von wo die Daten eingebunden werden damit keine Verwirrung aufkommt wenn man im Quelltext den Wert ändern will. Felder bei denen es imho Sinn macht sind: "Höhe", "Bild" und "Höhe über Meerespiegel". -- Quotengrote (D|B) 11:09, 19. Mär. 2017 (CET)

Mit Hilfe von Wiegels ist das die Anpassung für die Höhe -> Benutzer:Quotengrote/Wikidata/InfoboxBerg -- Quotengrote (D|B) 14:32, 19. Mär. 2017 (CET)

@Quotengrote:

• wie geht das, wenn mehr als eine Infobox in einem Artikel vorkommt? Die Vorlage unterstützt über NEBENBOX eine Berg-Infobox in einem anderen Artikel als dem eigenen. Etwa Walserberg (Österreich), Drei Berge von Dewa.
• Und was ist die Empfehlung? Solange in allen Infoboxen die Höhe steht, hat die Änderung ja keine Auswirkung. Damit die Änderung Sinn macht, muss die Höhe aus allen Infoboxen gelöscht werden.
• Gibt es eine Aufstellung, in welchen Fällen die Höhe in der Infobox von WD abweicht?

lg --Herzi Pinki (Diskussion) 00:45, 23. Mär. 2017 (CET)

@Herzi Pinki:

• Über mehrere Infoboxen habe ich mir noch keine Gedanken gemacht.
• Gelöscht werden muss nichts, solang lokal ein Wert drin steht wird der auch immer genommen, nur wenn keiner angegeben ist wird der von Wikidata verwendet. Das sehe ich z.B. bei neuen Artikeln als nützlich an.
• Eine Übersicht wo die Höhe der Infobox ungleich der im Artikeltext ungleich der Wikidata ist müsste noch erstellt werden, z.B. in Form einer Wartungskat damit dann händisch korrigiert werden kann. -- Quotengrote (D|B) 07:16, 23. Mär. 2017 (CET)

Für den ersten Fall müsst die Q-id an die Infobox optional übergeben werden und entsprechend ausgewertet. Den zweiten Punkt verstehe ich nicht, wenn ich WD traue, begebe ich mich auf dünnes Eis (die Qualität der bisherigen Einträge betrachtet), also muss ich ohnehin für die Höhe eine Karte konsultieren. Warum soll ich den Wert dann nicht in die Infobox schreiben? Gerade bei neuen Artikeln im Bergbereich gibt es oft solche, die nur in WP:sv und WP:ceb existieren, botgeneriert sind und die Höhe weiß Göttin wo her haben. Die Datenqualität der zugrundeliegenden Daten in z.B. geonames ist nicht gut. Hier entsteht ein automatisch generierter Beleg: (user generierter) Kontent in geonames → Übername nach WD → bot generierter Artikel als Quelle → Verbreitung der frohen Botschaft über die ganze Welt. Als Beispiel vielleicht Schießling und sv:Schiessling (abweichende Höhen, abweichende Koordinaten). Ich könnte mir aber einen Prozess vorstellen, der etwa so abläuft (ähnliches passiert auf commons bei Object location in Commons-Kategorien):

• wenn die beiden Werte in der Infobox und in WD voneinander (signifikant) abweichen, dann landet der Wert in WD / der Artikel in der WP in einer Wartungskategorie. Man könnte das auch im Artikeltext anzeigen (etwa farblich hinterlegt, mouseover) als Hinweis an den Leser, der Wert ist mit Vorsicht zu genießen.
• Die Diskrepanz wird untersucht und beidseitig der korrigierte Wert eingetragen (das ist wirkliche Arbeit und gehörte auch organisiert).
• Die Prüfung auf Diskrepanz bleibt drinnen, damit fällt eine Änderung an nur einer Seite wieder in der Wartungskategorie auf.

Schlussendlich wird aber damit Redundanz geschaffen, die nur dazu dient, zwei Werte als ungleich zu erkennen, die man ohne diese Redundanz gar nicht hätte. Es führt nach unseren heutigen Prozessen nicht sicher zu einem verbesserten Wert. Das alles müsste wesentlich {{Wikidata-Wert}} leisten. Eine Vorlage, die seit fast 2 Jahren im Entwicklungszustand ist und bei nur einer Version vermutlich nicht mehr weiter entwickelt wird. lg --Herzi Pinki (Diskussion) 09:05, 23. Mär. 2017 (CET)

Nur kurz da ich auf dem Sprung bin, man kann auch erzwingen das nur in WD belegte Werte angezeigt werden. Damit gäbe es wenigstens das Beleg Problem nicht. -- Quotengrote (D|B) 10:13, 23. Mär. 2017 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Quotengrote (D|B) 15:40, 15. Mai 2017 (CEST)

Parameter „dim“ einfügen und Wert an Vorlage:Coordinate übergeben

Die Vorlage:Infobox Berg bindet die Vorlage:Coordinate ein und verwendet sie, deren Parameter „dim“ wird dabei fix mit dem Wert „5000“ versehen (bzw. der Wert übernommen). Die ist jedoch je nach Größe/Ausdehnung des betreffenden Berges bisweilen nicht der beste Wert. Besteht die Möglichkeit, einen Parameter „dim“ in der Vorlage:Infobox Berg einzufügen und den dort eingetragenen Wert an den Parameter „dim“ der eingebundenen Vorlage:Coordinate zu übergeben? --X:: black ::X (Diskussion) 01:16, 16. Jan. 2016 (CET)

@X:: black ::X:, die Begeisterung hier hält sich in Grenzen. Technisch ist das natürlich möglich, hast du einen Beispielfall? Der Parameter dim bestimmt allerdings nur die Skalierung der über den Geohack aufgerufenen Kartendienste, die allesamt zoombar sind. Der Vorteil mit einer festen dim ist dass die Kartenausschnitte vergleichbar sind. Individualisierte dims bedeuten Arbeit und Fehlermöglichkeiten, dem muss auch ein Nutzen gegenüber stehen. Individualität steckt man doch vielleicht besser in die Inhalte und die Recherche, die Qualität des Artikels udgl., als in die Formatierung von selten aufgerufenen externen Diensten. Du bist der Erste, der mW mit dieser Anforderung kommt, d.h. viele andere sind mit der jetzigen Einstellung ev. zufrieden. Aber vielleicht einmal ein Beispiel? lg --Herzi Pinki (Diskussion) 01:05, 25. Aug. 2016 (CEST)

Kartenbreite

Gelegentlich kommen Hochkart-Karten zum Einsatz, welche dann nicht die volle Boxbreite nutzen. Es wäre zu wünschen, wenn die in Infobox Gebirgsgruppe integrierte Breitenanpassungsfunktion (Parameter KARTE-BREITE dort bis 324px) auch hier (dann z. B. bis 300px) zur Verfügung stünde und sich auch auf POSKARTE auswirkte, da ja bei Bergen eher diese zum Einsatz kommt.

Zu begrüßen wäre auch, wenn beim Aufruf der Positionskarte Symbol und Position mit übergeben würden; denn wenn man die Karte vergrößert mit dem Viewer darstellen will, wird nur die leere Karte, indessen nicht das schwarze Dreieck angezeigt. Doch gerade das will man ja mit der Vergrößerung erreichen.

--Friedo (Diskussion) 12:08, 24. Jul. 2016 (CEST)

Kennt sich denn niemand mit den beiden angesprochenen Angelegenheiten aus? --Friedo (Diskussion) 18:50, 24. Aug. 2016 (CEST)

es kennt sich schon wer aus, bisher hat noch keiner geantwortet: hast du ein dringendes Beispiel?

Zu begrüßen wäre auch, wenn beim Aufruf der Positionskarte Symbol und Position mit übergeben würden. Ja, verständlich, aber das gibt die Implementierung nicht her (das ist nur ein Bild mit einem Overlay-Symbol). Du solltest die Poskarte nicht überbewerten, sie gibt dir bloß einen ersten Anhaltspunkt, wo das Objekt liegen könnte, alles andere geht über die Geo-Koordinaten. Bei handgeschnitzten Karten ja ebenso. Bei den Poskarten ist nicht die Poskarte das was angeklickt werden sollte, sondern das Icon im Overlay. lg --Herzi Pinki (Diskussion) 01:32, 25. Aug. 2016 (CEST)

Ich finde es nicht so toll, wenn mittels magic numbers generelle Layoutfragen für bestimmte Bildschirmeinstellungen gelöst werden sollen. Es gibt immer Karten (z.B. Chile), die noch immer nicht die ganze Boxbreite einnehmen. Dafür muss man, je größer die Karte wird, umso mehr nach unten scrollen. Leute mit großem Bildschirm und großer Auflösung und kleiner Schrift sind da natürlich im individuellen Vorteil. Ich finde die Karte z.B. in Titlis für wenig hilfreich, da mit vielzuviel Details überladen, die niemand auch auf 300x400px ausnehmen kann. Die Karte macht nur in der Vergrößerung Sinn. Für mich sind die Umrisse des Bezugsobjekts (möglichst mit allgemeinem Wiedererkennungswert) und die Postionsmarke die entscheidende Information, mehr sollte man da nicht hineininterpretieren. @Pechristener:, die Disk zur Breite hat hier begonnen, ich habe deine Änderung gesehen, leider fehlt noch die Dokumentation des neuen Parameters. Magst du dich darum kümmern? lg --Herzi Pinki (Diskussion) 00:31, 11. Okt. 2016 (CEST)

Ich habe den von mir eingeführten Parameter für KARTE-BREITE wieder aus der Vorlage entfernt. Das Störende war die Limitierung der Pos-Karten-Höhe auf 300px, die ich am 2. Oktober auch entfernt hatte. Das habe ich nun so drin gelassen, denn sie verhindert, das lange schmale Karten ( wie zum Beispiel Chile) verkümmert dargestellt werden. Die Scrollfrage wird sich nie wirklich lösen können, aber die Höhenbegrenzung in dieser Form gibt es in anderen Infoboxen nicht, weshalb ich sie entfernt habe.--Pechristener (Diskussion) 02:21, 11. Okt. 2016 (CEST)

{{Infobox See}}, {{Infobox Gletscher}}, {{Infobox Schutzhütte}} um nur einige zu nennen, haben alle eine Beschränkung der Höhe der Karte. Viele andere Boxen helfen sich mit einer expliziten Angabe der Breite, aber eines von beiden braucht es sinnvollerweise. Und wenn ich oben von Titlis gesprochen habe, dann habe ich schon die Poskarte gemeint. Ich mach die Limitierung der Höhe bei Karte wieder rein. lg --Herzi Pinki (Diskussion) 09:20, 11. Okt. 2016 (CEST)

Eine Limitierung braucht es mMn unbedingt, ich würde dieses Limit sogar noch kleiner wählen, denn sonst steht bei Hochkant-Karten der Platzbedarf der Poskarte in keiner vernünftigen Relation zur Information, die sie bietet. Beim Titlis stimmt die Relation mMn zum Beispiel nicht, wer sich so genau für die Lage dieses Berges interessiert, verwendet sicher nicht die Poskarte. Ich halte großräumige Karten, die die Lage in den Alpen darstellen, ohnehin für sinnvoller... --Cactus26 (Diskussion) 09:54, 11. Okt. 2016 (CEST)

Die Limitierung der Höhe ist für mich ok, solange die optional und nicht fest drin ist. Ich kenne sie nur von den Infoboxen der Geographen, bei den Bahnstrecken gibt es sie nicht.--Pechristener (Diskussion) 00:11, 21. Dez. 2016 (CET)

Eine Limitierung des Spielraums des einzelnen Bankers ist ok, solange die optional ist und nicht fest irgendwo drin steht. Ich glaube in beiden Fällen kann ich den Knopf in meinem Kopf nicht lösen. lg --Herzi Pinki (Diskussion) 12:20, 22. Dez. 2016 (CET)

Was ist in diesem Zusammenhang ein Banker ? --Pechristener (Diskussion) 16:28, 10. Jan. 2017 (CET)

Zweifarbiger Map-Pointer

Ich habe mir erlaubt einen zweifarbigen Map Pointer einzubauen. Er sollte besser sichtbar sein als der alte.--Pechristener (Diskussion) 00:11, 21. Dez. 2016 (CET)

Infobox Berg/Archiv/2 (Österreich) neuer map-pointer	Infobox Berg/Archiv/2 (Österreich) alter map-pointer	Infobox Berg/Archiv/2 (Österreich) alter map-pointer
[[Datei:Vorlage:Positionskarte Schweiz Silvretta|class=noviewer notpageimage|240px|center|Infobox Berg/Archiv/2 (Vorlage:Positionskarte Schweiz Silvretta)]] Lage des Piz Buin in der Silvretta.	[[Datei:Vorlage:Positionskarte Schweiz Silvretta|class=noviewer notpageimage|240px|center|Infobox Berg/Archiv/2 (Vorlage:Positionskarte Schweiz Silvretta)]] Lage des Piz Buin in der Silvretta.

demnächst bekommen wir ohnehin die maki-icons und <mapframe>. 100 Leute warten mit dem roten icon jahrelang zufrieden oder haben sich nicht beschwert, einer hat eine andere Meinung und setzt es um und hat Recht. Mir ist es wurscht, mir kommt vor, ich seh es schlechter als vorher. Maximal ist das eine Geschmacksfrage und damit kein Grund für eine Änderung. lg --Herzi Pinki (Diskussion) 12:52, 22. Dez. 2016 (CET)

+1, für mich auch eine Verschlechterung der Sichtbarkeit. --тнояsтеn ⇔ 20:46, 9. Jan. 2017 (CET)

+1 für alten Pointer:

Ich sehe das auch als Verschlechterung der Sichtbarkeit an.

Die alte Dreiecks-Markierung ist besser sichtbar!

Daher bitte zurück zum alten Pointer!
--TOMM (Diskussion) 21:18, 9. Jan. 2017 (CET

+1 für den alten und besseren Pointer. --Milseburg (Diskussion) 15:26, 10. Jan. 2017 (CET)

Habe die Änderung aufgrund des eindeutigen Diskussionsverlaufs rückgängig gemacht. Es war allerdings ein schwarzer Marker drin . Der komplett rote, der oben als "alter map-pointer" bezeichnet wurde, gefällt mir auch gut. Nur der zweifarbige ist schlecht sichtbar. --тнояsтеn ⇔ 16:18, 10. Jan. 2017 (CET)

Etwas schräge Disk hier, wo ein Vergleich zwischen alt und neu gemacht ist, wo alt gar nicht alt ist. Rot scheint aber offenbar ok zu sein, das ist aus meiner Sicht schon viel besser als Schwarz.

btw: 100 Leute warten mit dem roten icon jahrelang zufrieden oder haben sich nicht beschwert, einer hat eine andere Meinung und setzt es um und hat Recht. Was ist das Problem, wenn einer Recht hat ? Hoffe nicht, dass jemand der Meinung bist, nur weil niemand reklamiert, sei alles in Ordnung und könne nichts verbessert werden. ... ansonsten hätten wir das Rad immer noch nicht erfunden --Pechristener (Diskussion) 16:26, 10. Jan. 2017 (CET)

Späte Antwort @Pechristener:. Mein Satz war ironisch gemeint. Ohne Diskussion eine Änderung an einer Stelle zu machen, die seit Jahren bei häufiger Verwendung nicht beanstandet worden ist, ist riskant. Es könnte sein, dass es allen wurscht ist oder dass eine Veränderung mit hoher Wahrscheinlichkeit auf Widerstand stößt. Nicht jede Mutation führt zu einem evolutionären Vorteil, … Recht hast du nur tautologisch. Du hast eine hidden agenda und versuchst den Mappointer zu ändern, nicht weil er nicht passt, sondern weil er für deine Karten nicht passt. Der Großteil der relief-Karten ist rotlastig, es hat schon seinen Grund warum der alte Mappointer schwarz war. Mein Fehler, dass ich oben den roten als alten bezeichnet habe. Ich lass das mal so, aber auch diese Änderung ist durch die Disk nicht wirklich abgedeckt. lg --Herzi Pinki (Diskussion) 00:27, 23. Mär. 2017 (CET)

@Herzi Pinki:Das mit der hidden Agenda ist eine Unterstellung. Die Idee, den Map Pointer zu ändern war gar nicht von mir, ich hatte sie nur versucht umzusetzen. Rotlastige Karten gibt es schon, aber nur im Alpenraum, das Beispiel von der Infobox ist nicht rotlastig. Die Änderung, die du jetzt rückgängig gemacht hast ist, nun doch drei Monate drin gestanden ohne dass sie jemand bemerkt oder gestört hat, und ist demzufolge nicht grundsätzlich falsch. Es braucht nicht für jede Änderung zuerst eine Diskussion, das lockt nur die Leute an, die zu allem nein sagen. Ich lasse jetzt dein Rückgängig trotzdem stehen, weil ich gerade an einer anderen Ecke tätig bin, was aber nicht heisst, dass es deshalb der idealzustand ist. Vielleicht könnte man sich auch überlegen, die Farbe des Pointers wählbar zu machen.--Pechristener (Diskussion) 04:46, 23. Mär. 2017 (CET)

Dann freut mich das, dass du keine hidden agenda hast, und nehme gerne meine Unterstellung zurück. Tut leid wenn es so angekommen ist. Ich wollte ursprünglich deine Änderung, nachdem Thgoiter auf den schwarzen Mappointer rückgesetzt hat, die ja relativ flott nach nur 7 Minuten erfolgt ist, nicht rücksetzen, aber die Ungleichbehandlung mit der Gebirgsgruppe war dann doch etwas, was ich für unschön empfunden habe. lg --Herzi Pinki (Diskussion) 08:29, 23. Mär. 2017 (CET)

Lagewunsch?

Hat die Infobox nicht früher mal einen Lagewunsch erzeugt, wie es die nur mit type und region befüllte Vorlage:Coordinate tut? Eigentlich wollte ich beim Hochtörl so einen erzeugen. -- Olaf Studt (Diskussion) 23:42, 16. Mär. 2018 (CET)

Ich dachte auch. Wohl ein Fall für die Werkstatt. --тнояsтеn ⇔ 22:14, 15. Apr. 2018 (CEST)

[6] vermutlich das da. ich aktiviere wieder. lg --Herzi Pinki (Diskussion) 12:18, 28. Jul. 2018 (CEST)

Kategorie:Wikipedia:Lagewunsch (mountain) bräuchte jetzt wieder Beachtung --Herzi Pinki (Diskussion) 13:36, 28. Jul. 2018 (CEST)

Danke --тнояsтеn ⇔ 22:30, 29. Jul. 2018 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: тнояsтеn ⇔ 22:30, 29. Jul. 2018 (CEST)

HTML-Fehler

Anscheinend erzeugt die Infobox unter bestimmten Bedingungen Fehler. Näheres unter

Wikipedia:WikiProjekt Vorlagen/Werkstatt#Linterfehler durch Pseudofehlerwartungsanalyse?

Ich berichte nur weiter. --Silvicola ^Disk 14:39, 27. Jul. 2018 (CEST)

danke fürs berichten, ist erl. lg --Herzi Pinki (Diskussion) 22:41, 29. Jul. 2018 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Herzi Pinki (Diskussion) 22:41, 29. Jul. 2018 (CEST)

Bearbeitung der Erklärungen

Die Parameter-Beschreibung konnte ich bearbeiten (und z. B. einen Tippfehler beseitigen), doch der weitgehend gleiche Text unter "TemplateData" ist für mich nicht erreichbar. Oder wie geht das?

--Friedo (Diskussion) 18:15, 13. Nov. 2014 (CET)

Von /Doku hierher kopiert. --PerfektesChaos 17:36, 2. Jan. 2018 (CET)

TL-OE

Die Region Oecusse (Gemeinde) ist nach Oe-Cusse Ambeno verschoben worden, ebenso die Kategorie:Berg in Oecusse nach Kategorie:Berg in Oe-Cusse Ambeno. Auch TL-OE wurde entsprechend angepasst. Trotzdem wird automatisch die alte Kategorie in die Artikel eingefügt, z.B. Puas. Was ist zu tun? --JPF just another user 09:05, 10. Mai 2019 (CEST)

scheint daran gelegen zu haben … «« Man77 »» Alle Angaben ohne Gewehr. 12:06, 10. Mai 2019 (CEST)

PS: Ganz extrem klug scheint mir diese Bastelei aber nicht zu sein. Weiß aber auch nicht, wie man das besser hinkriegt. … «« Man77 »» Alle Angaben ohne Gewehr. 12:07, 10. Mai 2019 (CEST)

Vielleicht die Kategorien wieder direkt den Autoren überlassen, statt per Halbautomatik in Infoboxen? ;-) --JPF just another user 20:05, 10. Mai 2019 (CEST)

Koordinaten aus Wikidata?

Im Artikel zum Vulkan Roccamonfina wurde die Vorlage:Einbindung von Wikidata-Koordinate verwendet; um die Infobox Berg einzusetzen, habe ich sie entfernt und die Koordinaten aus it:Roccamonfina (vulcano) hartcodiert eingetragen. Gibt es eine Möglichkeit, Wikidata-Koordinaten in der Infobox einzusetzen? -- Olaf Studt (Diskussion) 11:03, 8. Jul. 2019 (CEST)

P.S. Ich sehe sehr wohl das Problem, dass in Wikidata gar nicht so selten 2 Koordinatenpaare aus verschiedenen Quellen vorhanden sind. Und im vorliegenden Falle sind die Koordinaten auf Wikidata auf ganze Winkelminuten gerundet, in der italienischen WP dagegen dezimal mit 6 Nachkommastellen. -- Olaf Studt (Diskussion) 12:00, 8. Jul. 2019 (CEST)

Ich bin absolut dagegen, dass wir die Daten von Wikidata nutzen. Erstens ist nicht klar, welches System dort genutzt wird, dann ist das Ganze viel zu sehr gesplittet (Jeder Wert ein Zugriff) und es wimmelt dort von Fake-Einträgen, welche Scherzkekse eintragen und Fälschungen durch Geheimdienste bei Koordinaten von militärischer Bedeutung wie Brücken, Häfen, AKWs etc. Besser eigene Koordinaten Sammeln und einlesen. ÅñŧóñŜûŝî (Ð) 18:17, 8. Jul. 2019 (CEST)

Solange CEB:WP und SV:WP ungestört für ein und dasselbe Objekt zwei Wikidataitems erzeugen, wird das nicht gehen. --91.2.112.229 17:37, 17. Jul. 2019 (CEST)

Automatische Regionskat funktioniert bei Dundee Law nicht

Hallo zsuammen, kann jemand klären, warum beim Dundee Law als einzigem schottischen Berg die Zuordnung zur Regionskat, in diesem Fall die Kategorie:Berg in Dundee, nicht funktioniert? Stattdessen taucht er immer in der Kategorie:Berg in Schottland auf, die eigentlich keine Artikel mehr haben sollte, sondern nur Unterkategorien. Unter "REGION-ISO" steht in der Infobox ganz ordnungsgemäß "GB-DND", was das richtige Kürzel ist. Bei allen anderen schottischen Bergen hatte ich keine Probleme, nur der Dundee Law funktioniert nicht. Kann jemand mit mehr Ahnung von Vorlagen da mal schauen? Regards --Carsaig (Diskussion) 01:16, 27. Sep. 2020 (CEST)

Ich vermute, weil in der Vorlage:Info ISO-3166-2:GB-DND die Administrationseinheit "City of Dundee" heißt, es aber keine Kategorie:Berg in City of Dundee gibt? Bin aber nicht der Vorlagenexperte... --тнояsтеn ⇔ 21:22, 27. Sep. 2020 (CEST)

Das wars... habe jetzt alle Einträge in der ISO-Vorlage zu Dundee analog der Vorlage zu Aberdeen geschrieben, jetzt klappt es. Regards --Carsaig (Diskussion) 09:35, 28. Sep. 2020 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: тнояsтеn ⇔ 20:41, 28. Sep. 2020 (CEST)

Parameter REGION-ISO

Vorne in der Doku steht zu diesem Parameter: "Kombination aus den ISO 3166-1- bzw. ISO-3166-2-Codes durch "/" getrennt der Regionen in denen sich der Berg befindet."

In Stożek_Mały ist genau das gemacht, dort ist "REGION-ISO=PL-24/CZ-80" in der Infobox eingetragen. Das führt dazu, dass bei auf der Seite in der Infobox bei "Lage" nix steht. Wenn man die Seite im Quelltext öffnet, ist dann unten ein Rotlink bei Vorlage:Info ISO-3166-2:PL-24/CZ-80 zu sehen. Muss einfach diese fehlende Vorlage erzeugt werden oder fehlen ein paar Zeilen Code in dieser Vorlage? Ähnlich bei Wróżna, Stożek Wielki, Soszów Wielki, Ostry (Schlesische Beskiden), Kyrkawica, Kiczory (Schlesische Beskiden), Cieślar (Schlesische Beskiden). --Wurgl (Diskussion) 08:56, 23. Mär. 2019 (CET)

Bei Mont Blanc funktioniert REGION-ISO = FR-74/IT-AO. Andim (Diskussion) 09:34, 23. Mär. 2019 (CET)

Danke Andim! Durch intensives Anstarren des Codes hab ich das Problemchen entdeckt: Wenn so ein Schrägstrich im parameter REGION-ISO enthalten ist, dann sollte der Parameter LAGE ausgefüllt sein, ebi Mont Blanc steht dort "LAGE=Frankreich und Italien". --Wurgl (Diskussion) 09:56, 23. Mär. 2019 (CET)

Hallo Wurgl, hatte gerade („leider“ unabhängig vom Vorgesagten) dasselbe Problem von Deiner Fehlerliste mittels Ausfüllen des Parameters LAGE gelöst. Das lässt mich nochmals nach dem Doku-Text für REGION-ISO fragen, s. oben. Ist mit der Kombination gemeint, dass Berge auf Grenzlinien liegen und damit zwei Regionen zu erwähnen sind? Dann sollte das a) so formuliert werden und b) ergänzt werden, dass dann der Parameter LAGE Pflichtparameter wäre (um enben Fehlermeldungen zu vermeiden). Leider ist der Ersteller, Centic, seit Mai nicht mehr aktiv. Gruß, --Wi-luc-ky (Diskussion) 18:30, 12. Nov. 2019 (CET)

Wenn ihr bitte mal über meine Änderung drüberschauen wollt, Wurgl und Andim: Habe die Doku präzisiert, so dass mE Vorlagenfehler künftig leichter vermieden werden können. Gruß, --Wi-luc-ky (Diskussion) 16:16, 13. Nov. 2019 (CET)

Erstmal Danke und so ist es deutlich besser! Für so Doofe wie ich es bin noch ein Wunsch: Kannst du noch ev. per Fußnote bei allen Vorkommen des Wortes "zweiteilig" dazuschreiben "Zweiteilig bedeutet Grenzberg." … vielleicht sogar als ganzen Satz *g* --Wurgl (Diskussion) 16:26, 13. Nov. 2019 (CET)

Danke, Wurgl, für Deine Anregungen und Dein Dankeschön nach entsprechender Umsetzung direkt im Fließtext. Bin auch kein Bergexperte ;-) Gruß, --Wi-luc-ky (Diskussion) 18:23, 13. Nov. 2019 (CET)

Bildgröße, Ränder an den Bildseiten

Hallo,

ich finde bei der Infobox suboptimal, dass Bilder automatisch verkleinert werden, anscheinend dann, wen sie ein gewisses Verhältnis von Höhe zu Breite überschreiten. Warum? Es entsteht dann ein unschöner beidseitiger Rand. Das sieht direkt unprofessionell aus und so etwas gibt es in anderen Wikipedia-Sprachversionen auch nicht. Das Bild kann doch etwas größer sein, was stört daran? Auch könnte die Infobox ein gewisses Facelift vertragen. Gruß --Furfur ^{⁂ Diskussion} 11:17, 13. Okt. 2019 (CEST)

hallo @Furfur:, die Beschränkung der Höhe des Bildes macht mE Sinn, um extremhochformatige Bilder nicht eine große Fläche auf der Seite in Anspruch nehmen zu lassen. Was sind die Alternativen? Ein anderes weniger hochformatiges Bild oder eine manuelle Beschränkung der Höhe / Breite, die dann wieder zu denselben Effekten führt, nur viel viel wartungsaufwändiger ist. Ich werde deine Änderung daher wieder rückgängig machen. An großen Bildern stört: sie nehmen überproportional viel Fläche in Anspruch, die Übertragungszeiten werden größer, und in manchen Fällen ergibt sich mehr Leerraum neben der Infobox, weil dort zuwenig Text steht, um mit der größeren Infobox mitzuhalten. Was unprofessionell wirkt.

kannst du dein Begehr nach einem Facelift präzisieren? Gegen welche Richtlinien soll dieser Facelift erfolgen? Dein Geschmack alleine wird es ja nicht sein. lg --Herzi Pinki (Diskussion) 08:27, 2. Jan. 2020 (CET)

Dazu kommt, dass nach deiner Änderung die Bildgröße (300px) max ist, die Infoboxbreite jedoch nur noch 286px. Wie soll das gehen? lg --Herzi Pinki (Diskussion) 08:32, 2. Jan. 2020 (CET)

Hallo Herzi Pinki, natürlich sollte dann die Bildbreite auf 286px geändert werden, aber die Beurteilung, ob ein Bild zu groß ist, sollte dem Artikelersteller oder Infoboxnutzer überlassen sein. Der kann am Besten beurteilen, ob ein Bild zu groß ist. Es kann gerne ein Parameter Bildgröße dazu eingeführt werden. Die Regelung, dass Bilder verkleinert werden müssen, ist nicht sinnvoll und viel zu rigide. So, wie es früher festgesetzt war, ist die Bildgröße zu beschränkt. Da wird willkürlich eine bestimmte Größe für alle Bilder gleichzeitig festgesetzt, ein richtiges Prokrustesbett, und nur in der deutschen Wikipedia zu finden. Diese Infoboxen mit zwei Rändern an der Seite gibt es anderen Sprachversionen nicht. Die sehen hässlich und unprofessionell aus, so als ob jemand die falsche Bildgröße gewählt hätte oder ein Bild in einen Rahmen eingepasst hätte, der dazu viel zu groß ist. Diese Regularien sind zu rigide. Wenn, dann müsste die maximale Bildhöhe größer sein. Das ist ein rein am Schreibtisch ausgedachter Wert. Die Übertragungszeiten sind nicht ernsthaft ein Problem, wenn man nicht gerade eine Modem-Verbindung ans Internet hat. Ich habe den Artikel Yandangshan verfasst. Das Bild ist hoch – na und? Dann ist es eben so. Der Artikel ist ausreichend umfangreich, so dass man nicht sagen kann, dass der Text zu kurz kommt. --Furfur ^{⁂ Diskussion} 09:23, 2. Jan. 2020 (CET)

Natürlich ist der Wert am Schreibtisch ausgedacht. Dein Wert von den 286px Breite der Infobox kommt jetzt woher? Wenn du in dem von dir zitierten Artikel Yandangshan den Parameter BILD-BREITE=200px setzt (was jeder tun kann), damit das Bild nicht so großflächig ist, was ist dann anders? Schön wäre ein responsives Design. Hast du eine Idee wie man das umsetzen kann? Magst du dich da einarbeiten?

Zum konkreten Artikel: Es ist ein Gebirge, kein Berg. Die Infobox also die falsche. Für einen Berg ist es auch ein nicht erwünschtes Bild, siehe ebenfalls Vorlagendoku.

Wenn du Formatierungen änderst, müsstest du eigentlich alle Verwendungen der Infobox durchgehen, um zu sehen, ob das überall passt. Hast du das gemacht? Auch am Mobile?

Du bist die Antwort zum Facelift schuldig geblieben, bitte nachreichen, da ich sonst auch bei der Größenänderung von einer Geschmacksfrage ausgehe.

lg --Herzi Pinki (Diskussion) 09:44, 2. Jan. 2020 (CET)

@Furfur: hier gibt es mehrere Fehlverwendungen / Parameterfehler in der Infobox. Statt am Format zu basteln, magst du dich den Inhalten widmen? lg --Herzi Pinki (Diskussion) 09:46, 2. Jan. 2020 (CET)

Da könnte ich genauso argumentieren: wenn man eine feste Bildgröße festsetzt, müsste man die einzeinen Artikel durchgehen um zu sehen ob das nicht unschöne Ränder an den Bildern erzeugt. Ich habe nicht den Eindruck, dass beim derzeitigen Artikel Yandangshan etwas an der Bildgröße geändert werden müsste. Deine Vorstellung ist wohl, dass alle Bilder zwangsweise auf eine bestimmte Größe zusammenschrumpft werden müssen. Ich habe kein Problem mit der mobilen Ansicht des Artikels, so wie er jetzt ist, das sieht bei mir akzeptabel aus. Die optionale manuelle Einstellung der Bildhöhe ist in keiner Weise wartungsaufwändig. Was muss da gewartet werden? Die Breite einer Infobox wird durch den dort enthaltenen Text bestimmt. Die Infobox sollte nicht breiter als notwendig sein und andererseits sollte der Text darin nicht zu gequetscht sein.
Mit den Fehlverwendungen/Parameterfehlern kann ich mich gerne befassen, allerdings ist mir die Optik auch sehr wichtig. Das ist das Allererste, was der Leser sieht. --Furfur ^{⁂ Diskussion} 10:06, 2. Jan. 2020 (CET)

Ich finde, dass Furfur weitgehend recht hat.

• Was es die Box angeht, entspricht sie mit 286px Breite längst nicht mehr dem Quasi-Standard von 310px.
• Eine Breite von 310px ermöglicht es, dem Bild eine Breite von 300px zu verleihen, was den Server nicht mehr belastet, sondern im Gegenteil eher entlastet, denn 300px ist auch eine der auswählbaren Thumbbreiten, weshalb der Server diese Größe oft im Cache hat.
• Bei einer Usereinstellung von 300px für Thumbs ist das Bild in der Box genauso breit wie die Thumbs, was gut aussieht.
• Monitore haben heutzutage mind. HD, also 1920x1080 Pixel und da machen 24 Pixel absolut nichts aus. Wer mobil zugreift, muss sowieso Abstriche akzeptieren.
• Ladezeiten sind nur ein Problem, wenn wieder einmal ein paar Server ausfallen. Die Internetanschlüsse sind im 5G-Zeitalter allemal schnell genug.
• Es liegt in der Natur der Berge, dass sie meistens "Hochformat" haben und demzufolge sind Bilder davon oft Hochformat. Es macht am Layout des Artikels so gut wie nichts aus, wenn ein derartiges Bild 100px höher ist, vorrausgesetzt, man platziert andere Bestandteile mit Überlegung. So sollte notfalls mit dem Magic Word <code>__TOC__</code> das TOC neben die Infobox platziert werden und die Abschnitte kurze Titel haben, damit beides nebeneinander passt.
• Wie ich in der Vergangenheit schon öfters nachgewiesen habe, ist eine Schriftskalierung von 95 % in einer Infobox sinnlos, da es nur das Rendern verschlechtert, ohne Platz zu sparen.
• Ich empfehle daher sehr dringlichst, die Box auf die in der WP heute verbreiteten 310px und die Bilder auf 300px Breite zu setzen.
• Leere Seitenstreifen sehen stümperhaft aus. Ich halte es daher für zweckmäßig, den Bildern das häufige 3:4-Hochformat zu gönnen und die Höhe demzufolge bis 400px zu erlauben. Das wäre dann die Angabe 300x400px
• Viel mehr Höhe kann man im Gegenzug durch reduzieren der Zeilenhöhe sparen.

Gruß von ÅñŧóñŜûŝî (Ð) 13:07, 2. Jan. 2020 (CET)

Da Furfur laut Antonsusi recht hat, werde ich demnächst die Bildgröße auf 300x400 begrenzen, die Schriftgröße so ändern, dass nicht durch diverses Gefrickel eine Schriftgröße von 13.4 pt in der Infobox verwendet wird, sondern die Standardschriftgröße. Ich mache das dann in allen analogen Infoboxen, um die Anlässlichkeitsprogrammierung etwas abzumildern. Ich gehe davon aus, dass Facelift immer geschrien werden kann, aber oft ohne Bedeutung ist. lg --Herzi Pinki (Diskussion) 08:16, 8. Jan. 2020 (CET)

Regionscode

Ich habe beim Porak den Regionscode verfeinert, die Infobox kommt aber mit der Info nicht klar: Der Klammerzusatz wird nicht korrekt aufgelöst. Weiß jemand Rat? NNW 12:19, 5. Nov. 2022 (CET)

Diese Änderung hats gebracht. Wo ich mir unsicher bin: was macht "maxlevel" in der Vorlage und müsste dort auch eine "1" stehen? Es müssten dann auch noch die ISO-Vorlagen der anderen Rayons angepasst werden. --тнояsтеn ⇔ 15:14, 5. Nov. 2022 (CET)

Eigentlich ergibt es keinen Sinn, dass die Schreibweise sich ändert, wenn das Level verändert wird. Ich muss nochmal suchen, wo es schon einmal Probleme mit den Levels gab, habe ich leider nicht mehr spontan parat. Eigentlich liegen die meisten Rayone auf 2 ohne 1, nur in der Autonomen Republik Nachitschewan gibt es die vollständige Reihung. Soweit ich weiß, hat das bislang keine Probleme gemacht. NNW 16:53, 5. Nov. 2022 (CET)

Der Link wird gebaut als [[lemma|Kurzname Administrationsebene]] und der Kurzname bei Level 2 ist leer. --тнояsтеn ⇔ 19:11, 5. Nov. 2022 (CET)

Bzw. so gehts auch. --тнояsтеn ⇔ 19:14, 5. Nov. 2022 (CET)

Dann werde ich mal die Vorlagen durchgehen und korrigieren. NNW 19:16, 5. Nov. 2022 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: тнояsтеn ⇔ 19:55, 5. Nov. 2022 (CET)

Kopiervorlage

Warum sind da eigentlich die bescheuerten Leerzeichen drin? Kaum jemand hat in seinem Editor eine Maschinenschrift mit gleich breiten Zeichen, ergo ergibt das im Quelltext eine Wüste.

Übrinx wäre es dienlich, wenn Dominanz und Prominenz schon automatisch drin wären. --Elop 12:59, 15. Jun. 2020 (CEST)

Bzgl. der Leerzeichen bin ich leiderschaftslos, wage aber zu behaupten, dass die Mehrheit der Nutzer eine "Maschinenschrift" im Editor hat. --тнояsтеn ⇔ 20:57, 15. Jun. 2020 (CEST)

Ich bin bzgl. Dominanz und Prominenz leidenschaftslos ;-) Die an der zeichenzahl orientierte bündige Ausrichtung ermöglicht zumindest eine übersichtliche Darstellung bei Verwendung eines monospaced Font. Ich habe im übrigen auf dei Schnelle gar nicht herausgefunden, wie man den Wiki-Editor überhaupt auf Proportionalschrift umstellen kann. Kann man das (wenn man in einem "Offline-Editor" mit proportionalem Font editiert, ist man meiner Meinung nach selber schuld)? --Cactus26 (Diskussion) 07:50, 16. Jun. 2020 (CEST)

Nachtrag: "bescheuert" ist übrinx ein großartiger Einstieg in eine sachliche Diskussion.--Cactus26 (Diskussion) 08:07, 16. Jun. 2020 (CEST)

Einstellungen → Bearbeiten → Schriftart für den Text im Bearbeitungsfenster

Da kann man mit Serifen, ohne und feste Zeichenbreite wählen. Und wenn man richtige Texte lesen will, wird man sicher keine feste Zeichenbreite wählen.

Und wenn man keine feste Zeichenbreite hat, sind die Leerzeichen völliger Humbug.

Da, wo ich editiere, haben die Boxen auch nirgendwo mehr die Leerzeichen (da fällt es mir ja auf: Ich baue Dominanz und Prominenz ein, die dann als einzige Einträge Leerzeichenberge haben). Flußbox und Naturraumbox haben schon per default keine.

Selbstredend wollte ich die Leerzeichen nicht verletzen. Das sind superliebe Fonts - nur nicht fürs Rudel geeignet. --Elop 08:56, 16. Jun. 2020 (CEST)

Danke für den Hinweis, wo man einen proportionalen Font für den WP-Editor einestellen kann. Ich habe aber zumindest gewisse Zweifel, dass tats. die Mehrheit für den Quellcode eine Proportionalschrift verwendet. Und wie gesagt: Die an der Zeichenzahl orientierte bündige Ausrichtung bietet zumindest eine Chance, eine übersichtliche Darstellung einer Vorlagenverwendung zu bekommen. Wenn man die verschenkt, ist man selber schuld und es ist meiner Meinung nach nicht gerechtfertigt, diese Möglichkeit den anderen zu verbauen, die nicht so proportional-font-süchtig sind. Mit IT-Taxonomie scheinst Du Dich schwer zu tun Leerzeichen sind keine Fonts, es sind Zeichen oder Character. Lieb sind sie natürlich schon. Bei {{Taxobox}} werden sie bislang noch nicht beschimpft, es scheint also noch sichere Refugien zu geben.--Cactus26 (Diskussion) 09:38, 16. Jun. 2020 (CEST)

Du widersprichst Dir gerade auf der ganzen Linie selber! Wenn eben niemand Proportionalschrift hat, sieht auch niemand irgendeine "bündige Ausrichtung". Die existiert ausschließlich in der Kopiervorlage!

Das:

|BILD1              =

|BILD1-BESCHREIBUNG =

sieht im Editor so:

|BILD1              =

|BILD1-BESCHREIBUNG =

aus

Du müßtest schon mal selber die Kopiervorlage im Editor anschauen. Du könntest auch mal Stichproben machen, wie selten die Box mit bescheuerten Leerzeichen genutzt wird. Die schnippeln die Bearbeiter im Regelfall raus. Wobei die meisten eh diese Seite hier nicht kennen und einfach Boxen aus anderen Artikeln überschreiben. --Elop 14:48, 16. Jun. 2020 (CEST)

Kann es sein, dass Du gerade Proportionalschrift und Monospaced verwechsest? Schau doch die Bergiffe vorher nach, wenn Du sie nicht sicher auseinanderhalten kannst bevor Du anderen widersprüchliche Aussagen unterstelltst.--Cactus26 (Diskussion) 08:44, 17. Jun. 2020 (CEST)

Ich glaube, so langsam verzweifel ich ...

Den Begriff "monospaced" hast hier ausschließlich Du verwendet - ich selber habe ihn in meinem Leben noch nicht verwendet. Dabei kam die Aussage:

>>Die an der zeichenzahl orientierte bündige Ausrichtung ermöglicht zumindest eine übersichtliche Darstellung bei Verwendung eines monospaced Font. << (Cactus26(Diskussion) 07:50, 16. Jun. 2020 (CEST))

Dieser Satz ist mir bereits nicht begreiflich. Wenn jeder Buchstabe seine eigene Breite hat, wie kann man dann per abgezählten Leerzeichen bündig ausrichten?

Zwischen "BILD1" und "=" sind 14 Leerzeichen, zwischen "BILD1-BESCHREIBUNG" und "= ist es genau eines. Die Zeichenzahl ist jeweils gleich.

Und ich frage nochmal ganz explizit:

Frage 1: Siehst Du oben in meinem Post von 14:48, 16. Jun. 2020 (CEST) eine bündige Ausrichtung der Gleichheitszeichen?

Frage 2: Siehst Du bei Verwendung der umseitigen Vorlage in Deinem Editor eine bündige Ausrichtung der Gleichheitszeichen?

--Elop 09:28, 27. Sep. 2020 (CEST)

Hinweis:

Die Leerzeichen hatte Herzi am am 3. März 2018 eingefügt. Das erklärt auch, warum mir das gerade erst aufgefallen ist - denn ich habe neulich zum ersten Mal seit Jahren einen Bergartikel erstangelegt. Berge hatte in meinem Beritt meistens der leider verschollene Kollege TOMM angelegt - der es auch nicht mehr bemerkt haben konnte. --Elop 12:27, 28. Sep. 2020 (CEST)

Ich finde, für bescheuerte Leerzeichenfragen wäre ein MB mindestens angebracht :-) Ich habe damals die bescheuerten Leerzeichen nach einer Analyse der Verwendungen eingefügt, die Mehrzahl hatte bescheuerte Leerzeichen. Wenn ich mich recht entsinne. Jedenfalls, wollte man die bescheuerten Leerzeichen weghaben, dann sollte ein Bot alle Bergartikel dahingehend überarbeiten und neu formatieren. Nur die Formatvorlage zu ändern macht wenig Sinn. Bei einer Umstellung wären auch diverse Autoformatter anzupassen. Ich habe übrigens einen monospaced Zeichensatz in meinem Editor und meine, die Mehrzahl der BenutzerInnen stellt diesbezügliche Defaultwerte nicht um. Zu Dominanz und Schartenhöhe bin ich der Meinung, dass das Herausmessen aus Karten WP:OR ist, deshalb sind die Parameter extra.

Aktuelle Statistik:

• |NAME : 8109 Treffer
• | NAME : 7792 Treffer
•  | NAME : 77 Treffer

---

• NAME  += : 8009 Treffer (>1 Zwischenräume vor =)
• NAME= : 7202 Treffer (0)
• NAME = : 653 Treffer (1)

---

davon

• NAME  +=\n : 6014 Treffer (>1 / ohne Wert)
• NAME=\n : 2165 Treffer (0 / ohne Wert)
• NAME =\n : 125 Treffer (1 / ohne Wert)

---

an BREITENGRAD gemessen:

• 0 Zwischenräume vor = : 8642 Treffer
• 1 Zwischenräume vor = : 487 Treffer
• 2 Zwischenräume vor = : 2 Treffer
• 5 Zwischenräume vor = : 390 Treffer
• 6 Zwischenräume vor = : 7723 Treffer
• 7 Zwischenräume vor = : 35 Treffer
• 8 Zwischenräume vor = : 802 Treffer (entspricht Codeblock aus Vorlage)
• 9 Zwischenräume vor = : 261 Treffer
• in Summe >2 Zwischenräume vor = : 9239 Treffer

Inzwischen ist das Verhältnis ausgewogen, eine Geschmacksfrage halt.

lg --Herzi Pinki (Diskussion) 14:10, 28. Sep. 2020 (CEST)

Wieso müßte da ein Bot in den Bergartikeln was machen? Ich rede ja hier von der Kopiervorlage. Die nutze ich nur, wenn ich neu anlege. Und wenn ich die auffülle, tut das niemand, der im Editor eine Proportionalschriftart hätte.

Auf der Diskseite sieht das ja durchaus töfte aus, denn da sehe auch ich die Gleichheitszeichen alle untereinander. Im Artikel jedoch bezweifle ich, daß selbst jemand mit Proportionalschriftart da irgendwelche Vorteile von hätte.

Ich selber nutze noch häufiger als die Bergbox dei Infobox Fluss und die Infobox Naturraum in Deutschland. Deren zweite spart sogar die Leerzeichen vor dem "=".

8.000:8.000 verblüfft mich (ich sehe sehr selten bestehende Boxen mit Leerzeichenverschwendung). Das zeugt aber zumindest davon, daß es vor zweieinhalb Jahren eine Mehrheit ohne gegeben hatte.

Beim Breitengrad hat die Vorlage 8 Leerzeichen, die Artikel haben aber deutlich häufiger 6? Das kann ja nur heißen, daß nur eine Minderheit der Artikel mehr als ein Bild hat (was natürlich meistens auch Sinn macht).

Wollte Deinen Test mal mit der Flußbox machen, aber schon bei null Leerzeichen versagt da die Suchfunktion, sobald ich die dritten 5.000 abrufen will.

Ob man seinen Editor umstellt, hängt auch davon ab, was man damit macht. Ich selber bin vor allem Textfritze und möchte ganz gerne schon beim Formulieren sehen können, was ich da schreibe. Wer hingegen mit Skripten auf Fehlersuche ist, nur Boxen und Tabellen füllt oder ausschließlich Fotos einfügt, dem kann es erst einmal egal sein. Ich habe den Editor sogar serifenfrei, was es für mich in der Summe zwar besser lesbar macht, aber den Nachteil hat, daß mir OCR-Fehler nicht auffallen (komisch, der Link lnseI ist rot - den Artikel sollte ich dringend mal anlegen!). Manche Wörter oder Codes, wo es nicht eindeutig ist, muß ich sogar kopieren, in eine Leermail füllen und dort die Schriftart umstellen.

Zu Dominanz und Prominenz:

Ja, meistens bleibt dann nur OR (wobei unsere Koordinateneingaben auch OR sind - nur eben eine, wo man nicht so viele Fehler machen kann).

Zu den Hauptbergen findet man mitunter noch Quellen. Aber auch die sind u. U, mit Vorsicht zu genießen, da auch vor dem Internet Leute schon gerne voneinander abgeschrieben haben. Die Dill (Fluss) hatte bei uns und überall sonst mal, ähnlich wie der Rhein, eine grob falsche Längenangabe. Und als ich die mit der bestmöglichenQuelle (Gewässerstationierung im Kartendienst - da ist nicht einmal +/−-Rechnung nötig), wollte das unser Wetzlarer Lokalpatriot nicht auf sich sitzen lassen. Das hatte schlicht und einfach mal im 19. Jahrhundert falsch im Lexikon gestanden und war seither immer von überall übernommen worden.

Dominanzen und Prominenzen würde ich sogar bei bekannten Hauptbergen immer prüfen, vor allem die Prominenz! Wir hatten auch schon viele von Highrisepages übernommen, wo sich etliche als falsch herausstellten!

Es gab mal eine Diskussion zu Rainer Lipperts Altbaumartikeln. Da haben sie die Umfangswerte rausgestrichen, wenn sie von ihm gemessen wurden. Dabei ist das so ziemlich die zuverlässigste Quelle, die man sich da vorstellen kann: Erstens nimmt er immer exakt die gleichen Kriterien, zweitens mißt er nach ein paar Jahren neu nach - wo spätestens grobe Fehler auffallen würden.

Wenn hingegen die Webpräsenz einer Försterei erklärt (oder ein vom Förster geschriebenes Buch behauptet), die Eiche am Forsthaus xy habe 8 Meter Stammumfang, so ist das eher unzuverlässig. Ich würde auch eine Eigenangabe von Genitallängen nicht immer für zwingend zuverlässig erachten (wobei wir glücklicherweise keine Boxen mit diesem Eintrag haben).

Aber gerade weil das (ich bin wieder bei den Bergen) bis zu gewissem Maße OR ist, ist es sinnvoll, daß da z. B. möglichst genau die Scharte angegeben wird - am besten mit Koordinaten - denn dann weiß der Zweifelde auch, was er zu prüfen hat und was ein Gegenbeweis sein könnte. Und da man oft nur durch Höhenlinien abschätzen kann (im Mittelgebirgsbereich hat man lediglich in NRW mit TIM online Schartenpunkte aus der GK5 und DGM), müßte da eigentlich noch ein Genauigkeursparameter rein.

Selbst die Dominanz ist so richtig "einfach" nur dann zu bestimmen, wenn sie besonders hoch oder niedrig ist. Beim Großen Feldberg weiß jeder geographisch Kundige, daß er in Norden, Westen und Süden gar nicht erst suchen muß - und letztlich nach Ü880ern in der Rhön schauen. Und beim Kleinen ist klar, daß man die entsprechende Höhenlinie beim großen Bruder suchen muß. Aber z. B. bei der Mardorfer Kuppe hat man sehr viele Kandidaten und muß sehr gewissenhaft absuchen. Übrinx auch beim Kompass, der in NRW liegt und daher das bestmögliche Kartendienstmaterial hat.

Ich habe selber schon viele Angaben, Literatur oder Wikipedianer, falsifizieren können. Wobei Wikipedianer die Dominanz auch gerne von Gipfel zu Gipfel messen - was um 20 % und mehr fehlerhaft sein kann (auch wenn es beim Hegekopf zum Langenberg keine so riesige Rolle spielt).

Eigentlich kann man dergleichen nur zuverlässig machen, wenn man es regelmäßig macht. Wenn einer mit Erfahrung das gesamte Lechquellengebirge durchackert, ist das mit großer Wahrscheinlichkeit relativ korrekt. Wenn sowas hingegen jeweils nur jemand erstmals und ausschließlich für seinen Lieblingsberg macht, ist es mit größerer Wahrscheinlichleit falsch. Und zwar auch dann, wenn er es in ein Buch schreibt.

DGM sollte all das eigentlich in Verbindung mit entsprechenden Skripten superzuverlässig können. Scheint aber bislang schon von der Datengrundlage her schwer möglich - zumindest sind viele Schartenpunkte gar nicht verzeichnet. Und auch die Höhenpunkte weichen zuweilen je nach Maßstab knapp voneinander ab. Was ja nur heißen kann, das mindestens einer der beiden Algorithmen den höchsten Punkt gar nicht gefunden hat.

Zurück zu den Leerzeichen:

Wenn es hier tatsächlich Leerzeichenfreaks geben sollte (hatte ich nicht für möglich gehalten), dann können in der Doku ja zwei Kopiervorlagen stehen! Dann erführen wir auch tatsächlich, inwiefern das "Geschmackssache" wäre. Ich persönlich vermute nämlich, daß die Ersteller von Amöneburg (Berg), Mardorfer Kuppe oder Bastenberg (Ramsbeck) schlicht und einfach zu faul waren, die Leerzeichenwüsten zu löschen. --Elop 17:04, 28. Sep. 2020 (CEST)

von mir kommt weniger als Antwort: Mut zur Lücke bei Dominanz und Schartenhöhe. lg --Herzi Pinki (Diskussion) 17:27, 28. Sep. 2020 (CEST)

Es kommt doch mehr: in Kategorie:Wikipedia:Vorlagenfehler/Vorlage:Infobox Berg haben sich 1977 Parameterfehler jenseits der Leerzeichen angesammelt. --Herzi Pinki (Diskussion) 17:35, 28. Sep. 2020 (CEST)

Den hier hatte ich extra eingebaut, um Dich zu ärgern! --Elop 20:11, 28. Sep. 2020 (CEST)

Entschuldigt bitte, dass ich nicht die ganze Disk. lese. Zur Eingangsfrage: Ich nutze zum Editieren des Quelltextes einen monospaced Font, insofern profitiere ich von den Leerzeichen, die Darstellung ist übersichtlich, ich bin dafür das zu behalten. Ich vermute, dass viele mit Monospaced-Fonts im Quelltext-Editor arbeiten, nur so kann ich mir erklären, dass u.a. von den Biologen (siehe Vorlage:Taxobox) noch nie ein "Bescheuerter-Leerzeichen-Vorwurf" kam.--Cactus26 (Diskussion) 09:28, 2. Okt. 2020 (CEST)

Herzi hatte ja schon ermittelt, daß die aktuelle Verwendung in etwa halbe-halbe ist. In der Taxobox waren schon von der ersten Version an die Leerzeichen.

Ich selber hatte ja bislang fast nur die Flußbox, die Naturraumbox, die Bergbox (die aber seit Jahren nicht per Neueinstellung von Artikeln) und Boxen von Verwaltungseinheiten genutzt. Eigenständige Gemeinden wiederum habe ich kaum oder gar nicht angelegt, da, zumindest im deutschsprachigen Raum, 2006 schon fast alle einen Artikel hatten.

Die Vorlage:Infobox Ortsgliederung, die ich auch schon bei Neuanlagen verwendet habe, hat übrinx eine Mischform: Da sind bei gleicher Zeichenbrerite doe Einträge nur je in Blöcken bündig. Was es gegebenenfalls insbesondere einfacher macht, den gesuchten Block zu finden.

Frage aber an die Editoren mit gleicher Zeichenbreite:

Wäre eine Vorlage wie Benutzer:Elop/Bergbox für Euch eine Behinderung? Und wie ist es, wenn Ihr nur ein kleines Editierfeld (Handy) habt, sodaß LÄNGENGRAD = 7.123456 oder |BILD = Dinaudampfschiffahrtsgesellschafst-Versammlungsberg von Westnordwesten aus.jpg zu einem Umbrich führt?

Andere Frage:

Wie ist das für Leute mit Visual Editor? --Elop 10:51, 2. Okt. 2020 (CEST)

"Es kann nicht mehr als eine primäre Auszeichnung angegeben werden."

Auf Schloss Biedenkopf gibt die Infobox aus: "Es kann nicht mehr als eine primäre Auszeichnung angegeben werden." – Wo liegt der Fehler? --Hasenläufer (Diskussion) 21:34, 23. Dez. 2022 (CET)

Vermutlich gibt es ein Problem mit der gleichzeitigen Verwendung der {{Infobox Burg}}. --Hasenläufer (Diskussion) 22:17, 23. Dez. 2022 (CET)

Das wird es wohl sein. Das Angeben der identischen Koordinaten in beiden Infoboxen löst das Problem aber auch nicht und weglassen kann man den Parameter auch nicht. Gibt es da eine Lösung? Ist ja sehr unschön so... Grüße --Joma2411 (Diskussion) 23:01, 23. Dez. 2022 (CET)

Der Parameter NEBENBOX sollte das lösen können. … «« Man77 »» Alle Angaben ohne Gewehr. 23:23, 23. Dez. 2022 (CET)

Ja, so ist es. Besten Dank für die Unterstützung! --Hasenläufer (Diskussion) 08:37, 24. Dez. 2022 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: --Hasenläufer (Diskussion) 19:40, 24. Dez. 2022 (CET)