Vorlage Diskussion:Infobox Gemeinde in Deutschland/Archiv/2018

Datenverlust bei Einwohnerzahlen durch die Technik in dieser Vorlage

Letzter Kommentar: vor 6 Jahren13 Kommentare4 Personen sind an der Diskussion beteiligt

Vorweg: ich möchte mich nicht mit Vorlagen(programmierung), Datemstöbern in Kategorien und erst recht nicht mit Datenstöbern bei WikiData beschäftigen. Aber ich möchte Grafiken zur Einwohnerentwicklung erstellen. Dazu nutze ich entsprechende Tabellen in Artikeln. Daher mein Anliegen: ich möchte, das aktuelle Daten regelmäßig in die Tabellen übernommen werden.

Ich beschreibe mal ein Konservatives System bei dem die aktuellste Einwohnerzahl via Parameter in über die Infobox-Vorlage eingebunden wird (hat es ja mal gegeben). Das hat zwei entscheidende Vorteile:

Wenn jemand den Parameter händisch ändert, ist die Wahrscheinlichkeit hoch, das der Kollege ein Auge darauf wirft, wo die Zahl sonst noch sinnvoll eingebunden werden kann. Sowas machen Menschen typischerweise
Wenn der Autor sich nicht "menschlich" verhält, findet man fehlende Daten sehr einfach über die Versionsgeschichte (also eine konservative Technik die jeder beherrscht). Jeder kann also leicht die "Nachlässigkeit" seiner Vorgänger ausgleichen

Z.Zt. werden die Daten mehr oder weniger einmal pro Jahr geändert. Welche Technik genau eingesetzt wird ist für jemanden der nicht in der Materie steckt völlig intransparent. Es finden sich Hinweise, das die Daten in Kategoriebäumen "versteckt" sind ... möglicherweise sind entsprechende Doku-Schnipsel aber längst überholt und die Daten sind bei WikiData. Ich habe da keine Ahnung. Entscheidend ist aber, das ältere Daten faktisch verloren sind wenn die Infobox via Technik aktualisiert wurde. Ein Beispiel das mich heute aktuell sehr wütend macht ist der Artikel Berchtesgaden. In der Infobox findet jeder Leser den Wert für Dez. 2016. In der der Tabelle zur Einwohnerentwicklung weiter unten ist der aktuellste Wert von 2009. Damit man den "Witz" wirklich versteht und genießen kann: ich habe mir u.a. eine Atikelversion vom 17. Juni 2012 angesehen ... in dem Uraltartikel wird mir die Einwohnerzahl von 2016 angezeigt ... als hätte man damals in die Zukunft geschaut.

Und über Jahre wurde die Tabelle zur Einwohnerentwicklung nicht upgedatet, obwohl sicher ein Kollege die Daten recherchiert hat (sonst wären sie ja nicht in der Infobox). Aber nach einem Jahr sind die recherchierten Daten verloren weil sie schlicht niemand mehr findet (ich bin jedenfalls offensichtlich nicht der einzige der sie nicht findet). Und bei den Landesämtern sind natürlich auch ältere Daten schwieriger zu recherchieren als neuere.

Wir arbeiten an einer Enzyklopädie und werfen Daten nach einem Jahr weg! Das ist unglaublich!

Das Problem ist real! Ganz eindeutig hat die technische Variante hier mehr Probleme als es löst. Abschaffen ist also eine Lösung. Wenn es andere Lösungen gibt, dann sollten sie halt entwickelt werden. Nebenbei: Wenn beispielsweise ein Roboter zur jedem Ort eine Unterseite bei dem Artikel anlegt in der die Daten für Mensch und Maschine lesbar sind, soll es mir auch recht sein (mit Unterseiten kann ich mich beschäftigen - mit WikiData nicht). Z.zt. befinden sich aber Menschen im Hintertreffen.

Ich bitte um eine Lösung! Schließlich sind wir ein kollaboratives System bei dem man sich gegenseitig hilft und nicht Steine in den Weg legt. --Summer • Streicheln • ~~Note~~ 17:33, 5. Feb. 2018 (CET)

Lösung:

Du klickst im Artikel Berchtesgaden auf bearbeiten.

Du siehst, welche Vorlagen der Artikel nutzt, und findest die Vorlage:Metadaten Einwohnerzahl DE-BY.

Die Vorlage besitzt eine Versionsgeschichte, anhand derer du alle Einwohnerzahlen ab dem 31. Dezember 2007 ermitteln kannst, natürlich nicht nur für Berchtesgaden, sondern für alle bayerischen Verwaltungseinheiten. MfG Harry8 19:45, 5. Feb. 2018 (CET)

Das ist definitiv keine Lösung. Grund: wir arbeiten hier in (einem großen) Team. Jeder soll jederzeit das System verstehen und Updates einfügen können. Ich als einzelner kann den Arbeitswand nicht leisten den "deine" Methode erfordert. Nur dadurch, das andere möglichst konfortabel an den Tabellen mitarbeiten können funktioniert das System. Ich erstelle nur Grafiken und bin das letzte Glied in der Kette ... ich kann die Tabellen nicht pflegen!

