Vorlage Diskussion:Infobox Pass

Beispiele

Vorlage	Autor	Einbindungen	Beispiel
Vorlage:Infobox Passstrasse	Benutzer:Tschubby	erledigtErledigt	Zugerberg
Vorlage:Infobox Passstrasse2	Benutzer:Stephan Brunker	erledigtErledigt	Col du Galibier
Vorlage:Infobox Passstrasse3	Benutzer:Tschubby	erledigtErledigt	Albulapass
Hintergrundfarbe #CDB79E		erledigtErledigt	Independence Pass
CatScan: Gebirgspass ohne Infobox		erledigtErledigt	Abra del Acay
Ergebnis
Vorlage:Infobox Pass	Benutzer:visi-on	718	San-Bernardino-Pass

wie stehts denn damit, sind die jetzt deprecated, und werden schrittweise ersetzt, oder wahlweise verwendet? (was ich nicht schön fände..) gruß -- W!B: 21:35, 17. Mai 2007 (CEST)

• Die Seite Vorlage:Infobox Passstrasse sagt inzwischen: "Diese Vorlage ist obsolet", die anderen Vorlagen werden ja anscheinend schon länger nicht mehr verwendet. -- Ulflulfl 06:16, 13. Okt. 2009 (CEST)

der CatScan ist nur eine Hilfe, die Artikel zu finden, wo eventuell eine Infobox fehlt. Es gibt keine Vorschrift dort auch immer eine einzubauen. --Herzi Pinki 15:46, 19. Jun. 2010 (CEST)

Diskussion

Koordinaten

Font-size

Hi, visi-on, es wird ernst? Schöne Arbeit. Ist es recht, wenn ich hier fortfahre?

Eine kleinere Anmerkung: die WGS84 Koordinaten (für Schweizer Berge?) sind nicht nur in der Box extra klein geschrieben, sondern auch rechts oben auf der Seite. Sollten m.E. die gleiche Font-size haben wie die Koordinaten in anderen Artikeln. --Herzi Pinki 22:44, 27. Feb. 2007 (CET)

ich müsste die Koordinate Vorlage zweimal aufrufen, einmal für den Artikel und einmal Text, das ist aber nicht vertretbar. Nun sind nur noch die Landeskoordinaten klein erledigtErledigt-- visi-on TWW 23:37, 27. Feb. 2007 (CET)

Überlagerung im Vorlagenkopf

Im Vorlagenkopf hiesiger Infobox überlagern sich Koordinaten mit Koordinaten fehlen! Hilf mit. Das ist doch wohl keine Absicht?
--TOMM (Diskussion) 19:08, 17. Aug. 2014 (CEST)

Sackgasse

Liebe Leute! Habe für den Luz Ardiden die Vorlage Infobox Pass verwendet. Der Luz ist allerdings eine Sackgasse und hat nur eine Anfahrt. Hieltet ihr es für sinnvoll, eine eigene Vorlage für Sackgassen zu machen? Bei anderen Bergankünften mit einer Zufahrt, wie Courchevel, L'Alpe d'Huez oder Les Deux Alpes ist man das Problem umgangen, indem einfach keine Infos-Box verwendet wurde. --80.109.17.241 15:45, 2. Jun. 2007 (CEST)

Rechberg (Pass)

Hi Visi-on, kannst du dir bitte mal Rechberg (Pass) anschauen, folgende Problemchen tauchen dort auf:

• Die Positionskarte ist nicht zentriert (eventuell bewirkt irgendein Eintrag eine überbreite Tabelle)
• Die Dezimalwerte (Koordinaten, Steigung, Entfernungen, ..) werden mit CH-Punkt angegeben, nicht mit DE/AT-Komma

Danke --Herzi Pinki 19:57, 1. Apr. 2007 (CEST)

• ich dachte ich hätte es gesehen, warum es nicht zentriert, dem ist aber nicht so ...

und siehe da, der Parameter float bewirkt etwas ...-- visi-on 21:10, 2. Apr. 2007 (CEST)

• ich erhoffte mir hier eine Zielorientierte Lösung. ich verweigere mich aber derzeit einer Verwendung von formatNum. Grundsätzlich sehe ich das mit Komma und Punkt nicht so eng.

-- visi-on 20:56, 2. Apr. 2007 (CEST)

Danke --Herzi Pinki 22:35, 2. Apr. 2007 (CEST)

Mittelfristig wäre schon eine Darstellung mit dem Komma als Dezimaltrennzeichen schön, da es im deutschsprachigen Raum (außer bei Geldbeträgen in der Schweiz) üblich ist.--Arnulf zu Linden 02:48, 5. Aug. 2009 (CEST)

langfristig nicht mit veralteten, verwirrenden Tausendertrennzeichen zu rechnen ;-) -- visi-on 09:43, 5. Aug. 2009 (CEST)

IE

Visi-on, kannst du dir bitte mal Arlberg im IE anschauen. Die Box ist im IE unnötig breit und enthält viel Leerraum. Was im Firefox oder sonst was gut aussieht (ich kann mir nicht vorstellen, dass du IE verwendest, visi-on), ist im IE eine optische Katastrophe. Any idea? siehe auch Benutzer Diskussion:Rattenkönig#Österreichische Pässe. Danke --Herzi Pinki 00:04, 10. Apr. 2007 (CEST)

ich habe nicht unbedingt vor IE runterzuladen. Die neueste Version ist für mein Betriebssystem eh nicht verfügbar. Hast du eine Erklärung warum und wie IE den HTML code anders interpretiert? Dann kann ich Ableiten wie die Definition sein sollte.-- visi-on 00:58, 10. Apr. 2007 (CEST)

dann schau ich mir das Problem näher an. --Herzi Pinki 21:23, 10. Apr. 2007 (CEST)

Danke, und ich seh dich im Kampf mit Windmühlen ... -- visi-on 23:36, 10. Apr. 2007 (CEST)

wie sieht es mit Spaltenbreiten 90/120/120 aus?-- visi-on 00:12, 11. Apr. 2007 (CEST)

wenn ich deine Versuche richtig interpretiere scheitert es nun daran, das fixed gleiche Spaltenbreiten erzeugt. Das finde ich natürlich auch nicht schön und eine Platzvergeudung.-- visi-on 00:16, 11. Apr. 2007 (CEST)

So, der aktuelle Stand: ich habe die Tabelle auf table-layout=fixed gesetzt und die Rahmen der Bilder alle auf Null reduziert. Damit hat die Box immer gleiche Breite und der Inhalt lässt sie auch im IE nicht beliebig breit werden. Dafür habe ich einige Zeilenumbrüche zulassen müssen, und, wie du richtig bemerkt hast, haben die Spalten nun Breiten 1:1:1 (ist mir bisher noch nicht aufgefallen). Nur mit der Positionskarte funktioniert das so nicht, die hat immer einen Rahmen von 1px (kein Parameter dafür in Vorlage:Positionskarte), daher habe ich die Größe um die 2 Pixel reduziert. Im IE ist die Positionskarte allerdings um jeweils ein Pixel nach rechts und nach unten verschoben, weiß nicht warum, fällt aber vielleicht auch nicht gleich ins Auge.

Damit gibt es eine Lösung, die im IE keinen Leerraum links und rechts der Bilder erzeugt, die aber insgesamt suboptimal mit dem Platz umgeht (gleiche Spaltenbreiten). Schau dir mal den Unterschied an, gib bitte deinen Kommentar dazu ab. Das ursprüngliche Problem dürfte gewesen sein, dass der IE die Spalten viel breiter gemacht hat, als der Firefox, bei gleichem Inhalt.

Lösungsmöglichkeiten für flexible Spalten:

• fixe Aufteilung, nicht 1:1:1, - ist nicht wirklich flexibel
• Eine umhüllende Tabelle mit fixer Breite und nur einer Zelle mit einer weiteren, der ursprünglichen Tabelle
• ?? (ev. hast du ja eine bessere Idee)

was mich angeht nicht mehr vor dem Aufstehen.

Die Bildunterschrift habe ich wieder aktiviert, nur wenn keine BILDBESCHREIBUNG angegeben wird, steht dort nichts. --Herzi Pinki 00:45, 11. Apr. 2007 (CEST)

Bild
Wasserscheide a aa aaa aaaa aaaaa aaaaaa aaaaaaa aaaaaaaa a	b	c

Wie sieht:

im IE aus? Die class prettytable machts auch noch breiter als notwendig.-- visi-on 17:28, 11. Apr. 2007 (CEST)

hat im IE nicht den gewünschten Effekt. Die linke Spalte ist breiter als die beiden anderen, aber rechts ist in der linken Spalte noch jede Menge Platz. Erstaunlicherweise erfolgt der Zeilenumbruch auch unvermutet. Ich habe versucht, das Aussehen im IE hier nachzubauen.

Wasserscheide a aa aaa aaaa aaaaa aaaaaa aaaaaaa aaaaaaaa a

Warum da vor dem ersten "a" schon umgebrochen wird, völlig schleierhaft. --Herzi Pinki 20:49, 11. Apr. 2007 (CEST)

ich habe da so einen Verdacht: Der Text wird auf die richtige Breite formatiert die Spaltenbreite orientiert sich aber am Biorhythmus von B.G. -- visi-on 21:21, 11. Apr. 2007 (CEST)

Nachtrag: Die rechte Box

Bild
Wasserscheide a aa aaa aaaa aaaaa aaaaaa aaaaaaa aaaaaaaa a	b	c

ist (fast) ok, das Bild hat links einen Rand (3px?) und steht rechts am Tabellenrand an. Die darunter liegenden Spalten haben die gewünschten Breitenverhältnisse. Wird die Breite auf 328px erhöht, so tritt der IE Effekt auf.

Aber es nützt eh nichts, da wir keine festen Spaltenbreiten brauchen können. --Herzi Pinki 21:29, 11. Apr. 2007 (CEST)

Macht mich nicht grad glücklich-- visi-on 22:36, 11. Apr. 2007 (CEST)

So würde es vielleicht gehen, aber es macht die Dinge extrem kompliziert: Statt 3 Zellen je Zeile gibt es nur 2, in der rechten steht eine geschachtelte Tabelle mit wiederum 2 Spalten, mit Aufteilung 50:50; der innere Rahmen ist quasi selbst zu machen. Da die 2. Spalte immer 50:50 aufgeteilt wird, sollten alle Tabellenrahmen bündig untereinander zu stehen kommen.

Bild
Wassers.	a aa aaa aaaa aaaaa aaaaaa aaaaaaa aaaaaaaa a c a aa aaa aaaa aaaaa aaaaaa aaaaaaa aaaaaaaa a
Ort	a c a aa aaa aaaa aaaaa aaaaaa aaaaaaa aaaaaaaa a
kurz	a aa aaa aaaa aaaaa aaaaaa aaaaaaa aaaaaaaa a c
links	a aa aaa aaaa aaaaa aaaaaa aaaaaaa aaaaaaaa a
rechts	c

--Herzi Pinki 22:47, 11. Apr. 2007 (CEST)

tun sie aber in Firefox 2.0.0.3 nicht. Es ist zum ... -- visi-on 22:54, 11. Apr. 2007 (CEST)

