Vorlage Diskussion:Infobox Ortsteil einer Gemeinde in Deutschland/Archiv/2012

aus Wikipedia, der freien Enzyklopädie
< Vorlage Diskussion:Infobox Ortsteil einer Gemeinde in Deutschland
Dies ist die aktuelle Version dieser Seite, zuletzt bearbeitet am 17. April 2020 um 20:22 Uhr durch imported>Xqbot(627628) (Bot: Ersetze veraltetes <source> tag und veralteten "enclose"-Parameter).
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)

Zusätzliche Parameter für Fläche und Einwohner

Bei ehemals selbstständigen Gemeinden mit Ortsteilen, die eingemeindet worden sind, kann man die Angaben in der Infobox bisher unterschiedlich interpretieren, sie könnten sich auf die ehemalige Gemeinde mit ihren Ortsteilen oder auf den jetzigen Ortsteil der neuen Gemeinde ohne frühere Ortsteile beziehen. Im zweiten Fall wären EWZ und Fläche größer als im ersten. Diese möglichen Ungenauigkeiten ließen sich durch zwei zusätzliche Parameter umgehen, die hinter die Flächen- und EWZ-Angaben mit Ortsteilen o.Ä. einfügen. Haltet ihr das für sinnvoll? --Inkowik 14:14, 2. Jan. 2012 (CET)

Die meisten Gemeinden haben vor ihrer Eingemeindung in eine größere Gemeinde mehrfach die eigene Fläche gewechselt, daher halte ich diese Variante für wenig sinnvoll. Es ist eigentlich eindeutig, dass sich die Infoboxen auf die heutigen Ortsteile beziehen und nicht auf die ehemaligen Gemeinden. Deren Kenndaten lassen sich ja bei Bedarf irgendwo im Text unterbringen. -- j.budissin+/- 16:33, 2. Jan. 2012 (CET)
Ich vermute, dass es bisher unterschiedlich gehandhabt wurde, was in einem Ortsteilartikel steht und daher auch, was die IB angibt. Bei neu angelegten Ortsteilartikeln ist davon auszugehen, dass ausschließlich über den Teilort geschrieben wird. Da ein Gemeindeartikel aber das gesamte Gemeindegebiet beschreibt, wird in der Regel bei einer Abänderung des Artikels bei Eingemeindung auch weiterhin alles zu diesem Gebiet beschrieben stehen, auch wenn dies nun mehrere Ortsteile sind. Das ist eine Unschärfe, mit der wir leben müssen (genauso wie der Begriff „Ortsteil“ in einigen Artikeln als verwaltungstechnische Bezeichnung gemeint ist und manchmal einfach nur eine Ansiedlung, unabhängig von ihrem Verwaltungsstatus, beschreibt). Hier ist dann wohl eher Fließtext geeignet, um die Grundlagen der Fakten klar darzustellen. Wenn ein Artikel nicht mehr eine Gemeinde, sondern nur noch einen Teil davon beschreiben soll, ergeben die Punkte „Fläche“, „Einwohner“ und „Eingemeindet“ in der IB keinen Sinn, denn die Gemeinde ist üblicherweise die kleinste Einheit, für die Daten der Statistischen Landesämter vorliegen bzw. der Begriff „eingemeindet“ bezieht sich ausschließlich auf ganze Gemeinden. NNW 21:41, 2. Jan. 2012 (CET)
Einspruch, Einwohnerdaten für Ortsteile bekommt man in vielen Fällen vom Einwohnermeldeamt, Flächenangaben stehen auch oft zur Verfügung und der "Eingemeindet"-Parameter ist schon von daher sinnvoll, als dass es hier um die erste Eingemeindung des betreffenden Ortes geht und die allerersten Gemeinden meist nur aus einem Ort bestanden. -- j.budissin+/- 23:55, 2. Jan. 2012 (CET)

Höhenangaben

Gelten diese für den Siedlungsbereich des Ortes oder für dessen Gemarkung? -- Silvicola Diskussion Silvicola 18:28, 6. Feb. 2012 (CET)

Falls du die Von-Bis-Zahlen meinst, würde ich sagen, dass diese für die Gemarkung gelten. Wir beschreiben in den Ortsteil-Artikeln ja nicht nur die Siedlungsbereiche sondern immer die ganzen Gemarkungen. So hatte ich es jedenfalls immer verstanden. Siehe zum Thema auch die Diskussion unten. --TMg (Diskussion) 05:56, 18. Mär. 2012 (CET)

Fläche

Ist die Anzahl der Dezimalstellen für den Parameter Fläche begrenzt? Die amtliche Statistik in Deutschland gibt Zahlen bis auf Ar genau an, das wären bei der Einheit km² vier Nachkommastellen. Das wurde mir beispielsweise im Artikel Blankenborn auf zwei Nachkommastellen gekürzt. Wie viel Präzision ist relevant? Soll man vorhandene Informationen künstlich auf geringere Präzision kürzen?--Ratzer (Diskussion) 16:34, 19. Mär. 2012 (CET)

Meiner Ansicht nach ist es gut und zweckmäßig, solche übergenauen Zahlen für die Anzeige im Artikel ein wenig zu runden. Aber das muss die Vorlagenprogrammierung übernehmen, beim Ausfüllen der Vorlage sollte man die Zahlen immer so genau wie möglich angeben. Unabhängig davon kann ich dein Problem aber nicht nachvollziehen, ich sehe im genannten Beispiel alle Kommastellen. Mit „wurde mir gekürzt“ meinst du offenbar nicht die Vorlage sondern dass ein anderer Benutzer eingegriffen hat. Das halte ich wie gesagt für „suboptimal“. Das sollten wir hier technisch lösen und nicht durch manuelles Runden in den Artikeln. Weitere Meinungen dazu? --TMg 18:44, 19. Mär. 2012 (CET)
Ich habe jetzt eine Rundung auf maximal 2 Nachkommastellen eingebaut. Das ist äquivalent zur Gemeinde-Infobox und anderen Vorlagen. Flächen kleiner als 1 km² werden in „ha“ und ebenfalls mit 2 Nachkommastellen angezeigt, so dass nie zu grob gerundet wird. --TMg 20:46, 19. Mär. 2012 (CET)
Danke, das ist eine gute Lösung. Die Übersichtlichkeit der Anzeige ist gewahrt, die vorhandene Präzision bleibt dennoch intern erhalten.--Ratzer (Diskussion) 21:26, 19. Mär. 2012 (CET)
Habe ich oben richtig gelesen: die amtliche Statistik, die in Deutschland Zahlen (von Ortsteil-Flächen) bis auf Ar genau angibt?? Rauenstein 20:57, 19. Mär. 2012 (CET)
Die amtliche Statistik in Deutschland wird arbeitsteilig vom Statistischen Bundesamt und den statistischen Landedsämtern durchgeführt. Letztere sind für die Erhebung und Auswertung der Einzeldaten zuständig. Hier geht es um die "Flächenerhebung nach Art der tatsächlichen Nutzung", einer Bundesstatistik. Im Normalfall ist die Gemeinde die kleinste Regionaleinheit. Die Flächen in Ar für die Gemeinden in Bayern können u.a. hier abgerufen werden. Die anderen statistischen Landesämter haben ähnliche Angebote. (Man kann von der Regionaldatenbank Deutschland die Flächen auch deutschlandweit auf Gemeindeebene abrufen, dort aber nur auf Hektar genau.) Gegen Bezahlung (Sonderauswertung) werden die Landesämter die Flächen auch auf Gemarkungsebene nachweisen. Im Fall Blankenborn, welches bis 1945 zu Bayern gehörte und seither zu Rheinland-Pfalz, verwendete ich die Flächenangabe der ehemaligen Gemeinde, die sich im Amtlichen Ortsverzeichnis von Bayern 1925 fand und die im Artikel referenziert ist. Stattdessen könnte man auch im Statistischen Landesamt Rheinland-Pfalz nachfragen, ob dort eine Flächenangabe der Gemarkung Blankenborn verfügbar ist. Dass die ehemalige Gemeinde als Gemarkung fortbesteht, zeigt das Gemarkungsverzeichnis Rheinland-Pfalz. Für Ortsteile an sich gibt es m.W. keine Flächenangaben, da diese nicht flächenmäßig abgegrenzt sind. Nur für ehemalige Gemeinden und für Gemarkungen.--Ratzer (Diskussion) 21:26, 19. Mär. 2012 (CET)
Der Weg über die Anfragen war mir schon bekannt, es ist aber von Bundesland zu Bundesland unterschiedlich. Während es in einigen noch die alten Gemarkungen gibt, werden in anderen Bundesländern quer über ehemalige Gemeindegrenzen Gewerbegebiete oder Reihenhaussiedlungen gebaut. Gemeindewälder oder Allmenden haben längst ihre Bestimmung verloren und Landwirte bzw. Kooperativen agieren eh viel großflächiger. Will sagen: wer braucht eine genaue Ortsteilfläche? Ob eine vor 1925 vermessene Gemarkungsfläche heute noch auf die vierte Stelle nach dem Komma stimmt, weiß auch keiner und es misst wohl auch niemand mehr nach. Ich weiß nur, dass hier jedes Jahr (nach Erscheinen der neuen Zahlen der Stat. Landesämter) viele Flächen immer wieder neu angepasst werden (ich meine nicht die Änderungen nach Eingemeindungen). gruss Rauenstein 21:55, 19. Mär. 2012 (CET)
Das stimmt natürlich, es gibt jedes Jahr wieder Flächenkorrekturen, oder auch hier und da leichte Grenzverschiebungen zwischen Gemeinden, die nirgends online dokumentiert werden. Daher kann man in den Datenbanken der amtlichen Statistik die Flächen auch zu unterschiedlichen Ständen abrufen, aktuell zum Stand 31.12.2010. Die Wahrscheinlichkeit, dass die Gemeindefläche von 1925 mit der Gemarkungsfläche vom 31.12.2010 auf Ar genau übereinstimmt, ist gering. Dennoch ist der Nachweis im Ortsverzeichnis von 1925 eine historische Tatsache, die man besser 1:1 übernehmen sollte, als daran herumzudoktorn und eine willkürliche Anzahl von km²-Dezimalstellen wegzustreichen, weil's sowieso nicht so genau ist (besser wäre natürlich die aktuelle Gemarkungsfläche). Vielleicht wäre noch ein Zeitbezug zur Flächenangabe in der Infobox eine Überlegung wert.Gruß,--Ratzer (Diskussion) 22:56, 19. Mär. 2012 (CET)
Jetzt hab ich's mal beim Landesvermessungsamt Rheinland-Pfalz probiert, und die haben mir die Gemarkungsfläche auf Quadratmeter genau mitgeteilt: 1.719.166 m², allerdings ohne Zeitbezug, soweit ich sehen kann. Auf jeden Fall ziemlich nah dran an der Gemeindefläche von 1925, die mit 1,7206 km² bzw. 1.720.600 m² angegeben ist. Eine Abweichung von unter einem Prozent...--Ratzer (Diskussion) 11:29, 20. Mär. 2012 (CET)