Und nochmal: hier werden mit Aufwand Daten recherchiert, ein Jahr lang als aktuell eingebunden und dann in der Versionsgeschichte von schwer auffindbaren Dateien versenkt. Guck doch mal einfach, wie zugemüllt Kategorie:Vorlage:Metadaten Einwohnerzahl DE ist (wo pro Bundesland ein Eintrag stehen sollte sind es 49 - das ist abschreckend!).

Und weil oben bemängelt wurde das keine Lösung genannt würde. Den ganzen Kram abschaffen ist eine Lösung!!! Es macht keinen Sinn, Daten zentral zu halten wenn sie am Ende nur an einer einzigen Stelle weitergenutzt werden. Entweder schafft man es das System so auszubauen das die Daten mehrfach genutzt werden können - oder man stampft es einfach ein. Einziges Problem: irgendwer hat Herzblut in das Zeug gesteckt (halt ein Risiko, wenn man ohne vorherige Analyse und vermutl. ohne Informatikkenntnisse versucht solche Projekte zu stemmen).

Wegen mir soll es auch eine Lösung sein, wenn ein Roboter dafür sorgt, die Daten auf die jeweilige Artikeldisk der Orte oder eine Unterseite zu schreiben. So, das jeder sie finden kann. Entweder man investiert da nochmal richtig Arbeit rein. Oder man stampft der derzeitigen Automatismus ein. (aber wenn man einen Bot einsetzt, könnte der gleich den Parameter der Infobox-Vorlage vernünftig setzten - dann wäre alles über die Versionsgeschichte des Artikels gut sichtbar - oben schrieb ich schon, das Dateneinbindung über Vorlage allein deshalb doof ist, weil beim Aufrufen einer alten Version neue Daten angezeigt werden).

Es ist jedenfalls ein Unding, das in einer Enzyklopädie faktisch Daten vernichtet werden. --Summer • Streicheln • ~~Note~~ 20:40, 5. Feb. 2018 (CET)

PS: gerade habe hier eine Tabelle akt. und anschl. die Grafik. Aber es fehlen ein paar Jahre dazwischen weil ich es nicht leisten kann die Daten nachzurecherchieren.

PS2: @Harry8: ich weiß ja nicht, ob du deine Anleitung extra vereinfachend geschrieben hast oder selbst nicht weißt wie es geht ... über Bearbeiten von Berchtesgarden ist es noch ein weiter Weg bis Vorlage:Metadaten Einwohnerzahl DE-BY. --Summer • Streicheln • ~~Note~~ 20:47, 5. Feb. 2018 (CET)

Das steht dann doch unten bei den Vorlagen und ist (ggf. mit F3) schnell zu finden. MfG Harry8 22:59, 5. Feb. 2018 (CET)

Es gibt eine wunderbare Möglichkeit zu Testen ob etwas einfach ist oder nicht. Für einfache Dinge lässt sich immer eine kurze einfache Anleitung schreiben. Umseitig im Abschnitt Einwohner wäre genau so eine Anleitung sinnvoll. Wenn du es versuchst, wirst du feststellen das es nicht einfach ist. --Summer • Streicheln • ~~Note~~ 23:32, 5. Feb. 2018 (CET)

… wenn sie am Ende nur an einer einzigen Stelle weitergenutzt werden ist nicht richtig. Die Daten werden nicht nur in der jeweiligen Gemeinde-Infobox verwendet, sondern auch in den Auflistungen der Gemeinden in höhergestufteten Einheiten, also z.B. in den Landkreis-Artikeln oder in Listen zu den Gemeinden eines Bundeslandes (nicht immer und überall, aber meistens). Dein Einwand, nicht jeder sei in der Lage herauszufinden, welche Vorlage welche Information bereithält, gilt letztlich für jede Vorlage, also z.B. auch für Navi-Leisten oder diese Flaggen-Dinger wie

Deutschland. Auch die sind nicht für immer festgelegt, aber daraus kann man nicht fordern, sie sollten weg. NNW 10:23, 6. Feb. 2018 (CET)

@NordNordWest: du hast meine eigentliche Kritik verstanden? --Summer • Streicheln • ~~Note~~ 10:33, 6. Feb. 2018 (CET)

Ja, habe ich. Aber deine Kritik gilt natürlich weiter. Wenn ein neuer Bürgermeister gewählt wird, wird der in aller Regel händisch in der Infobox eingetragen und der alte kommt dann meist nirgends mehr vor. Hier gibt es also dasselbe Problem und ganz ohne Vorlage. NNW 10:39, 6. Feb. 2018 (CET)

