Java und JOSM - benutzerfreundliche Engabemaske

Guten Tag liebe Java-Kenner!

ich habe da eine Idee (und auch ein Konzept) für eine JOSM-Verbesserung:

Für ein Projekt bräuchte ich dringend eine benutzerfreundliche Eingabemaske.

Menschen die keine erfahrenen OSMer sind, kommen mit den Tags nicht zurecht.
Deshalb möchte ich sie durch eine intelligente Benutzerführung unterstützen.
Dabei sollen Eingaben auch auf Validität geprüft werden.

Leider kann ich aber kein Java- aber ich kann gut beschreiben…
Ein Grundgerüst mit den wichtigsten Funktionen würde mir schon mal sehr helfen!

Wer kann mir helfen?

Herzlichen Dank,
Markus

Was genau möchtest du denn haben beziehungsweise wo besteht der unterschied zu den Eingabemasken die es unter Vorlagen bereits gibt?

Hi,

Die Vorlagen sind nicht in der Lage, Eingabeprüfungen durchzuführen. Für die Masken fehlen verschiedenen Eingabe-Elemente. Sie sind nicht in der Lage, eingabespezifisch regelgesteuert zu verzweigen, und können nicht aus den Eingaben regelgesteuert Datensätze zusammenbauen. Da dies mittelfristig nicht geändert wird, haben mir die Entwickler ein Plugin empfohlen.

Ich möchte ein Frontend, das ganz simpel zu bedienen ist, und das automatisch die für das Backend komplexe Datenstruktur zusammenbaut. Ich kenne die Regeln und weiss , wie man das benutzerfreundlich darstellen kann, aber ich kann es nicht programmieren.

Ich möchte:

  • Plugin (Grundgerüst)
  • Tags von JOSM-Objekten holen
  • Eingabemaske anzeigen
    – Listenfed (fixe Auswahl)
    – Checkbox
    – Gruppe von Radiobuttons
    – Feld Text
    – Feld Fliesskommazahl
    – Schlüssel, Wert, Werteliste, Bezeichner
    – Icons
  • Eingaben entgegennehmen
  • Eingabeprüfung
  • alles zusammenführen und nach Regeln ergänzen und wieder in JOSM laden

(und wenn alles funktioniert, wird es wahrscheinlich noch für viele andere Anwendungen gebraucht werden können)

Gruss, Markus

PS: eine genauere Beschreibung kann ich Dir gern per PM schicken oder telefonisch erklären.

Mh das klingt sehr aufwendig was du dir da vorstellst und ich glaube der Nutzen ist dafür nicht groß genug. Also ich bin wohl eher nicht daran interessiert.

Das klingt ja so als wolltest du eine sehr komplexe Anwendung zur Definition von Dialogen die dann automatisch total super sind. Bei uns in der Firma haben wir auch ein Produkt was sowas in der Art macht (so grafisch und Eingabemasken und regeln und so) das kann ich dir aber leider nicht zur Verfügung stellen :wink:
Weiterhin sehe ich den großartigen Nutzen nicht da für viele Eingabefelder nicht viele Informationen aus dem Kontext entnommen werden können und nicht viel Validierung gemacht werden kann. Ich finde auch das die vorhandenen Vorlagen relativ gut sind und - ohne jemandem zu nahe treten zu wollen - frage ich mich wie qualitativ hochwertig die Daten sind die von jemandem kommen der sie nicht versteht. Vielleicht liege ich aber auch mit dieser Einschätzung total falsch.
Den Workflow zu verbessern würde natürlich sinn machen. Beispielsweise muss um ein Restaurant einzutragen zurzeit folgendes gemacht werden: (kann z.t. mit Tastaturshortcuts beschleunigt werden, das ist aber auch nicht intuitiv)

  • Knotenpunkt setzen Werkzeug auswählen
  • Knoten anlegen
  • Vorlagen menu öffnen
  • Restaurant finden und anklicken