Was mich nicht nur bei der Fläche, sondern auch bei anderen Parametern dieser Infobox stört, ist dass nicht klar ist worauf sich die Werte genau beziehen. Hier ist von Gemarkungen die Rede, das ist aber grundsätzlich was anderes als ein Ortsteil, oder die ehemalige Gemeinde (deren Fläche häufig angegeben wird). --Septembermorgen (Diskussion) 14:21, 15. Apr. 2012 (CEST)

Auf die Gefahr hin, dass ich mich wiederhole, aber dieses Problem besteht nicht nur bei der Infobox, sondern bei den gesamten Artikeln. Dorf, Ortsteil, Stadtbezirk und was es sonst noch gibt, werden dort munter durcheinander geworfen und wenn es konkrete Werte braucht, wird das genommen was gerade da ist. Und in vielen Fällen stimmen ja auch ehemalige Gemeinde, heutige Gemarkung und heutiger Stadtteil überein. Mein Eindruck ist mittlerweile, dass eine klare Abgrenzung des Ortsteils eher die Ausnahme ist und es in der Regel einerseits amtlich wild durcheinander geht und andererseits ständig Bezug auf „gefühlte“ Einheiten genommen wird. Ich habe noch eine Geschichte in Erinnerung (ich glaube es war Dortmund-Großholthausen) bei der in unmittelbarer Nähe zum eigentlichen Dorf eine Siedlung entstand. Diese lag allerdings schon auf dem Gebiet eines anderen Dorfes. Da die Siedlung aber irgendwann größer wurde, ging der Name des Dorfes auf diese über. Heute liegen Dorf und Siedlung in unterschiedlichen Stadtbezirken. Da mich meine Erinnerung spätestens hier verlässt, können wir es auch gleich als fiktives Beispiel weiterführen. Die Gemarkungsgrenzen, Postzustellbezirke und was man sonst noch verzweifelt als Kriterium heranziehen möchte, laufen dann noch mal völlig kreuz und quer. Eine offizielle Einteilung unterhalb des Stadtbezirks gibt es nicht. Und spätestens jetzt wüsste ich auch nicht mehr womit genau sich er Artikel beschäftigen sollte. Andererseits gibt es aber ein großes Zugehörigkeitsgefühl innerhalb von altem Dorf und neuer Siedlung (und natürlich wird sich wechselseitig die Zugehörigkeit abgesprochen). Da ist dann die Infobox noch das geringste Problem, aber diese Probleme spiegeln sich natürlich darin wider. --Alex (Diskussion) 17:20, 15. Apr. 2012 (CEST)
Nur mal so als Gedanke: Als es noch keine Ortsteilinfobox gab, gab es ein paar Stimmen (nicht nur von mir), die aus genau diesen Gründen gegen eine Infobox argumentiert haben. Die Box täuscht eine Amtlichkeit und Genauigkeit vor, die es in der Praxis gar nicht gibt. Unter anderem deswegen gibt es bis heute den Kompromiss, es den jeweiligen Hauptautoren zu überlassen, ob sie eine Box wollen oder nicht. --TMg 00:43, 16. Apr. 2012 (CEST)

Einzelnachweise angeben

Wie ist die Vorgabe "In die Box dürfen Zahlen nur unter Angabe einer verlässlichen Quelle eingetragen werden." umzusetzen? Fügt man z.B. hinter der Flächenangabe ein ref-Tag ein, so wird die Fläche nicht mehr korrekt ausgegeben (Punkt statt Komma, km² fehlt). Siehe z.B. Alten (Dessau-Roßlau)#Einzelnachweise. -- Andre de 15:35, 9. Feb. 2012 (CET)

Quellen kannst du in den Text einbauen, wenn das sinnvoll erscheint, und zusätzlich in der Zusammenfassungszeile angeben. --TMg (Diskussion) 05:53, 18. Mär. 2012 (CET)
Das ist klar, aber auch sehr global. Schöner wäre, wenn die Vorlage etwas 'unempfindlicher' reagieren würde, z.B. ein ref-Tag bei der Formatierung der Zahl in besagtem Feld ignoriert. Darauf zielte meine Frage. Viele Grüße. --Andre de (Diskussion) 19:20, 18. Mär. 2012 (CET)
Dass man in Zahlenfelder auch nur Zahlen eingeben kann, ist Absicht und notwendig. Sonst fängt irgend jemand an, dort Dinge wie „bis 2011: 12 ha, seit 2012: 14 ha“ einzutragen. --TMg 22:19, 18. Mär. 2012 (CET)
Von beliebigem Text war nicht die Rede (welcher im Übrigen aber auch jetzt bereits eingegeben werden kann). Ich hatte angeregt, dass die Vorlage speziell mit ref-Tags hinter einer Zahl umgehen können sollte. Alternativ kann man auch die besagte Vorgabe rausnehmen. Im Moment ist die Vorgabe nicht ordentlich umsetzbar, nur darauf wollte ich hinweisen. Leider gelingt es Dir nicht, konkret auf Fragen und Vorschläge einzugehen. Andre de (Diskussion) 01:11, 16. Apr. 2012 (CEST)
Dein letzter Satz sorgt auch hervorragend dafür, dass sich dies in Zukunft nicht ändern wird. --32X → Autorengilde № 1 09:44, 16. Apr. 2012 (CEST)
Damit kann ich leben. Allerdings stand das wohl auch schon vor meinem letzten Beitrag fest. Weiterhin halte ich die Antworten zu diesem Thema von Herrn TMg für nicht sehr konstruktiv, dies ist meine persönliche Wahrnehmung und diese wollte ich abschließend zum Ausdruck bringen. Viele Grüße! Andre de (Diskussion) 13:11, 16. Apr. 2012 (CEST)

Schaut mal bei Vorlage:Infobox Fluss:

1. Zu jedem nachzuweisenden Parameter DINGSBUMS einen weiteren namens NACHWEIS-DINGSBUMS, in dem man eideutig und ohne viele Worte (also anders, als wenn man aus dem Artikeltext heraus belegt) explizit einen eindeutigen Bezug auf einen Parameter hat
2. Zu jedem nachzuweisenden Parameter DINGSBUMS zwei weitere namens DINGSBUMS-PREFIX und DINGSBUMS-SUFFIX, mit denen man den DINGSBUMS-Eintrag rein numerisch belassen kann und trotzdem im dargestellten Text in relativierendem, modifizierendem oder erläuterndem Text einpacken kann.

Ich habe schon bei ein paar Ortschaftsartikeln en passant Höhen eingetragen, dann aber die Möglichkeit arg vermisst, auch die Belege für sie passend eintragen zu können. Man will da schon sagen, wo diese herkommen: Schätzung nach dem Höhenlinienbild auf Karten, Texteintrag zum Ortsnamen auf Karten, Höhenmarke in flacher Ralsohle dicht an Siedlungsgrenze usw., um nur von Kartenquellen zu reden. Bei den vorgefundenen weiß man dann entsprechend nicht, woher sie kommen: amtliche Höhenangabe in Gemeindeverzeichnissen, Kartenquellen – oder nur aus dem Bauch eines großzügigen Bearbeiters heraus. Die Einträge sind unbelegt nicht glaubwürdig, gleichzeitig zaudert man, sie zu ändern, wenn man selbst eine Quelle hat, weil die vorgefundenen ja höherem Wissen entstammen könnten, von dem man aber nur leider nicht belegt sieht, woher es kommt und wie hoch es tatsächlich zu schätzen ist.

Ist natürlich entsprechend anzupassen, also keine durchgehende Großschreibung, Parameternamens-Modifikatoren für die dekorierenden Zusätze nicht mal vorn, mal hinten anbringen usw. Im höchsten Grade danach trachten, das System der Parameter durchschaubar und die Namen prognostizierbar zu halten.

Von-Bis-Höhenangabe