Womit exakt belegt wäre, das du das Problem nicht verstanden hast!!! Ruft man eine alte Version des Altikels aus, dann sieht man sofort den Namen des alten Bürgermeisters. So einfach finde ich alte Daten, wenn sie händisch aktualisiert werden. Würde der Brügermeister über eine Vorlage aktualiert, würde auch der Aufruf alter Versionen den neuen (und dann eigentlich falschen) Bürgremeister anzeigen. Aber das ist ja das Fatale - die Vorlagenprogrammierern erkennen noch nicht einmal die Probleme, die sie verursachen. -- Summer • Streicheln • ~~Note~~ 14:44, 6. Feb. 2018 (CET)

Es ist noch schlimmer als ich angenommen habe. Gerade finde ich folgendes Beispiel in Wachtberg#Einwohnerentwicklung. Bis zum 16. Juni 2014 waren stehen in der Einwohnertabelle ab 1999 ein Wert pro Jahr. Am Ende der Datenreihe ist ein Lück von 2009 bis 2012 - also drei Jahre. Hier der Permanent-Link: spezial:permalink/131355719#Einwohnerentwicklung. Mit diesem Edit (am selben Tag) wurde der Wert für 2012 durch eine Vorlage erstetzt. Ich mutmaße, das damals extakt der 2012-Wert durch die Vorlage angezeigt wurde. Nun kommt aber das fatale, Jahr für Jahr vergrößert sich die Lücke. Inzwischen ist sie von 2009 bis 2015 ... ich vermute, das in dden Nächsten Wochen die Daten für 2016 in das Vorlagensystem übernommen werden. Dann hätten wir eine Lücke von 2009 bis 2016. DAS IST EINFACH SCHEIẞE!!!

Nochmal zum schon gesagten: gerade dadruch, das die Vorlagen scheinbar perferkt arbeiten, verkleistern sie die Fehler. Niemanden fallen Lücken wie die oben beschriebene auf. Alle wähnen sich im Glauben, das alles in Ordnung sei. Man verhindert Recherche zum günstigen Zeitpunkt - bzw. wenn der Fehler (hier die Lücke) auffällt. wird die Nachrecherche schwieriger.

Für Wachtberg habe ich gerade die Grafik c:File:Einwohnerentwicklung von Wachtberg.svg angelegt. Die Datenlücke ist deutlich sichtbar. In der Dateibeschreibung (Abschn. 'Daten' bei der Grafik) habe ich als Quelle den deutschen Artikel angegeben. Ich komme mir fast wie ein Lügner vor, weil ich weiss das die Daten aus der Quelle bald verschwunden sein werden. --Summer • Streicheln • ~~Note~~ 14:44, 6. Feb. 2018 (CET)

Nun ja, Scheiße schreien kann jeder;) Nützt aber nix. Es sei denn, du erklärst dich dazu bereit, jedes Jahr manuell alle ca. 12.000 Gemeinden + Amtsverwaltungen + Landkreise + Gemeindelisten der Landkreise und Amtsverwaltungen etc. zu korrigieren ... Das machst du wahrscheinlich nicht. Wenn du (wie oben bereits erklärt) die Versionsgeschichte der Vorlage anschaust, kannst du die Daten fix ermitteln. Lücken habe ich nicht entdeckt. Falls das zu schwierig ist, habe ich die Daten mal in zwei Minuten rausgesucht:

Wachtberg:

2007 20093
2008 20117
2009 20253
2010 20202
2011 20395
2011 19614 (Korr. Zensus)
2012 19786
2013 19827
2014 19964
2015 20457

Gruß. --Schiwago (Diskussion) 15:24, 6. Feb. 2018 (CET)

Die Vorlagenprogrammierern erkennen noch nicht einmal die Probleme, die sie verursachen. Ich schätze, dass bislang keiner hier auf die Idee gekommen ist, dass jemand in der Infobox einer alten Artikelversion nach Einwohnerzahlen sucht, wo sie bei den Statistikämter deutlich bequemer zu finden sind, gerne auch als vollständige Reihen für eine Gemeinde. Übrigens hast du noch das Problem der Grafiken. Wird denn bei deinem Permalink eine Karte von diesem Zeitpunkt gezeigt? Nein, wird sie nicht. Und anders als bei den Einwohnerzahlen, bei denen ein Datum steht, sodass Fehler auszuschließen sind, ist das bei Bildeinbindungen überhaupt nicht der Fall. Wenn ich mir also in zwei, drei Jahren den heutigen Wachtberg-Artikel aufrufe, werde ich die dann aktuelle Dateiversion sehen. Um dich modifiziert zu zitieren: „In dem Uraltartikel wird mir eine Grafik mit Einwohnerzahlen bis 2020 angezeigt ... als hätte man damals in die Zukunft geschaut“. Konsequenterweise müsstest du auf Dateien verzichten und das mit Bordmitteln darstellen. NNW 16:07, 6. Feb. 2018 (CET)

Der Amtliche Gemeindeschlüssel enthält keine Leerzeichen