ich habe auch 2.0.0.3, bei mir schaut die Tabelle gut aus. Was meinst du genau (PS: habe da einen Halbsatz wieder weggelöscht); ich verwende monospace.css, vielleicht hat es damit auch was zu tun. --Herzi Pinki 23:08, 11. Apr. 2007 (CEST)

bei Ort ist das Feld mit dem a ein Pixel breiter und das Feld rechts daneben um diesen einen schmaler. monospace.css: ich will ja nun gar nichts mehr ausschliessen, wüste aber nicht warum es sollte.-- visi-on 23:15, 11. Apr. 2007 (CEST)

hatte ich auch, den Effekt, aber dann ist er verschwunden. Daher entsprechenden Satz wieder gelöscht.
Aber ich hab's jetzt nachvollziehen können, es hängt von der eingestellten Schriftgröße ab (Da kommt aber Freude auf!):

• Bei Ansicht -> Schriftgrad-> Normal tritt der Effekt bei mir nicht auf.
• Bei Ansicht -> Schriftgrad-> Verkleinern oder Ansicht -> Schriftgrad-> Vergrößern tritt der Effekt aber auf.
• Dreht man weiter am Rädchen, so sind die Rahmenteile einmal bündig und dann wieder nicht.

(vielleicht sollte man den Galibier von der anderen Seite nehmen, vom Col du Lautaret, da ist er viel einfacher) --Herzi Pinki 23:35, 11. Apr. 2007 (CEST)

Gegensteigung

Bei Col de la Croix de Fer ist die durchschnittliche Steigung von Südwesten nicht richtig: Es gibt eine Gegensteigung, daher kann man nicht einfach die Länge des Anstiegs durch den Höhenunterschied teilen, um zur durchschnitt. Steigung zu kommen. -- Gruss Zehnfinger 00:13, 13. Apr. 2007 (CEST)

Danke für deine Aufmerksamkeit. Zur Steigung: in der Vorgängerversion hat der Wert gefehlt, mathematisch gesehen ist die Durchschnittssteigung schon korrekt, nur die Radfahrer rechnen das anders. Diskussion von dort hierher verlegt. --Herzi Pinki 00:27, 13. Apr. 2007 (CEST)

Die Steigung bei der Vorgängerversion habe ich bewusst wegen der Gegensteigung weggelassen. M.E. (neudeutsch: imho) wäre es wohl sinnvoller, wie bisher auch die Höhendifferenz und die Länge der Steigung anzugeben, dann kann man allenfalls die Steigung weglassen. -- Zehnfinger 00:37, 13. Apr. 2007 (CEST)

Letzte Änderung

Nach der letzten Änderung funktioniert das mit den Koordinaten wohl nicht mehr richtig. --SteveK ?! 21:10, 9. Jan. 2008 (CET)

Ooh, steht aber schon lange auf der ToDo-Liste-- visi-on 21:22, 9. Jan. 2008 (CET)

Wartet doch bitte noch das Meinungsbild ab und beschränkt euch auf, hier in der Diskussion vorzubringende, Änderungswünsche. Danke -- visi-on 21:28, 9. Jan. 2008 (CET)

Die Formatierung der eingebundenen IB kam nach der Änderung durcheinander. Deshalb mein Revert. Eine Änderung sollte man schon überprüfen ob sie richtig fluppt. --SteveK ?! 22:20, 9. Jan. 2008 (CET)

Ich war von deinem Diskussionsbeitrag so aufgeschreckt, dass ich meinte es betreffe meine letzte Änderung an der IB. Die Koordinaten sind hier nicht zu meiner Zufriedenheit gelöst. Dafür musste ich erst die neue Koordinatenvorlage entwerfen ;-) -- visi-on 15:52, 10. Jan. 2008 (CET)

Nein, gestern hat es hier eine Änderung gegeben, die meine erste Einbindung der InfoBox seltsam aussehen ließ. Konnte mir das erst gar nicht erklären. Diese Änderung hatte ich dann 20 Minuten nach dem Edit revertiert, Zeit genug um zu sehen das was falsch war. Wie ich dich kenne hättest du den Fehler gleich nach der Änderung gesehen. --SteveK ?! 18:42, 10. Jan. 2008 (CET)

Man kann nicht wachsam genug sein. Seltsamerweise ging der Edit in meiner Beobachtungsliste unter, aber dein Diskussionsbeitrag rief mich sofort auf den Plan. -- visi-on 18:58, 10. Jan. 2008 (CET)

XML-Seite für den VM

Ich finde es übrigens schade, dass es noch keine XML-Seite für den VM gibt. Der VM erleichtert die Einbindung der Box erheblich --SteveK ?! 19:22, 10. Jan. 2008 (CET)

ich schau's mir mal an und wie gesagt hier ist demnächst Baustelle. -- visi-on 19:26, 10. Jan. 2008 (CET)

Ich war so frei und habe damit mal begonnen, bei der Menge an Parametern ist das aber eine aufwändigere Sache. --SteveK ?! 20:14, 10. Jan. 2008 (CET)

MAXSTEIGUNG und LAENGE (Infobox Pass vs. Passstraße)

Wenn man die obsolete Infobox Passstraße durch die detailliertere Infobox Pass ersetzen will, stößt man auf folgendes Problem (ist mir beim Seitenumbau Grosser Sankt Bernhard aufgefallen):

Die meisten der Parameter kann man direkt übernehmen oder sind recht einfach umzusetzen. Die beiden bisherigen Parameter MAXSTEIGUNG und LAENGE sind aber nicht "abbildbar"!

Es ist natürlich sinnvoller die Daten als MAXSTEIGUNG1 / 2 bzw. LAENGE1 / 2 anzugeben. Wenn diese Infos aber schlicht nicht so detailliert vorliegen (was bei einer ganzen Reihe von bestehenden Passseiten der Fall ist) wäre es doch schick wenn man zumindest die vorhandenen "unschärferen" Werte darstellen würde/könnte.

Hatte mir die Vorlage selbst kurz angeschaut, aber ich fürchte wenn ich da was ändere mache ich mehr kaputt als heile :-) -- Ulflulfl 06:31, 13. Okt. 2009 (CEST)

Hallo Ulflulfl, wo willst du die unschärferen Werte eintragen, ohne etwas zu suggerieren, was nicht da ist? Die LAENGE1/2 ist in vielen Fällen aus Karten oder mittels Google maps eruierbar, und notwendig, um die durchschnittliche Steigung berechnen zu können. Die MAXSTEIGUNG1/2 ist von untergeordneter Wichtigkeit, aber es ist etwa für Radfahrer schon interessant, ob die MAXSTEIGUNG bergauf oder bergab zu bewältigen ist. Ich würde einen Wert für MAXSTEIGUNG als html-Kommentar übernehmen, aber gucken, ob ich irgendwoher aktuellere Daten bekommen. lg --Herzi Pinki 00:17, 14. Okt. 2009 (CEST)

Hi! "suggerieren, was nicht da ist" verstehe ich nicht, sowohl MAXSTEIGUNG (maximale Steigung des gesamten Passes) als auch die LAENGE (Gesamtlänge) sind doch reale Werte und so ja bislang in Infobox Passstraße als Parameter vorhanden. Wie auch immer - mir geht es primär darum, allgemein die Infobox Pass einzusetzen, weil sie mehr Möglickeiten als die "alte Passstraße" bietet (z.B. die Poskarte finde ich sehr hilfreich) und m.E. etwas übersichtlicher ist. Ich hab in letzter Zeit eine ganze Reihe neuer Pass Infoboxen in Seiten bisher ganz ohne Infobox eingefügt, dabei sind mir schon einige Seiten aufgefallen wo ich MAXSTEIGUNG / LAENGE hätte eintragen können, weil die Infos (nur diese) bereits im Fliesstext stehen. Dann bin ich auf die IB Passstraße gestoßen und hab die Parameter dort gesehen. Jetzt wollte ich nach und nach die alten IB auf neu umstellen (sind noch etwas über 50 Stück), aber die bisher vorhandenen Infos "verschwinden" zu lassen wollte ich halt auch nicht. Ich hab allerdings jetzt auch nicht vor, für die ganzen Pässe einzeln die "Seitenlängen" bei Google rauszusuchen - ne Menge Arbeit und für mich nicht sooo interessant. Ich kann jetzt a) die IBs von Passstraße nach Pass umstellen und dabei MAXSTEIGUNG / LAENGE einfach als unsichtbare Parameter stehenlassen, b) warten bis IB Pass so umgebaut ist wie ich meinte oder c) nichts tun. Was meinst du ist am sinnvollsten? -- Ulflulfl 00:58, 14. Okt. 2009 (CEST)

Denzel-Alpenstraßen-Skala

Die Denzel-Skala sollte man auch mit aufnehmen. liesel 10:31, 25. Dez. 2009 (CET)

Gibts dafür eine allg. verfügbare Quelle? Ist halt nur für Alpenstraßen verfügbar. Wie offiziell ist die Denzelskala? Die Unterscheidung zwischen SG1 bis SG3 scheint mir eher für Flachländer zu sein. Ich verstehe nicht, warum z.B. das Stilfser Joch SG3 sein soll, ist halt länger und höher, aber eine stinknormale Straße, nicht einmal extrem steil. Geht mit Wohnwagen und Holländer davor. Was ist mit anderen Bewertungen, Weires (siehe hier) verwendet z.B. 1 bis 4 Sterne für die französischen Pässe (POV Bewertung). Aber für die Radsportbergwertung ist auch Platz in der Box, also warum nicht. --Herzi Pinki 12:25, 25. Dez. 2009 (CET)

Hier kann man die Bewertungen auch erfahren. Auf Grund der großen Verbreitung des "Denzel" in den einschlägigen Kreisen, kann man schon von einer allgemein anerkannten Skala reden.