Moin moin, ich habe ja schon ein paar Mal über die Von-Bis-Angabe bei der Höhe moniert; da es mir gerade aber wieder negativ aufgefallen ist, nerve ich noch mal. Bei der Frage, ob man die Höhe des Ortes an einem Referenzpunkt festmacht oder die gesamte Spanne der Höhenlagen angibt, kann man getrennter Meinung sein. Diese Infobox hat sich für die Angabe des tiefsten (Höhe) und des höchsten Punktes (Höhe-bis) innerhalb eines Ortsteils entschieden. So weit, so schlecht. Allerdings kann der Parameter Höhe auch die Bedeutung „mittlerer [Höhen]wert“ haben. Vermutlich aus diesem Grund, wird der Wert an die Vorlage {{Coordinate}} weitergereicht, selbst wenn der niedrigste Punkt angegeben ist. Ich hoffe das war jetzt trotz der Knappheit einigermaßen verständlich formuliert. Lässt man mal die Abschaffung der Von-Bis-Angabe außen vor, gibt es meiner Meinung nach drei Lösungsmöglichkeiten für diesen Problem:

  1. Man führt einen zusätzlichen Parameter Höhe-Ortslage (oder ähnlich) ein und dieser wird an die Vorlage Coordinate weitergereicht. Als Quelle würde sich in vielen Fällen http://www.geodatenzentrum.de/ anbieten, das neuerdings einen Wert gerechnete Höhe über NN für die Objektart Ortslage ausgibt.
  2. Man gibt gar keinen Wert mehr an die Vorlage Coordinate weiter.
  3. Irgendwelche Fallabfragen in der Vorlage, die nur den Wert von Höhe weitergeben, wenn Höhe-bis leer ist. Andernfalls muss man sich wieder etwas überlegen (kein Wert weitergeben, Mittelwert aus Höhe und Höhe-bis, …

Meinungen? --Alex (Diskussion) 22:51, 11. Mär. 2012 (CET)

Tut mir leid, wenn die Frage provokant klingt, aber wen juckt es, was die Coordinate-Vorlage für eine Höhe bekommt? Wird die irgendwo weiter verarbeitet und wenn ja, wo und mit welchen Auswirkungen? Ansonsten kann ich nur wiederholen, was ich immer zu den Höhenangaben sage. --TMg (Diskussion) 13:09, 14. Mär. 2012 (CET)
Das ist ein Argument die Vorlage hier nicht einzubauen oder am besten ganz abzuschaffen, aber keines um den Parameter systematisch falsch weiterzugeben. Noch jemand was zur Sache? --Alex (Diskussion) 17:40, 14. Mär. 2012 (CET)
Inwiefern soll diese angepisste Reaktion die Diskussion voran bringen? Ich möchte gern wissen, ob die Weitergabe des Höhen-Parameters an die Coordinate-Vorlage irgend eine Auswirkung hat. Wenn nein, dann ist deine vorgeschlagene Lösung Nummer 3 (nur weiter geben, wenn Höhe-bis nicht angegeben ist) die einfachste und das Problem ist aus der Welt. Andernfalls plädiere ich dafür, das Parameter-Tripel Höhe, Höhe-von und Höhe-bis einzuführen. Höhe steht dann für die mittlere Höhe (oder die Höhe der Ortslage oder wie auch immer man das nennen möchte) und wäre Pflicht, die anderen beiden wären optional. Bei der Umstellung könnte ein Bot helfen. Er müsste die Zahlen aus Höhe nach Höhe-von verschieben, falls eine Höhe-bis angegeben ist. Das betrifft laut Vorlagenauswertung aktuell rund 3500 Artikel. --TMg (Diskussion) 05:49, 18. Mär. 2012 (CET)
Ich verstehe den Bezug von Höhen- und Koordinatenangaben auch nicht. Überhaupt ist die Verfügbarkeit von genauen Daten für tausende Ortsteile, deren Flächen auch noch völlig unklar sind, sehr gering. Das Thema würde ich bei klar umreißbaren Gemeinden vermuten, bei sehr vielen Ortsteilartikeln sind die Angaben eher Spielereien. Rauenstein 15:20, 18. Mär. 2012 (CET)
Insofern als hier nicht zum x-ten Mal über Sinn und Zweck von Vorlagen und Meta-Daten im Allgemeinen und dem Nutzen der Vorlage {{Coordinate}} im Speziellen, die Angabe von Höhen und Koordinaten für Ortsteile etc. pp. diskutiert wird. Da das einigermaßen geklappt habt, gebe ich mal Preis, dass der Vorschlag mit den drei Höhenangaben nicht ganz unbewusst an erster Stelle stand. Umsetzen? --Alex (Diskussion) 22:54, 19. Mär. 2012 (CET)
Das ist immer noch keine Antwort auf meine Frage. --TMg 23:26, 19. Mär. 2012 (CET)
Ich habe jetzt selbst gesucht. Die Höhe wird nicht an den Geohack weiter gereicht und damit auch von keinem der dort aufgeführten Dienste weiter verarbeitet. Aber sie steht als unsichtbares Microformat im Artikel und kann dort potentiell von allen möglichen Diensten gefunden und weiter verarbeitet werden. Also doch auftrennen. Aber bitte nicht „Höhe-Ortslage“. In der Dokumentation der Coordinate-Vorlage steht, dass es sich um die Höhe bei den Koordinaten handeln soll und das wäre nicht unbedingt das Selbe wie „Höhe-Ortslage“. Deshalb allgemein „Höhe“, dann kann man allein aus dem Parameternamen keine falschen Schlüsse ziehen. --TMg 08:46, 20. Mär. 2012 (CET)
Okay, wenn das Konsens werden sollte, bleibt noch die Frage wie wir die drei Parameter in der Infobox darstellen: alle drei anzeigen oder Höhe (an der Stelle der Kooridnaten) ausblenden sobald Höhe-bis vorhanden ist? --Alex (Diskussion) 23:26, 20. Mär. 2012 (CET)
Ich dachte an Letzteres. --TMg 23:49, 21. Mär. 2012 (CET)
Ich hätte nichts dagegen und würde mich über eine Umsetzung freuen. --Alex (Diskussion) 13:16, 22. Mär. 2012 (CET)

Ich habe die Vorlage vorbereitet. Aktuell wird sowohl das alte Verhalten („Höhe“ mit optionaler „Höhe-bis“) als auch das diskutierte neue Verhalten unterstützt. Der nächste Schritt ist wie oben erwähnt, per Bot in allen Artikeln mit „Höhe-bis“ die „Höhe“ nach „Höhe-von“ zu schieben. Mit der entsprechenden Anfrage würde ich aber noch warten, siehe unten. Danach kann die Vorlage so umgebaut werden, dass sie uns eine Fehlerliste für alle verbleibenden und zukünftigen Artikel erzeugt, bei denen eine „Höhe-bis“ ohne „Höhe-von“ angegeben wird. Der letzte Schritt ist der aufwendigste: Bei allen Artikel, in denen aktuell ein Höhenbereich steht, muss der dann fehlende Parameter „Höhe“ nachgepflegt werden. Können wir das irgendwie automatisieren und es dem Bot, der sowieso ran muss, gleich als Aufgabe mitgeben? Lässt sich das Geodatenzentrum irgendwie maschinell abfragen? --TMg 19:18, 22. Mär. 2012 (CET)

D’accord. Beim Geodatenzentrum kann man eine XML-Anfrage stellen und bekommt dann eine XML-Antwort, die auch die gerechnete Höhe über Normalnull zwischen <gn:hoeheger> und </gn:hoeheger> einschließt. Was immer das jetzt heißen mag. Da wir aber keinen eindeutigen Identifikator haben, sehe ich keine Möglichkeit so etwas zu automatisieren. --Alex (Diskussion) 19:59, 22. Mär. 2012 (CET)
Geht schon, zumindest bei Ortsteilen, die es vom Namen her nur einmal gibt. Den hoffentlich kleinen Rest kann uns der Bot in eine Arbeitsliste schreiben. Ich habe eine entsprechende Anfrage gestellt. Wenn es noch mehr Ideen gibt, was der Bot gleich mit erledigen könnte, gebt bitte dort Bescheid. --TMg 20:03, 22. Mär. 2012 (CET)
Super, danke. Mehr ändern würde ja auch bedeuten die Infobox weiter umzubauen. Das halte ich zwar prinzipiell für keine schlechte Idee (die auf der {{Infobox Verwaltungseinheit in Deutschland}} beruhenden Vorlagen sind recht weit ausgebaut und könnten als Vorbild dienen), allerdings halte ich das in der Kürze der Zeit für nicht durchführbar. Für den Anfang könnte man ja die Parameter Postleitzahl2 und Vorwahl2 abschaffen und bei Postleitzahl1 beziehungsweise Vorwahl1 die 1 weglassen. Andernorts werden die unterschiedlichen Postleitzahlen und Vorwahlen ja auch nicht getrennt erfasst und spätestens wenn es noch ein dritte gibt, ist der Vorteil der getrennten Erfassung wieder dahin. --Alex (Diskussion) 21:08, 22. Mär. 2012 (CET)
Ich bin der Hauptautor der Verwaltungseinheit-Vorlage. ;-) Mit den Postleitzahlen/Vorwahlen in einem Feld habe ich dort schlechte Erfahrungen gemacht, aus vielerlei Gründen. Einer ist, dass die Umschaltung zwischen Ein/Mehrzahl sehr kompliziert ist. Das ist bei zwei Feldern ganz einfach. Außerdem ist bei Ortsteilen eher anzunehmen (anders als bei Gemeinden), dass sie nur eine PLZ/Vorwahl haben. Kurz, ich würde hier dabei bleiben. --TMg 21:17, 22. Mär. 2012 (CET)
Umso mehr hatte ich auf Zustimmung gehofft. (-; Das mit den mehreren Postleitzahlen (Vorwahlen wohl weniger) ist vermutlich wieder ein Stadt-/Land-Ding. (Siehe beispielsweise Dortmund-Berghofen.) Ich kann den Aufwand nicht beurteilen, aber direkt schlüssig sind die beiden Parameter meiner Meinung nach nicht. --Alex (Diskussion) 21:46, 22. Mär. 2012 (CET)
Nach einem Blick in die Vorlagenauswertung ziehe ich meine Einschätzung zurück. In die zwei Felder wird noch größerer Unsinn eingetragen als in eins (Beispiel, Beispiel). Wenn die Artikelautoren sowieso irgend welchen Freitext eingeben, können sie das auch in einem Feld tun. Ich bin mir aber unsicher, ob wir das im Rahmen dieses Botdurchganges gleich mit machen sollten? Vielleicht nur die „1“ bei den beiden Feldern entfernen lassen? --TMg 22:05, 22. Mär. 2012 (CET)
Nur interessehalber: wie würdest Du denn die beiden Infoboxen füttern? Postleitzahlen und Vorwahlen waren die einzigen beiden Punkte, bei denen ich noch die Möglichkeit sah
ad hoc
etwas zu machen. Aber wenn nicht, dann nicht. --Alex (Diskussion) 00:09, 23. Mär. 2012 (CET)

Eine Frage: Wie kommt es eigentlich, dass so häufig ein Höhenintervall angegeben ist? Ich wüsste gar nicht so recht, woher ich diese Daten für einen Ortsteil bekommen könnte (außer sie irgendwie in einer ausreichend genauen Karte zu erforschen). Woher stammen diese Daten?--Cactus26 (Diskussion) 11:27, 8. Apr. 2012 (CEST)

Du sagst es: die Daten werden aus irgendwelchen Karten erraten. In der Regel eher schlecht als recht. Liegt unter anderem daran, dass das Gebiet eines Ortsteil unscharf abgegrenzt ist oder diese Grenzen dem Autor unbekannt sind. Ich hatte beispielsweise mal einen Fall, wo es statt 60 Meter Spannweite tatsächlich 150 waren. Als Höhe-bis wird häufig ein markanter „Gipfel“ in der Nähe genommen. (Auch wenn das gar nicht der höchste Punkt des Ortsteils ist, weil dieser nicht mehr im Ortsteil liegt oder ein höherer Berg in den Ortsteil hereinragt, dessen Gipfel außerhalb liegt.) Und bei Höhe-von ist mein Eindruck, dass noch viel wilder geraten wird. Unterm Strich: Theoriefindung. Aber das ist an dieser Stelle ein Kampf gegen Windmühlen. --Alex (Diskussion) 12:42, 8. Apr. 2012 (CEST)
Also gut, finden wir uns mit der von-bis Angabe ab. Ich habe jetzt mal untersucht, ob ich an die Angaben des Geodatenzentrums rankomme. Es ist mir gelungen, wenn auch nicht direkt über deren WFS-Schnittstelle (für die muss man sich offensichtlich registrieren, möglicherweise kostenpflichtig). Aber an ihren temporären "Werbe-Link" unter "XML-Antwort" komme ich dran. Da könnte ich die Höhe entnehmen, für das Element Ortslage, dass ich zudem mit der PLZ abgleichen könnte. Auch die Einwohnerzahl wäre verfügbar.--Cactus26 (Diskussion) 18:06, 14. Apr. 2012 (CEST)
<quetsch>Die Einwohnerzahl würde ich nicht aus der Quelle entnehmen. Die übernimmt das BKG ja auch nur aus anderer Quelle. (Vermute ich zumindest.)</quetsch> --Alex (Diskussion) 17:20, 15. Apr. 2012 (CEST)
Schön, dass noch jemand daran arbeitet. Inzwischen wäre es mir wie bei den Botanfragen schon erwähnt auch Recht, wenn nur die Parameter umbenannt würden (damit ich den alten Modus „Höhe + Höhe-bis“ aus der Vorlage ausbauen kann) und das mit dem Nachfüllen der fehlenden Daten bleibt. Wobei es natürlich Klasse wäre, wenn das hinzukriegen wäre. Die oben angedeutete Sache mit den PLZ/Vorwahlen würde ich nicht mit aufgreifen, vor allem da es keinen Verbesserungsvorschlag dazu gibt, der die Situation signifikant verbessern würde. --TMg 13:44, 15. Apr. 2012 (CEST)

Ich rücke mal raus. Ich habe mich unklar ausgedrückt, die PLZ ziehe ich nur heran um sicherzustellen, dass ich den passenden Eintrag beim GeoDatenZentrum finde, z.B. für Roßbach (Braunsbedra) kann man auf diese Weise beim GeoDatenZentrum die 123 m finden. Insgesamt habe ich jetzt folgendes implementiert:

  • Wenn Höhe und Höhe-bis angegeben, nicht aber Höhe-von, wird Höhe nach Höhe-von übertragen
  • Wenn die Ermittlung der Höhe beim GeoDatenZentrum erfolgreich ist (abgesichert durch PLZ)
    • Eintragen der Höhe (eine ggf. vorhandene Angabe wird ggf. ersetzt, die Angabe wird mit dem Kommentar-Suffix "<!--GeoDatenZentrum-->" versehen
    • Wenn Hoehe-von und Hoehe-bis der Angabe des GeoDatenZentrums widersprechen (also nicht von <= GDZ <= bis), rauswerfen
  • Wenn eine Änderung erfolgte: Neusortierung der Parameter entsprechend Kopiervorlage

Was man bei dieser Änderung miterledigen könnte, wäre lat_xxx/lon_xxx auf Breitengrad/Längengrad umstellen, aber das wurde beim letzten mal schon nicht gewünscht. Ein paar Reperaturen von Parameterschrott würde ich gerne vorab mit einem meiner Standard-Bots erledigen um mich hier nicht damit rumschlagen zu müssen. Was ich noch erforsche ist, wie ich mit dem Redir Infobox Ortsteil einer Gemeinde umgehen soll.--Cactus26 (Diskussion) 15:53, 15. Apr. 2012 (CEST)

Nachtrag: Hier mal ein Testedit (in diesem Fall passt die ermittelte GDZ-Höhe in das von-bis-Intervall). Zudem ein paar statistische Daten zu 50 "trocken" getesteten Artikeln: Für 75% war die Ermittlung der Höhe über das GDZ möglich, für 35% davon wurde eine bereits existierende Höhe ersetzt, in keinem Fall gab es nicht zur GDZ-Höhe passende Intervallgrenzen.--Cactus26 (Diskussion) 16:37, 15. Apr. 2012 (CEST)

Supi. Mit der PLZ meinte ich etwas anderes (weiter oben kurz diskutiert). Dein Vorgehen bzgl. PLZ ist einleuchtend, dazu habe ich außer Lob nichts weiter zu sagen. :-) Als Kommentar würde ich <!-- Quelle: Geodatenzentrum --> schreiben. Die Weiterleitung würde ich auflösen. Ich wüsste nicht, was dagegen spräche. Breiten/Längengrad bitte ebenfalls umstellen (außer, mir widerspricht jemand, aber auch hier wüsste ich nicht, warum). Die alten, kryptischen Parameter sind ja inzwischen nicht einmal mehr dokumentiert. --TMg 23:31, 16. Apr. 2012 (CEST)
Das Beispiel zeigt aber auch das Dilemma der von-bis-Angaben: Nach TIM-Online reichen die Höhen der Gemarkung (auf die sich die Angaben laut Vorlagenbeschreibung jetzt beziehen sollen) von etwa 255 m (Richtung Eiserfeld) bis 482 m (Eisenhardt). Die jetzigen Angaben scheinen sich nur auf die Ortslage zu beziehen. Der Umstellung auf Breiten-/Längengrad widerspreche ich nicht. Ein Parameter pro Wert (gerne dezimal) ist meiner Meinung nach besser als sich einen Wert aus bis zu drei Parametern zusammenzusuchen. Allerdings halte ich die Angabe von i.d.R. zwei Nachkommastellen (oder Bogenminuten) für Ortsteile für zu gering. Die Position dürfte oft am Rand oder außerhalb des Ortes liegen. Es sollten schon drei (und nicht mehr als vier) Stellen sein. .gs8 (Diskussion) 08:39, 17. Apr. 2012 (CEST)

Danke für das Feedback. Folgendes zum Status:

  • Ergänzung "Quelle" in Kommentar: geht klar
  • Weiterleitungen "Infobox Ortsteil einer Gemeinde": Sind bereits aufgelöst für "dt. Artikel" (es wäre schön, eine dedizierte Vorlage für intl. Ortsteile statt dieses Redirects einzuführen)
  • Umstellung Breitengrad/Längengrad: Ich würde bei der Übertragung der Parameter keine Modifikation vornehmen, sondern sie so übertragen, wie die Vorlage das derzeit macht ( |NS={{{Breitengrad|{{#if: {{{lat_deg|}}} | {{{lat_deg}}}{{#if: {{{lat_min|}}}|/{{{lat_min|}}}/{{{lat_sec|}}} }}}}}}}). Eine Korrektur der Genauigkeit halte ich bei dieser Umstellung nicht für sinnvoll machbar, auch eine Umrechnung in eine dezimale Darstellung würde die angegebene Genauigkeit verfälschen, denke ich (es sei denn man würde hier auch versuchen, die Angaben des GDZ zu übernehmen, würde ich aber baw. vertragen)
  • Sinnhaftigkeit der Von-Bis-Angaben: Fragwürdig, siehe Disk. oben. Würde aber vorschlagen, dieses heiße Eisen jetzt nicht anzufassen, durch die Übernahme der GDZ-Angaben für die Ortslagenhöhe erkennt man vlt. in Zukunft besser, wie sinnvoll die bisherigen Angaben sind.
  • Weiterer Test. Habe 500 Artikel "trocken" getestet (ohne Koordinaten-Umstellung). Statistik:
    • 70% wurden vom Bot verändert
    • bei 73% gelang die Ermittlung der Höhe beim GDZ (bei 6% davon stimmte die bereits eingetragene Höhe exakt)
    • in 3 Fällen (6%) enthielten die Höhenangaben nicht interpretierbare Werte (Altenbach (Schriesheim), Freienhagen (Waldeck), Reinhartshofen). Ich werde solche Fälle in einem halbautomatisierten Verfahren vorab bereinigen.
    • In mindestens 4 Fällen (z.B. Rehburg) gelang die Höhenermittlung via PLZ nicht, es wäre aber eine Ermittlung unter Heranziehen der Koordinaten möglich gewesen. Dieser Herausforderung werde ich mich noch stellen (hat jemand einen Vorschlag, welche Abweichung tolerabel ist?)
  • Ich werde o.g. Ergänzungen noch umsetzen und dann einen Test mit 20-30 Artikeln machen und die Änderungen hier zur Prüfung darstellen.

--Cactus26 (Diskussion) 09:54, 17. Apr. 2012 (CEST)

  • Das mit der Genauigkeit von Länge und Breite sollte auch eher in der Vorlagenbeschreibung stehen und bei der Umsetzung zur Darstellung im Artikel berücksichtigt werden.
  • Die nicht interpretierbaren Höhen lassen sich leicht von Hand ändern (s. Quelltext). Kannst Du eine bundesweite Liste erstellen? Wie groß wird die?
  • Höhenänderung: Bei geringen Abweichungen (etwa 10 m) halte ich eine Änderung vorhandener Werte nicht für erforderlich.
  • Sollen die GDZ-Koordinaten (statt Postleitzahl) nur genutzt werden, um gleichnamige Orte zu unterscheiden? Da gleichnamige Orte in der Regel nicht direkt nebeneinander liegen, sollte hier ein Schwellwert von etwa 2 km (0,02° oder 1') klein genug sein. Zur automatischen Änderung bei so großen Abweichungen würde ich die GDZ-Koordinaten aber nicht verwenden.
  • Die GDZ-Koordinaten könnte man aber verwenden, um eine Liste mit großen Abweichungen (z.B. > 500 m) zu erstellen, damit man solche Fehler beheben kann. .gs8 (Diskussion) 12:12, 17. Apr. 2012 (CEST)
Denke Du hast alles so verstanden, wie ich es gemeint habe. Prima. Ich stimme Dir auch in allen Punkten zu. Anmerkungen:
  • (durch den Bot) nicht interpretierbare Höhenangaben. Ich kann eine Liste erstellen, nach allem, was ich bisher gesehen habe, sind es nicht viele. Ich habe geeignete Werkzeuge, mit denen ich diese Daten offline (in Excel) bearbeiten und zurückspielen kann, vermutlich brauche ich da gar keine Unterstützung, wenn doch, melde ich mich.
  • Geringe Abweichung der Höhe: Du hast Recht, zu pedantisch sollte man da nicht sein. 10m erscheint mir da vlt. ein bisschen viel. Vlt. äußerst sich ja noch jemand dazu.
  • die GDZ-Angaben sollen nur genutzt werden, um den passenden Datensatz zu identifizieren. Danke für die Herleitung des Schwellwerts (ich konnte aus dem Stegreif gar nicht zwischen Grad und Metern umrechnen, aber ich wusste, dass jemand mitdiskutiert, der das kann)
  • Abweichungen protokollieren zw. GDZ- und Artikel-Koordinaten. Dazu muss ich die bisherige Implementierung ein wenig umstellen (die internen Schnittstellen passen nicht mehr), aber es wäre wirklich schade, diese Möglichkeit nicht zu nutzen, wo ich alle Daten dazu eigentlich beisammen habe.
--Cactus26 (Diskussion) 13:06, 17. Apr. 2012 (CEST)

Ich habe jetzt einen Trockentest mit den Koordinaten durchgeführt: Statistik: Bei 408 von 500 Artikeln ist die Ermittlung und Prüfung der Koordinate möglich. Dabei ist die Abweichung bei 77 (19%) > 0.005 Grad, bei 27 (7%) > 0.01 Grad und bei zweien (Bruchhausen (Ettlingen), Bachheim) > 0.02 Grad (0.019 bei Poppenlauer). Ein Beispiel mit einer Abweichung von 0.01 ist Haaren (Aachen), (Artikel vs GDZ). Außer in letzterem Fall ist die Koordinate im Artikel eindeutig falsch. Wäre nicht zu überlegen, die Anpassung auch gleich durch den Bot machen zu lassen? Es sind doch recht viele und der Artikel muss ziemlich sicher ohnehin bearbeitet werden.--Cactus26 (Diskussion) 09:54, 20. Apr. 2012 (CEST)

Auch die Koordinaten von Haaren (Aachen) sind ungenau. Hier könnte der Bot die Werte des GDZ übernehmen. Bei anderen Artikeln sind die Koordinaten nur auf Minuten angegeben, das bedeutet schon bis zu 1 km Rundungsfehler; oder eine Abweichung bis 3 km, wenn die letzte Stelle um 1 ungenau ist. Meiner Meinung nach ist die Genauigkeitsvorgabe von 1" oder 0.01° in der Vorlagenbeschreibung eine Stelle zu gering. Wenn Du die Koordinaten ändern willst, z.B. ab einer Abweichung von 500 m, solltest Du eine Liste der Änderungen, etwa in dieser Form erstellen:
Dann kann man das von Hand kontrollieren. Die Korrektur scheint jedenfalls sinnvoll. Länge und Breite (in Grad) kannst Du näherungsweise so umrechnen: Abstan (in km) = sqrt((B*110)^2+(L*70)^2). .gs8 (Diskussion) 16:09, 20. Apr. 2012 (CEST)
Ok, danke für die Prüfung/Vorschläge. Werde ich so protokollieren. 500m als Schwellwert sorgt wohl für etwas mehr Änderungen als mein bisheriger Schwellwert von 0.01 Grad.--Cactus26 (Diskussion) 17:52, 20. Apr. 2012 (CEST)

Testlauf für 20 Artikel

Habe nun den versprochenen ersten Test für 20 Artikel durchgeführt (17 wurden bearbeitet). Den Schwellwert für Höhenabw. habe ich auf 5m gesetzt, den für die Koordinate mal auf 0.01 Grad (was zur Korrektur der Koord. bei Wiednitz führte):

--Cactus26 (Diskussion) 10:51, 20. Apr. 2012 (CEST)

Sieht gut aus. Bei Wiednitz sind beruhen die Abweichungen auf Rundungsungenauigkeiten (Angabe auf Minuten). Bei Altenbach beträgt die Abweichung gegenüber der Angabe im Artikel 6 m, das ist deutlich weniger als die alte Höhe und unterhalb von 10 m. Automatisch kann man das wohl kaum mit dem Artikelinhalt abgleichen. .gs8 (Diskussion) 16:09, 20. Apr. 2012 (CEST)
Im Fall Altenbach geht das natürlich gar nicht, da der Wert im Artikeltext nicht mit der bisherigen Höhe in der IB übereinstimmt. Aber selbst wenn es eine Übereinstimmung gäbe, wäre eine automatische Korrektur mit vernünftigem Aufwand mMn nicht möglich, da man sich hier ja auch noch mit allen möglichen Formatierungsvarianten herumschlagen muss (und was, wenn hinter dem Wert im Fließtext auch noch eine Ref als Quelle steht?). Was ich verscuhen könnte, wäre bei einer Anpassung der Höhe in der IB im Fließtext zu suchen, ob der bisherige Wert vorkommt und prtokollieren, wenn dies der Fall ist. Was hältst Du davon?--Cactus26 (Diskussion) 17:52, 20. Apr. 2012 (CEST)
Das bringt nichts. Wenn der Wert vorkommt, gibt es ja kein Problem. Und wenn ein anderer im Text steht (was interessanter wäre), merkt der Bot das nicht. Schließlich passen in diesem Fall ja beide Werte recht gut zusammen. Bei den Höhenangaben bringt es (jedenfalls außerhalb des Flachlandes) nichts, sich um 10 m Gedanken zu machen. Sie dienen (wie TMg auch mal geschrieben hat) der schnellen Einordnung. Wer weitere Angaben (Ort der Höhe, Quelle, ...) machen will, soll das im Artikel schreiben.
Übrigens wurde der Parameter Höhe-Bezug bisher gar nicht beachtet. Streng genommen kannst Du nicht einfach eine Höhe allein ändern, sondern mußt gleichzeitig prüfen, ob sich die neue Höhe auf ein anderes System bezieht. Bei der Genauigkeit von mehreren Metern ist es jedoch egal, ob dort NHN (aktuell), NN oder HN steht. Deswegen, und weil NHN aktuell ist, sollte das der Standard sein. Bei der Eingabe neuer Höhen sollte der Parameter Höhe-Bezug daher gestrichen werden und die Vorlage sowie die Beschreibung auf diesen Standard angepaßt werden. Lediglich bei ellipsoidische Höhen (Abweichung können bei WGS84 50 m betragen) wäre eine explizite Angabe des Höhenbezugs nötig. Aber die will wohl keiner eingeben. Am besten wäre es, den Parameter ersatzlos aus der Vorlage zu streichen, denn
  • Bei der Angabe von Höhen auf ganze Meter gibt es kaum einen Unterschied zwischen NHN und NN.
  • Bei drei Höhenwerten wären korrekterweise drei Höhenbezüge nötig.
  • Ich glaube nicht, daß alle Autoren diesen Parameter korrekt angeben oder bei Änderungen beachten.
.gs8 (Diskussion) 14:30, 21. Apr. 2012 (CEST)
Ich folge Deiner Argumentation und wäre auch für eine Entfernung des Parameters. Die GDZ-Höhe ist lt. Angaben des GDZ eigentlich eine (gerechnete) NN-Höhe und keine NHN-Höhe. Spräche das nicht eigentlich gegen den Standard NHN (Deinen ersten Vorschlag)?--Cactus26 (Diskussion) 15:07, 21. Apr. 2012 (CEST)
Bei der Angabe auf ganze Meter ist NN=NHN (z.B. NRW, s.S. 6). Welcher Laie kann den Paramter denn korrekt angeben? Die Festpunkthöhen wurden zwar schon vor mehreren Jahren auf NHN umgestellt, die Höhenlinien in Kartenwerken sind aber wohl kaum verändert, beziehen sich streng genommen also noch auf NN, tatsächlich genausogut auf NHN. Außerdem ist der Höhenbezug nicht immer angegeben, so daß er gar nicht geprüft werden kann. Ich vermute fast, viele Autoren geben einfach NN an, weil sie das irgendwann (als an NHN noch keiner dachte) in der Schule gelernt haben. Und sie sehen es ja heute auch noch überall, haben also keinen Grund, das zu hinterfragen. NHN ist der aktuelle Standard im deutschen Vermessungswesen und künftig werden sich immer mehr Höhen darauf beziehen, während hier NN als Höhenbezug unbeachtet weiterschlummert. .gs8 (Diskussion) 16:14, 21. Apr. 2012 (CEST)
Hier fehlte der Parameter Höhe (=376), ebenso hier (=61). .gs8 (Diskussion) 16:32, 21. Apr. 2012 (CEST)
Bei den letzten Bot-Änderungen habe ich nur nicht numerische Inhalte konvertiert, nicht weiter auf den Rest geachtet, da diese der eigentliche Bot-Lauf schon korrigiert hätte. Ich möchte jetzt mit Höhe-Bezug nicht noch ein Fass aufmachen, sonst dauert es endlos, bis wir hier starten können. Ich würde jetzt erstmal vorschlagen, in den Fällen, in denen der Bot eine Höhe vom GDZ einträgt, Höhe-Bezug zu entfernen. Ok?--Cactus26 (Diskussion) 19:15, 21. Apr. 2012 (CEST)

Irgendetwas mit den drei Höhenparametern stimmt noch nicht. dieser Version des Artikels Sassenroth sind alle drei Höhenparameter eingetragen, aber nur im Parameter "Höhe" ein Eintrag, die anderen beiden sind leer. Anzeige in der Infobox = nichts. --Update (Diskussion) 19:27, 21. Apr. 2012 (CEST)

Ich glaube ich verstehe was Du meinst. Das liegt tats. an der bisherigen Vorlagenimplementierung, mir war das auch schon aufgefallen. Du musst Höhe-Von ganz entfernen (nicht leer setzen), damit Höhe zum tragen kommen. Der Bot wird das genau so machen, aber vlt. sollte man zus. die Vorlage verbessern.--Cactus26 (Diskussion) 08:24, 22. Apr. 2012 (CEST)

Weiterer Test mit 100 Artikeln

Habe nun einen weiteren Test mit 100 Artikeln gemacht. Dabei wurden 93 angepasst, bei 65 war ein Abgleich der Daten mit dem GDZ möglich. Details hier. Bitte um Feedback.--Cactus26 (Diskussion) 14:55, 22. Apr. 2012 (CEST)

Die ersten 20 sind Ok. In Busendorf (Beelitz) wurde die Höhe um 22 m geändert. Das scheint mir viel, stimmt aber mit dem GDZ-Wert und prüfen kann ichs nicht. In Cleverns ist die Lage nur auf Minuten angegeben. Liegt das innerhalb Deines Schwellwertes? In Ahrensmoor hast Du die Lage geändert. Gibt es eine Liste solcher Änderungen? Oder hältst Du eine Prüfung für nicht notwendig? Grevenbrück ist auch richtig korrigiert. Zu Deiner obigen Frage: die Streichung des Höhenbezugs ist nicht dringend und Du kannst ihn vorerst nur bei den geänderten Höhen löschen. .gs8 (Diskussion) 18:38, 22. Apr. 2012 (CEST)
Entschuldige, ich hätte obigen Link besser hervorheben sollen: Benutzer:Cactus26/Test.IBOrtsteil.20120422. Hier (untere Liste) ist zu erkennen, dass die Abweichung in Cleverns 0.465 beträgt und damit knapp unter unserem Schwellwert von 0.5 liegt. Ich habe schon wohl fast alle geprüft, bei denen die Koord. angepasst wurde, bei allen war es eine Präzisierung. Ich glaube auch, dass die Koordinate das sicher verlässlichste Datenelement des GDZ ist, die Höhe schien mir ebenfalls sehr verlässlich, wenn ich es gegen Google-Reliefdarstellung prüfen konnte.--Cactus26 (Diskussion) 18:56, 22. Apr. 2012 (CEST)
Hab ich übersehen. Ich habe mir grad Merkstein angesehen. Das scheint nicht so klar (von Alt-Merkstein nach Magerau). Wenn Du eine Liste fehlender Höhen erstellst, könnte ich die (für NRW) nachtragen. .gs8 (Diskussion) 19:05, 22. Apr. 2012 (CEST)
Die Koordinaten von Merkstein kann man aber lassen, wenn man den Stadtteil und nicht dessen Untergliederung (alte Dörfer) betrachtet. Hätte ich zwar anders gemacht, aber ein Hin und Her bringt auch nichts. .gs8 (Diskussion) 19:13, 22. Apr. 2012 (CEST)
(BK)Habe nicht verstanden, was Du bei Merkstein meinst. Wenn ich mir Google-Relief ansehe, sind die 154 plausibel. Der Hügel nördlich ist über 200m, bis zur Ordmitte sind 2 Höhenlinien (20m), also würde es passen. Ich würde sagen, das hinzuspielen weiterer Höhen in NRW machen wir separat, wird mir sonst irgendwie zu viel (der Abgleich der Ortsnamen ist sicherlich auch nicht ganz einfach).--Cactus26 (Diskussion) 19:19, 22. Apr. 2012 (CEST)
Die Bemerkung zu Merkstein war nicht ganz klar: dabei ging es um die Lage(änderung), nicht um die Höhe. Der folgende Satz bezieht sich auf fehlende Höhen allgemein. Die Idee war, eine Liste zu haben, um die Höhen nach der Bot-Bearbeitung (wie Du auch vorschlägst) nachzutragen. .gs8 (Diskussion) 13:33, 23. Apr. 2012 (CEST)
Ok, alles klar, die Liste werden ich nach dem Bot-Lauf erstellen. Wenn Du eine Liste in elektronischer Form hast, auf der evtl. auch die Koord. vorhanden sind, könnte man durchaus auch einen autmatisierten Abgleich ins Auge fassen. Im Hinterkopf habe ich die ganze Zeit noch, ob die jetzt entwickelte "Technologie" auch für {{Infobox Gemeinde in Deutschland}} interessant sein könnte.--Cactus26 (Diskussion) 14:59, 23. Apr. 2012 (CEST)

Durchführung des Bot-Laufs

Wenn keine Einsprüche kommen, werde ich den Bot-Lauf heute Abend starten. Nochmal zusammenfassend die Aktionen:

  • Die Parameter lat_xxx und lon_xxx werden in Breitengrad/Längengrad umgesetzt
  • Wenn Höhe und Höhe-bis angegeben, nicht aber Höhe-von, wird Höhe nach Höhe-von übertragen
  • Wenn die Ermittlung der Koordinaten und der Höhe beim GeoDatenZentrum erfolgreich ist (abgesichert durch PLZ und Koordinate)
    • Eintragen der Höhe (wenn die Höhe mehr als 5m abweicht, wird eine ggf. vorhandene Angabe ersetzt, die Angabe wird mit dem Kommentar-Suffix "<!-- Quelle : Geodatenzentrum-->" versehen). Wenn die Höhe des GDZ verwendet wird, wird der Parameter Höhe-Bezug entfernt
    • Wenn Hoehe-von und Hoehe-bis der Angabe des GeoDatenZentrums widersprechen (also nicht von <= GDZ <= bis), rauswerfen
    • Wenn die Koordinate des GDZ mehr als 500m von der des Artikels abweicht, wird die des GDZ übernommen
  • Wenn eine Änderung erfolgte: Neusortierung der Parameter entsprechend Kopiervorlage

--Cactus26 (Diskussion) 16:11, 23. Apr. 2012 (CEST)

Sorry, dass ich mich so spät wieder einklinke, aber wenn das BKG auf der Seite geodatenzentrum.de Höhenangaben in Meter über NN ausgibt, warum sollte man den Parameter Höhe-Bezug nicht auch entsprechend füttern? Der Unterschied mag unerheblich sein, aber zumindest ist der Bezug dann klar. Ansonsten alles top. --Alex (Diskussion) 16:41, 23. Apr. 2012 (CEST)
Ich glaube nicht, daß dieser Parameter ordentlich geplegt wird. Wenn irgendwann mal ein Kartenwerk auf NHN umgestellt ist und in der Infobox Höhen nachgetragen oder geändert werden, wird dieser Parameter wahrscheinlich kaum beachtet und beibehalten. Außerdem kann die Infobox 3 Höhen enthalten. Damit wären bis zu 3 Höhenbezüge möglich, was noch mehr Verwirrung und möglicherweise Fehler verursachen könnte. Meiner Meinung nach sollte der Parameter daher gestrichen und in der Vorlagenbeschreibung angegeben werden, daß sich die Höhen auf NHN beziehen (Wenn Höhen auf ganze Meter angegeben werden, sind NN- und NHN-Wert gleich, man muß also die Werte nicht ändern). Und wenn sich Höhen einheitlich auf NHN beziehen, kann in der Infobox standardmäßig "m ü. NHN" ergänzt werden. Bei der Lage fragt ja auch keiner nach dem Bezugssystem, und dort können die Unterschiede über 100 m groß sein.
@Cactus26: von mir gibts ein Ok für das Vorgehen. Eine digitale Höhenliste habe ich nicht. Ich hoffe, daß der Rest ohne Höhe sehr klein ist und manuell bearbeitet werden kann. .gs8 (Diskussion) 18:16, 23. Apr. 2012 (CEST)
Stimmt, das wird ja an alle drei Parameter angehängt. Ich war beim ersten Fall hängen geblieben, wo ja die Höhe des BKG eingetragen wird (die sich auf NN bezieht). Dann Parameter ganz raus? Ansonsten würde ich als
default
NN setzen, das scheint mir im Moment noch gebräuchlicher. --Alex (Diskussion) 19:00, 23. Apr. 2012 (CEST)
Das mit dem Default können wir noch klären, ich interpretiere das sonst mal so, dass Du nichts gegen den Start einzuwenden hast, ich lege als los: [1] (nicht signierter Beitrag von Cactus26 (Diskussion | Beiträge) 19:57, 23. Apr. 2012 (CEST))
Jepp, die Interpretation war richtig. (-; --Alex (Diskussion) 23:14, 23. Apr. 2012 (CEST)
Habe heute morgen erstmal abgebrochen, zum einen, um die Server nicht zu sehr zu strapazieren, zum anderen, um ein bisschen analysieren zu können. Vermutlich wird der Bot 3 Nächste brauchen, um durchzukommen. Bisher wurden 6233 Artikel bearbeitet, 91% wurden geändert, bei 73% war die Ermittlung der GDZ-Koord. mgl, bei etwa 12% wurde die Koordinate angepasst, --Cactus26 (Diskussion) 07:36, 24. Apr. 2012 (CEST)
Nachtrag: Aufgefallen sind mir ein paar merkwürdige Fälle mit mehreren IBs: Sende, Manheim, Mödlareuth.--Cactus26 (Diskussion) 07:38, 24. Apr. 2012 (CEST)
Da muß man die Artikelautoren ansprechen und fragen, ob das in dieser Form sinnvoll ist oder wie es am besten geändert werden kann (vielleicht Aufteilung?). Ich habe jedenfalls 2 Infoboxen in Manheim gelöscht und in den beiden den Parameter Nebenbox (ja, solche Fälle sind vorgesehen) gesetzt. Ansonsten hat der Bot bisher gute Arbeit geleistet und muß wohl nicht mehr im Einzelfall überprüft werden. .gs8 (Diskussion) 17:44, 24. Apr. 2012 (CEST)
Danke für die Prüfung. Die heutige Nachtschicht habe ich soeben gestartet.--Cactus26 (Diskussion) 18:59, 24. Apr. 2012 (CEST)
Statistik von heute Nacht: 6865 wurden verarbeitet, 92,5% bearbeitet, bei 66,3% war die Ermittlung der Daten beim Geodatenzentrum mgl.--Cactus26 (Diskussion) 09:51, 25. Apr. 2012 (CEST)
Statistik der letzten Nacht: 5333 bearbeitet, davon 85% angepasst, bei 57% war die Ermittlung der Daten beim Geodatenzentrum mgl. Nehme an, die, die zunehmend geringer werdende Erfolgsquote beim GDZ-Abgleich hängt damit zusammen, dass die zuletzt angelegten Ortsteile eher "exotischere" sind.--Cactus26 (Diskussion) 06:54, 26. Apr. 2012 (CEST)
Damit die Statistik nicht verfälscht wird: Es gibt auch Fehlerkennungen. --32X → Autorengilde № 1 10:36, 26. Apr. 2012 (CEST)
Ich verstehe das Wort "Fehlerkennung" in diesem Zusammenhang nicht. Und was das mit obigen Angaben zu tun hat, ist mir auch nicht klar. Kannst Du mir das bitte erläutern?--Cactus26 (Diskussion) 10:49, 26. Apr. 2012 (CEST)
Ich sehe da keine Fehlerkennung, sondern unterschiedliche Interpretationen der Ortsmitte (einmal Bahnhof(?) und einmal die Häuser). Der GDZ-Datensatz bezieht sich auf die Ortslage, nicht auf die Gemeinde wie hier angegeben. .gs8 (Diskussion) 11:15, 26. Apr. 2012 (CEST)
Schnittblumenstrauß
Einfach mal ein kleines Dankeschön …
… für die hilfreiche Arbeit Deines Bots, Cactus26. Liebe GrüVorlage:SSe, -- emha d|b 11:57, 26. Apr. 2012 (CEST)
Der GKD-Satz beinhaltet die Größenangabe 109 km², was gerundet der Größe der Gemeinde (108,78 km²) entspricht. Ortsteile haben in der Regel nur eine Größenangabe, wenn sie zu einem bestimmten Zeitpunkt noch eine eigenständige Gemeinde waren (für Mönau (1994 eingemeindet) wird nichts angegeben, für Uhyst (Spree) (2007 eingemeindet) wird die Größe der damaligen Gemeinde angegeben). Da die Siedlung Spreetal niemals eigenständig war (und die Gemeinde auch nicht nach ihr benannt ist), bezieht sich die Angabe offensichtlich nicht auf die Siedlung. --32X → Autorengilde № 1 16:20, 26. Apr. 2012 (CEST)
Danke für die Erläuterung. Gegen einen Fall wie Spreetal (wo ein kleinerer "eigenartikliger" Ortsteil namensgebend für eine aus mehreren (teilweise größeren) Ortteilen bestehende Gemeinde ist) ist wohl kein Kraut gewachsen. Wie aus Deinen Beispiel Uhyst schon ersichtlich, ist eine Flächenangabe beim GDZ alleine noch kein Indiz, dass es sich nicht um einen (heutigen) Ortsteil handelt. Wenn der Bot dauerhaft zur Verifikation eingesetzt würde (was bisher nicht geplant ist), müsste man sich hier was überlegen. @emha: Danke :-) --Cactus26 (Diskussion) 06:58, 27. Apr. 2012 (CEST)
Bei genauerem Hinsehen habe ich gemerkt, daß die Datensätze des GDZ nicht korrekt sortiert sind: ich habe bis jetzt die Objektart Ortslage und nicht das Feld Größe betrachtet. Die Datensätze der Ortslagen enthalten Lage und Höhe die Ortslage (Siedlung, bebauter Bereich). Dann gibt es aber bei manchen Ortslagen eine Größe. Diese bezieht sich nicht immer auf den Ortsteil, sondern (wenn sie denselben Namen wie die Gemeinde haben) auf die gesamte Gemeinde, ist an dieser Stelle also falsch. Dann gibt es eine Objektart Verwaltungseinheit mit der Einwohnerzahl der Gemeinde, hierhin würde auch die Größe gehören. Das Beispiel Spreetal zeigt, daß sich die Lage der Ortslage tatsächlich auf die Siedlung und die Lage der Verwaltungseinheit tatsächlich auf die Gemeinde beziehen. Der Bot kann Lage und Höhe der Datensätze Ortslage also weiter für die Ortsteile verwenden, nur die Größe ist hierfür unbrauchbar. .gs8 (Diskussion) 08:34, 27. Apr. 2012 (CEST)
Das heißt, die übernommenen Angaben waren in diesem Fall eigentlich zutreffend?--Cactus26 (Diskussion) 09:30, 27. Apr. 2012 (CEST)
Soweit ich das nach Openstreetmap und Google Earth beurteilen kann: ja. Aber es geht hier nur um 600 m, die Siedlung findet man mit beiden Werten. Und wenn 32X sich dort besser auskennt, muß die Lage des GDZ nicht übernommen werden. Wo die Ortsmitte liegt, ist eben auch Interpretationssache. .gs8 (Diskussion) 10:55, 27. Apr. 2012 (CEST)
Dann würden zumindest die Koordinaten am Rand der Siedlung liegen, was ich nicht so prickelnd finde. --32X → Autorengilde № 1 17:38, 2. Mai 2012 (CEST)
Kurze Anmerkung: Der Ort Spreetal ist nicht Namensgeber für die Gemeinde, den Namen trug zur NS-Zeit bereits der nordöstliche Ort Zerre, später hieß auch eine LPG im heute südlichen Gemeindegebiet so. Das steht alles noch nicht im Gemeindeartikel, weil ich die Implikation des Gemeindenames mit einem nationalsozialistischen Ursprung vermeiden wollte und noch keine hinreichend gute Formulierung fand. Bei der Namensfindung wurde auch Spreeheide vorgeschlagen, anders als bei der Nachbargemeinde Elsterheide wurde dieser Name jedoch vom zuständigen Ministerium abgelehnt. --32X → Autorengilde № 1 17:38, 2. Mai 2012 (CEST)

Erkennbarkeit, dass es sich um einen Ort in Deutschland handelt

Ich weiß nicht, ob das schon mal Thema war, aber mich stört an der Vorlage die mangelnde Information darüber, dass es sich beim Artikelgegenstand um einen Ort in Deutschland handelt. Auch in den zugehörigen Ortsteil-Artikeln wird meistens nur der Landkreis oder ähnliches erwähnt, aber nicht der Staat, so dass der Leser raten oder erst die Gemeinde anklicken muss, um das herauszubekommen. Man kann vom Durchschnittleser mE nicht erwarten, dass er das an der verwendeten Vorlage erkennt bzw. weiss, dass es diese für Schweiz, Österreich o.ä. in der Form nicht gibt. Ein kleines Bild der Flagge oder z.B. Ausschreibung in der Gemeindezeile ("Gemeinde xxx in Deutschland") fände ich sinnvoll.--Berita (Diskussion) 13:28, 2. Mai 2012 (CEST)

Halte ich für unnötig, das (Bundes)Land ist als Information ausreichend.--Leit (Diskussion) 14:49, 2. Mai 2012 (CEST)

Eingemeindungsdatum Wikipedia:Datumskonventionen

Hallo, weshalb wir eigentlich nicht nach Wikipedia:Datumskonventionen verfahren und zum Beispiel 4. Oktober 1973 mit 4. Okt. 1973 abgekürzt. Gruß, Rechtschreibkontrolle (Disk) 05:22, 1. Jul. 2012 (CEST)

Weil das kein in Stein gemeißeltes Gesetzt ist. Diese zweite Schreibweise ist in Fällen wie hier ebenfalls üblich. Guck zum Beispiel mal in deine Signatur. Bei der Langschreibweise besteht die Gefahr, dass sie innerhalb der Infobox-Spalte auf zwei Zeilen umgebrochen wird. --TMg 10:49, 1. Jul. 2012 (CEST)
Diskussionsseiten sind nicht der Namensraum, da spielt es keine Rolle. Juni und Juli werden ja auch nicht in der Box abgekürzt. Vielleicht sollte man die Box einfach ein Paar Pixel breiter gestalten um ein einheitliches Erscheinungsbild gemäß Wikipedia:Datumskonventionen zu erhalten. Der Schreibende von Daten wird so nur verwirrt und man spart sich das Ewige korrigieren. Rechtschreibkontrolle (Disk) 19:29, 1. Jul. 2012 (CEST)
Ich empfinde den Punkt nicht gerade als dringlich, aber vielleicht kann man tatsächlich Wikipedia:Datumskonventionen#Datumsangaben in Tabellen umsetzen. Also TT.MM.JJJJ statt TT. MMM. JJJJ. --Alex (Diskussion) 20:35, 1. Jul. 2012 (CEST)
Ich kann hier ehrlich gesagt kein Problem erkennen, erst recht keines, das „Verwirrung“ beim Schreibenden auslösen würde. Das eingegebene ISO-Datum wird für die Ausgabe halt formatiert. Wo ist da das Problem? Und ich wiederhole mich, wenn ich betone, dass „ein einheitliches Erscheinungsbild gemäß Wikipedia:Datumskonventionen“ kein in Stein gemeißeltes Gesetz ist. Erst recht nicht, wenn es wie hier „nur“ um einen Stichtag geht, bei dem der Tag und der Monat sowieso nur bedingt interessieren. Die Hauptsache ist das Jahr. Nur deshalb werden wir die Box ganz sicher nicht verbreitern. --TMg 00:35, 5. Jul. 2012 (CEST)
Bedenke beim Thema „Verwirrung“ eben den Punkt Wikipedia:Datumskonventionen, woran sich der Schreibende halten sollte und das ist ein Widerspruch zur Box. Deshalb bessere ich seit Jahren in genau in diesem Punkt – bisher immer ohne Beschwerden – bei den Datumsangaben nach. Die Box sollte mit gutem Beispiel vorangehen. Rechtschreibkontrolle (Disk) 01:45, 5. Jul. 2012 (CEST)
Das kannst du gern dort machen, wo es Sinn ergibt, aber hier kann ich nur wiederholen, dass WP:DK kein Zwang ist. Das Datum ist hier aus den genannten Gründen ganz bewusst und mit voller Absicht so geschrieben, wie es geschrieben ist. --TMg 01:53, 5. Jul. 2012 (CEST)
… wobei ich gerade merke, dass ich dich falsch verstanden habe. Ich dachte, du meinst das Belegdatum. Das Eingemeindungsdatum schaue ich mir an. --TMg 01:57, 5. Jul. 2012 (CEST)
Eingemeindung: Das meinte ich, nicht die (Klammerangabe), sorry habe ich mich missverständlich ausgedrückt. Gruß, Rechtschreibkontrolle (Disk) 02:04, 5. Jul. 2012 (CEST)

Ach TMg, du bist doch der Beste. Manchmal sind es die Kleinigkeiten, die einen glücklich machen :-). Vielen Dank für deine Mühen! Liebe Grüße, Rechtschreibkontrolle (Disk) 02:12, 5. Jul. 2012 (CEST)

Höhenangaben

Im Archiv wurde das Thema schonmal angesprochen. Ich finde das Verhalten der Infobox einfach nichts anzuzeigen, wenn der „Höhe-Von“ Parameter leer ist sehr unschön. Denn schließlich kopiert man sich ja normalerweise die aktuelle Vorlage der Infobox mit allen Parametern und füllt diese dann aus. Das führt aber bei Angabe von nur einer Höhe zu keiner Anzeige der Höhe in der Infobox. Ein Löschen des „Höhe-Von“ Parameters als Lösung finde ich Quatsch, denn es sollte der Grundsatz gelten: Ein fehlender Parameter sollte sich verhalten wie ein leerer Parameter. Könnte das jmd. fixen? Gruß, --Arnd (Diskussion) 14:23, 2. Jul. 2012 (CEST), PS: Wie wäre es eigentlich statt einzelner von-/bis-Parameter eine Vorlage zu machen, die die Angabe von Intervallen erlaubt. Dies könnte neben der Höhe auch bei Zeit usw. Verwendung finden.

Ein sehr guter Hinweis, vielen Dank dafür. Hintergrund ist, dass wir den Parameter „Höhe-von“ neu eingeführt und die Vorlage dazu in eine Art Kompatibilitätsmodus geschaltet hatten. Siehe Archiv. Was noch fehlte war die endgültige Umstellung des Vorlagenquelltextes. Das habe ich jetzt nachgeholt. Eine extra Vorlage für Intervallangaben käme mir etwas merkwürdig vor. Wenn das nötig ist, sollte man meiner Meinung nach einfach „1999–2000“ schreiben (nicht formalisiert) oder wie hier extra Parameter dafür einführen (streng formalisiert). Eine extra Vorlage hätte alle Nachteile dieser beiden Wege, aber kaum einen Vorteil. --TMg 16:44, 5. Jul. 2012 (CEST)
Danke, läuft alles. Ich denke jetzt haben wir eine akzeptable Lösung. --Arnd (Diskussion) 16:56, 5. Jul. 2012 (CEST)
eine solche Vorlage schlummert bereits im BNR, damit könnte man einfach 1999–2000 schreiben und in der Vorlage entsprechend auswerten, nur so als Hinweis. lg --Herzi Pinki (Diskussion) 01:54, 6. Jul. 2012 (CEST)
Die Implementierung ist abgesehen von ein paar fehlenden Features (Minuszeichen, Komma, Tausendertrennzeichen) beeindruckend. Aber wie gesagt löst das meiner Meinung nach nicht das vordergründige Problem. Man müsste die Benutzer erziehen, |Höhe = {{bis|100-200}} |Höhe = 100-200 mit Bindestrich einzugeben, also es genau falsch zu machen. Statt dessen könnte man sie auch dazu erziehen, |Höhe = 100–200 mit Bis-Strich einzugeben. Dabei lernen sie sogar noch etwas fürs Leben, denn wenn sie das einmal wissen, werden sie das auch im nächsten Word-Dokument so machen. Dass das eine maschinell auswertbar wäre und das andere nicht, halte ich für kein gutes Argument: Ein Bot könnte beides gleich gut auswerten. --TMg 19:29, 6. Jul. 2012 (CEST)
Hallo TMg, ich glaube jetzt haben wir ein Abwärtskompatibilitätsproblem. Alte Infoboxen mir "Höhe"- und "Höhe-bis"-Einträgen wie Wünschensuhl machen jetzt falsche Ausgaben. Sollte nicht der CactusBot "Höhe" auf "Höhe-von" verschieben? --Arnd (Diskussion) 12:06, 11. Jul. 2012 (CEST)
Ich hab mal einen Wartungslink eingebaut, um abschätzen zu können, wie viele Fälle das betrifft (dauert sicher eine Weile, ehe die Liste komplett ist). Wenn es nur ein paar Dutzend sind, sollten wir das von Hand korrigieren. Sonst sollte der Bot nochmal ran. --TMg 00:07, 12. Jul. 2012 (CEST)
Ok. Werden solche Listen nur in bestimmten Intervallen aktualisiert? Wann müsste sie fertig sein? Wir können sie dann gerne zusammenarbeiten. Gruß, --Arnd (Diskussion) 09:01, 12. Jul. 2012 (CEST)
Habe alles soweit von Hand korrigiert. Dabei ist mir aufgefallen, dass auch Artikel von Namibia beeinflusst wurden, die die Vorlage „Infobox Ortsteil einer Gemeinde“ verwenden wie z.B. Swakopmund-Vogelstrand. Hab es dort auch korrigiert. Gruß, --Arnd (Diskussion) 16:06, 13. Jul. 2012 (CEST)
Ich hatte beim Überfliegen der Problemstellen den Eindruck, dass das auch Absicht sein könnte: Mittlere und maximale Höhe. Das ist typischerweise die Spitze eines Hügels oder Berges und im Gegensatz zur minimalen Höhe leicht zu ermitteln. Ich wollte das ungern ohne Überprüfung umbügeln. --TMg 21:52, 13. Jul. 2012 (CEST)
Aber dieser Vorbehalt hätte ja dann auch auf alle vom Bot geänderten Werte gelten müssen. Oder meintest du speziell die Orte in Namibia? --Arnd (Diskussion) 12:00, 14. Jul. 2012 (CEST)
Ich meinte, dass wir nicht wissen können, ob jemand absichtlich die mittlere + maximale Höhe eingegeben hat oder ob er noch die alte Bedeutung der beiden Parameter im Kopf hatte. Nach nochmaligem Überlegen ziehe ich meine Bedenken aber zurück. Es wird in allen Fällen ziemlich sicher die minimale Höhe gemeint sein. Also alles gut so. Vielen Dank für die Überarbeitungen. --TMg 18:21, 14. Jul. 2012 (CEST)

Politisch oder Siedlungsgeschichtlich

Soll die Vorlage eigentlich nur bei Vorliegen des politisch-rechtlichen Status Orts- bzw. Stadtteil verwendet werden oder können auch Siedlungsplätze (Weiler oder mittlerweile verwachsene Orte) die Vorlage verwenden? --Arnd (Diskussion) 21:11, 10. Jul. 2012 (CEST)

So wie ich es verstanden habe, kann die Vorlage für alles verwendet werden, was sich Ortsteil schimpft. Das ist unabhängig vom (in einigen Ländern vorhandenen) rechtlichen Sinn. --Alex (Diskussion) 22:09, 10. Jul. 2012 (CEST)

Koordinaten-Anzeige in der Infobox

Welchen Sinn macht es denn die Koordinaten innerhalb der Infobox noch einmal anzuzeigen, wenn diese ja bereits an Artikelanfang zusammen mit dem Ortsnamen angezeigt werden. Neuerdings kann man auch noch die "Interaktive Karte" am oberen und im Koordinatenfeld ausklappen. Wäre es nicht sinnvoller auf diese zweite Anzeige, wie ja auch in der Infobox Gemeinde in Deutschland, zu verzichten?
MfG --wivoelke (Diskussion) 20:03, 29. Okt. 2012 (CET)

Ich verstehe den Sinn einer zweiten Karte auch nicht. Die Open-Street-Maps sind sehr viel übersichtlicher. Außerdem wird er betreffende Ort darin auch sofort markiert. Die neue Karte sollte schnellstmöglich entfernt werden.--Karl-Heinz (Diskussion) 21:13, 29. Okt. 2012 (CET)
Dem kann ich nur zustimmen. --Arnd (Diskussion) 21:38, 29. Okt. 2012 (CET)
Ihr Helden! Der Wikiminiatlas hat mit der Infobox nichts zu tun sondern wurde als Helferlein (Gadget) für alle Benutzer standardmäßig aktiviert und kann von jedem angemeldeten Nutzer in den persönlichen Einstellungen deaktiviert werden. Siehe auch WP:NEU#27. Oktober. Dem ging eine Diskussion bei den Verbesserungsvorschlägen voraus.
Die Wiederholung der Koordinaten in der Infobox ist noch ein Relikt aus alter Zeit. Früher standen die Koordinaten bei der Gemeindeinfobox nur dort, erst später kam die kleine Darstellung in der rechten oberen Ecke hinzu. Während die Ausgabe irgendwann aus der Gemeindeinfobox (und einigen anderen Geo-Infoboxen) verschwand, blieb sie in anderen (wie dieser hier) drin. Es gibt halt auch Ortsteilartikel, bei denen so wenig in der Infobox steht, dass die Koordinaten wichtiges Füllmaterial darstellen. --32X → Autorenngilde № 1 21:53, 29. Okt. 2012 (CET) PS: OpenStreetMap wird nur mit Binnenmajuskeln und ohne Bindestrich und Plural-s geschrieben.
Danke dir, mein Heldenvater, für die Aufklärung. --Karl-Heinz (Diskussion) 22:46, 29. Okt. 2012 (CET)

Das einzige Argument für die zweite Anzeige ist ja wohl das Füllmaterial bei spärlichen Parametern. Nach meinen Erfahrungen wird ja sonst gegen jede Redundanz argumentiert. Wenn man die Anzeige aus diesen Gründen aber schon behalten will, wie währe es dann ihn nur anzuzeigen wenn die Gesamtzahl der Parameter kleiner (z.B.) drei ist? Gruß --wivoelke (Diskussion) 10:54, 4. Nov. 2012 (CET)

Nachdem es keine weitere Resonanz gab habe ich unter Vorlage:IBOXtest eine Variante von „Infobox Ortsteil einer Gemeinde in Deutschland“ erstellt, die die Ausgabe des Koordiantenfeldes unterdrückt wenn ausreichend andere Angaben gemacht wurden. Bei der Unterdrücken der Ausgabe durch den Paramter Nebenbox belibt sie aber auf jeden Fall erhalten. Testweise habe ich die neue Vorlage bei Allertshofen eingebunden. --wivoelke (Diskussion) 16:39, 13. Nov. 2012 (CET)

Ich hab die Untervorlage mal direkt in die Hauptvorlage geholt. Funktional habe ich nichts geändert. Dein Punktesystem finde ich ein wenig merkwürdig.
  • Ist der Parameter Nebenbox ausgefüllt, wird die Koordinate immer angezeigt. OK.
  • Die Koordinate verschwindet, wenn einer der Parameter Lagekarte, Poskarte oder Ortswappen ausgefüllt ist. Das leuchtet mir nicht ganz ein. Warum macht ein Ortswappen die Koordinate überflüssig?
  • Wenn von den Parametern Höhe, Fläche, Einwohner, Eingemeindungsdatum, Vorwahl1 und Postleitzahl1 drei ausgefüllt sind, verschwindet die Koordinate. Die Idee ist interessant, ich finde sie aber ehrlich gesagt nicht einleuchtend. Angenommen, jemand fängt an, die Box auszufüllen und unterschreitet dabei gerade so die Punktegrenze. So lange wird die Koordinate angezeigt. Später kommt jemand (oder sogar der selbe Benutzer) und trägt die Höhe nach. Plötzlich verschwindet die Koordinate. Warum? Das kann der Benutzer in diesem Moment doch gar nicht verstehen.
Ich bin für ein konstantes, nachvollziehbares Verhalten. Mit Nebenbox: Die Koordinate wird nur in der Box angezeigt. Ohne Nebenbox: Die Koordinate wird nur oben rechts angezeigt. --TMg 19:23, 13. Nov. 2012 (CET)

Leider haben die Änderungen das Verhalten doch verändert. Die Koordinate oben rechts wird jetzt nur noch bei minimaler Parameterbelegung angezeigt, so wars natürlich nicht gedacht. Habe Ursprungsverhalten wieder hergestellt. Mit dem Vorschlag der Steuerung über den Parameter Nebenbox kann ich mich auch einverstanden erklären. Allerdings würde dann die Verwendung als Füllparameter nicht mehr erfüllt, wie stark auch immer dieses Argument ist. --wivoelke (Diskussion) 12:49, 14. Nov. 2012 (CET)

Habe jetzt die Testinfobox Vorlage:IBOXtest auf die Steuerung der Koordinatenanzeigr über den Parameter Nebenbox umgestellt. Wenn es keine ernsthaften Einwände gibt werde ich nächste Woche diese Version nach Vorlage: Infobox Ortsteil einer Gemeinde in Deutschland übertragen. --wivoelke (Diskussion) 15:55, 19. Nov. 2012 (CET)

KFZ-Kennzeichen

Ich würde gerne das Feld "Kfz-KzNeu" mit dem aktuellen KFZ-Kennzeichen einfügen, weil seit der aktuellen Kennzeichenliberalisierung einige Ortsteile ihr altes Kennzeichen wieder ausgeben dürfen. (z.B. Wattenscheid und Wanne-Eickel) --Gusaw (Diskussion) 22:47, 23. Dez. 2012 (CET)

Das gehört aber nicht bei den Ortsteilen hin, sondern bei der Stadt oder Gemeinde, siehe Düren --Karl-Heinz (Diskussion) 22:54, 23. Dez. 2012 (CET)--Karl-Heinz (Diskussion) 22:54, 23. Dez. 2012 (CET)
Zur Stadt gehört es nicht, weil nicht jeder in der Stadt das Kennzeichen erhalten kann, sondern nur die Bewohner des Ortsteils. Beispiel: Alle Bochumer können das Kennzeichen BO erhalten, aber Bochum-Wattenscheider haben die Wahl zwischen BO und WAT. (nicht signierter Beitrag von Gusaw (Diskussion | Beiträge) 23:26, 23. Dez. 2012 (CET))
Ich kann mir ehrlich gesagt nicht vorstellen, dass plötzlich verschiedenes Recht für die Bewohner der selben Statt gelten soll, nur weil sie an einer anderen Straße wohnen. Wo kann man das nachlesen? --TMg 00:36, 24. Dez. 2012 (CET)
Stimmt, TMg hat Recht. Somit ziehe ich meinen Vorschlag zurück. --Gusaw (Diskussion) 09:45, 24. Dez. 2012 (CET)

Attribute zur Eingemeindung

Hallo zusammen! Wie sieht es mit den Attributen zur Eingemeindung aus? Sollen die bei immer abhängigen Ortsteilen auch verwendet werden? Ein Beispiel: Die Hummelmühle war nie eine eigenständige Gemeinde. Sie gehört bis zum 30. April 1978 zur Gemeinde Massenricht. Am 1. Mai 1978 wurde die Gemeinde Massenricht zusammen mit ihren Ortsteilen (darunter auch die Hummelmühle) nach Hirschau eingemeindet. Soll ich nun im Fall der Hummelmühle die Attribute zur Eingemeidung leer lassen oder genauso befüllen wie auf Massenricht?

Ich würde nur das "Eingemeindungsdatum =1978-05-01" hinzufügen, ohne "Eingemeindet-nach=" zu setzen, weil damit die Eingemeindung in die aktuelle Gemeinde beschrieben wird. Gruß --wivoelke (Diskussion) 15:17, 17. Nov. 2012 (CET)
Nein, für Ortsteile, die nie selbst Gemeinden waren, wird kein Eingemeindungsdatum angegeben, nur für ehemals selbständige Gemeinden. Dort steht auch immer das Datum des Verlustes des Gemeindestatusses. Eingemeindet-nach wird nur ausgefüllt, wenn eine Gemeinde in eine andere Gemeinde eingegliedert wurde und jetzt nicht mehr zu dieser Gemeinde gehört. MfG Harry8 21:40, 17. Jan. 2013 (CET)
Sehe ich genau so. Was zählt, ist einzig das Datum des Verlust der kommunalen Eigenständigkeit (sofern vorhanden). Alles andere sind keine Eingemeindungen, sondern Umgemeindungen oder Umgliederungen. Ob man dafür noch einen eigenen Parameter einführen sollte, sei dahingestellt. Jedenfalls kommt, da die meisten geographischen Orte wohl immer Teil einer Gemeinde waren, deren Hauptort sich woanders befand, der Paramater Eingemeindung gar nicht in Frage.--Leit (Diskussion) 22:37, 17. Jan. 2013 (CET)
Abgerufen von „https://de.wikiup.org/index.php?title=Vorlage_Diskussion:Infobox_Ortsteil_einer_Gemeinde_in_Deutschland/Archiv/2012&oldid=198989275“