Letzter Kommentar: vor 6 Jahren10 Kommentare5 Personen sind an der Diskussion beteiligt

und ohne Leerzeichen wird er auch im Editmodus in die Infobox eingetragen, z.B. 09172131 im beispielhaften Fall Schneizlreuth. Weil so eine lange Ziffernfolge dem geneigten Leser nicht zugemutet werden kann, wird sie in der Darstellung übersichtlich mit drei Leerzeichen (Deppenleerzeichen?) gegliedert: 09 1 72 131: Land, Regierungsbezirk, Kreis, Gemeinde. Das hat nur einen Nachteil: Die Leerzeichen sind nicht nur optisch, sondern bleiben bei copy&paste erhalten, mit dem Ergebnis, dass in Datenbanken, in denen man einzelne Gemeinden durch Eingabe des AGS abrufen kann (z.B. GENESIS-Bayern), die Gemeinde 09 1 72 131 nicht gefunden wird. Bitte um Lösungsvorschläge. Die übersichtliche Darstellung mit Leerzeichen ist ja durchaus ansprechend, aber vielleicht gibt's einen Trick, der die Leerzeichen beim copy&paste wieder rauswirft?--Ratzer (Diskussion) 16:56, 19. Jul. 2018 (CEST)

Man kann ja den Gemeindeschlüssel ohne Probleme dem Quelltext entnehmen. MfG Harry8 19:53, 19. Jul. 2018 (CEST)

Hab ich auch geschrieben (ohne Leerzeichen wird er auch im Editmodus in die Infobox eingetragen). Nur, wird das von jedem WP-Leser erwartet, dass er in den Edit-Modus geht und nachsieht, wie die Einträge darin aussehen? Das wäre wirklich unzumutbar. Fakt ist, der AGS hat keine eingebetteten Leerzeichen, also warum welche darstellen?--Ratzer (Diskussion) 08:02, 20. Jul. 2018 (CEST)

Ohne Frage sind die Leerzeichen zum Lesen sinnvoll. Auch bei Mobilgeräten wo C&P unbekannt/umständlich ist. Da das analoge Problem immer und immer wieder auftritt (Beispielsweise bei Kontodaten), sollten vor allem die Anbieter der Formulare angesprochen werden. Technisch ist es simpel die Leerzeichen in bestimmten Formularfeldern raus zu filtern. Die Anbieter müssen halt Rückmeldung von ihren 'Kunden' bekommen. --188.97.184.13 09:47, 20. Jul. 2018 (CEST)

Die zentrale GENESIS-Programmierung beim Statistischen Bundesamt setzt nicht mal Vorschläge der statistischen Landesämter um. Ich vermute, dass hier eine personelle Unterbesetzung herrscht. Das können wir getrost vergessen, dass die einen Leerzeichenfilter beim AGS-Eingabefeld programmieren werden. Aber was eiern wir in der WP hier noch herum? Die aus optischen Gründen eingefügten Leerstellen sind falsch, denn der Amtliche Gemeindeschlüssel hat keine eingebetteten Leerstellen. Muss ich noch deutlicher werden?--Ratzer (Diskussion) 11:50, 21. Jul. 2018 (CEST)

Man kann fragen, und man kann die Programierer fragen, Ich habe diesmal keinen gefragt. Ich habe es selber gemacht. mfg --Thomas021071 (Diskussion) 19:02, 22. Jul. 2018 (CEST)

Leider hast du es falsch gemacht; alle Gemeindeschlüssel haben Fehlermeldungen produziert Vorlage:Infobox Verwaltungseinheit in Deutschland/Wartung/Fehler in Gemeindeschlüssel. Gruß --FriedhelmW (Diskussion) 20:28, 22. Jul. 2018 (CEST)

Wo waren die Fehler als Beispiel? Ich lerne gerne. wenn es alle waren habe ich keinen Fehler gemacht. Wenn der Fehler in der Wartung gezeigt wird, ist es kein Fehler. Wo hast du den Fehler gesehen ? mfg --Thomas021071 (Diskussion) 21:39, 22. Jul. 2018 (CEST)

Alle Gemeindeschlüssel waren hier. --FriedhelmW (Diskussion) 21:46, 22. Jul. 2018 (CEST)

Danke für den Tipp, da habe ich nur die hälfte gesehen, bei der Wartung komm ich nicht weiter.--Thomas021071 (Diskussion) 22:20, 22. Jul. 2018 (CEST)

website

Letzter Kommentar: vor 6 Jahren6 Kommentare4 Personen sind an der Diskussion beteiligt

gudn tach!
gibt's wesentliche einwaende, den website-parameter auch in der gerenderten version "Website" (statt "Webpräsenz") zu nennen? vorteile waeren: 1. website ist ein wesentlich haeufiger verwendeter begriff und somit vermutlich leichter verstaendlich; 2. wenn parametername und gerenderte bezeichnung identisch sind, laesst sich der parameter besser merken. 3. einheitlichkeit: es ist auch der in der wikipedia haeufiger verwendete begriff. in infoboxen steht (gefuehlt) meistens "Website". -- seth 13:41, 25. Nov. 2018 (CET)