Die Bewertung der Straßen ist im obigen Artikel eigentlich recht gut dargestellt. Es sind die drei Punkte Fahrzeug (mit welchem Fz. ist das ohne Probleme möglich, wie ist die Straße (Belag, Steilheit, Ausgesetztheit) beschaffen und wie ist die Erfahrung des Fahrers. So sprechen die engen Kehren und die Steigung bis 15 % fürs die SG 3 beim Stilfersjoch, dazu kommt die Höhe über 2000 m. Zum Vergleich die Glocknerstraße hat eine 2, der Tauerntunnel 1-2. Bei allem was über 3 ist muss man dann mit unbefestigter Straße rechnen, bei 5 sind es dann reine Feld- oder Schotterwege.

Natürlich kann ein Holländer das mit seinem Wohnwagen machen. Ist halt nur die Frage wie erfahren ist der Fahrer und wie hat das Fahrzeug das verkraftet (Bremsen, Motor etc.). liesel 22:28, 25. Dez. 2009 (CET)

Auf http://alpenrouten.de/ erfährt man den Denzel nicht, da dort nur die schwierigste Stelle angegeben wird, aber wir für beide Seite getrennte Werte brauchen. lg --Herzi Pinki 16:51, 26. Dez. 2009 (CET)

Ich habe mal einige verglichen, es wird in der gleiche Wert angegeben wie im Buch. Im Buch wird manchmal noch zwischen den beiden Seiten unterschieden, was diese Seite nicht tut. liesel 17:01, 26. Dez. 2009 (CET)

Woher weiß man jetzt, ob der Wert aus der Webpage DENZEL1 oder DENZEL2 ist? Na, wahrscheinlich aus dem Text sollte das hervorgehen. Aber soweit ich das verstanden habe gibt es entweder DENZEL1 oder DENZEL2, aber selten bis gar nicht beide. Trotzdem macht es natürlich Sinn, die beiden Seiten getrennt zu bewerten, da bergauf und bergab zwei Paar Stiefel sind (z.B. als Radfahrer). --Herzi Pinki 17:18, 26. Dez. 2009 (CET)

Es wird weniger nach bergauf bzw. bergab unterschieden, da die Schwierigkeiten trotzdem vorhanden sind. Die Nordseite desTendapasses hat 2-3, die Südseite 3-4. Auch beim Bergabfahren ist da die Südseite aufgrund der vielen Kehren nicht von ohne. Da können auch beim Radfahrer die Finger müde und die Bremsen ihre Wirkung verlieren. Die Schwierigkeiten sind halt andere, aber nicht weniger hoch.

Von den 640 Hochzielen im Buch haben 43 unterschiedliche Werte. liesel 17:31, 26. Dez. 2009 (CET)

Die Frage bleibt offen, woher weiß man, ob der Wert aus der Webpage sich auf die eine oder andere Seite bezieht. Diesen Wert für beide Seiten einzutragen, mag in vielen Fällen nicht falsch sein, aber im Allgemeinen fehlt dann für diese Angabe die Quelle. Ein analoges Problem tritt auf, wenn du bei der Umstellung von Vorlage:Infobox Passstrasse auf Vorlage:Infobox Pass die vormals passbezogene maximale Steigung ohne weitere Quellen nun als maximale Steigung beider Seiten interpretierst, wo sie für zumindest eine Seite nur eine obere Schranke der maximalen Steigung darstellt. siehe auch #MAXSTEIGUNG und LAENGE (Infobox Pass vs. Passstraße)

Wenn der Denzel eine Gesamtbewertung des Passes ohne Unterscheidung der beiden Seiten darstellt, dann ist die Art der Implementierung in der Infobox zumindest irreführend und es sollte nur dann zwei Werte für die beiden Seiten angegeben werden, wenn dies die Literatur hergibt. Wenn nicht, ist ein Wert für beide Seiten gemeinsam in der Mitte die bessere Alternative. lg --Herzi Pinki 17:01, 27. Dez. 2009 (CET)

Ok, kein Problem den Wert auch in der Mitte darzustellen. Im Zweifel sollte man auf das Buch zurückgreifen. Dies sollte in einer gut ausgestatteten Bibliothek zu finden sein. Ich hätte auch kein Problem die kritischen Sachen einzutragen, dann wäre das Kapitel weitgehend abgeschlossen.

Ja das mit der Steigung und der Länge habe ich auch schon festgestellt, aber das kann man in den meisten Fällen relativ schnell recherchieren. liesel 17:21, 27. Dez. 2009 (CET)

habe neuen Parameter DENZEL eingebaut, für den ganzen Pass ohne Seitenbezug. DENZEL1 und DENZEL2 sind jetzt auch isoliert möglich. lg --Herzi Pinki 17:51, 27. Dez. 2009 (CET)

Positionskarte

Gibt es bezüglich der Positionskarte irgendwelche Präferenzen? Ich habe jetzt beim ersetzen der „Infobox Passstraße“ durch „Infobox Pass“ einmal die Reliefkarte genutzt: Wir haben auch noch eine spezielle Karte für die Alpen (Bezugsrahmen "Alpen" könnte noch in der xml-Vorlage ergänzt werden) bzw. Savoyen oder Südtirol. Siehe auch: Wikipedia:Kartenwerkstatt/Positionskarten. liesel 16:11, 27. Dez. 2009 (CET)

Bisher habe ich immer die politische Karte genutzt. Der Einheitlichkeit wegen. Aber ich habe kein Problem mit der Reliefkarte, die ja auch noch die politischen Grenzen anzeigt. Ein Problem wird bei Bergen in Grenzlage deutlicher: Haben wir für alle Länder Reliefkarten? Haben wir nicht und damit wird es dann per se uneinheitlich. Irgendwie würde es Sinn machen, die Auswahl des Kartentyps per Vorlage zu machen, aber ich glaube, dass es dafür keine belastbare Namenskonvention gibt. Desgleichen halte ich die automatische Verwendung der Gebirgskarte für sinnvoll, aber nur wenn einheitlich. Dann müsste es aber z.B. für die Schweiz neben Alpen auch Jura in gleicher Ausführung geben und die Karte müsste aus der Gebirgsgruppe automatisch ableitbar sein. Habe schon mal drüber nachgedacht, würde aber für Gebirge und Gebirgsgruppen analoge Metadaten-Infrastruktur wie für die ISO 3166-2 Daten bedeuten. Dabei gibt es dafür nicht mal eine international belastbare hierarchische Struktur. Vorarbeit ist also notwendig.

Bevor wir das jetzt generell umstellen, sollten wir weitere Meinungen abwarten. lg --Herzi Pinki 16:46, 27. Dez. 2009 (CET)

Reliefkarten gibt es im Moment für CH, FRA, ITA. Da es keine Inselkarten sind, gibt es bei Grenzlagen keine Probleme. Wobei es langfristig auch für die anderen Länder Reliefkarten geben wird (hier hilft es auch manchmal nachzufragen und Bedarf anzumelden). Gerade für solche "unpolitischen" Punkte wie den gebirgigen Lemmatas (Berge, Pässe) finde ich die Reliefkarten aussagekräftiger. Man sieht die Lage im Gebirge besser.

Eine andere Frage bis zu welcher Untergliederung eines Landes man die Positionskarte nutzt, also z.B. keine Regionalkarten.

Die Frage nach speziellen Gebirgskarten ist dann noch einmal eine andere Sache. Ich finde aber pl:Mont Blanc aussagekräftiger als Mont Blanc. liesel 17:04, 27. Dez. 2009 (CET)

ich auch, und ich würde mir wünschen, die Berge und ihre Lage geographisch und unabhängig von den politischen Wirrnissen zu beschreiben. Der Punkt ist nur, dass es möglich ist, aus dem ISO 3166 Codes die politische Karte abzuleiten, während es z.B. aus CH-BE für den Kanton Bern nicht möglich ist, zwischen Jura und Alpen zu unterscheiden. Und eine manuelle Vergabe der Karten halte ich für nicht sinnvoll, da erstens Arbeitsaufwand, zweitens Fehleranfälligkeit, drittens Uneinheitlichkeit. lg --Herzi Pinki 17:16, 27. Dez. 2009 (CET)

Bei Einheitlichkeit meinte ich pro Typ von Artikel (oder Infobox), also für alle Pässe, weiters verstünde ich unter Einheitlichkeit auch, dass benachbarte Pässe (etwa Bielerhöhe und Reschenpass und Umbrailpass gleiches Look&Feel haben). --Herzi Pinki 17:16, 27. Dez. 2009 (CET)

Wenn man den Vorlagenmeister nutzt, wäre es kein Problem die entsprechenden Positionskarten (diese muss ja sowieso angegeben werden, unabhängig vom ISO-Code) an prominenter Stelle hervorzuheben. Man könnte die Vorlage auch so programmieren, dass bei Angabe des entsprechenden Gebirges die richtige Gebirgskarte und die dazugehörige Kategorie in den Artikel kommen.

Kategorie:Pass nach Gebirge zeigt eigentlich welcher Bedarf besteht (so denn alle Pässe eingeördnet wären). Bei den Bergen wäre es analog. Ich glaube wenn man an die Kartenzeichner herantritt und sagt, wir bräuchten eine Positionskarte für Gebirge X um damit 200 Artikel damit zu versehen, sind die schnell bereit was zu machen. Btw. die Alpenkarte würde sich beim Reschenpass wesentlich besser machen als die Italien-Karte. liesel 17:36, 27. Dez. 2009 (CET)

Worin besteht jetzt das Problem, wenn man mittels Bot ö.ä. in alle Alpenpässe die Alpenpositionskarte einsetzt? Wer in Zukunft einen Alpenpass anlegt nimmt entweder diese gleich, weil er nichts anderes in anderen Artikeln sieht oder lässt die Karte weg. Da die Angabe des ISO-Code nicht automatisch die Karte einsetzt, muss dies sowieso per Hand erfolgen. Und in der Kartenwerkstatt wurde unmissverständlich gesagt, wenn ihr schon die "Alpenkarte" nicht wollt, dann gibt es auch keine für andere Gebirge. Und gerade im Vergleich Umbrail-Stilfser kann ich gleiches Look&Feel nicht erkennen.

Und wie ich schon schrieb, man könnte die Infobox auch ähnlich der Vorlage:Infobox Gemeinde in Deutschland programmieren. Dort wird durch die Angabe der übergeordneten politschen Einheiten gleich die entsprechende Kategorie erstellt. Hier wäre das z.B. "Alpenpass" gleichzeitig könnte dann auch automatisch die Positionskarte auf "Alpen" gesetzt werden. liesel 16:42, 29. Dez. 2009 (CET)

Vorweg, ich überleg mir mal was, aber geographische Regionen lassen sich nicht so einfach in Subeinheiten dividieren wie politisch-administrative Gebilde. -- visi-on 16:58, 29. Dez. 2009 (CET)

Das muss auch gar nicht so ins Detail gehen, weil niemand für jedes Mittelgebirge eine Karte erstellen wird. Ich halte Liesels Ansatz von der Übernahme des Gebirgsnamens in der Infobox als Ersatz für den ISO-3166-2-Code für handhabbar. Wenn Gebirge X angegeben ist und eine entsprechende Positionskarten-Vorlage vorhanden ist, wird diese eingebunden. Dabei muss nicht für jeden Höhenzug eine eigene Vorlage gemacht werden, Berge im Jura können vorerst auch auf der Alpenkarte gezeigt werden. Und wenn keine entsprechende Karte vorhanden ist, muss eben auf den ISO-Code zurückgegriffen werden. Es muss nur klar sein, dass das kein weltabdeckendes Prinzip werden kann (und vor allem nicht über Nacht für alle Gebirge anzubieten ist). Die Geografen sollten sich überlegen, welche Einheiten sinnvoll dargestellt und abgegrenzt werden, im Zweifel mit etwas mehr Umgebung, damit auch strittige Definitionen abgedeckt werden. NNW 13:02, 30. Dez. 2009 (CET)

bereits der Detailierungsgrad der Alpen tendiert gegen abzählbar unendlich ... ;-) -- visi-on 13:31, 30. Dez. 2009 (CET)

zwei generelle Anmerkungen:

