Hi,
Ja, das System der Seezeichen ist tatsächlich nicht trivial.
Genau deshalb will ich ja dem Benutzer ersparen, sich damit beschäftigen zu müssen.
Die Definition der Dialoge hingegen ist entsprechend einfach (das kann ich).
Etwas komplexer ist die konsistente Umsetzung in verschiedene Sprachen.
Aber das lässt sich sicher mit einer DB gut lösen.
Eine angebundene DB für Bezeichner, Variablennamen, Hilfetexte und ihre Übersetzungen wäre leicht zentral zu pflegen.
Darin könnten auch die Renderregeln und die Regeln für die Eingabeprüfung abgelegt werden,
und wären so jedem Programmierer (Renderer, Anwendungen) zentral und aktuell zugänglich.
Und das Ganze wäre endlich mal maschinenlesbar.
(sicher auch interessant für viele andere Anwendungen, nicht nur für die Seezeichen)
sind eine Voraussetzung für Seekarten. Jeder Seemann weiss das aus eigener Erfahrung. Denn anders als im Strassenverkehr sieht man auf See nicht, wenn man von der Fahrbahn abkommt. Und wenn man es merkt ist es oft nicht mehr korrigierbar.
Ich will den Benutzer aber unterstützen
a) intuitiv und visuell mit Icons zu arbeiten (Seezeichen sind bekannt und vertraut)
b) an alle Attribute zu denken
c) dabei möglichst wenig Flüchtigkeits- oder Logikfehler zu machen
d) sich nicht um das Datenschema kümmern zu müssen
Genau darum geht es.
Deinem 4-Schritt-Beispiel “Restaurant” entsprechen für einen Leuchtturm mit Sektorenfeuer mehrere Dutzend manuelle Schritte.
(ok, das war jetzt das kompexeste Beispiel, für die meisten reichen vier Schritte)
Wenn mir mal jemand ein Grundgerüst machen könnte,
dann könnte ich exemplarisch zeigen was ich meine.
Und dann könnten wir gemeinsam das “Drumherum” (Grafik, Regeln, Datensatzgenerierung, DB) entwickeln.
Gruss, Markus
(Details gern per Mail oder telefonisch)
@tel000: für “Spezialisten” kann man problemlos den generierten Datensatz als S-57-Code in einem Fenster anzeigen. Und natürlich muss das Tool in beide Richtungen arbeiten: erfassen neuer Objekte und anzeigen bestehender. Wenn das Tool mal steht, kann es für viele andere OSM-Bereiche verwendet werden (z.B. Validitätsprüfung für Zahlen, Öffnungszeiten, Hausnummern, etc) . Das Schöne an einem Plugin ist, dass es erst mal unabhängig von JOSM existiert und frei gestaltet und später weitgehend beliebig geändert und entwickelt werden kann.