[FT-Talk] Tonnen in Amerika

[Matthias Julius]

"Jan Jesse" <jan at jesse.de> writes:

> Hallo Matthias,
>
>> werden:
>> > | : Trennung von erlaubten Werten (green|red|yellow)
>> > z.B. buoy:color=green|red|yellow
>> > * : Wert unbestimmt (jede Eingabe erlaubt)
>> > z.B name=*
>> > Das erklärt sich glaub ich selbst.
>>  Was hier noch fehlt, ist die Moeglichkeit, eine Checkbox
>> vorzugeben. Evtl. koennte der Preset-Generator yes|no in eine
>> Checkbox verwandeln. Das haette den Vorteil, dass man das schon
>> jetzt verwenden koennte.
>
> Die yes|no Funktion ist glaub ich in JOSM schon eingebaut, kann also
> verwendet werden. Wir haben da ein Symbol "Testleuchte", da kannst Du
> ja mal probieren :-)

Ja, JOSM kennt ein <check> element fuer seine Presets. Aber kann FT
sowas generieren? Ich hatte zumindest nicht den Eindruck. Daher war
mein Vorschlag, dass der FT-Preset-Generator z.B. aus
fog_signal=yes|no sowas macht wie:

<check key="light" default="off" delete_if_empty="true" />

>
>> Auch fehlt natuerlich die Moeglichkeit, das Ganze mehrsprachig zu
>> machen. Die Presets unterstuetzen das ja.  Aber das ist eine andere
>> Geschichte.
>
> Die Mehrsprachigkeit ist ein Problem. Wir diskutieren das gerade, aber
> wir hatten bis letzte Woche einfach zu viele Baustellen. Außerdem
> lohnt sich das warten, denn neuerdings passiert ja sehr viel, und wir
> bekommen ein Feedback, daß m.E. mehr oder weniger sagt: Die FreieTonne
> ist in OpenStreetMap integriert, und ab jetzt passiert alles im
> JOSM. Das würde die Frage der Mehrsprachigkeit auf die Presets
> reduzieren, und hier wären wir evtl. mit viel weniger Aufwand
> dabei. Lassen wir das vielleicht noch 4 Wochen reifen :-)

Sicher, es eilt ja nicht. Ich bezog mich auch nur auf die
JOSM-Presets. Es waere natuerlich auch schoen, wenn die Webseite
mehrsprachig waere, aber das ist noch eine ganz ander Baustelle.

Man muesste eine Syntax entwickeln, die der Server dann
in entsprechend lokalisierte Presets umsetzt. Vielleicht sowas wie

buoy(Buoy;de:Tonne)=lateral_port(lateral port;de:Lateral Backbord)|lateral_starboard(lateral starboard;de:Lateral Steuerbord)

wird zu

<combo key="buoy"
       text="Buoy" de.text="Tonne"
       values="lateral_port,lateral_starboard"
       display_values="lateral port,lateral starboad"
       de.display_values="Lateral Backbord,Lateral Steuerbord"
       default="" delete_if_empty="true" />

> Ich präferiere die Icons, weil unser Ansatz eben nicht OSM war und
> ist. OSM ist Methode. Für mich ist die Darstellung der Daten auf
> verschiedenen Endgeräten interessant. Und hier benötigen wir am Ende
> Icons, die auf verschiedenen Geräten (Garmin, Tomtom, Navigon ...)
> darstellbar sein sollen. Dafür brauchen wir einfache technische
> Lösungen. Z.B. sind die JOSM-Presets ja nicht von allein in der Lage,
> Icons zusammen zu bauen...

Mit den JOSM-Styles habe ich mich noch nicht befasst.

Der Server koennte ja die Symbole fuer solche Geraete auch
zusammenbasteln. Mir geht es vorrangig um die Dateneingabe und die
Verwaltung der Symbole. Tonnen koennen z.B. Topzeichen, Lichter,
Nebelsignale sowie Radar-Reflektoren haben. Das ergibt also 16
Kombinationen fuer jede Art von Tonne (wenn man nicht bestimmte
Kombinationen ausschliessen will). Wir haben drei verschiedene Tonnen
und Baken in den Menues fuer Lateralmarken. Das macht dann 96
Eintraege. Und das kann man natuerlich niemanden zumuten.