• das ist hier eine stille Ecke, habe daher im Projekt Berge und Gebirge darauf hingewiesen. Aber auch die Geografen sollten involviert werden.
• Gebirge, im Gegensatz zu den meisten Ländern, haben gefühlsmäßig ein ungünstigeres Breiten/Längenverhältnis, da sie ihrer Natur nach eher lineare Gebilde sind. Damit ergibt sich zum aktuellen Chile-Problem dann auch noch ein Problem mit den Rockies, dem Ural, dem australischen Ostküstengebirge, den Neuseeländischen Alpen, den Appalachen, dem Apennin, den Vogesen, den Skanden. Alpen, Pyrenäen und Himalaya sind ja zum Glück Ost-West orientiert und machen weniger Probleme.

lg --Herzi Pinki 13:20, 30. Dez. 2009 (CET)

dritte Anmerkung

• die grossen Pässe liegen nicht in sondern zwischen Gebirgen, das ergibt sich aus der orographischen Definition eines Gebirges -- visi-on 13:29, 30. Dez. 2009 (CET)

Genausgut findet man auch Staaten die nicht ins Format passen. Neben Chile fällt mir noch Italien, Argentinien, Japan, Norwegen, Schweden, Neuseeland und Vietnam ein. Vor allem bei den Rocky-Mountains-Pässen in Colorado ist mir aufgefallen, wenig aussagekräftig so eine Bundesstaatskarte ist (Tennessee Pass (Colorado)). Alternativ könnte man auch für jede Staats-Positionskarte eine weitere mit den topografischen Angaben anbieten. Nur wäre das noch mehr Arbeit für die Kartenzeichner.

Eher liegen ja die großen Pässe zwischen zwei verwaltungstechnischen Einheiten (Staaten, Kantone etc.) liesel 13:42, 30. Dez. 2009 (CET)

Dass für jede administrative Karte eine Reliefversion gemacht wird, ist eh geplant, wird bei den wenigen Mitarbeitern aber noch dauern. Wir sind schon anderthalb Jahre mit den jetzigen Karten beschäftigt gewesen. Ein paar Gebiete aber haben sie schon.

Die meisten Pässe dürften wohl innerhalb eines Gebirges liegen, die am Rand haben Pech (oder eben Glück, weil die Karten großzügig geschnitten werden könnten). Andererseits hat Oberstdorf mit der D-Karte auch Pech und keiner beklagt sich. Etwas liegt immer am Rand.

Vielleicht findet sich ja ein Weg, lange Gebirge in mehreren sinnvollen Abschnitten darzustellen. Die Alpen könnte man recht einfach in West- und Ostalpen teilen, fragt sich nur, wie das programmiertechnisch zu lösen wäre. Und ob das die Geografen ohne Blutvergießen hinbekommen. NNW 14:19, 30. Dez. 2009 (CET)

Infobox Pass (Alpen)

300 px

Infobox Pass (Alpen)

500 px

Es ist ja eher eine Frage der Auflösung. Wobei ich bei den Alpen da noch kein Problem sehe. Wenn man Gebirge unterteilt, z.B. die Anden dann sollte man keine feste Grenze wählen, sondern einen gewissen Überlappungsbereich. Ach und bisher ist in der WP relativ wenig Blut geflossen, dann schon eher Schweiss. ;-) liesel 14:43, 30. Dez. 2009 (CET)

Also zu den Alpen, die sind ja super, die sind ein schlechtes Beispiel für ein schlechtes Beispiel. Schön rechteckig, fast goldener Schnitt, hoher Erkennungs- und Wiedererkennungswert. Ein Bild das wir schon tausendmal gesehen und internalisiert haben. Vielleicht geht es anderen mit dem Erzgebirge oder dem Altai ähnlich. Die Alpen in ihrer kompakten Darstellung in Ost und West zu teilen, halte ich für unnötig. Es raubt uns auch die Möglichkeit, neuer ganzheitlicher Perspektiven. Und wo ist West, und wo ist Ost? Nach welcher Einteilung teilen wir?

@Liesel: Zum Coloradobeispiel von Liesel, das liegt wohl an der unnötigen und mE sinnlosen Detaillierung der Karten auf immer kleinere administrative Einheiten. Würden wir überall die Karte von der Granularität country nehmen, würde damit automatisch die Anzeige auf Basis der US-Karte erfolgen, und nicht auf Basis der Colorado-Karte. Ich fürchte nur, die Saarländer und Sachsen finden das dann wieder nicht so gut. Ich schon, da ich die Umrisslinien von Saarland oder Sachsen nicht im Kopf habe und nicht in einen größeren Kontext einordnen kann.

@NNW, wir haben die Gebirgsgruppe in der Box, das Problem ist doch, dass wir hunderte verschiedene Gebirgsgruppen in der Box haben. Als Links, unverlinkt, Mehrfachangaben durch Komma oder / getrennt, mit Kommentar. Daher ist es nicht so ganz einfach, aus dem Freitext für die Gruppe den Namen der Karte automatisch zu erzeugen.

Ich versuche mal zusammenzufassen:

1. Obwohl die Disk hier begonnen wurde, ist das Problem umfassender und wir sollten Berge, Gebirge, Pässe, Höhlen, ev. Flüsse und dergleichen gemeinsam betrachten, also Objekte, die ohne Zutun des Menschen im Gegensatz zu z.B. Orten einfach da sind. Natürlich kann eine Umstellung nur schrittweise, Infobox für Infobox erfolgen. Aber die Perspektive sollte klar sein. Und die Menge, um die es geht.
2. Berge liegen nicht nur in Gebirgen, d.h. man ist relativ schnell bei anderen Regionen, die sich nicht als Gebirge definieren.
3. Pässe, wie visi-on oben richtig ergänzt hat (danke), liegen, je bedeutender (im geografischen, nicht im touristischen Sinn), umso weniger in einem Gebirge (z.B. Colle di Cadibona). Aber das lässt sich mit der Randlage, die bei politischen Karten ja auch existiert, akzeptieren. Dafür würden die Berge von der oftmaligen Randlage auf politischen Karten in die Mitte des Geschehens rücken.
4. Derzeit erfolgt die Kategorisierung nach Gebirge explizit, d.h. nicht über die Infobox. Die Angabe eines Gebirges dort hat keine Auswirkung auf die Kategorisierung. Ausnahme: Vorlage:Infobox Schutzhütte, wo aus dem Gebirge die Kat gebildet wird, dies aber unter dem Aspekt Kategorie:Gebirge als Thema. Dies wäre geeignet umzustellen, um Redundanz zu vermeiden.
5. Es gibt unterschiedliche Bedürfnisse, die die Poskarten erfüllen sollen, die kaum unter einen Hut zu bringen sind:
   1. Für die Nachbarschaft wünsche ich mir eine möglichst genaue Karte, dass der Großglockner etwa mitten in AT liegt, hilft wenig. Für die Ferne wünsche ich mir eine Karte mit Wiedererkennungswert, am Fall Tennessee Pass (Colorado) sieht man, wie durch Erhöhung der Genauigkeit Information verloren geht. Nur was ist Ferne, was ist Nähe?
   2. Für einen Autor, der sein Lieblingsobjekt beschreibt, ist es Unsinn, die Lage eines Düsseldorfer Berges auf der DE-Karte darzustellen, für jemand, der keine Ahnung hat (und meistens haben wir alle miteinander keine Ahnung), z.B. auch einen Leser, ist die Information, wo Düsseldorf nun eigentlich liegt, viel relevanter.
   3. Politische Karten haben hohen Wiedererkennungswert, grenzüberschreitende topologische Karten sind zumindest gewöhnungsbedürftig. Das muss man erst einmal durchsetzen, auch bei Autoren, die generell Infoboxen und solche Automatismen als Einschränkung ihrer Kreativität und Gestaltungsfreiheit betrachten.
   4. generell die OMA-Tauglichkeit
   5. Insgesamt erwarte ich mir von der Positionskarte eine auf einem Blick verwertbare Information, wo ein Objekt nun liegt.
   6. Geo-Kartendienste lösen dieses Problem anders, durch Zoomen, automatisches Switchen der Darstellungsart, exzessive Benutzereinstellungsmöglichkeiten (allesamt nicht OMA tauglich, am ehesten noch der französische Dient). Politische Grenzen und eindimensionale Orientierungslinien wie Straßen sind dort in der Regel überdominant.
   7. Wir haben noch den GeoHack und externe Dienste, wir müssen nicht alles selbst machen.
