[Freezvaut-devel] Vorschlag für Bekanntmachung von FreeZVAUT

Jan-Oliver Wagner jan at intevation.de
Fre Jan 13 11:34:29 CET 2006


On Wed, Jan 11, 2006 at 11:24:13AM +0100, "Jäger, Frank \(KRZ\)" wrote:
> mit der Formulierung bin ich im Wesentlichen einverstanden.

OK, dann war das ein +1 ?

> Die genannten Listen sind auch OK.

gut.

> A. Zu der vorangegangenen Diskussion möchte ich noch mal Stellung nehmen:
> 
> 1) Wir verwenden WMS und WFS, da wir die ALK aus dem Mapbender heraus benutzen. Mapscript ist bei uns kein Thema.

OK. Ist ja kein Problem wie Silke schon schrieb.

Aber nochmals zur Erinnerung: der entscheidende Wert von FreeZVAut 1.0 sind die
deutlich besseren Symbol-Fonts.
Es ist total egal wie man sie verwendet, sie sind auf jeden Fall
deutlich vollständiger und korrekter als vorher.

> 2) Die Formulierung "100% ZVAut-konform ist nicht möglich" sollte vermieden werden, da das die Anwender nur verunsichert.

Die steht ja schon gar nicht mehr in Silkes Vorschlag drin ...

Übrigens hatte ich die reingesetzt weil dies _streng_ genommen der
Wahrheit entspricht. Hintergrund: die vorgeschriebenen Fonts sind
geschützt und dürfen nicht als Freie Software verteilt werden.
Baut man einen Font identisch nach, kann man verklagt werden.
Armes Deutschland wo Vorschriften mit exclusiver Rechteverwertung
gebündelt werden.

> Die ALK Version 0.3 von CCGIS hat den Ansprüchen einer Bezirksregierung genügt. Sie hat die Genehmigung zur Auskunft "Amtliche ALK" dafür erteilt.
> Da sollte eine "verbesserte Version" doch erst recht genügen.
> Wir sollten nicht "päpstlicher sein als der Papst". Wenn es für eine Bezirksregierung ZVAut-konform genug ist, ist es das auch für uns.

"Amtliches ALK" klingt doch gut, da sollten wir verwenden.
Was "Konformität" angeht, kann man sich Ärger einholen wenn man zu einer
offizielen Verordnung/technischen Vorschrift Konformität behauptet, sie
aber nicht wirklich hat.
Wie Arnulf schon mal in Bonn sagte, eigentlich brauchen wir einfach eine
neue Definition, die besser geeignet ist. Schaffen wir doch einfach
Fakten ;-)

> B. Noch einige weitere Gedanken in dem Zusammenhang:
> 
> 1. Für den Qualitäts-Druck aus Mapbender gibt es "_4"-Versionen der Mapdateien mit 4facher Auflösung. Das werden wir wieder brauchen.

Wer möchte sie herstellen (ist glaube ich nicht allzu schwierig, oder?) ?

> 2. Bei Mails an die Liste EDBS2WKT bitte bedenken, dass dort auch viele Anwender registriert sind. Bitte keine Entwickler-Fachsprache sondern allgemeinverständlich formulieren.

hm, ist denn der Announcement-Text OK oder nicht?

> 3. Ich hoffe, dass bei der "Harmonisierung der Datenmodelle" nicht eine größere Menge Arbeit für mich heraus kommt, weil ich das Programm total umstrukturieren muss.
> Einerseits denke ich, dass ich ein fast optimales Datenmodell gefunden habe, um die - eigentlich gegensätzlichen - Strukturen von ALK und OGC zusammen zu bringen.
> Andererseits kann ich das zur Zeit nicht leisten.
> In das Projekt ist bereits sehr viel Arbeit hinein geflossen, und die externe Finanzierung war verschwindend gering. Als kommunaler Dienstleister fehlt uns die Struktur für die Finanzierung von freien Softwareprojekten.
> Die "Bitte um finanzielle Unterstützung des Projekts" wurde - mit einer Ausnahme - ignoriert. 
> Das Projekt wurde also fast ausschließlich vom KRZ getragen. Mehr geht nicht ohne externe Finanzierung und die werden wir nicht bekommen für eine "Umstrukturierung" ohne neue Leistungsmerkmale des Programms.
> Zudem ist die Personaldecke bei uns sehr dünn.

schauen wir doch erstmal. Aber egal wie das Datenmodell nachher
aussieht, die Symbol-Fonts solltest Du einfach in Deine MapServer
Anwendungen einbauen können.

> Ich rede nicht von Namensänderungen bei Feldern oder Tabellen. Das wäre sehr einfach möglich, da nur jeweils ein Literal geändert werden müsste.
> (Allerdings müssten alle Anwender ihre eigenen Abfragen anpassen.)
> Ich rede von tiefen Eingriffen in die Logik, falls wirklich Datenbank-Strukturen geändert werden müssten.

Ich denke, zuerst analysieren wir die Situation einmal vorurteilsfrei.
Dann schauen wir wie es weitergehen sollte.

Grüsse

	Jan
-- 
Jan-Oliver Wagner: www.intevation.de/~jan  | GISpatcher: www.gispatcher.de
Kolab Konsortium : www.kolab-konsortium.de | Thuban    : thuban.intevation.org
Intevation GmbH  : www.intevation.de       | Kolab     : www.kolab.org
FreeGIS          : www.freegis.org         | GAV       : www.grass-verein.de