Man koennte das natuerlich auch durch Untermenues weiter
untergliedern, aber viel besser wird das damit auch nicht. Ich halte
es fuer deutlich anwenderfreundlicher, wenn man bsw. nur eine rote
Tonne im Menue auswaehlt und dann ankreuzen kann, welche Zusaetze
vorhanden sind.

>
> Bleiben wir bei Deinen Spezialtonnen an den Niagara-Fällen. Sie sind
> nicht gelb, ich weiß, Du hast ja mit dem Fuß aufgestampft. Allein
> aufgrund der Tatsache, daß Garmin-GPI's nicht mehr als 80 Icons
> darstellen können (hab ich mühsam ausgetestet, ich hab alles gegeben,
> aber es sind nur 80), hab ich also in der Garmin-Ausgabe unserer Daten
> jetzt einen Filter. Und siehe, die Tonnen sind doch gelb :-(
>
> Ich will einfach sagen, daß wir ohnehin nicht unendlich viele Symbole
> ausgeben können. Die Navi-Hersteller begrenzen das.

Das ist natuerlich ein Problem. Aber es ist weitestgehend unabhaengig
von obigem. Wenn die Geraete mehrere Symbole fuer das selbe Objekt
ausgeben koennten, wuerde das ja die Anzahl der verschiedenen Symbole
nur reduzieren.

>
> Trotzdem auch hier: Jeder Ansatz sollte neu überdacht werden, sobald
> er technisch umgesetzt ist. Wo bleibt sonst die Entwicklung. Und
> schließlich ginge es hier ja "nur" um das Taggingschema, daß eben
> genau jener Logik unterliegt, und evtl. als Teilprojekt eeiner
> Revision unterzogen werden könnte. Das Prinzip:
> Pflicht-Erkennungstags, Optionstags (JOSM) und fremde Erkennungstags
> würde ich aber unbedingt beibehalten. Mikes genialster Streich der
> letzten Wochen :-)

Das finde ich auch gut geloest.

Was ich gerne haette ist eine Klasse von Zusatzsymbolen, die dann bei
der Definition der Grundsymbole zur Auswahl stehen. Also wenn ein
Zusatzsymbol "Licht" definiert ist, kann man fuer das Grundsymbol
"Tonne" ankreuzen, ob ein Licht damit kombiniert werden kann oder
nicht. Und wenn ja, kann der Server direkt die kombinierten Symbole
erzeugen.

>
> Das bringt uns zu der prekären Frage nach dem Prgrammcode. Derzeit ist
> der obwohl gewollt, de facto nicht frei. Einfach weil nur Mike und ich
> Zugriff haben. Das hat was damit zu tun, daß wir alles, was OSM
> betrifft, ja erst in diesem Jahr gebaut haben (seit Weihnachten
> :-)). Das wäre gar nicht möglich gewesen, wenn wir allen Wünschen
> gefolgt wären ...
>
> Fest steht, daß die Entwicklung mehr Leute braucht, und wenn sich
> jemand beteiligen will, ist er willkommen. Das soll aber nicht in die
> Geschichte mit den vielen Köchen ausarten, und das muß vor allem mit
> Mike abgestimmt werden. Aber prinzipiell bin ich sehr dafür, daß sich
> auch andere an der Entwicklung beteiligen.

Ihr muesst ja nicht gleich jedem Schreibrechte einraeumen. Aber wenn
Ihr den Code zur Verfuegung stellt, koennen sich den andere Leute
angucken und Euch bei Bedarf einen Patch schicken. Dann koennt Ihr
Euch immer noch ueberlegen, ob Ihr den ignorieren wollt oder nicht.

>
> Besprechen wir das also mit Mike, wenn er wieder gesund ist, und
> versuchen dann, einen geordneten Prozeß zu entwickeln.

Gerne.

>
> Momentan genieße ich die Atempause :-)

Ich wuensche erholsame Tage.

Disclaimer: Es liegt mir natuerlich fern, hier hereinzuplautzen und
Euch vorschreiben zu wollen, wie Ihr was tun sollt. Das alles sind nur
Vorschlaege, und es steht Euch selbstverstaendlich frei, die fuer gut
zu befinden oder nicht. Es sind eben Dinge, von denen ich denke, dass
sie das Leben von Anwendern einfacher machen, aber das muss sich ja
nicht mit Eurer Meinung decken.

Gruesse aus Michigan,

Matthias