6. Dies alles nochmals überdenkend, meine ich, dass es unmöglich ist, für alle Benutzergruppen die ideale Lösung zu finden. In diesem Sinne ist der von NNW gemachte Hinweis auf die PositionskarteX, die wir unter Missachtung ihrer Möglichkeiten sträflich vernachlässigen, der richtige. (Danke NNW). Standardmäßig und per Infobox generiert wünsche ich mir eine Anzeige der
   1. Karte mit politischen Grenzen auf staatlicher Ebene als Default. Diese Karten sind flächendeckend vorhanden und ihre Umrisse sehr vielen Menschen geläufig. Ob dies nun in Reliefdarstellung oder nicht erfolgt, ist egal und ändert wenig. Wenn eine Reliefkarte vorhanden, dann sollte sie auch verwendet werden, im anderen Fall Rückfall auf die existierenden Karten, die allesamt ausreichend Unterstrukturen enthalten (Flüsse, Subgrenzen).
   2. Karte auf erster administrativer Ebene (adm1st) oder, falls vorhanden, auf zweiter administrativer Ebene (adm2nd), alternativ beides oder abhängig von der Infobox auch beschränkt auf die erste Ebene. Wer fängt schon was an mit dem Landkreis oder dem Bezirk oder gar dem County (abgesehen von der Verfügbarkeit entsprechender Karten)
   3. Karte der Region im geographischen Sinn, also des Gebirges, oder einer äquivalenten Struktur, so existent. Dies ist übrigens das oben angerissene Teilproblem. :-(
   4. Alle Karten werden automatisch aufgrund verwertbarer Informationen in der Infobox erzeugt, ähnlich einer automatischen Kategorisierung (die gleich mit erledigt werden sollte). Die Karten werden in Abhängigkeit ihrer Existenz erzeugt, d.h. aber auch ohne Wahlmöglichkeit durch den Hauptautor. Existiert die Karte, wird sie verwendet. Ein zusätzlicher Parameter mit dem Namen der Großlandschaft ist wohl nötig und zusätzlich zum ISO Code anzugeben.

Off Topic:

1. Die Poskarte bei Vorlage:Infobox Pass automatisch aus dem ISO code zu erzeugen, würde ganz einfach gehen. Bezüglich Randlage ist kein Unterschied zu den Bergen, und Karten, die die Südschweiz mit Norditalien zeigen (oder Ostperu und Westbolivien), haben wir eh keine. Kann mich an keinen Grund erinnern, warum das damals nicht geschehen ist.

   Die Versionsgeschichte erinnert mich daran, dass der Entwurf ein Jahr vor Vorlage:Info ISO-3166-2 war und damals war mein Fokus auf der Umsetzung der drei Spalten. Inzwischen hat sich die Navigation durch die Administrationhierarchien etabliert. -- visi-on 22:04, 30. Dez. 2009 (CET)

2. Bei Gebirgsgruppe ist das schwieriger, da die Einpunktlösung für flächige Gebilde ohnehin schon ein schlechter Kompromiss ist.
3. Zu den Nord-Süd-Bandwürmern (wie Chile oder Ural) eine Idee. Vielleicht machen wir in definierten Fällen die Poskarte an den rechten Rand der Infobox in eine zusätzliche Spalte, dafür über die volle Höhe?

   gute Idee, dass könnte man mal Testen, ich befürchte nur, dass der zusätzliche Platzbedarf in der Breite – die Box hat jetzt schon überbreite – nicht überall gut ankommt-- visi-on 22:04, 30. Dez. 2009 (CET)

--Herzi Pinki 21:01, 30. Dez. 2009 (CET)

Danke, diese Fülle muss nun erstmal reflektiert werden ... -- visi-on 21:43, 30. Dez. 2009 (CET)

Bei Loveland Pass habe ich das mal mit der USA-Karte statt der Colorado-Karte umgesetzt. Wobei ich vermute, dass als gemeinsamer Nenner eher die Umrisslinie der Staaten als irgendwelche kleineren adminstrativen Einheiten allgemein bekannt sind.

Gerne kann man die Diskussion auch woanders weiterführen, schlecht wäre es nur, wenn sie ergebnislos einschlafen würde. Nicht das mein Auftreten hier als Eindringen aufgefasst wird, aber manchmal schaut man halt auch in andere einen interessierende Gebiete und findet dann einige nicht nachvollziehbare Sachen. Wenn hier also Diskussionen zum wiederholten Male geführt werden, könnt ihr mich das ruhig wissen lassen.

Ja die Anwendung von topografischen Karten scheint mir bei natürlichen geografischen Objekten sinnvoll. Dies muss nicht immer eine Positionskarte sein. Bei flächigen Objekten (Gebirge, Seen, Wüsten) macht sich das eher ungünstig. Aber bei Einzelobjekten sollte eine topografische Karte erste Wahl sein. Das man das nicht alles auf einmal umstellen kann, sollte eigentlich klar sein. Aber mit Hilfe vieler Benutzer und einiger Bots schafft man das schon. Ich denke da nur an die Umstellung der Koordinaten-Vorlage.

Bei einem ordentlichen Zuschnitt der Gebirgskarten gibt es kaum Problem mit Pässen in Randlage. Diese liegen ja trotzdem meist auf dem Gebirgskamm.

Bei Bergen in Einzellage ist hier dann die topografische Karte auf Staatsebene immer noch möglich.

Gerade mit den Positionskarten können wir nicht alle Informationsbedürfnisse abdecken. Hier sollte anhand des geografischen Objektes entschieden werden, welches die geeignetere Grundlage (administrative, topografische, thematische Karte) ist.

Zusätzlich wären dann immer noch detaillierte, speziell erstellte Karten im Artikel möglich. Gerade bei vielen außereuropäischen Gebieten versagen auch heute noch die Kartendienste im Netz.

Die PositionskarteX war mir bisher noch nicht bekannt und mich wundert es, dass diese bisher noch nicht genutzt wird. Gerade bei geografischen Objekten in Grenzlage Chaiber-Pass bietet diese gute Möglichkeiten der Darstellung.

Ein weiterer gangbarer Weg wäre es wahrscheinlich zuerst die Automatisierung in den Infoboxen zu verbessern (Positionskarte, Kategorie) und in einem weiteren Schritt durch den Einsatz von PositionskarteX die Möglichkeiten der verschiedenen Kartendarstellungen auszuschöpfen.

Bei den Nord-Süd-Riesen könnte man auch mit Schieber experimentieren. liesel 23:21, 30. Dez. 2009 (CET)

Zur Verdeutlichung ein paar Beispiele:

• Pfitscher Joch: Alpenkarte
• Abra del Acay: Argentinien
• Stilfser Joch:Italien
• Chaiber-Pass: Afghanistan, obwohl Pass in Pakistan liegt
• Loveland Pass: USA-Karte statt Colorado-Karte: Ute Pass
• Oberalppass, Passwang, Nufenenpass, Klausenpass, Rickenpass, Schwägalp, Hulftegg, Weissensteinpass, Col des Mosses, Wolfgangpass, Wildhaus (Pass), Sattel (Pass), Stoss AR, Scheltenpass, Glaubenbielenpass, Col du Marchairuz: topografische Karte Schweiz

liesel 10:41, 9. Jan. 2010 (CET)

Danke für die Beispiele, nur wofür? --Herzi Pinki 00:37, 10. Jan. 2010 (CET)

Wenn eventuell noch weitere mitdiskutieren wollen, damit diese sich gleich mal ein Bild machen können, bzw. damit wir auch schneller auf einige prägnante Beispiele zurükgreifen können ohne lange suchen zu müssen. liesel 11:17, 10. Jan. 2010 (CET)

ich jedenfalls wär sehr dafür, topographische karten für topgraphische objekte wär eine wirkliche bereicherung --W!B: 18:50, 5. Jan. 2010 (CET)

Das Problem was ich beim Aufruf einer Seite mit einer Positionskarte immer habe: Raten, welches Gebiet eigentlich gerade dargestellt wird. Wäre es da nicht sinnvoll, daß die Kartenüberschrift gleich anzeigt was die Karte darunter darstellt? Also anstelle von "Karte" besser ein "Lage in Italien", "Lage in Baden-Württemberg" oder "Lage in den Alpen". Das es eine Karte ist sehe ich ja auch so, das braucht man nicht hinschreiben :-) Damit hat man auf den ersten Blick eine viel bessere Info, was dargestellt wird. -- Ulflulfl 16:54, 10. Jan. 2010 (CET)

Zwischenstand

Habe jetzt die reliefkarten defaultmäßig eingebaut und die Poskarte wird automatisch aus dem Iso code bestimmt, muss also nicht mehr angegeben werden. Umsetzung ist fertig, aber es muss noch nachgeräumt werden. lg --Herzi Pinki 01:42, 21. Mär. 2010 (CET)

Ich trieb mich neulich aus Interessen in den Admiralitätsbergen herum. Dabei bemerkte ich, dass bei einigen Bergen die Antarctica location map.svg, bei anderen hingegen die Antarctica relief location map.jpg angezeigt wurde. Dort wo ich war, habe ich die Reliefkarte als Alternativkarte angegeben, da sie eine detaillierte Übersicht bietet ohne überfrachtet zu sein. Herzi Pinki bemerkte dies und bat hier um eine Stellungnahme. Grundsätzlich würde ich bei allen Objekten, die das Relief einer Landschaft ausmachen eine entsprechende Reliefkarte bevorzugen. Wenn sich das standardmäßig einstellen ließe, fände ich das ausgezeichnet. Für Berge o.ä., wo es (noch) keine passende Reliefkarte gibt, sollte dann eine andere Positionskarte angezeigt werden. --Milseburg 17:35, 19. Mai 2010 (CEST)

Orte die auf Pässen liegen

Was macht man bei solchen Fällen? Beispiel: Predeal. liesel 12:40, 19. Jun. 2010 (CEST)

• Weiterleitung mit Passkategorien
• 2 Infoboxen in einem Artikel
• nix, warum auch (nicht jeder Pass braucht eine Infobox (z.B. auch nicht Jungfraujoch))

Das Problem, dass eine Objekt in mehr als eine Klasse fällt bzw. dass semantisch zusammengehörendes auch in einem Artikel beschrieben wird, haben wir doch öfter (See, Stausee; Berg und Stock; Menschen mit mehreren Berufen für die sie relevant sind; ...) --Herzi Pinki 14:57, 19. Jun. 2010 (CEST)

Ersteres ist nicht notwendig, wenn Pass und Ort die gleiche Bezeichnung haben. Zweiteres halte ich für ungünstig, vor allem bei kurzen Artikeln. Dann nur den Ort mit einem Infobox versehn. Bei anderen Sachen (See, Stausee, Berg) kann man sich streiten, was wichtiger ist, Pass oder See. (wir haben nur bei sportler infoboxen) Dritte Möglichkeit widerspricht der Angabe der unter "Beispiele" angegebenen Anzahl der Artikel ohne Infobox. Ich habe kein Problem damit, dass nicht in jedem Artikel eine Box ist. Aber dann sollte man das auch klar kommunizieren. liesel 15:06, 19. Jun. 2010 (CEST)

Ich habe die Möglichkeiten oben alternativ gemeint, je nach den Kriterien, die du ja eh ausgeführt hast. Und du hast Recht, wir haben nur für Sportler Infoboxen, aber da gibt es auch etwa eine Beth oder einen Eric Heiden. Dann nur den Ort mit Infobox versehen - was ist mit Forch?

CatScan ist ein Werkzeug, das uns hilft, Artikel aufzuspüren, wo u.U. Handlungsbedarf besteht. Handlungen können beispielsweise sein:

• Einbau einer Infobox
• Kategorien in Weiterleitung auslagern
• falsche Klassifizierung auflösen (z.B. Zugerberg)
• Ignorieren (bei Redirects und Listen üblich)
• abwarten, fall Autoren Infoboxen nicht mögen und revertieren.

(vermutlich nicht vollständig). CatScan sagt uns nicht, dass eine Infobox fehlt und daher eingebaut werden muss. In diesem Sinn sollte das oben auch nicht verstanden werden. lg --Herzi Pinki 15:27, 19. Jun. 2010 (CEST)

Forch hatte noch keine Infobox.

Natürlich ist mir klar wozu CatScan dient. Aber in Verbindung mit der Anzahl der noch nicht mit Box versehenen Artikel wird halt der Eindruck erweckt, dass da was abzuarbeiten ist. liesel 15:32, 19. Jun. 2010 (CEST)

Forch ist ein Ort und deine Frage war nach Orten, die auf Pässen liegen :-) --Herzi Pinki 15:48, 19. Jun. 2010 (CEST)

das scheint mit NEBENBOX erledigt, cf. Waidring und Flecken (Gemeinde St. Ulrich), zwei Talpässe - das gegenteil übrigens Fernpass (Pass hat Vorrang vor Kleinstort) - siehe auch #Nebenbox unten --W!B: 03:08, 15. Jan. 2011 (CET)

Probleme mit Opera

Hallo, diese Infobox wird in Opera nicht richtig dargestellt. Hier gibt es Screenshots mit der aktuellen Browser-Version [1] [2]. Kann das bitte jemand beheben? Danke --Wkpd 13:57, 15. Dez. 2010 (CET)

Nebenbox

hab die fehlende doku zum standerd-geoboxen-feature ergänzt: wie oben gesagt, verschiedene geobjektklassen fallen zweckdienlicher weise öfter zusammen, was nicht unterbinden sollte, die IBs dafür anzusetzen - ich hab übrigens in Vorlage:Infobox Gemeindeteil in Österreich #Nebenbox noch das feature NEBENOX=2 eingeführt, das die box dann auch nicht rechtsbündig, sondern als textbox links ausrichtet: das erleichtert layoutprobleme, die jetzt mit dem setzen der IB in eine tabelle gehackt werden müssen - cf. Flecken (Gemeinde St. Ulrich) #Geographie, die IB macht sich imho dort als übersichtliche darstellung des sachverhalts extrem gut (tatsächlich könnte sie so aber auch in Pillerseestraße stehen, und wäre dort ebenfalls eine nebenbox) --W!B: 03:17, 15. Jan. 2011 (CET)