4 schritte insgesamt die alle Manuell eingeleitet werden müssen. Eine Toolbar aktion zum POI einlegen die dann nachdem setzen des Punktes direkt einen Wizard zum erstellen öffnet mit einer durchsuchbaren Liste möglicher POIs wäre vermutlich cooler. Damit wären es nurnoch 2 explizite schritte

  • Poi Werkzeug auswählen
  • POI anlegen

Auserdem würde man nicht mehr durch die gefährliche rote linie beim auswählen des Vorlagen Menüs verwirrt werden. Aber ob das den Aufwand wert ist?!

Der einzige Vorteil des Vorlagenmenüs ist, dass man sich die englischen Begriffe nicht merken muss…

Benutzerfreundlich Eingabemasken halte ich für sehr wichtig!

Bei den momentanen Vorlagen stört mich, dass man nicht wirklich weiß welche Tags da dann gesetzt werden. Außerdem kann man Objekte mit den Vorlagen nur erstellen, und nicht bearbeiten, oder?

Andersrum :wink: man kann Objekte nur bearbeiten und nicht erstellen. Und ja das ist schon richtig: der einzige vorteil ist das man sich die tag schlüsselworte nicht merken muss und sich nicht merken muss was für tags für einen bestimmten typ sinn machen (z.b. bei straße gibt es ein eingabefeld für höchstgeschwindigkeit, beim taggen ohne vorlage vergesse ich gerne die einzutragen wenn ich sie mir nicht speziell aufgeschrieben habe, kann aber gut vorkommen das ich eine straße eintrage wo ich die geschwindigkeit eh weiß und sie beim manuellem eintragen nur vergessen würde.
Was aber stimmt: es gibt keine möglichkeit die vorlagen eingabemaske für ein bereits typisiertes element erneut zu öffen (also die passende maske zu den existierenden tags zu finden) dh. zum bearbeiten eines bestimmten typs muss auf die richtige vorlage geklickt werden. Verbesserungspotential ist auf jedenfall da.

Das meinte ich… :slight_smile: Allerdings hatte ich noch nicht gemerkt, dass wenn man die richtige Vorlage bei einem bereits getaggten Objekt, öffnet, dass dann die Felder bereits ausgefüllt sind. Daher dachte ich, dass man nur neu erstellen kann.

Ich fänds super, wenn das entsprechende Formular rechts wo auch die Tags stehen angezeigt werden würde. Dann hätte man direkt beim anwählen eines Objektes schon eine übersicht darüber was noch fehlt.

Außerdem fehlen in den Vorlagen etliche Felder. Bei vielen kann man nur einen Namen angeben.

Bei vielen Tags wären Prüfungen sinnvoll. Zum Beispiel, dass bei maxspeed nur Zahlen und Punkte eingegeben werden können.

Und etwas wie z.B. Öffnungszeiten würde eine eigene Maske erfordern, die dann den Wert zusammensetzt. Ich tagge Öffnungszeiten eher selten, da ich immer erst im Wiki nachlesen muss, wie der Wert genau aufgebaut sein muss.

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.

Hallo Markus,

ich möchte dein Engagement in der Sache ja nicht in Frage stellen, aber wie sehen deine Vorstellungen einer “OSM-Seekarte” genau aus? In dem Bereich gibt es nicht nur in Deutschland genaue Regelungen. Bei großen seegehenden Sportbooten (und für Berufsschiffer sowieso) besteht eine Verpflichtung, aktuelle amtliche(!!) Seekarten mitzuführen. Auch “elektronische” Karten müssen hier sicherlich zumindest amtlich geprüft sein. Aber das ist dir sicher bekannt.
Die Niesche, die eine Seekarte auf OSM-Basis füllen könnte, dürfte eher klein sein, sofern vorhanden.

Gruß,
Sven

Hallo Sven,

Schön einen weiteren Kenner der Materie unter uns zu haben - willkommen!

Bitte mach zu diesen Themen einen neuen Thread auf - sonst kommen wir hier durcheinander.

Danke, Markus

Guten Morgen!

ich suche immer noch dringend jemanden, der mal ein paar erste Zeilen Java schreibt,
damit der benutzerfreundliche JOSM-Editor ein erstes Gesicht bekommt…

Inzwischen gibts immer mehr Anwendungswünsche dafür:

  • Seekarte
  • Wanderkarte
  • Cyclemap
  • ÖPNV-Karte
  • Pistemap

Alle die spezifische Tags verwenden brauchen den benutzerfreundlichen Editor!

Gruss, Markus

Ich finde die Idee nicht schlecht. Ein Plugin-Skelett würde ich Dir auch zusammenschustern, aber dann müsste man sich erstmal Gedanken machen, wie man die Regeln festlegt und in die GUI integriert. Hast Du da schon genauere Vorstellungen?

Super!
Schick mir eine Mail oder Deine Tel-Nr, dann liefere ich Genaueres.

Gruss, Markus

Genau so wäre es ideal!

Leider kenne ich mich mit Java überhaupt nicht aus…

Vielleicht kannst Du mit einer kleinen **Datenbank **helfen?

Die Datenbank müsste enthalten:

  • alle Variablennamen
  • die Bezeichner für de Variablen in verschiedenen Landessprachen (erst mal Deutsch, Englisch, Amerikanisch)
  • die Wertelisten für alle Variablen
  • die Bezeichner für jeden einzelnen Wert aus der Werteliste in verschiedenen Landessprachen
  • Gültigkeitsregeln für die Variablenwerte
  • Mouse-over-Hilfetexte in verschiedenen Landessprachen

Dafür müsste es eine kleine Benutzerschnittstelle geben, mit der man die DB füllen und pflegen kann,
und mit dem man die DB als Tabelle anzeigen kann.

Diese DB soll zentral für ganz OSM erstellt und gepflegt werden.
Alle Editoren, z.B. das geplante Plugin “benutzerfreundlicher JOSM-Editor”, und alle **Anwendungen **sollen die DB direkt nutzen können.

Gruss, Markus

Dieses Wochenende (3.-5. April) findet ein Entwicklertreffen in Nürnberg statt.

Themen sind:

  • benutzerfreundlicher JOSM-Editor
  • Taggingschema Seezeichen
  • Taggingschema Hafen
  • Rendering Seekarte
  • Datenbank für Variablen und Regeln
  • Datenimport

Wenn Du mitarbeiten magst bist Du herzlich eingeladen!

Melde Dich telefonisch bei mir: 09155-1715

Gruss, Markus

Ich habe eine Wiki-Seite de:Seamap-Editor angelegt.

Und ein Ticket in JOSM

Gruss, Markus

Hallo Markus,

bei Seekarten gibt es noch ein weiteres Problem. Änderungen werden wochenweise mitgeteilt und müssen in die amtlichen Seekarten von Hand nachgetragen werden. Änderungen in OSM würden aber nur auffallen, wenn jemand mal wieder an der “Tonne” vorbei kommt oder durch Zufall mit seinem Boot auf dem neuen Wrack aufsetzt, welches noch nicht kartographiert wurde aber in den Amtlichen Nachrichten schon verfügbar war. Als Bootsführer würde ich mich ehrlich gesagt ungern auf so eine Karte verlassen. Um aber zu sehen, wo Fahrwasser oder Sperrbereich verlaufen (also als reine Informationsquelle und nicht zur Realnavigation) würde ich die Idee auch begrüßen und finde sie interessant. Macht aber sicherlich viel Arbeit. Eine bessere Bedienerfreundlichkeit in JOSM ist sowieso immer willkommen (wobei es von Version zu Version besser wird :wink: ).

Gruss Bernd

Hallo Bernd,

:slight_smile: Vielleicht wird das Plugin ja ein Schritt in diese Richtung…

Die anderen Themen die Du angesprochen hast sind wichtig.
(Sie sind uns bewusst und wir haben auch erste Lösungen dafür).

Dafür solltest Du aber einen neuen Thread aufmachen, sonst kommen wir hier durcheinander.

Gruss, Markus