Re: heritage Denkmalschutz

Nahmd,

openzzz wrote:

Am besten würde man solche Dinge über Konfigurationsdateien lösen, um nicht bei jedem Problem an die Programmierer gehen zu müssen.

Die Erzeugung der Hauptkarte (wie wohl der allermeisten) Karten wird (schon immer) über eine Konfigurationsdatei gesteuert. Wie auch sonst?

Ein zentraler Admin prüft regelmäßig, ob die Visualisierung mit dem Datenmodell passt und justiert notfalls an den Config-Dateien.

Der braucht überhaupt nicht zu prüfen, denn das machen die Nutzer der Karte. Das Problem besteht ausschließlich darin, dass die Verwalter der Hauptkarte die Config nicht anpassen. Und ist begrenzt auf die Hauptkarte; die Verwalter der anderen Karten sind erreichbar und antworten auf Wünsche. Was natürlich nicht heißt, dass sie alle Wünsche erfüllen. Aber das erwartet auch keiner.

Ist OSM denn noch nicht flexibel konfigurierbar?

OSM?

Meinst Du den Renderer, der die Tiles der Hauptkarte erzeugt? Der ist vor kurzem noch umgestellt worden, um leichter Anpassungen vornehmen zu können.

Netzwolf wrote:

Das Problem steht seit Wochen an. Hast Du es den Verwaltern der Hauptkarte bereits mitgeteilt? Und wie sieht deren Reaktion aus?

Das catchall-Problem wurde bereits gemeldet.

Ich bin auf die Reaktion der Kartenverwalter gespannt. Meine Kristallkugel befrage ich lieber nicht. 🤔

Aber hier meine ich, dass solche temporären Geodaten, die für die Nutzer auch quasi Null Nutzwert haben, überhaupt nicht in die Datenbank gehören.

And now for something completely different: die Relevanzdiskussion.

Du hältst etwas für irrelevant, also raus damit aus der Datenbank. Ginge es nach mir, würde ich den ganzen 3D-Firlefanz™ und alles was mit Seefahrt zu tun hat tilgen. Das erste, weil es mich nicht interessiert und eine wie schwach auch immer definierte Vollständigkeit nicht erreichbar ist, das zweite, weil ich mangels Grün-Sensoren in DE keine Lizenz dafür bekomme.

Bevor es jemand in den falschen Hals bekommt: würde ich natürlich nicht. Weil nicht ich entscheide, was relevant ist.

Das bindet nur unnötige Mapper-Aufmerksamkeit. Die Objekt-Masse im JOSM-Editor ist schon groß genug.

Nein, die ist noch viel zu klein. Deshalb sammeln wir doch wie wild. Was meinst Du, welche Datenmengen uns 3D- und Indoor-Mapping noch bescheren werden?

Sollen die etwa von der OSM-Community auch noch gepflegt werden? Ist doch für die Katz, wenn sich die Wahlkreisgrenzen für jede Wahl sowieso ändern und amtlicherseits als Shapefile bereitgestellt werden.

Und wieder eine andere Geschichte: alle Daten in der OSM-Datenbank können (und werden) veralten. Ich kann nicht für jeden von mir erfassten Weg garantieren, dass ich einmal im Monat nachschaue, ob der noch da ist. Ich trag die aber trotzdem ein.

Ob Wahlkreisgrenzen in die Datenbank gehören, dazu habe ich keine Meinung. Das Datenvolumen ist überhaupt kein, und das mögliche Veralten nur ein schwaches Argument gegen die Aufnahme.

So eine Spezialkarte kann sich jeder selbst Overlayen, ohne OSM dafür belasten zu müssen.

Die Anbindung externer Datenbanken an OSM ist ein ungelöstes Problem. Natürlich kann ich jeden Firlefanz über die Karte drübermalen. Aber: eine Anfrage “wieviele Schulen gibt es in den einzelnen Wahlbezirken” kann ich bei integrierten Daten leicht beantworten lassen, aus dem Shapefile eher nicht. Unabhängig davon, ob die Anfrage sinnvoll ist.

Das wäre so, als ob man als Tag zu den Tankstellen-Gebäuden gleich noch die Benzinpreise in der Datenbank vorhält. Sicher nützlich für den Normalbürger, aber das lässt sich auch als von OSM unabhängiges Overlay realisieren.

Nicht alles, was hinkt, ist auch ein Vergleich: auch die Eisenbahnlinien lassen sich als Overlay realisieren. Buslinien sowieso – da die sich bei jedem Fahrplanwechsel ändern können. Und Geschäfte: andauernd öffnet oder schließt eins. Und die 3D-Objekte: warum sind die nicht in einer externen Datenbank in einem standardisierten 3D-Format gespeichert?

Einfache Antwort: weil die unterschiedlichen Mitstreiter bei OSM unterschiedliche Interessen haben. Und weil nur die Daten mit überschaubarem Aufwand verarbeitbar sind, die sich in der Haupt-Datenbank befinden. Lösch die T5 und T6 Pfade aus der Datenbank (“sowas hat in nem Stadtplan nix verloren, pack das in eine eigene DB und machn Overlay”), und ich bin weg. Lösch die 3D-Infos, und die 3D-ler sind weg. Lösch die Seefahrt-Infos, und die Seeleute sind weg.

Denkmalschutz-Eigenschaften sind natürlich interessantere Objekteigenschaften. Obwohl man da vielleicht unterscheiden sollte, ob es wirklich um ein Denkmal im Sinne einer Sehenswürdigkeit handelt oder um ein x-beliebiges Fachwerkhaus (wo der Denkmalschutz wohl eher dem Besitzer auf die Nerven und ans Portemonnaie geht). Ersteres ist durchaus als Overlay-Karte sinnvoll.

Du vermanschst “heritage=*” und “tourism=attraction”.

Denkmalgeschützt ist definiert durch die Aufnahme in einer entsprechenden Liste (und oft eine Plakette am Haus). Ob Du ein Gebäude für relevant hältst, ist für die Eigenschaft “denkmalgeschützt” belanglos. Es sind auch Gebäude denkmalgeschützt, die Dich nicht interessieren. Weil denkmalgeschützt nicht sehenswürdig impliziert. Und sehenswürdig nicht denkmalgeschützt.

Wenn die Geschichtskarte Sehenswürdigkeiten zeigt, dann nicht, weil sie Sehenswürdigkeiten sind, sondern weil sie historisch oder geschützt sind.

Gruß Wolf