Danke für die Ergänzung. erleichtert Layoutprobleme ist wohl wahr, eigentlich sollten wir sie erschweren, macht sich dort extrem gut, kann wohl nur ironisch gemeint sein. Ich finde das nicht. Nebenbox ist die Ausnahme, bei dir scheint sie zur Regel zu werden. lg --Herzi Pinki 12:48, 15. Jan. 2011 (CET)

ich dachte Du bist gegen atomisierung, nein, es war nicht ironisch - soll ich noch einen artikel Waidring (Pass) schreiben (was TF wäre, obwohl dort in Waidring unstrittig einer ist, und noch dazu ein wichtiger, nur hat er keinen namen)?

ich persönlich halte die artikel, die eine monster-IB mit drei zeilen text sind, für unfug (bei pässen leider häufig, über viele gibt es halt kaum was zu sagen, ausser dass es sie gibt, aber die IB ist immer wohlgefüllt): da hast Du recht, ich mag sie, ich glaube, nebenboxen gehört die zukunft, um sachverhalte darzustellen, die zuwenig material für einen artikel abgeben, aber darstellungswert sind - "eine IB, ein artikel", das modell dürfte langfristig nicht haltbar sein, und das modell "IB statt text" (mit eigenem lemma als rechtfertigung für die IB) erst recht, oder bauen wir einen zettelkasten? - die wikiboxia wäre ein überlegenswerter fork: nur IBs --W!B: 06:50, 18. Jan. 2011 (CET)

verstehe jetzt dein Argument nicht ganz, warum soll durch mehrere Nebenboxen in einem Artikel der Text mehr werden? ME sollte sich ein Artikel in der Auswahl der Infobox auf den wesentlichen Aspekt einer Sache konzentrieren, der Rest muss weder in eigene Artikel (WL reichen) noch in eigene Boxen gepresst werden. Und wenn der Artikel eine gewisse Länge überschreitet, gibt es die Möglichkeit einer Teilung und dabei immer noch die Möglichkeit, eine andere Infobox einzubauen. Du hast ja jetzt schon zuwenig Text, um die diversen Boxen untereinander platzieren zu können, nebeneinander füllt den unschönen Weißraum, bringt das aber auch mehr Text. Der Satz Der Ort liegt an der Talwasserscheide des Pillerseetals, wo der Grieslbach (Haselbach, Loferbach), der von Osten aus den Loferer Steibergen kommt, nach Norden fließt, und der Moosbach zur Fieberbrunner Ache (Pillerseeache) nach Südosten. in Flecken ist doch schon der Kern, die Infobox (abgesehen, dass hier offensichtlich Layoutprobleme auch in der box bestehen, weil du ihr keine Möglichkeit zum Zeilenumbruch lässt), bringt keine sinnvoll weiterführende Information. lg --Herzi Pinki 13:47, 25. Jan. 2011 (CET)

Vorlage:All Coordinates

Habe mal folgende Frage: Bei Washington Pass habe ich die o. g. Vorlage eingefügt. Dummerweise Vorlage:Smiley/Wartung/???  wird unter OSM in der Navigationsleiste nur der Titel des WP-Artikels eingefügt (also Washington Pass), so dass ich zwei Marker mit der Bezeichnung Washington Pass habe und nicht einen mit Washington Pass und einen mit Rainy Pass (gleichfalls im Artikel beschrieben und als Nebenbox deklariert). Kann man das ändern, indem irgendwo in der Inforbox:Pass noch ein Parameter gesetzt wird, oder ist das ein Problem von OSM? Gruß --Vorwald (Diskussion) 11:06, 1. Jun. 2018 (CEST)

Default Poskarte fürs Trentino (und evtl. andere Alpenregionen)?

Auf die Gefahr, das ich ein altes Pferd aufzäume (ich habe die Diskussion weiter oben gelesen) ... Aktuell wird als default Poskarte für das Trentino (ISO: IT-TN) Italien gesamt eingeblendet, was für eine "erste Lagebestimmung" leider etwas zuuu grob ist :-) Könnte man stattdessen vielleicht besser die Poskarte "Vorlage:Positionskarte Alpen" einblenden? Diese Karte finde ich für Alpenpässe gegenüber der Italienkarte deutlich geeigneter und man könnte sich z.B. dann die "händischen" Einträge für Pässe (s. Dateiverwendungen ) wohl in vielen Fällen sparen.

Zwei Beispiele für Defaultkarten die mir nicht recht gefallen (eines zu grob, eines zu fein ;-):

• Passo di Vézzena: Kartenüberschrift "Karte (Trentino)", Karte aber tatsächlich ganz Italien (außerdem Karte sehr grob, man erkennt die Lage kaum)
• Stilfser Joch: Kartenüberschrift "Karte (Südtirol)", Karte ist tatsächlich Südtirol (Karte ist aber zu fein, außer man kennt sich in Südtirol bereits sehr gut aus)

In beiden Fällen würde ich die Relief Alpen Karte vorziehen, da sie in meinen Augen hier ein guter Kompromiß ist. Andere Meinungen? -- Ulflulfl 00:51, 25. Jan. 2011 (CET)

Hallo Ulflulfl,

Karte #1

Alpen (Alpen) Marker #1

Karte #2

Südtirol (Südtirol) Marker #1

Karte #3

Südtirol (Südtirol) Marker #1

Karte #4

Italien (Italien) Marker #1

Karte #5

Italien (Italien) Marker #1

• die Poskarte wird (nicht nur bei den Pässen, sondern an vielen Stellen) aus dem iso-code bestimmt. Eine Änderung der Poskarte für das Trentino von der Italienkarte auf die Alpenkarte wäre zwar an zentraler Stelle möglich (für Trentino hier, mehr als 200 Einbindungen), hätte aber globale Auswirkungen und wäre etwa bei Gemeinden eher nicht erwünscht. Ohne großes Meinungsbild ist da vermutlich nur Zoff zu holen. Und mit dem Trentino ist es ja nicht getan. Und würde natürlich eine Asymmetrie zwischen den Alpen und dem Apennin erzeugen.
• Sonst bleibt nur das manuelle Eintragen, das mir auch nicht gefällt, da erstens Editwar anfällig und zweitens Geschmackssache und drittens wegen der Einheitlichkeit.
• die Kartenüberschrift ist falsch, seit Monaten, aber du bist der erste, der das bemerkt hat. Mein Vorschlag wäre hier, die Zeile mit Karte komplett zu streichen (es ist ja augenscheinlich, dass es sich um eine Karte handelt), und die Region steht zwei Zeilen weiter oben als Text. Meinung?
• bei Südtirol stimme ich dir zu, aber über kurz oder lang werden wir für jede Provinz eine Karte haben, wo man sich gut auskennen muss, um etwas zu erkennen. Ich fange mit der Karte von Sachsen auch nix an. Alternative wäre hier, generell (es gibt nur eine box, Einheitlichkeit) auf die nächste administrative Ebene zu wechseln, das wäre dann Italien. Italien würde ich auch blöd finden, aber bei der Schweiz die Gesamtschweiz der Kantönlikarte vorziehen.
• So rechts ein Vorschlag der Implementierung mit mehreren Karten. Die Alpen / Jura / Anden / wären aber immer noch als zusätzlicher Parameter notwendig; dafür könnte man daraus dann auch automatische Pass nach Gebirge-Kategorien generieren.

lg --Herzi Pinki 11:30, 25. Jan. 2011 (CET)

• Das mit dem Editwar hatte ich fast befürchtet ;-) Ich werde das Gefühl nicht los, daß hier eine Auftrennung in politische und geografische Objekte sinnvoll ist. Bei einer Gemeinde werden mich eher die politischen Grenzen interessieren, bei einem Berg hingegen eher die Geografie. Andererseits gibt es bestimmt genügend Grenzfälle, wo mal das eine und mal das andere besser wäre. Ob man das jetzt automatisiert oder nur von Hand in den Griff bekommt weiß ich nicht (automatisiert wäre natürlich schöner). Was mich aktuell ein wenig "stört" ist die Uneinheitlichkeit und die in (zu?) vielen Fällen eher "suboptimalen defaults". Frage mich daher eher: Können wir es überhaupt hinbekommen, einen wirklich sinnvollen Default für die einzelnen Gebirge hinzubekommen? Also Alpen immer "Alpen Relief", Vogesen immer xy, usw. Wie man das dann "durchführt", also jeweils von Hand einträgt oder automatisch ist dann ja erst die nächste Frage.
• Die Kartenüberschrift sollte sich natürlich auf den Kartenausschnitt beziehen :-) Sowas wie "Lage in Italien". Wenn das nicht geht eher streichen als was falsches.
• Diese Idee der feingranularen Poskarten (Südtirol) taucht doch ganz allgemein nix! Ich wage zu behaupten, daß 99,9% der Leser weder mit der Karte eines Kantons noch einer Niedersachsenkarte spontan was anfangen können (mich eingeschlossen). Bei der Karte geht es doch um eine ganz grobe Übersicht, die Details schaut man sich besser auf einer großen "interaktiven" Karte an.
• Ich finde das Konzept der "umschaltbaren Poskarte" irgendwie witzig, weiß aber nicht ob das wirklich intuitiv verstanden / angewendet wird

-- Ulflulfl 21:11, 25. Jan. 2011 (CET)

PositionskarteX ISO

Habe ein bisschen Infrastruktur geschaffen, neue Vorlage:PositionskarteX ISO, diese erzeugt dynamisch aus dem iso-code die Karten, die man weiterschalten kann. Und sie erlaubt genau eine weitere Primärkarte, die nicht aus dem ISO code ableitbar ist, also z.B. die Alpen.

Karte #1

Alpen (Alpen) Marker #1

Karte #2

Südtirol (Südtirol) Marker #1

Karte #3

Trentino-Südtirol (Trentino-Südtirol) Marker #1

Karte #4

Italien (Italien) Marker #1

Karte #5

Europa (Europa) Marker #1

Beispiel für Südtiroler Pass

{{Benutzer:Herzi Pinki/Vorlage:PositionskarteX ISO|region1=Alpen|region-iso=IT-BZ|maptype=relief
|lat = 46/31/50/N
|long = 11/6/44/E
|border=none
|float=right
|type=mountain
|elevation=1555
|width=300x200
}}

weitere Beispiele siehe Benutzer:Herzi Pinki/Vorlage:PositionskarteX ISO/Test.

--Herzi Pinki 15:22, 26. Jan. 2011 (CET)

Vorschlag für Erweiterung dieser Box

Anschließend an die Disk weiter oben mache ich mal folgenden Vorschlag:

