Quelltext der Seite Vorlage Diskussion:Infobox Berg/Archiv/2

{{Archiv}}

== 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.[[Benutzer:Caumasee|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 [[Benutzer:Herzi Pinki/Vorlage:PositionskarteX ISO/Test|diese]] Initiative von Herzi Pinki die optimale Lösung. --[[Benutzer:Svíčková|Svíčková]]  <small>  [[Benutzer Diskussion:Svíčková|na smetaně]]  </small> 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.<br />MfG --[[Benutzer:TOMM|TOMM]] 09:13, 21. Mai 2011 (CEST)
:du kannst HÖHE-ANMERKUNG dafür verwenden. lg --[[Benutzer:Herzi Pinki|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, --[[Benutzer:Svíčková|Svíčková]]  <small>  [[Benutzer Diskussion:Svíčková|na smetaně]]  </small> 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? --[[Benutzer:Capricorn4049|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. --[[Benutzer:Langläufer|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 --[[Benutzer:Herzi Pinki|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. --[[Benutzer:Isjc99|Isjc99]] 21:58, 13. Nov. 2011 (CET)
: Zum Verlinken von Kartendiensten sollte ausschließlich die Koordinaten-Einbindung mit Absprung auf die zentrale [http://toolserver.org/~geohack/geohack.php?pagename=Rifugio_Pian_Grand&language=de&params=46.413271_N_9.163095_E_dim:50_region:CH_type:landmark 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. --[[Benutzer:Alexrk2|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"'' --[[Benutzer:Isjc99|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, --[[Benutzer:Svíčková|Svíčková]]  <small>  [[Benutzer Diskussion:Svíčková|na smetaně]]  </small> 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 ''Wander''karten 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"'' <small>(''nicht [[Hilfe:Signatur|signierter]] Beitrag von'' [[Benutzer:Isjc99|Isjc99]] ([[Benutzer Diskussion:Isjc99|Diskussion]]&nbsp;|&nbsp;[[Spezial:Beiträge/Isjc99|Beiträge]]) 07:50, 16. Nov. 2011 (CET)) </small>
:Man könnte das Kartenblatt doch automatisch aus der Koordinate bestimmen! Wäre das was für eine neue Vorlage? Oder bei geohack? --[[Benutzer:Langläufer|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. <small>(''nicht [[Hilfe:Signatur|signierter]] Beitrag von'' [[Benutzer:Isjc99|Isjc99]] ([[Benutzer Diskussion:Isjc99|Diskussion]]&nbsp;|&nbsp;[[Spezial:Beiträge/Isjc99|Beiträge]]) 20:34, 16. Nov. 2011 (CET)) </small>

Diese Möglichkeit (siehe Vorlagendoku) gibt es schon seit Anbeginn der Zeitrechnung (Entstehung der Infobox) mit dem Parameter TOPO-KARTE. [http://de.wikipedia.org/wiki/Spezial:Linkliste/Vorlage:Infobox_Berg/Wartung/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 --[[Benutzer:Herzi Pinki|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. --[[Benutzer:Isjc99|Isjc99]] 19:47, 19. Nov. 2011 (CET)

Ich habe die Legende in der Vorlage entsprechend dieser Diskussion angepast. --[[Benutzer:Isjc99|Isjc99]] 22:45, 30. Nov. 2011 (CET)
== Vorlagenanpassung Schartenhöhe/Bezugsberg ==

Ergebnis [http://de.wikipedia.org/w/index.php?title=Diskussion:Schartenh%C3%B6he&oldid=95513644#.C3.9Cberarbeitung_vom_18._Oktober_2011 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?--[[Benutzer:Cactus26|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. --[[Benutzer:Langläufer|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.--[[Benutzer:Cactus26|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. --[[Benutzer:Langläufer|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.--[[Benutzer:Cactus26|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. --[[Benutzer:Svíčková|Svíčková]]  <small>  [[Benutzer Diskussion:Svíčková|na smetaně]]  </small> 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 --[[Benutzer:Herzi Pinki|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 --[[Benutzer:Herzi Pinki|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....--[[Benutzer:Cactus26|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? --[[Benutzer:Klaron|Klaron]] 08:17, 9. Nov. 2011 (CET)
:hast du ein Beispiel? Ich habe einen beliebigen Versuch gestartet, und da hat es funktioniert. lg --[[Benutzer:Herzi Pinki|Herzi Pinki]] 18:57, 19. Nov. 2011 (CET)
::[http://de.wikipedia.org/w/index.php?title=Cerro_Morado&oldid=96571108 Hier] ist ein Beispiel. Werden die Koordinaten dezimal angegeben, erscheint rechts oben im Artikel die Meldung "Koordinaten fehlen". --[[Benutzer:Klaron|Klaron]] 12:19, 30. Nov. 2011 (CET)
:::Es liegt an was anderem, die Vorlage erwartet [http://de.wikipedia.org/w/index.php?title=Cerro_Morado&diff=prev&oldid=96580096 groß geschr. Parameter]. Viele Grüße --[[Benutzer:Cactus26|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. --[[Benutzer:Klaron|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.--[[Benutzer:Cactus26|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. --[[Benutzer:Klaron|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 --[[Benutzer:Herzi Pinki|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.--[[Benutzer:Cactus26|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? --[[Benutzer:Klaron|Klaron]] 18:43, 7. Dez. 2011 (CET)
::::::::::[http://toolserver.org/%7Ekolossos/templatetiger/template-parameter.php?lang=dewiki&template=Infobox%20Berg Hier] hast du eine Liste der verwendeten Parameter der Infobox Berg, auch der falschen. Aktualisierung erfolgt allerdings in unbekannten Intervallen. Mithilfe ist willkommen. [http://www.mediawiki.org/wiki/Bugzilla#Requesting_a_feature 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 --[[Benutzer:Herzi Pinki|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. --[[Benutzer:Klaron|Klaron]] 16:51, 23. Dez. 2011 (CET)

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

Hallo zusammen,

ich hatte mal [[Benutzer_Diskussion:TOMM/Archiv/2010#Genauigkeit_von_Höhenangaben|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ß --[[Benutzer:SteveK|SteveK]] [[Benutzer_Diskussion:SteveK|?!]] 21:58, 21. Dez. 2011 (CET)

: Sehr gute Idee!<br />MfG --[[Benutzer:TOMM|TOMM]] 22:06, 21. Dez. 2011 (CET)
:Kleingt plausibel, [x] make it so. --[[Benutzer:H-stt|h-stt]] [[Benutzer Diskussion:H-stt|<small>!?</small>]] 11:18, 23. Dez. 2011 (CET)
== Änderungen vom 7. Januar ==

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

# 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. 
# Syntax <u>funktionsgleich</u> 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.
# 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.
# 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 [[Benutzer:Antonsusi| '''Å'''ñŧóñŜûŝî]]&nbsp;[[Benutzer_Diskussion:Antonsusi|'''(Ð)''']] 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 <nowiki><nocinclude>-</nocinclude></nowiki> 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 Diskussion:Berge und Gebirge|Portal]]. 

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

# 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. 
# Die Leerzeile ist leicht zu beheben.
# Bilderhöhe
## 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.
## 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).
# 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.
# Parsererror habe ich bei meinem Stichprobenaufruf (ca 10 Seiten) nicht entdeckt, aber das ist auch reparierbar
# Der Ausschluss anderer NRs ist nur ein umhüllendes If, das wäre auch änderbar.
# 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. 
# 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.
# Das Portal kannte ich noch gar nicht. Werde mich mal dort melden.
:[[Benutzer:Antonsusi| '''Å'''ñŧóñŜûŝî]]&nbsp;[[Benutzer_Diskussion:Antonsusi|'''(Ð)''']] 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 --[[Benutzer:Herzi Pinki|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 --[[Benutzer:Herzi Pinki|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.--[[Benutzer:Cactus26|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:
::* <s>Die Noincludes wegnehmen.</s> 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 [[Benutzer:Antonsusi| '''Å'''ñŧóñŜûŝî]]&nbsp;[[Benutzer_Diskussion:Antonsusi|'''(Ð)''']] 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 --[[Benutzer:Herzi Pinki|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. [[Benutzer:Antonsusi| '''Å'''ñŧóñŜûŝî]]&nbsp;[[Benutzer_Diskussion:Antonsusi|'''(Ð)''']] 17:11, 8. Jan. 2012 (CET)
::: Danke für die Fehlerkorrektur. --[[Benutzer:Herzi Pinki|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.--[[Benutzer:Slimguy|Slimguy]] 20:48, 1. Feb. 2012 (CET)
::Seite mit einem Beispiel ? [[Benutzer:Antonsusi| '''Å'''ñŧóñŜûŝî]]&nbsp;[[Benutzer_Diskussion:Antonsusi|'''(Ð)''']] 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.--[[Benutzer:Slimguy|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 [http://wikitech.wikimedia.org/view/Server_admin_log hier].--[[Benutzer:Wdwd|wdwd]] 23:33, 1. Feb. 2012 (CET)
== "Expression-Fehler: Unerwarteter Operator <" ==

Dieser Fehler tritt [http://de.wikipedia.org/w/index.php?title=Tendaguru&oldid=99213879 hier auf]. [http://de.wikipedia.org/w/index.php?title=Diskussion:Tendaguru&oldid=99313292#Infobox Diskussion]. Was kann die Ursache sein? --[[Benutzer:Daniel Mietchen|Daniel Mietchen]] 15:18, 6. Feb. 2012 (CET)
: [{{fullurl:Vorlage:Infobox Berg|diff=99342112}} behoben]. --[[Benutzer:Fomafix|Fomafix]] 20:53, 6. Feb. 2012 (CET)
::[http://de.wikipedia.org/w/index.php?title=Tendaguru&action=historysubmit&diff=99342184&oldid=99276598 Danke]! --[[Benutzer:Daniel Mietchen|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ß, --[[Benutzer:J. Patrick Fischer|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ß, --[[Benutzer:Flominator|Flominator]] 19:21, 18. Feb. 2012 (CET)

::Klappt! Danke! --[[Benutzer:J. Patrick Fischer|JPF]] ''just another user'' 22:07, 18. Feb. 2012 (CET)
:::macht bei mir eine [http://de.wikipedia.org/w/index.php?title=Paitchau&printable=yes leere Tabellenzeile], statt keiner (FF 11 auf OS X). lg --[[Benutzer:Herzi Pinki|Herzi Pinki]] ([[Benutzer Diskussion: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-Sehschwäche|rot-grün]] ist es für viele gleich ganz weg. --[[Spezial:Beiträge/88.77.190.111|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 --[[Benutzer:Herzi Pinki|Herzi Pinki]] ([[Benutzer Diskussion: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? --[[Spezial:Beiträge/84.178.49.152|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.  [[Benutzer:Antonsusi| '''Å'''ñŧóñŜûŝî]]&nbsp;[[Benutzer_Diskussion:Antonsusi|'''(Ð)''']] 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. --[[Spezial:Beiträge/84.178.31.87|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.<br />[[Benutzer:Watzmann|Watzmann]]<sup> [[Benutzer Diskussion:Watzmann|Disk.]]</sup>  20:06, 27. Jun. 2012 (CEST)
{| class="wikitable float-right" style="width:320px; margin-left:4em;"
| style="width:160px;"|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. 
|}
{{Infobox Berg
| NAME             = Test Spaltenbreiten
| BILD             =
| BILDBESCHREIBUNG =
| HÖHE             = 4810
| HÖHE-BEZUG       = FX
| HÖHE-ANMERKUNG   = ({{Höhe|4792|FX}} ohne Eiskappe)
| LAGE             = [[Frankreich]] und [[Italien]]
| GEBIRGE          = [[Mont-Blanc-Gruppe]]
| BREITENGRAD      = 45/49/57/N
| LÄNGENGRAD       = 6/51/51.5/E
| REGION-ISO       = FR-74/IT-AO
| POSKARTE         = Alpen
| DOMINANZ         = 2812
| DOMINANZ-BEZUG   = [[Kjukjurtlju]]
| SCHARTENHÖHE     = 4697
| SCHARTE          = Beim [[Kubenasee]]
| TYP              = 
| LETZTE ERUPTION  = 
| GESTEIN          = [[Granit]]
| ALTER            = 
| ERSTBESTEIGUNG   = [[8. August]] [[1786]], [[Jacques Balmat]] und [[Michel-Gabriel Paccard]]
| ERSCHLIESSUNG    = 
| 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.
}}
:::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. [[Benutzer:Antonsusi| '''Å'''ñŧóñŜûŝî]]&nbsp;[[Benutzer_Diskussion:Antonsusi|'''(Ð)''']] 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. <br />[[Benutzer:Watzmann|Watzmann]]<sup> [[Benutzer Diskussion:Watzmann|Disk.]]</sup>  06:16, 28. Jun. 2012 (CEST)
:::::zustimmung. [[Benutzer:Langläufer|Langläufer]] ([[Benutzer Diskussion: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. [[Benutzer:Antonsusi| '''Å'''ñŧóñŜûŝî]]&nbsp;[[Benutzer_Diskussion:Antonsusi|'''(Ð)''']] 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.<br />[[Benutzer:Watzmann|Watzmann]]<sup> [[Benutzer Diskussion:Watzmann|Disk.]]</sup>  19:01, 28. Jun. 2012 (CEST)
::::::Das wäre sogar präziser, denn die "Lage" ist auch Geographisch. --[[Benutzer:Langläufer|Langläufer]] ([[Benutzer Diskussion: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. --[[Benutzer:Milseburg|Milseburg]] ([[Benutzer Diskussion: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 --[[Benutzer:Herzi Pinki|Herzi Pinki]] ([[Benutzer Diskussion: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 (Berg)|Habicht]], [[Drei Schwestern (Berg)|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 [[Hochkönig (Bergmassiv)|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. -- [[Benutzer:Gurpitscheck|Gurpitscheck]] ([[Benutzer Diskussion: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? --[[Benutzer:Sextant|Sextant]] ([[Benutzer Diskussion:Sextant|Diskussion]]) 21:22, 27. Aug. 2012 (CEST)
:Repariert ([http://de.wikipedia.org/w/index.php?title=Vorlage:Info_ISO-3166-2:NZ-TAS&diff=prev&oldid=109468537], [http://de.wikipedia.org/w/index.php?title=Vorlage%3AInfo_ISO-3166-2%3ANZ-WGN&diff=109468585&oldid=70201523]). --[[Benutzer:Thgoiter|тнояsтеn]] [[Benutzer Diskussion:Thgoiter|⇔]] 14:34, 18. Okt. 2012 (CEST)
:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Thgoiter|тнояsтеn]] [[Benutzer Diskussion:Thgoiter|⇔]] 14:34, 18. Okt. 2012 (CEST)</small>

== 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! --[[Benutzer:Langläufer|Langläufer]] ([[Benutzer Diskussion:Langläufer|Diskussion]]) 11:24, 31. Jul. 2012 (CEST)
:[http://de.wikipedia.org/w/index.php?title=Vorlage%3AInfobox_Berg&diff=109493664&oldid=108693199 done] --[[Benutzer:darkking3|darkking3]] <sup><small>[[Benutzer Diskussion:darkking3|&#1337;]]</small></sup>  08:49, 19. Okt. 2012 (CEST)
:<small>Archivierung dieses Abschnittes wurde gewünscht von: --[[Benutzer:darkking3|darkking3]] <sup><small>[[Benutzer Diskussion:darkking3|&#1337;]]</small></sup>  08:48, 19. Okt. 2012 (CEST)</small>
== Skalierung Positionskarte ==

Aufgrund der Restultate beim Einsatz der {{tl|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æ]].--[[Benutzer:Cactus26|Cactus26]] ([[Benutzer Diskussion:Cactus26|Diskussion]]) 16:09, 22. Feb. 2013 (CET)
:umgesetzt, siehe [http://de.wikipedia.org/w/index.php?title=Vorlage:Infobox_Berg&diff=114785517&oldid=114234500].--[[Benutzer:Cactus26|Cactus26]] ([[Benutzer Diskussion: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 [[benutzer:Cactus26/Schneeferner|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: [http://de.wikipedia.org/w/index.php?title=Benutzer%3ACactus26%2FInfobox_Gletscher&diff=111886103&oldid=111885831].--[[Benutzer:Cactus26|Cactus26]] ([[Benutzer Diskussion:Cactus26|Diskussion]]) 09:32, 20. Dez. 2012 (CET)
:umgesetzt, siehe [http://de.wikipedia.org/w/index.php?title=Vorlage:Infobox_Berg&diff=114785517&oldid=114234500].--[[Benutzer:Cactus26|Cactus26]] ([[Benutzer Diskussion: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 --[[Benutzer:Herzi Pinki|Herzi Pinki]] ([[Benutzer Diskussion: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 {{tl|Infobox Gletscher}} den Text entspr. umgestellt. Ich schlage vor, hier ebenfalls das Spaltenpräfix entspr. zu setzen (analog zu {{tl|Infobox Pass}}, {{tl|Infobox Gebirgsgruppe}}, {{tl|Infobox Naturraum in Deutschland}}, ...).--[[Benutzer:Cactus26|Cactus26]] ([[Benutzer Diskussion:Cactus26|Diskussion]]) 13:45, 8. Mär. 2013 (CET)

:ok --[[Benutzer:Herzi Pinki|Herzi Pinki]] ([[Benutzer Diskussion:Herzi Pinki|Diskussion]]) 00:23, 10. Mär. 2013 (CET)
::danke für die Rückmeldung. Habe es umgesetzt.--[[Benutzer:Cactus26|Cactus26]] ([[Benutzer Diskussion: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! --[[Benutzer:Comanderkeen|Comanderkeen]] ([[Benutzer Diskussion: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 [[Geoid]]s) 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. --[[Benutzer:Alexrk2|alexrk]] ([[Benutzer Diskussion:Alexrk2|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! --[[Benutzer:Comanderkeen|Comanderkeen]] ([[Benutzer Diskussion: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. --[[Benutzer:Milseburg|Milseburg]] ([[Benutzer Diskussion: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. --[[Benutzer:Comanderkeen|Comanderkeen]] ([[Benutzer Diskussion: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. --[[Benutzer:Rolf-Dresden|Rolf-Dresden]] ([[Benutzer Diskussion: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. --[[Spezial:Beiträge/79.216.218.67|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? --[[Benutzer:Rolf-Dresden|Rolf-Dresden]] ([[Benutzer Diskussion:Rolf-Dresden|Diskussion]]) 09:45, 2. Dez. 2012 (CET)
:::::::Eben, deshalb ist die Dezimetergenauigkeit ja Pseudogenauigkeit. --[[Spezial:Beiträge/79.216.223.17|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.<br />[[Benutzer:Watzmann|Watzmann]]<sup> [[Benutzer Diskussion:Watzmann|Disk.]]</sup>  11:43, 2. Dez. 2012 (CET)

[[File:Fichtelberghaus Juli 2010.jpg|thumb|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 [http://www.harzlife.de/top/brockenhoehe.html 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. --[[Benutzer:Alexrk2|alexrk]] ([[Benutzer Diskussion:Alexrk2|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--[[Benutzer:Comanderkeen|Comanderkeen]] ([[Benutzer Diskussion: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 ;-) --[[Benutzer:Svíčková|Svíčková]]  <small>  [[Benutzer Diskussion:Svíčková|na smetaně]]  </small> 16:15, 2. Dez. 2012 (CET)
<small> 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". --[[Benutzer:Alma|Alma]] ([[Benutzer Diskussion:Alma|Diskussion]]) 08:46, 14. Dez. 2012 (CET) </small>
:::Ich war bzgl des Eiskappenproblems vom Mt. Everest ausgegangen, siehe [[Mount_Everest#H.C3.B6henangaben_und_-messungen|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. --[[Benutzer:Alexrk2|alexrk]] ([[Benutzer Diskussion:Alexrk2|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. --[[Benutzer:Milseburg|Milseburg]] ([[Benutzer Diskussion:Milseburg|Diskussion]])

{{anker|herzi pinki}}Hallo mitsammen, dachte immer ich hätte das mit den ganzen Metern geschrieben, [http://de.wikipedia.org/w/index.php?title=Vorlage:Infobox_Berg/Doku&diff=97200878&oldid=96756576 weit gefehlt]. Der technische Grund dahinter ist, dass die Vorlage {{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 --[[Benutzer:Herzi Pinki|Herzi Pinki]] ([[Benutzer Diskussion:Herzi Pinki|Diskussion]]) 23:53, 9. Mär. 2013 (CET)
: Im deutschen  [http://www.adv-online.de/icc/extdeu/binarywriterservlet?imgUid=d6c43fd2-1153-911a-3b21-718a438ad1b2&uBasVariant=11111111-1111-1111-1111-111111111111 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ä). <small> - Höhenfestpunkte und Lagepunkte sind wie bereits ausgeführt ein anderes Thema. </small> 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. --[[Benutzer:Alexrk2|alexrk]] ([[Benutzer Diskussion:Alexrk2|Diskussion]]) 00:38, 10. Mär. 2013 (CET)

:Hallo, die [http://de.wikipedia.org/w/index.php?title=Vorlage:Infobox_Berg/Doku&diff=97200878&oldid=96756576 Ä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 →''[http://de.wikipedia.org/wiki/Spezial:Linkliste/Vorlage:Infobox_Berg/Wartung/Eventuell_ungültige_Höhenangabe Linkliste:Eventuell ungültige Höhenangabe]''. Woran das liegt kann ich nicht sagen, da seit Dezember 2011 [http://de.wikipedia.org/w/index.php?title=Vorlage%3AInfobox_Berg&diff=114785517&oldid=96180197 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 --<small>[[Benutzer:Knochen|Knochen&nbsp;ﱢﻝﱢ‎]]&nbsp;</small> 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 {{Vorlage|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 {{Vorlage|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 <br />''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.''<br />wird dann (gleich ein paar andere Sachen mit erledigt):<br />''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.''<br />Zufrieden? --[[Benutzer:Herzi Pinki|Herzi Pinki]] ([[Benutzer Diskussion: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. --[[Benutzer:TMg|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 (Berg)|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]]... --[[Benutzer:Cactus26|Cactus26]] ([[Benutzer Diskussion: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 --[[Benutzer:Herzi Pinki|Herzi Pinki]] ([[Benutzer Diskussion: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.--[[Benutzer:Cactus26|Cactus26]] ([[Benutzer Diskussion: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. --[[Benutzer:Milseburg|Milseburg]] ([[Benutzer Diskussion: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 --[[Benutzer:Herzi Pinki|Herzi Pinki]] ([[Benutzer Diskussion: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 [http://geoportal.geodaten.niedersachsen.de DGK5] allerdings 267,5 Meter. Pff. --[[Benutzer:Alexrk2|alexrk]] ([[Benutzer Diskussion:Alexrk2|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. ?? --[[Benutzer:Herzi Pinki|Herzi Pinki]] ([[Benutzer Diskussion:Herzi Pinki|Diskussion]]) 01:17, 10. Mär. 2013 (CET)
:::Nimm doch den [http://toolserver.org/~geohack/geohack.php?pagename=Bierberg_(Kalefeld)&language=de&params=51.77578_N_10.03811_E_dim:5000_region:DE-NI_type:mountain Geohack] - dort ist der NiedersachsenViewer ja neuerdings mit verlinkt ;) <small>ps: musst dan dort noch die 1:5000 unter Geobasisdaten manuell anhaken und reinzoomen</small> --[[Benutzer:Alexrk2|alexrk]] ([[Benutzer Diskussion:Alexrk2|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. --[[Benutzer:Herzi Pinki|Herzi Pinki]] ([[Benutzer Diskussion: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. --[[Benutzer:Alexrk2|alexrk]] ([[Benutzer Diskussion:Alexrk2|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 --[[Benutzer:Herzi Pinki|Herzi Pinki]] ([[Benutzer Diskussion:Herzi Pinki|Diskussion]]) 16:41, 10. Mär. 2013 (CET)
::::::: Ähm, ich hab mal [https://dl.dropbox.com/u/66257497/Bierberg%20%28Kalefeld%29.jpg 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) --[[Benutzer:Alexrk2|alexrk]] ([[Benutzer Diskussion:Alexrk2|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 --[[Benutzer:Herzi Pinki|Herzi Pinki]] ([[Benutzer Diskussion: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 --[[Benutzer:Herzi Pinki|Herzi Pinki]] ([[Benutzer Diskussion:Herzi Pinki|Diskussion]]) 22:21, 10. Mär. 2013 (CET)
:::::::::[http://geoportal.geodaten.niedersachsen.de/navigator/basicviewer.jsp?MAP_NAME=map_one&BBOX=571371%2C5736360%2C571871%2C5736860&SRS=EPSG%3A25832&LAYERS=map_618%2Clayer_3710&STYLES=%2Cstyle_layer_3710 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. --[[Benutzer:Alexrk2|alexrk]] ([[Benutzer Diskussion:Alexrk2|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 --[[Benutzer:Herzi Pinki|Herzi Pinki]] ([[Benutzer Diskussion:Herzi Pinki|Diskussion]]) 20:08, 11. Mär. 2013 (CET)

=== Rätsel ===

{{All Coordinates|pos=right|section=Rätsel}}
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, [http://www.geodienste.bfn.de/schutzgebiete/#?centerX=3398807.720?centerY=5765945.427?scale=5000?layers=524 BfN Karte] ({{Coordinate|NS=52.017239|EW=7.525329|type=landmark|elevation=95.3|name=Rösteberg (BfN)?|text=Rösteberg (BfN)?|region=DE-NW|dim=500}}) Ausgabe 2011
* TIM: Höhe 94.3, [http://www.tim-online.nrw.de/tim-online/initParams.do?role=default&bbox=398625,5763914,399125,5764414&srs=EPSG:25832 TIM], DGK5 dazuladen, auf Kartenmittelpunkt 7,526334;52,018863 zoomen ({{Coordinate|NS=52.018884|EW=7.526305|type=landmark|elevation=94.3|name=Rösteberg?|text=Rösteberg (TIM) ?|region=DE-NW|dim=500}})

* 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 --[[Benutzer:Herzi Pinki|Herzi Pinki]] ([[Benutzer Diskussion:Herzi Pinki|Diskussion]]) 23:04, 14. Mär. 2013 (CET)

Nachtrag: Google Relief hat etwas weiter westlich ({{Coordinate|NS=52.018381|EW=7.518504|type=landmark|elevation=100|name=Rösteberg?|text=Rösteberg (Google) ?|region=DE-NW|dim=500}}) noch eine geschlossene 100m-Höhenlinie, wo TIM gerade mal 91,5 m angibt. --[[Benutzer:Herzi Pinki|Herzi Pinki]] ([[Benutzer Diskussion: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. --[[Benutzer:Alexrk2|alexrk]] ([[Benutzer Diskussion:Alexrk2|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ßer Feldberg|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. --[[Benutzer:Milseburg|Milseburg]] ([[Benutzer Diskussion: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. [[Spezial:Beiträge/213.54.150.74|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. --[[Benutzer:SteveK|SteveK]] [[Benutzer_Diskussion: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? [[Spezial:Beiträge/213.54.150.73|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. [[Spezial:Beiträge/213.54.166.169|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ß!<br />--[[Benutzer:TOMM|TOMM]] ([[Benutzer Diskussion:TOMM|Diskussion]]) 10:12, 16. Aug. 2014 (CEST)

Ist mir auch schon aufgefallen, weiß jemand, warum? --[[Benutzer:Dampftrain|Dampftrain]] ([[Benutzer Diskussion:Dampftrain|Diskussion]]) 10:28, 16. Aug. 2014 (CEST)
:Habe Tschubbys unabgestimmte Änderung rückgängig gemacht.<br />[[Benutzer:Watzmann|Watzmann]]<sup> [[Benutzer Diskussion:Watzmann|Disk.]]</sup>  15:02, 16. Aug. 2014 (CEST)

::OK --[[Benutzer:Dampftrain|Dampftrain]] ([[Benutzer Diskussion:Dampftrain|Diskussion]]) 16:09, 16. Aug. 2014 (CEST)

:::Danke!<br />--[[Benutzer:TOMM|TOMM]] ([[Benutzer Diskussion: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 [[Normalnull|NN]] angezeigt statt [[Normalhöhennull|NHN]] (gültig seit 1992) und auch dahingehend verlinkt? Siehe z.B. [[Grünten]]. Gruss --[[Benutzer:Schofför|Schofför]] ([[Benutzer Diskussion:Schofför|Diskussion]]) 00:42, 30. Dez. 2014 (CET)
:Weil dort <nowiki>HÖHE-BEZUG = DE-NN</nowiki> statt <nowiki>HÖHE-BEZUG = DE-NHN</nowiki> als Parameter angegeben ist.<br />[[Benutzer:Watzmann|Watzmann]]<sup> [[Benutzer Diskussion:Watzmann|Disk.]]</sup>  00:47, 30. Dez. 2014 (CET)
::Ach sooo! Werde das dort jetzt ändern. Danke für den Hinweis und Gruss --[[Benutzer:Schofför|Schofför]] ([[Benutzer Diskussion:Schofför|Diskussion]]) 02:15, 30. Dez. 2014 (CET)
:::Gerne. <br />[[Benutzer:Watzmann|Watzmann]]<sup> [[Benutzer Diskussion:Watzmann|Disk.]]</sup>  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 {{S|;)}}). 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 --[[Benutzer:Schofför|Schofför]] ([[Benutzer Diskussion: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]]. --[[Benutzer:Milseburg|Milseburg]] ([[Benutzer Diskussion: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. --[[Benutzer:Schofför|Schofför]] ([[Benutzer Diskussion: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<br />[[Benutzer:Watzmann|Watzmann]]<sup> [[Benutzer Diskussion:Watzmann|Disk.]]</sup>  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.

--[[Benutzer:FkMohr|Friedo]] ([[Benutzer Diskussion:FkMohr|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.<br />[[Benutzer:Watzmann|Watzmann]]<sup> [[Benutzer Diskussion:Watzmann|Disk.]]</sup>  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. 
::--[[Benutzer:FkMohr|Friedo]] ([[Benutzer Diskussion:FkMohr|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.<br />[[Benutzer:Watzmann|Watzmann]]<sup> [[Benutzer Diskussion:Watzmann|Disk.]]</sup>  20:54, 2. Feb. 2015 (CET)

== Thumbtime für Videos ==

[[Datei:Piz Campagnung, aerial video.webm|mini|links|Ohne thumbtime.]]
[[Datei:Piz Campagnung, aerial video.webm|thumbtime=0:15|mini|links|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:
<pre>
| photo = {{#invoke:InfoboxImage|InfoboxImage|image={{{image|Piz Campagnung, aerial video.webm}}}|thumbtime={{{image_thumbtime|0:15}}}}}
</pre>
gibt es so was ähnliches auch bei uns?--[[Benutzer:Capricorn4049|Capricorn4049]] ([[Benutzer Diskussion:Capricorn4049|Diskussion]]) 19:27, 24. Feb. 2015 (CET)

{{Absatz}}

== 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. --[[Spezial:Beiträge/87.163.77.70|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. --[[Benutzer:Thgoiter|тнояsтеn]] [[Benutzer Diskussion:Thgoiter|⇔]] 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? [[Benutzer:Haster|Haster]] ([[Benutzer Diskussion:Haster|Diskussion]]) 08:32, 23. Nov. 2015 (CET)
:Welchen Parameter meinst du? Man kann {{tl|Infobox Gebirgsgruppe}} und {{tl|Infobox Berg}} doch auch bei niedrigen Höhenzügen verwenden, vgl. z,:b. [[Baumberge]] mit dem 187&nbsp;m hohen [[Westerberg (Baumberge)|Westerberg]]. --[[Benutzer:Watzmann|Watzmann]]<sup> [[Benutzer Diskussion:Watzmann|praot]]</sup> 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. [[Benutzer:Haster|Haster]] ([[Benutzer Diskussion:Haster|Diskussion]]) 18:35, 23. Nov. 2015 (CET)
:::Ok. Jetzt habe ich dein Problem verstanden. Es geht demnach um [[Spezial:Diff/147174966/next|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? --[[Benutzer:Watzmann|Watzmann]]<sup> [[Benutzer Diskussion:Watzmann|praot]]</sup> 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? --[[Benutzer:Milseburg|Milseburg]] ([[Benutzer Diskussion:Milseburg|Diskussion]]) 15:23, 24. Nov. 2015 (CET)
:::::Nicht dass ich wüsste. Da muss man ggf. die Parameter-Dokumentation entsprechend klar abfassen. --[[Benutzer:Watzmann|Watzmann]]<sup> [[Benutzer Diskussion:Watzmann|praot]]</sup> 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.--[[Benutzer:Cactus26|Cactus26]] ([[Benutzer Diskussion: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? [[Benutzer:Haster|Haster]] ([[Benutzer Diskussion: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". -- [[Benutzer:Quotengrote|Quotengrote]] ([[Benutzer Diskussion:Quotengrote|D]]&#124;[[Spezial:Beiträge/Quotengrote|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]] -- [[Benutzer:Quotengrote|Quotengrote]] ([[Benutzer Diskussion:Quotengrote|D]]&#124;[[Spezial:Beiträge/Quotengrote|B]]) 14:32, 19. Mär. 2017 (CET)

::{{Ping|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 --[[Benutzer:Herzi Pinki|Herzi Pinki]] ([[Benutzer Diskussion:Herzi Pinki|Diskussion]]) 00:45, 23. Mär. 2017 (CET)
:::{{ping|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. -- [[Benutzer:Quotengrote|Quotengrote]] ([[Benutzer Diskussion:Quotengrote|D]]&#124;[[Spezial:Beiträge/Quotengrote|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 {{Vorlage|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 --[[Benutzer:Herzi Pinki|Herzi Pinki]] ([[Benutzer Diskussion: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. -- [[Benutzer:Quotengrote|Quotengrote]] ([[Benutzer Diskussion:Quotengrote|D]]&#124;[[Spezial:Beiträge/Quotengrote|B]]) 10:13, 23. Mär. 2017 (CET)
:<small>Archivierung dieses Abschnittes wurde gewünscht von:  [[Benutzer:Quotengrote|Quotengrote]] ([[Benutzer Diskussion:Quotengrote|D]]&#124;[[Spezial:Beiträge/Quotengrote|B]]) 15:40, 15. Mai 2017 (CEST)</small>

== 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? --[[Benutzer:X:: black ::X|X:: black ::X]] ([[Benutzer Diskussion:X:: black ::X|Diskussion]]) 01:16, 16. Jan. 2016 (CET)
:{{Ping|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 --[[Benutzer:Herzi Pinki|Herzi Pinki]] ([[Benutzer Diskussion: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 ''[[Vorlage:Infobox Gebirgsgruppe|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.

--[[Benutzer:FkMohr|Friedo]] ([[Benutzer Diskussion:FkMohr|Diskussion]]) 12:08, 24. Jul. 2016 (CEST)

:Kennt sich denn niemand mit den beiden angesprochenen Angelegenheiten aus? --[[Benutzer:FkMohr|Friedo]] ([[Benutzer Diskussion:FkMohr|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 --[[Benutzer:Herzi Pinki|Herzi Pinki]] ([[Benutzer Diskussion: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. {{Ping|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 --[[Benutzer:Herzi Pinki|Herzi Pinki]] ([[Benutzer Diskussion: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.--[[Benutzer:Pechristener|Pechristener]] ([[Benutzer Diskussion:Pechristener|Diskussion]]) 02:21, 11. Okt. 2016 (CEST)
::{{Vorlage|Infobox See}}, {{Vorlage|Infobox Gletscher}}, {{Vorlage|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 --[[Benutzer:Herzi Pinki|Herzi Pinki]] ([[Benutzer Diskussion: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... --[[Benutzer:Cactus26|Cactus26]] ([[Benutzer Diskussion: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.--[[Benutzer:Pechristener|Pechristener]] ([[Benutzer Diskussion: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 --[[Benutzer:Herzi Pinki|Herzi Pinki]] ([[Benutzer Diskussion:Herzi Pinki|Diskussion]]) 12:20, 22. Dez. 2016 (CET)
::::::Was ist in diesem Zusammenhang ein ''Banker'' ? --[[Benutzer:Pechristener|Pechristener]] ([[Benutzer Diskussion: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.--[[Benutzer:Pechristener|Pechristener]] ([[Benutzer Diskussion:Pechristener|Diskussion]]) 00:11, 21. Dez. 2016 (CET)

{| class="float-right" style="background-color:transparent;"
|
{{Positionskarte|Österreich|mark=RedBlackMountain.svg|maptype=relief|marksize=16|lat=47/4/30|long=12/41/40|region=AT
|caption=neuer map-pointer}}
|
{{Positionskarte|Österreich|mark=RedMountain.svg|maptype=relief|marksize=16|lat=47/4/30|long=12/41/40|region=AT
|caption=alter map-pointer}}
|
{{Positionskarte|Österreich|mark=BlackMountain.svg|maptype=relief|marksize=16|lat=47/4/30|long=12/41/40|region=AT
|caption=alter map-pointer}}
|-
|
{{Positionskarte | Schweiz Silvretta
| lat=46.844166666667
| long =  10.118333333333
| region = CH
| caption = Lage des Piz Buin in der Silvretta.
|float=left
| mark = RedBlackMountain.svg 
| marksize=14
}}
|
{{Positionskarte | Schweiz Silvretta
| lat=46.844166666667
| long =  10.118333333333
| region = CH
| caption = Lage des Piz Buin in der Silvretta.
|float=left
| mark = RedMountain.svg 
| marksize=14
}}

|}

:demnächst bekommen wir ohnehin die maki-icons und <nowiki><mapframe></nowiki>. 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 --[[Benutzer:Herzi Pinki|Herzi Pinki]] ([[Benutzer Diskussion:Herzi Pinki|Diskussion]]) 12:52, 22. Dez. 2016 (CET)

::+1, für mich auch eine Verschlechterung der Sichtbarkeit. --[[Benutzer:Thgoiter|тнояsтеn]] [[Benutzer Diskussion:Thgoiter|⇔]] 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''!<br />--[[Benutzer:TOMM|TOMM]] ([[Benutzer Diskussion:TOMM|Diskussion]]) 21:18, 9. Jan. 2017 (CET
::::+1 für den alten und besseren Pointer. --[[Benutzer:Milseburg|Milseburg]] ([[Benutzer Diskussion: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 [[Datei:BlackMountain.svg|16px]]. Der komplett rote, der oben als "alter map-pointer" bezeichnet wurde, gefällt mir auch gut. Nur der zweifarbige ist schlecht sichtbar. --[[Benutzer:Thgoiter|тнояsтеn]] [[Benutzer Diskussion:Thgoiter|⇔]] 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 --[[Benutzer:Pechristener|Pechristener]] ([[Benutzer Diskussion:Pechristener|Diskussion]]) 16:26, 10. Jan. 2017 (CET)
::::::: Späte Antwort {{Ping|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 [https://de.wikipedia.org/w/index.php?title=Vorlage:Infobox_Berg&diff=161495880&oldid=161495673 diese Änderung] ist durch die Disk nicht wirklich abgedeckt. lg --[[Benutzer:Herzi Pinki|Herzi Pinki]] ([[Benutzer Diskussion:Herzi Pinki|Diskussion]]) 00:27, 23. Mär. 2017 (CET)
{{Ping|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.--[[Benutzer:Pechristener|Pechristener]] ([[Benutzer Diskussion: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 --[[Benutzer:Herzi Pinki|Herzi Pinki]] ([[Benutzer Diskussion: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. -- [[Benutzer:Olaf Studt|Olaf Studt]] ([[Benutzer Diskussion:Olaf Studt|Diskussion]]) 23:42, 16. Mär. 2018 (CET)
:Ich dachte auch. Wohl ein Fall für die [[WP:VWS|Werkstatt]]. --[[Benutzer:Thgoiter|тнояsтеn]] [[Benutzer Diskussion:Thgoiter|⇔]] 22:14, 15. Apr. 2018 (CEST)

::[https://de.wikipedia.org/w/index.php?title=Vorlage:Infobox_Berg&type=revision&diff=158082234&oldid=133466668&diffmode=source] vermutlich das da. ich aktiviere wieder. lg --[[Benutzer:Herzi Pinki|Herzi Pinki]] ([[Benutzer Diskussion:Herzi Pinki|Diskussion]]) 12:18, 28. Jul. 2018 (CEST)

[[:Kategorie:Wikipedia:Lagewunsch (mountain)]] bräuchte jetzt wieder Beachtung --[[Benutzer:Herzi Pinki|Herzi Pinki]] ([[Benutzer Diskussion:Herzi Pinki|Diskussion]]) 13:36, 28. Jul. 2018 (CEST)
:Danke --[[Benutzer:Thgoiter|тнояsтеn]] [[Benutzer Diskussion:Thgoiter|⇔]] 22:30, 29. Jul. 2018 (CEST)

:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Thgoiter|тнояsтеn]] [[Benutzer Diskussion:Thgoiter|⇔]] 22:30, 29. Jul. 2018 (CEST)</small>

== HTML-Fehler ==

Anscheinend erzeugt die Infobox unter bestimmten Bedingungen Fehler. Näheres unter
: [[Wikipedia:WikiProjekt Vorlagen/Werkstatt#Linterfehler durch Pseudofehlerwartungsanalyse?]]
Ich berichte nur weiter. --[[Benutzer:Silvicola|Silvicola]]&nbsp;[[Benutzer Diskussion:Silvicola|<sup>Disk</sup>]] 14:39, 27. Jul. 2018 (CEST)
:danke fürs berichten, ist erl. lg --[[Benutzer:Herzi Pinki|Herzi Pinki]] ([[Benutzer Diskussion:Herzi Pinki|Diskussion]]) 22:41, 29. Jul. 2018 (CEST)
:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Herzi Pinki|Herzi Pinki]] ([[Benutzer Diskussion:Herzi Pinki|Diskussion]]) 22:41, 29. Jul. 2018 (CEST)</small>

== 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?

--[[Benutzer:FkMohr|Friedo]] ([[Benutzer Diskussion:FkMohr|Diskussion]]) 18:15, 13. Nov. 2014 (CET)

: <small>Von [[/Doku]] hierher kopiert.</small> --[[Benutzer:PerfektesChaos|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? --[[Benutzer:J. Patrick Fischer|JPF]] ''just another user'' 09:05, 10. Mai 2019 (CEST)
:scheint [https://de.wikipedia.org/w/index.php?title=Vorlage%3AInfo_ISO-3166-2%3ATL-OE&type=revision&diff=188419142&oldid=188324293 daran] gelegen zu haben … [[Benutzer:Man77|'''««''']]&nbsp;Man77&nbsp;[[Benutzer Diskussion:Man77|'''»»''']] <span style="font-size:40%;">Alle Angaben ohne Gewehr.</span> 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. … [[Benutzer:Man77|'''««''']]&nbsp;Man77&nbsp;[[Benutzer Diskussion:Man77|'''»»''']] <span style="font-size:40%;">Alle Angaben ohne Gewehr.</span> 12:07, 10. Mai 2019 (CEST)
::Vielleicht die Kategorien wieder direkt den Autoren überlassen, statt per Halbautomatik in Infoboxen? ;-) --[[Benutzer:J. Patrick Fischer|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? -- [[Benutzer:Olaf Studt|Olaf Studt]] ([[Benutzer Diskussion: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. -- [[Benutzer:Olaf Studt|Olaf Studt]] ([[Benutzer Diskussion: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. [[Benutzer:Antonsusi| '''Å'''ñŧóñŜûŝî]]&nbsp;[[Benutzer_Diskussion:Antonsusi|'''(Ð)''']] 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. --[[Spezial:Beiträge/91.2.112.229|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 --[[Benutzer:Carsaig|Carsaig]] ([[Benutzer Diskussion: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... --[[Benutzer:Thgoiter|тнояsтеn]] [[Benutzer Diskussion:Thgoiter|⇔]] 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 --[[Benutzer:Carsaig|Carsaig]] ([[Benutzer Diskussion:Carsaig|Diskussion]]) 09:35, 28. Sep. 2020 (CEST)

:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Thgoiter|тнояsтеn]] [[Benutzer Diskussion:Thgoiter|⇔]] 20:41, 28. Sep. 2020 (CEST)</small>

== 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)]]. --[[Benutzer:Wurgl|Wurgl]] ([[Benutzer Diskussion:Wurgl|Diskussion]]) 08:56, 23. Mär. 2019 (CET)

: Bei [[Mont Blanc]] funktioniert <code>REGION-ISO = FR-74/IT-AO</code>. [[Benutzer:Andim|Andim]] ([[Benutzer Diskussion:Andim|Diskussion]]) 09:34, 23. Mär. 2019 (CET)
:: Danke [[Benutzer:Andim|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]]"''. --[[Benutzer:Wurgl|Wurgl]] ([[Benutzer Diskussion:Wurgl|Diskussion]]) 09:56, 23. Mär. 2019 (CET)

::: Hallo [[Benutzer:Wurgl|Wurgl]], hatte gerade („leider“ unabhängig vom Vorgesagten) dasselbe Problem von [[Benutzer:Wurgl/Fehler Vorlagen|Deiner Fehlerliste]] mittels [[Spezial:Diff/193987745|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, [[Benutzer:Centic|Centic]], seit Mai nicht mehr aktiv. Gruß, --[[Benutzer:Wi-luc-ky|Wi-luc-ky]] ([[Benutzer Diskussion:Wi-luc-ky|Diskussion]]) 18:30, 12. Nov. 2019 (CET)

:::: Wenn ihr bitte mal über [[Spezial:Diff/194015360|meine Änderung]] drüberschauen wollt, [[Benutzer:Wurgl|Wurgl]] und [[Benutzer:Andim|Andim]]: Habe die Doku präzisiert, so dass mE Vorlagenfehler künftig leichter vermieden werden können. Gruß, --[[Benutzer:Wi-luc-ky|Wi-luc-ky]] ([[Benutzer Diskussion: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* --[[Benutzer:Wurgl|Wurgl]] ([[Benutzer Diskussion:Wurgl|Diskussion]]) 16:26, 13. Nov. 2019 (CET)

:::::: Danke, [[Benutzer:Wurgl|Wurgl]], für Deine Anregungen und Dein Dankeschön nach [[Spezial:Diff/194018328|entsprechender Umsetzung]] direkt im Fließtext. Bin auch kein Bergexperte ;-) Gruß, --[[Benutzer:Wi-luc-ky|Wi-luc-ky]] ([[Benutzer Diskussion: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ß --'''''[[User:Furfur|<span style="color: #8806CE; font-family: Palatino, Times, serif">Furfur</span>]]'''''<sup> &#8258; [[User talk:Furfur| Diskussion]]</sup> 11:17, 13. Okt. 2019 (CEST)

:hallo {{Ping|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 --[[Benutzer:Herzi Pinki|Herzi Pinki]] ([[Benutzer Diskussion: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 --[[Benutzer:Herzi Pinki|Herzi Pinki]] ([[Benutzer Diskussion:Herzi Pinki|Diskussion]]) 08:32, 2. Jan. 2020 (CET)

::Hallo [[Benutzer:Herzi Pinki|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. --'''''[[User:Furfur|<span style="color: #8806CE; font-family: Palatino, Times, serif">Furfur</span>]]'''''<sup> &#8258; [[User talk:Furfur| Diskussion]]</sup> 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 --[[Benutzer:Herzi Pinki|Herzi Pinki]] ([[Benutzer Diskussion:Herzi Pinki|Diskussion]]) 09:44, 2. Jan. 2020 (CET)

{{Ping|Furfur}} [https://de.wikipedia.org/w/index.php?search=-incategory%3A%22Berg+in+Antarktika%22+incategory%3A%22Wikipedia%3AVorlagenfehler%2FVorlage%3AInfobox+Berg%22&title=Spezial:Suche&go=Artikel hier gibt es mehrere Fehlverwendungen / Parameterfehler] in der Infobox. Statt am Format zu basteln, magst du dich den Inhalten widmen? lg --[[Benutzer:Herzi Pinki|Herzi Pinki]] ([[Benutzer Diskussion: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.<br />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. --'''''[[User:Furfur|<span style="color: #8806CE; font-family: Palatino, Times, serif">Furfur</span>]]'''''<sup> &#8258; [[User talk:Furfur| Diskussion]]</sup> 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 <nowiki><code>__TOC__</code></nowiki> 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 <code>310px</code> und die Bilder auf <code>300px</code> 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 <code>300x400px</code>
:::::* Viel mehr Höhe kann man im Gegenzug durch reduzieren der Zeilenhöhe sparen.
:::::Gruß von [[Benutzer:Antonsusi| '''Å'''ñŧóñŜûŝî]]&nbsp;[[Benutzer_Diskussion:Antonsusi|'''(Ð)''']] 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 --[[Benutzer:Herzi Pinki|Herzi Pinki]] ([[Benutzer Diskussion:Herzi Pinki|Diskussion]]) 08:16, 8. Jan. 2020 (CET)