Da es sich um deutsche Gemeinden handelt plädiere ich auch für den deutschen Begriff. Was aber durchaus sinnvoll wäre, die Bezeichnung "Webpräsenz" durch "[[Website|Webpräsenz]]" zu ersetzten. Gruß --wivoelke (Diskussion) 17:31, 26. Nov. 2018 (CET)

Nur zur Erläuterung: Der Eintrag folgt derzeit hinter Website. Sichtbar wird der Begriff hinter dem Begriff Webpräsenz. MfG Harry8 17:55, 26. Nov. 2018 (CET)

gudn tach!

die begruendung von wivoelke kann ich nicht nachvollziehen. "website" ist ein deutscher begriff und steht auch schon wesentlich laenger im duden als "webpraesenz". zudem ist "webpraesenz" etymologisch auch nicht deutsch, da der erste bestandteil "web" des kompositums ebenfalls aus dem englischen kommt. die etymologie ist aber ohnehin wurscht fuer die heutige bedeutung.

selbst wenn du recht haettest mit der deutschhaftigkeit des wortes, wuerde ich das argument fuer nicht sinnvoll halten, denn wir schreiben das wort ja nicht in der jeweiligen landessprache der gemeinden. soll heissen: wir schreiben auch nicht "Verkkosivusto" bei der infobox zu finnischen gemeinden.

@Harry8, genau, danke fuer die umformulierung von mir genannten zweiten punkts. -- seth 00:03, 28. Nov. 2018 (CET)

da keine einwaende mehr kommen, wuerde ich es demnaechst ersetzen. -- seth 12:37, 3. Dez. 2018 (CET)

Bezeichner Eindeutschen ist der größte Unsinn den man manchen kann - es versaut schlicht jede Form von internationaler Zusammenarbeit und Austausch ... der Gipfel ist Eindeutschen von vordefinierten Bezeichnern. In sofern unterstütze ich das Ausdeutschen. --Summer • Streicheln • ~~Note~~ 16:51, 3. Dez. 2018 (CET)

Automatische Kategorisierung in Kategorie:Gemeinde in Bundesland

Letzter Kommentar: vor 6 Jahren15 Kommentare5 Personen sind an der Diskussion beteiligt

Moin, wie umseitig beschrieben erfolgt eine automatische Kategorisierung in Kategorie:Gemeinde in Bundesland. Das führt dazu, dass Leipzig die Kategorie:Gemeinde in Sachsen erhält. Sächsische Gemeinden führen die Bezeichnung Stadt wenn Sie die Bedingungen von Abs. 2 SächsGemO erfüllen. Analoge Regelungen finden sich in den Gemeindeordnungen anderer Bundesländer. Vereinfacht gesagt, werden als Städte Gemeinden bezeichnet, die über Stadtrechte verfügen. Da wir Kategorien für Städte führen, wie z.B. Kategorie:Stadt in Sachsen, halte ich es für zweckmäßig die automatische Kategorisierung dahingehend zu ändern. Mit dem Parameter Art= fragen wir bereits den Gemeindetyp ab. Beim Leipzig Beispiel steht dort also Art=Stadt. Damit die Kategorisierung so spezifisch wie möglich erfolgt, könnte so eine automatische Kategorisierung anhand des Gemeindetyps erfolgen. Was haltet ihr von diesem Vorschlag? Regards, Christoph Braun (Diskussion) 13:16, 9. Dez. 2018 (CET)

eine Kategorienzusammenführung etwa in 'Städte und Gemeinden in ...' würde das Problem pargmatisch lösen ... aber ich fürchte für Pragmatischmus klebt schon zuviel Hirnschmalz an den bestehenden Kategorien. Als Akademiker ist man ja froh, wenn man seine Begabung zur Differenzierung ausleben darf. --Summer • Streicheln • ~~Note~~ 12:20, 10. Dez. 2018 (CET)

Nachtrag: gleichzeitiges intelligentes Suchen in mehreren großen Kategorien führt nebenbei zu mehr Erfolg als das Aufspüheren fein differenzierter Kategorien. Mit incategory:"Geboren 1943" incategory:"gestorben 1970" incategory:Frau kommt man weiter als mit einer Kategorie:1943 geborene und 1970 gestorbene Frau. --Summer • Streicheln • ~~Note~~ 12:48, 10. Dez. 2018 (CET)

Zu Leipzig: Es ist eine Gemeinde in Sachsen. Wo soll da ein Problem sein? MfG Harry8 16:57, 10. Dez. 2018 (CET)