• die PositionskarteX wird in die Infobox eingebaut. Damit haben wir dann einen representativen Querschnitt an Regionen und Beispielen, um darüber diskutieren zu können.
• neue Parameter GEBIRGSSYSTEM (bessere Vorschläge willkommen), mit der Bedeutung hierarchisch übergeordnetstes Gebirge, also Alpen, Jura, Vogesen, Pyrenäen, Himalaya, Anden, Ural und dergleichen. Dieser Wert wird nicht angezeigt, aber falls es eine passende Karte gibt, wird diese vorrangig angezeigt. Die durch den (ersten) ISO-code bestimmten Karten werden nachrangig angezeigt.
• automatische Prüfung auf POSKARTE=Alpen. eventuell lässt sich die POSKARTE auch noch in die PositionskarteX einrarbeiten.
• aus GEBIRGSSYSTEM wird auch automatisch kategorisiert, Alpenpass, Pass in den Pyrenäen, Pass im Jura (Jeweils ohne weitere Unterkategorien), etc. (falls die Kategorie existiert). Dazu wird eine zentrale Mappingtabelle benötigt.
• neuer Parameter TYP mit den Werten Gebirgspass, Talpass, Talwasserscheide. Default ist Gebirgspass. Abhängig von den Werten erfolgt eine automatische Kategorisierung in Gebirgspass und Talpass, und Talwasserscheide. Für Talpass wird ein zusätzlicher Parameter WASSER benötigt, da WASSER1 und WASSER2 auf beiden Seiten des Talpasses per Definition identisch sein müssen. Eine Talwasserscheide, die ja kaum als Pass wahrgenommen wird, verliert alle Angaben, bis auf Koordinaten, Poskarte, Richtung (SEITE), Höhe, Regionen und Gewässer

--Herzi Pinki 15:22, 26. Jan. 2011 (CET)

Klingt wie Fortschritt :-) Das einzige wäre vielleicht der Parametername TYP, ist sehr kurz und etwas "unintuitiv" beim ausfüllen (was meinen die jetzt mit TYP?!?). Eventuell auf PASSTYP abändern? -- Ulflulfl 13:25, 30. Jan. 2011 (CET)

klingt es nur, dann sollten wir es bleiben lassen. :-( --Herzi Pinki 13:32, 30. Jan. 2011 (CET)

Damit war schon ein Fortschritt in die richtige Richtung und der Smiley aufmunternd gemeint -- Ulflulfl 13:51, 30. Jan. 2011 (CET)

Eingebundene Karte falsch beschriftet

zB bei Paso de la Cumbre: „Karte (Mendoza)“ ist falsch, man sieht Argentinien als Ganzes.

Selbiges bei Infobox Stausee. Wenn das wer fixen kann, bitte gleich bei beiden Boxen. lg, danke, … «« Man77 »» Originalsignatur ohne Klammerzusatz 14:13, 25. Jun. 2012 (CEST)

hallo, man kann das fixen indem eine Positionskarte von Mendoza bereitgestellt wird. Gibt es keine solche, erfolgt der Rückfall auf die nächst höhere administrative Einheit. In diesem Fall Argentinien. Eine einfache Möglichkeit wäre es, die Beschriftung wegzulassen (das das eine Karte ist, ist auch ohne Beschriftung erkennbar). lg --Herzi Pinki (Diskussion) 22:00, 26. Mär. 2013 (CET)

Keine Wintersperre

Für den Parameter "Sperre" ist als Erklärung angegeben: "Zeitraum der Sperre: z. B. Nov.–Juni". Spricht etwas dagegen, dort auch anzugeben, wenn es keine Wintersperre gibt, also so:

|SPERREART = Winter
|SPERRE = keine

Bei vielen (kleinen) Pässen ist es nicht offensichtlich, ob diese überhaupt eine Wintersperre haben. Die Angabe "keine" ist daher m.E. eine korrekte und wesentliche Information, die in die Infobox gehört. --Alpöhi (Diskussion) 20:22, 26. Mär. 2013 (CET)

Mit der Begründung «Keine Sperre ist keine Sperre und wird daher nicht unter Sperre eingetragen, unüblich» hat Herzi Pinki heute entsprechende Angaben bei den Pässen Col des Mosses, Bözbergpass und Brünigpass entfernt. Ein solcher Hinweis, wenn auch bis anhin eher unüblich, kann für einige durchaus informativ, nützlich und hilfreich sein. Der Zweck der Info-Box ist es ja, dass sich jemand schneller als im Fließtext orientieren kann. Ich würde in einem solchen Falle eine Information auch zulassen, die gemäß (bisheriger) offizieller Sichtweise weder vorgesehen noch überhaupt (bisher) eine Information ist. Dazu brauchte es nur den Hinweis, dass (allenfalls in begründeten Einzelfällen) auch aufgelistet werden kann, wenn ein Pass den ganzen Winter hindurch befahrbar gehalten wird. – Mit «Straßenzustandsbericht» hat dies, wie vom Fachmann befüchtet, noch nichts zu tun. --B.A.Enz (Diskussion) 21:50, 26. Mär. 2013 (CET)

Dass es «normalerweise» keine Wintersperre über einen Pass gibt, ist sicherlich nicht nur für mich relevant ;-) . Die Angabe in der Infobox muss aber ganz klar als Wintersperre erkennbar sein - also «keine Wintersperre». Wenn bei «Sperre» nur keine steht, könnte dies missverstanden werden (mindestens von mir). Es gibt ja noch weitere Gründe für eine Sperre; Höhe, Breite, Länge, Gewicht, Anhänger usw. Gut, ich weiss, das gilt eher als «Beschränkung» und weniger als «Sperre». Gruss --Schofför (Diskussion) 14:37, 27. Mär. 2013 (CET)

Sorry, da habe ich ich wohl etwas nicht so genau beschrieben: Wenn die zwei Parameter SPERREART und SPERRE wie oben angegeben sind, dann erscheint in der Infobox: "Wintersperre | keine". Ich hoffe, das löst deinen Einwand auf. --Alpöhi (Diskussion) 14:56, 27. Mär. 2013 (CET)

Ich schliesse mich an: "keine Wintersperre" ist für einen befahrbaren Pass eine durchaus relevante Information und sollte IMHO der Übersichtlichkeit zuliebe besser in der Infobox stehen als im Prosatext. Wenn in der Infobox keine Info über eine Wintersperre vorhanden ist, würde ich (und ich nehme an, die meisten Leser) das nicht so interpretieren, dass es keine Wintersperre gibt, sondern so, dass diese Information einfach fehlt. Daher bin ich für den Vorschlag von Alpöhi, und zwar genauso mit den zwei wie oben angegebenen Parametern, damit der berechtigte Einwand von Schofför bzgl. anderen Arten von Sperren berücksichtigt ist. Beim Julierpass ist das übrigens schon seit mindestens drei Jahren so umgesetzt. Der Col_de_l’Aiguillon ist ein Beispiel für eine IMHO weniger gute Lösung: "Sperre: -". Und beim Brünigpass stand vor Herzi Pinkis Änderung "Sperre: keine Wintersperre", realisiert über "|SPERRE = keine Wintersperre". Es wäre also für eine Vereinheitlichung schon angebracht, hier zu einer gemeinsamen Meinung zu kommen und dann in die Parametererklärung der Infobox reinzuschreiben, wie es denn nun gemacht werden soll. --Patagonier (Diskussion) 20:32, 27. Mär. 2013 (CET)

bis auf dass bei SPERRE ein Zeitraum reinzuschreiben ist, sind die Parameter korrekt beschrieben. Hier eine Liste der Pässe ohne explizite Wintersperre oder ohne explizite Nicht-Wintersperre, schlicht undefiniert (620 Stück - was machen wir damit?). Und hier die Liste der explizit eingetragenen keine Wintersperren (29) - Ich nehme daher gerne meine Aussage nicht üblich zurück, allerdings nicht für den Brünigpass und den Bözbergpass, so jedenfalls unüblich und der Boxbeschreibung widersprechend. Bei insgesamt 755 Verwendungen der Box und damit insgesamt 106 explizit eingetragenen Sperren. lg --Herzi Pinki (Diskussion) 23:39, 31. Mär. 2013 (CEST)

Und was willst du uns jetzt damit sagen? Dass bei SPERRE ein Zeitraum reinzuschreiben ist, ist ja nicht in Stein gemeisselt, da können wir ja im Erklärungstext angeben: „Zeitraum der Sperre: z. B. Nov.–Juni oder keine“. Mit den 620 Pässen ohne Angabe machen wir das, was wir in WP immer machen: Warten bis jemand anderes verbessert/ausfüllt/anlegt oder selber verbessern/ausfüllen/anlegen. --Alpöhi (Diskussion) 11:23, 1. Apr. 2013 (CEST)

So, wir haben jetzt das gemacht, was wir immer machen. Gewartet. Inzwischen ist die Anzahl der Pässe ohne Angabe auf fast 700 angestiegen. Schaut nicht so aus, als ob Warten zum Ziel führte. lg --Herzi Pinki (Diskussion) 18:26, 8. Jan. 2015 (CET)

Passhöhe

Warum wird beim Parameter „Passhöhe“ nach Höhe über dem Meeresspiegel und nicht nach Passhöhe weitergeleitet? Hinter der Höhenangabe wird ja auf die Höhe (Einheit, Mass) verwiesen, z.B. auf Meter über Meer. Gruss --Schofför (Diskussion) 10:26, 22. Jul. 2013 (CEST)

Anscheinend hat hier niemand etwas dazu zu sagen. Habe es darum jetzt geändert. --Schofför (Diskussion) 08:16, 27. Jul. 2013 (CEST)

TemplateData...

...zur Nutzung mit dem VisualEditor fehlt noch! liesel Schreibsklave^® 19:39, 8. Dez. 2013 (CET)

Höhendistanz mit Fußpunkt

anstatt die HD immer manuell zu berechnen (ich setze immer ein #expr:Passhöhe-Talhöhe) wärs doch viel einfacher, die Talhöhe alternativ eingeben zu können, und die vorlage rechnet das. insbesondere ist der talpunkt ja immer völlig willkürlich (auswahl al gusto des autors), also wäre zu annotieren, was man hergenommen hat, und warum – am besten per einzelnachweis oder unten eingeschobener anmerkung, oder beides: dann künnte man auch alternativen anbiten, bei bergsteigerpässen etwa nur talgrund zu talgrund, nicht talort zu talort, oder hydrographisch nach mündungshöhe etwa für gänzlich unwegsame pässe --W!B: (Diskussion) 08:17, 26. Dez. 2014 (CET)

hab ich mir auch schon gedacht, ich kümmer mich drum. lg --Herzi Pinki (Diskussion) 23:03, 8. Jan. 2015 (CET)

HORT1 und HORT2 machen das in Zukunft, die Referenz ist durch ORT1 und ORT2 immer gegeben. Ich verstehe nicht ganz, was davon abweichende Bezugspunkte sollen, sie verwirren doch nur. Die Wahl von ORT1 und ORT2 ist die Auswahl al gusto, die Höhe ergibt sich damit von selbst. Gut, ev. ist der Bezugsort eine längere Beschreibung, und schwer in die Infobox zu pflegen, aber dann ist doch auch die Höhe fraglich. Es muss ja keine angegeben werden. lg --Herzi Pinki (Diskussion) 00:58, 9. Jan. 2015 (CET)

jedenfalls danke fürs einpflegen: gut so --W!B: (Diskussion) 06:38, 19. Apr. 2015 (CEST)

Wegdistanz Luftlinie

bei nur zu fuß gangbaren pässen hat man fast nie die genau weglänge, oft ist sie auch wertlos, wenn es mehrere anstiegsalternativen gibt. daher wäre eine angabe der distanz luftlinie da viel sinnvoller und aussagekräftiger. dazu bräuchte es zusätzliche parameter, einfacher aber einen schalter LÄNGE-LL= ja, der das dann auch in der IB annotiert --W!B: (Diskussion) 08:17, 26. Dez. 2014 (CET)

die LÄNGEn-Angaben kommen aus den Straßenpässen, und dort sind sie messbar (z.B. mit google maps). Bei Fußwegen ist die Angabe der Länge, wie du richtig bemerkt hast, wertlos. Insoferne sollte sie unterbleiben. Die Luftentfernung ist ja genauso wertlos, ein frei definiertes Maß bloß um ein Maß zu haben? Ich ließe mir ja Gehzeiten einreden, aber WP ist kein Wanderführer und Gehzeiten sind keine objektiven Maßzahlen. lg --Herzi Pinki (Diskussion) 01:02, 9. Jan. 2015 (CET)

@Herzi Pinki: (spätes re) stimmt, tun wir nicht eindeutig definierte talpunkte (am besten: unbelegte) künftig wieder weg. sollte man vielleicht in der beschreibung noch genauer definieren, wann die beiden sätze "talort" überhaupt zur anwendung kommen sollen.

vielleicht eine vereinfachte kopiervorlage: das anführen aller parameter in IBs, selbst die, die man definitiv nicht verwendet, führt nur zu unnötiger vervollständigungsmanie: ich mach bei meinen IBS in der kopiervorlage immer einen basis-satz (immer auszufüllen: gefordert und erwünscht), und einen vollständigen satz (alle optionen). das verhindert das. --W!B: (Diskussion) 06:46, 19. Apr. 2015 (CEST)

Bedeutung von Passhöhe

Ich nehme an, es ist der höchste Punkt der Passstraße gemeint. Man könnte aber allenfalls auch denken, es sei die Höhe des Sattelpunkts gemeint, was ja voneinander durchaus abweichen kann, indem die Passtraße etwa eingegraben ist (–) oder diesen Punkt seitlich passiert (+). Ich möchte vorschlagen, wenigstens in der Parameterbeschreibung das Gemeinte unzweideutig zu bezeichnen. --Silvicola ^Disk 12:20, 30. Apr. 2015 (CEST)

Unter Pass & Gebirgspass ist klar gesagt, dass es sich um den Sattelpunkt (Wasserscheide) handelt. Es wird auch stets zunächst der Pass (also ein Punkt) beschrieben. Zu diesem kann es verschiedene Verkehrswege geben, die unter dem Artikel mitbehandelt werden. Daher wird der Scheitelpunkt der Passstraße oft davon abweichen. Es gibt aber in der Umgebung eines Passes beliebig viele höhere Punkte, so dass nur der niedrigste diesen richtig beschreibt.

Da das oft zu Verwechselungen führt, schlage ich vor, zusätzlich den Parameter "STRASSENSCHEITEL" einzuführen.

Meistens haben Pass und Straßenscheitel dieselben Namen, daher unterscheidet z. B. SwissTopo nach Pass & Strassenpass.

--Friedo (Diskussion) 17:40, 13. Mai 2017 (CEST)

Anmerkung

Wie kann man zu einem Zahlenwert eine Anmerkung (z. B. Quellenangabe) machen? Bei der Vorlage "Berg" gibt es z. B. "HÖHE-ANMERKUNG=". Ich habe an einer Stelle "PASSHÖHE-ANMERKUNG=..." eingefügt, was derzeit unwirksam ist und schlage vor, diese Funktion einzuführen. --Friedo (Diskussion) 21:42, 25. Aug. 2015 (CEST)

Wäre nett, wenn sich jemand darum kümmerte ... --Friedo (Diskussion) 17:44, 13. Mai 2017 (CEST)

Habe das jetzt selbst eingebaut, scheint zu funktionieren (Anwendung als Quellenverweis: Malojapass & Felber Tauern); ist aber in der Doku noch nicht enthalten. --Friedo (Diskussion) 17:40, 1. Jun. 2018 (CEST)

Infobox-Breite

Die Breite der Vorlage:Infobox Pass ist wohl falsch eingestellt, weil Boxen in zahlreichen Artikeln, die eine solche Box enthalten, oft viel zu breit angezeigt werden.
--TOMM (Diskussion) 10:21, 3. Jul. 2017 (CEST)

Aus demselben Grund bin ich auch gerade hier gelandet: beim Glaspass erschlägt die Infobox mit ihrer Breite den ganzen Rest des Artikels (ältere Firefox-Version, Notebook). Könnte jemand, der sich mit der Erstellung von Infoboxen auskennt, einmal nachsehen, weshalb das passiert? --Nuhaa (Diskussion) 19:05, 5. Jul. 2017 (CEST)

Da hat jemand die feste Breite raus genommen. Ich habe das mal wieder rein gesetzt. --SteveK ?! 22:29, 5. Jul. 2017 (CEST)

Danke! --TOMM (Diskussion) 09:29, 7. Jul. 2017 (CEST)

Symbol

In der POSKARTE erscheint an der Position des Objekts (hier Pass) ein roter Punkt; dabei gibt es doch passendere Symbole (vgl. hier) für einen Pass, ggf. sogar noch in grober Richtung (vier Versionen), die dann aber noch als Parameter einzuführen wäre oder sich aus Seite1 & Seite2 herleiten ließe. --Friedo (Diskussion) 17:59, 7. Okt. 2017 (CEST)

HTML-Fehler

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

Wikipedia:WikiProjekt Vorlagen/Werkstatt#Linterfehler durch Pseudofehlerwartungsanalyse?

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

Bild

Um ggf. ein weiteres Bild weiter unten einfügen zu können, habe ich mal den Parameter Bild1 (entsprechend der Infobox Berg) eingefügt; ist in der Dokumentation aber noch nicht enthalten. --Friedo (Diskussion) 11:17, 27. Dez. 2019 (CET)

Ich habe nun versucht, auf diesem Weg eine zweite Positionskarte - versuchsweise bei Splügenpass - einzufügen. Das ist leider noch nicht optimal gelungen (Abstand zwischen den Karten und die senkrechte Spalten-Trennungslinie). Vielleicht weiß jemand, wie man das besser programmiert (meine Versuche mit "colspan" waren da wenig erfolgreich). --Friedo (Diskussion) 15:46, 28. Dez. 2019 (CET)

Bug bei Bildbeschreibung

Siehe: Schanz (Pass)

Die etwas länger geratene Bildbeschreibung bricht an der nach oben in ihr Feld hochgezogenen Spaltengrenze zwischen den Sätzen der Daten für die erste und die zweite Passseite um. Ich vermute doch, dort sollte gar keine Spaltengrenze sein, sondern die Bildbeschreibung sollte über alle drei Spalten – Titelspalte, Spalte für Seite 1, Spalte für Seite 2 – hinwegreichen? Vielleicht nur ein falscher colspan-Wert 2 statt richtig 3. --Silvicola ^Disk 23:57, 2. Jan. 2020 (CET)

Das vermute ich auch. Ich habe es von 2 auf 3 geändert und hoffe, dass das sonst keine anderen negativen Auswirkungen hat. --GT1976 (Diskussion) 08:24, 8. Jan. 2020 (CET)

Danke, damit aus meiner Sicht erledigtErledigt --Silvicola ^Disk 13:12, 8. Jan. 2020 (CET)

Bug in der Infobox

Könnte bitte jemand in der Infobox das so umbauen, das keine Artefakte bei der API-Abfrage des Klartextes mehr zu sehen sind. Das führt bei Benutzung der API z.B. bei TheBook zu unschönen Artefakten. Siehe auch Diskussion Wikipedia:Fragen_zur_Wikipedia#Bugs_in_Vorlagen_von_Infoboxen - Beispiel:

• Kunzum-Pass, API-Abfrage, TheBook: Kunzum-Pass
• Brennerpass, API-Abfrage, TheBook: Brennerpass
• und andere.

Vielen Dank! -- sk (Diskussion) 19:39, 15. Jul. 2020 (CEST)

Sollte hiermit behoben sein. --Prüm ✉ 11:57, 2. Aug. 2020 (CEST)

SPERREART

Wenn bei Sperrart "LKW" eingetragen wird, entsteht "LKW-sperre" (z.B. hier: Pyhrnpass), was grammatikalisch falsch ist, da es "LKW-Sperre" sein sollte. Mit "Winter" passt es: "Wintersperre". Evtl. immer "-Sperre" ergänzen, so dass "LKW-Sperre" und "Winter-Sperre" entstehen? --Atc (Diskussion) 13:33, 26. Aug. 2020 (CEST)

Parameter KARTE

Ich habe ein Problem gefunden mit der Darstellung des Parameters KARTE, siehe Bsp. hier:

https://de.wikipedia.org/w/index.php?title=Irshad-Pass&oldid=176563022

--Elutz (Diskussion) 23:21, 29. Dez. 2020 (CET)

Gefixt, Testseite Vorlage:Infobox Pass/Test ergänzt --Elutz (Diskussion) 22:00, 1. Jan. 2021 (CET)

Dieser Abschnitt kann archiviert werden. --Elutz (Diskussion)

Hauptstrasse (Nummer)

Hier fehlt noch ein Feld für die Strassennummer, sofern eine Hauptstrasse über den Pass führt. --ProloSozz (Diskussion) 18:18, 25. Jan. 2021 (CET)

Fehlermeldungen führen auf gelöschte Unterseiten

Hallo, Lemmata in der Kategorie:Pass in Provence-Alpes-Côte d’Azur wie bspw. Col du Lautaret zeigen drei Fehlermeldungen von remindErrorMessages:

• x führt auf die (gelöschte) Unterseite Vorlage:Infobox Pass/Wartung/POSKARTE
• k führt auf die (gelöschte) Unterseite Vorlage:Infobox Pass/Wartung/keine Sperre eingetragen
• x führt auf die (gelöschte) Unterseite Vorlage:Infobox Pass/Wartung/Profil fehlt

Liegt es an der Vorlage oder an den Lemmatexten? Gruß, --Wi-luc-ky (Diskussion) 17:45, 27. Jun. 2022 (CEST)

Fehler durch leere Parameter

Servus,
Ich möchte auf dieses Problem hinweisen. Könnt Ihr es bitte entweder wegprogrammieren oder wegdokumentieren?
Danke & Gruß, Ciciban (Diskussion) 12:50, 20. Nov. 2022 (CET)

Ich hab mal alle diese Wartungs-Links auskommentiert, für so etwas macht man m.E. besser eine Vorlagenauswertung per Programm (z.B. so etwas wie TemplateTiger). Eigentlich müsste man mal die gesamte Vorlage bereinigen, aber dazu fehlt mir leider die Zeit. --Reinhard Kraasch (Diskussion) 20:23, 13. Apr. 2023 (CEST)