Moin, vielen Dank für eure Rückmeldungen. Je nachdem welchen Ansatz des Kategoriesystems man verfolgt, erhält man unterschiedliche Ergebnisse. Zur Zeit gibt es Kategorie:Gemeinde in Bundesland und Kategorie:Stadt in Bundesland. Hierbei ist die Kategorie:Stadt in Bundesland immer selbst durch Kategorie:Gemeinde in Bundesland kategorisiert und bildet so den Umstand ab, dass rechtlich alle Städte auch Gemeinden sind. Das von Summer angeführte Beispiel Kategorie:1943 geborene und 1970 gestorbene Frau kann ich an dieser Stelle nicht nachvollziehen, da der Ansatz nicht in der Verschachtelung vorhander Kategorien besteht. Vielmehr sehe ich das Problem darin, dass eine Auswertung (z.B. über Petscan) von Kategorie:Gemeinde in Bundesland bzw. Kategorie:Stadt in Bundesland zu inkonsistenten Ergebnissen führt, da die Kategorie Kategorie:Stadt in Bundesland nicht umfassend alle Städte abbildet. Die untergeordnete Kategorie:Stadt in Bundesland innerhalb von Kategorie:Gemeinde in Bundesland zu führen, wie es momentan der Fall ist, ist nur dann zweckmäßig, wenn diese Kategorie auch genutzt wird.

Mein Verständnis des Kategoriesystems ist, dass angestrebt wird, möglichst konkret und eindimensional zu kategorisieren. So ist der VW Golf beispielsweise exklusiv in Kategorie:Volkswagen-Automobil kategorisiert. Die Kategorie ist wiederum selbst in Kategorie:Automobil nach Hersteller und die dann in Kategorie:Automobil kategorisiert. Der Ursprüngliche Artikel VW Golf wird also nicht doppelt in Kategorie:Volkswagen-Automobil und Kategorie:Automobil kategorisiert.

Wendet man diesen Ansatz auf das Leipzig Beispiel an, würde man folgerichtig Leipzig in Kategorie:Stadt in Sachsen kategorisieren und nicht doppelt in Kategorie:Stadt in Sachsen und Kategorie:Gemeinde in Sachsen, da Kategorie:Stadt in Sachsen ja bereits in Kategorie:Gemeinde in Sachsen kategorisiert wurde.

Ich hoffe das Problem ist so etwas deutlicher geworden. Regards, Christoph Braun (Diskussion) 18:07, 10. Dez. 2018 (CET)

Ja, das ist jetzt deutlich geworden, und deinem Vorschlag stehe ich positiv gegenüber. MfG Harry8 19:48, 10. Dez. 2018 (CET)

Ob Stadt oder Gemeinde, das hat doch keine wirkliche Bedeutung, das ist ein Titel, aus dem nichts resultiert. Ich denke, wir machen viel zu viel Gewese um diesen Titel. Und dann hätten wir noch die Bergstädte, die Märkte, die Flecken … NNW 21:05, 10. Dez. 2018 (CET)

Die rechtlichen Aspekte der Unterscheidung zwischen Stadt und Gemeinde, die sich im Wesentlichen auf ihre Bezeichnung und die Bezeichnung ihrer Organe reduzieren, halte ich hier nicht für relevant. Da wir bereits eine Situation haben, in der es Kategorie:Stadt in Bundesland gibt, die allerdings inkonsequent geführt wird, gibt es m.E. zwei sinnvolle Optionen: I. Kategorie:Stadt in Bundesland einstellen und II. Kategorie:Stadt in Bundesland konsequent führen. Ein "weiter so, wie bisher" halte ich für eine Schlechtlösung und keine ernstzunehmende III. Option. Wie oben geschrieben, ist der Titel dann entscheidend, wenn man die Kategorien als Grundlage für weitere Arbeiten nutzt. Wer also plant Abfragen Anhand der Kategorie:Stadt in Bundesland durchzuführen, hat damit zur Zeit keinen Erfolg. Dabei ist die Unterscheidung in Städte und Gemeinden aus meiner Sicht hinreichend. Auch das statistische Bundesamt und die statistischen Landesämter nutzen in ihren Auswertungen die Untergliederung in Gebietskörperschaften nach Gemeinden und Städten.

Ich stimme dir zu, dass eine weitere Feingliederung möglich wäre, die Sonderformen von Verwaltungseinheiten abbildet, die sich aus den Gemeindeordnungen der Länder ergeben. Für Bergstädte gibt es Kategorie:Bergstadt in Deutschland, für Märkte, Marktflecken, Marktgemeinden und Flecken gibt es Kategorie:Minderstadt in Deutschland. Die Fallzahlen für Deutschland sind gemessen an der Gesamtzahl der Gemeinden in Deutschland (~11.000) überschaubar. Der Aufwand aus der Abfrage des Parameters Art= die Kategorisierung zu automatisieren ebenfalls. Es geht hier also um die Frage, ob wir einen Parameter, den wir sowieso schon nutzen, für eine automatisierte Kategorisierung verwenden wollen, die wir bereits für Kategorie:Gemeinde in Bundesland durchführen. Regards, Christoph Braun (Diskussion) 22:36, 10. Dez. 2018 (CET)

Wenn dich die rechtliche (Nicht-)Unterscheidung nicht interessiert, für welche Bereiche soll die Unterscheidung denn sonst von Belang sein? Was ist an Arnis bis Berlin anders als an Gröde bis Seevetal? Ändert sich etwas, wenn eine Gemeinde zur Stadt wird? NNW 10:35, 11. Dez. 2018 (CET)

Die Unterscheidung ist für denjenigen von Belang, der eine potentielle Auswertung vornimmt. Da sich Städte und Gemeinden, die nicht Städte sind, anhand von Faktoren unterscheiden können, die jenseits der Legaldefinition liegen (z.B. wirtschaftliche, infrastrukturelle, demografische oder andere Faktoren - such dir was aus), hängt der konkrete Unterscheidungsbedarf vom Einzelfall ab. Geeignete Werkzeuge für diese Auswertungen sind etwa PetScan (wie oben bereits genannt) oder TreeViews. Wesentliche Leistung ist es, das vorhandene System, dass bereits in Kategorie:Stadt in Bundesland unterscheidet entweder konsequent anzuwenden oder die Sortierung nach Kategorie:Stadt in Bundesland abzuschaffen. Welche Lösung präferierst du? Und welche konkreten Bedenken hast du gegen eine automatisierte Kategorisierung anhand des Parameters Art= (WENN Art=Stadt, DANN Kategorie:Stadt in Bundesland, SONST Kategorie:Gemeinde in Bundesland) in der Vorlage? Regards, Christoph Braun (Diskussion) 22:07, 11. Dez. 2018 (CET)

Nochmal zum mitlesen. Eine Stadt ist eine Gemeinde und Leipzig ist eine Gemeinde und eine kreisfreie Stadt. Steht alles in der Kat. Wo ist das richtige Problem? mfg --Thomas021071 (Diskussion) 22:23, 11. Dez. 2018 (CET)

Ich plädiere für Abschaffung der Stadt-Kats, weil Städte eben nicht automatisch andere Faktoren als Nicht-Städte haben, nicht umsonst habe ich oben Arnis erwähnt. Das ist ein Dorf mit dem Titel Stadt. Daneben liegt Grödersby und das ist auch ein Dorf, nur ohne Titel Stadt. So what? Wichtiger als so ein Status sind ganz andere Faktoren: Lage im Verkehrsnetz, Abstand zu Zentren, wahrscheinlich ist sogar die Höhe wichtiger. Ich sehe daher überhaupt keinen Sinn in so einer Unterscheidung. NNW 22:28, 11. Dez. 2018 (CET)

Wie erhält man dann ohne Kategorie:Stadt in Bundesland eine Liste von Städten in einem Landkreis/Bundesland, die nicht manuell als Listenartikel geführt wird? Regards, Christoph Braun (Diskussion) 23:25, 11. Dez. 2018 (CET)

Wenn du die Städte in einem Bundesland finden willst, gibt es z.Zt. nur die Möglichkeit sie über die entspr. Kategorie zu finden. Es ist aber ein Fehler zu glauben, das man eine Kategoriesystem nur genügend Kleinteilig auffasern muss um alles finden zu können. Das gegenteil ist der Fall. Ein Beispiel das vermutlich überrascht: es gibt keine Kategorie, die die Orte mit Binnenhafen in Niedersachsen auflistet. Trotzdem findet man sie wenn man sie mit >>>incategory:"Gemeinde in Niedersachsen" incategory:"Ort mit Binnenhafen"<<< (bitte mal ins Suchfled oben recht eingeben!). Gäbe es eine Kategorie:Stadt, so könnte man sie ganz einfach für Kombinationssuche benutzen. Gibt es aber nicht. Statt dessen wird alles bis ins letzte zerfasert.

Echte Informatiker mögen mich jetzt Prügeln ... aber ich versuche mal es anhand von Datenbankmodellen zu erklären. Es gibt im groben zwei Modelle: wir verwenden eine Hirachische Datenbank. Hirachische Datenbanke haben eine Baumstruktur und sind sehr leicht zu bedienen. Bei einer Suche spaziert man einfach die Pfade entlang bis man glücklich ist. Das zweite Datenbankmodell baut auf Tabellen auf und nennt sich relational. Kennzeichnend ist, das sie durch Befehlskonstrukte abgefragt werden. Abfragen sind dort deutlich Schwieriger - die Möglichkeiten sind aber größer. Meist nennt sich die Sprache zur Abfrage übrigens SQL. Nun kann man relativ leicht die Vorteile aus beiden Welten kombinieren, indem man die Struktur einer einer Hirachischen Datenbank eben nicht kleinteilig auffasert. Aber ich fürchte, das rede ich gegen Wände. Aber wer sich das Beispiel mit den geboren/gestorben (siehe oben) nochmal anschaut sieht, das man mit nicht zerfaserten kategorien sehr weit kommt. --Summer • Streicheln • ~~Note~~ 01:14, 12. Dez. 2018 (CET)

Moin Summer, was du hier beschreibst, erinnert mich stark an die alte "tags vs. categories" Diskussion auf Wikimedia Commons. Dort wurde diskutiert ob das hierarchische Wikipedia Kategorien System oder das Tag basierte System von z.B. flickr besser geeignet ist, damit Nutzer die gewünschten Inhalte finden. Mit der zunehmenden Integration von Wikidata (Stichwort Commons:Strukturierte Daten) bleibt abzuwarten, wie das ausgeht.

Hier auf Wikipedia haben wir zur Zeit ein System, in dem Städte unvollständig in Kategorie:Stadt in Bundesland abgebildet werden. Übergeordnet gibt es die Kategorie:Stadt in Deutschland. Wie kleinteilig oder "zerfasert" diese Kategorie zu führen ist (z.B. Landkreisebene) halte ich nicht relevant für die von mir aufgeworfene Frage, da wir unabhängig von der Tiefe der Kategorie Städte nicht konsistent abbilden. Solltest du das für diskussionswürdig erachten, erscheint mir Kategorie Diskussion:Stadt in Deutschland der richtige Ort dafür. Gerne versuche ich noch einmal die von mir weiter oben aufgeworfene, aber unbeantwortete Frage zu stellen: Welche konkreten Bedenken bestehen gegen eine automatisierte Kategorisierung anhand des Parameters Art= (WENN Art=Stadt, DANN Kategorie:Stadt in Bundesland, SONST Kategorie:Gemeinde in Bundesland) in der Vorlage, mit dem Ziel Städte als Städte zu kategorisieren? Regards, Christoph BraunDez. 2018 (CET)

Christoph Braun: eine hirachische Datenbank, wie es das Kategoriesytem ist, besticht durch seine Einfachheit. Vor allem die einfache Suche indem man den Baum ein paarmal entlangspaziert und sein Ergebnis findet. Wenn man die Äste aber zusehr zerfasert und parallele Äste aufbaub, wird der Spaziergang zum Gewaltmarsch. Ich möchte mich nicht an der Frage Ort/Gemeinde/Stadt/etc. verausgaben. Aber der Grundgedanke, das man durch ungezügelten Ausbau der Baustruktur die Recherche ab einen gewissen Punkt erschwert statt erleichtert sollte klar sein. Und das sollte man dann im Auge behalten ohne sich über ein einziges Detail zu streiten. --Summer • Streicheln • ~~Note~~ 17:33, 15. Dez. 2018 (CET)

Bitte antworten zu KFZ-Kennzeichen

Letzter Kommentar: vor 5 Jahren5 Kommentare4 Personen sind an der Diskussion beteiligt

folgendes kopiert von Diskussion:Eisenhüttenstadt#Kfz-Kennzeichen ohne Wertung durch mich. --V ¿ 00:22, 14. Okt. 2018 (CEST)

Die einzig verfügbaren Kennzeichen (genauer Unterscheidungskennzeichen) sind doch LOS und EH, oder? In der Infobox tauchen aber auch BSK und FW auf. Das geschieht wohl automatisch durch die Vorlage:Infobox Gemeinde in Deutschland anhand des Gemeinde- bzw. Kreisschlüssels. Da EH, BSK und FW aber eine Sonderstellung haben, taugt die automatische Logik der Vorlage nichts. Die Seiten von Beeskow, Fürstenwalde, u.a. haben natürlich das gleiche Problem. Kann man dagegen was machen? --Sommozzatore (Diskussion) 00:12, 14. Okt. 2018 (CEST)

Die offiziellen Unterscheidungszeichen im Landkreis Oder-Spree sind LOS, BSK, EH und FW. Man kann sie erhalten, egal in welcher Gemeinde des Landkreises man wohnt. Darum ist die Auflistung in den Infoboxen korrekt. MfG Harry8 12:29, 14. Okt. 2018 (CEST)

@Harry8: verstehe ich das richtig. Wenn man z.B. in der Stadt Aachen wohne, könnte ich auch ein Kennzeichen MON beantragen, oder in der Stadt Euskirchen eines für Schleiden (SLE), oder in der Stadt Düren gar wählen zwischen DN, Jül, MON, oder SLE? Oder kann ich gar weitere Kennzeichen wählen oder nur die des Kreises (Städteregion)? --Elrond (Diskussion) 14:52, 1. Mär. 2019 (CET)

In der Stadt Aachen kannst du außer dem AC auch das MON erhalten. Das gilt auch für die anderen Gemeinden in der Städteregion.

Auch deine anderen Vermutungen sind richtig. Im gesamten Kreis Euskirchen sind EU und SLE möglich, im gesamten Kreis Düren sind dies DN, JÜL, MON und SLE, aber nicht AC und nicht EU. MfG Harry8 15:10, 1. Mär. 2019 (CET)