Am Samstag, 20. Februar 2010 10:51:51 schrieb Christian Wagner: > Am Donnerstag, den 18.02.2010, 22:32 +0100 schrieb Falk Zscheile: > > > > > > Am 18. Februar 2010 21:51 schrieb Christian Wagner > > <wagnerschrist...@gmail.com>: > > Am Donnerstag, den 18.02.2010, 00:27 +0100 schrieb Ulf > > Lamping: > > > > > Kennst du das JOSM TOMS Plugin? Das macht genau das, > > zumindest für die > > > Bojen (wenn ich das als Landratte so richtig verstanden > > habe). > > > > Ja kenne ich, und das Teil macht IMHO den gleichen Fehler der > > hier immer > > wieder zu Verwirrungen führt. Es versucht die Seezeichen in > > eine OSM- > > untypisches Raster zu pressen. Da werden z. B. Topzeichen > > feste > > Tonnenfarben zugeordnet (Einzelgefahrzeichen etc.). Irgendwo > > auf der > > Welt gibt's dann ein Einzelgefahrenzeichen mit gelber > > Tonnenfarbe oder > > eine Kardinaltonne hat eine Lichtsequenz welche ich im Editor > > eben nicht > > auswählen kann und dann geht der Zinnober wieder von vorne > > los. Warum > > nicht mappen was wirklich da ist? > > > > Nein, dass siehst Du falsch. Die Topzeichen und Tonnenfarbe stehen > > immer in einem festen Zusammenhang. So kannst Du auf die Tonnenfarbe > > schließen, wenn du die Farbe selbst nicht erkennen kannst oder die > > Farbe schon längst verschwunden ist. Bei Kardinaltonnen zeigen die > > Spitzen des Topzeichens immer in Richtung der schwarzen Bauchbinde der > > gelben Tonne. Gleicher Zusammenhang gilt für die Kennung > > (Lichtsequenzen) und Farbgebung bei den Kardinaltonnen.[1] Das ist > > überall gleich und dient der Sicherheit der Schifffahrt. So gesehen > > macht es der Editor dem Mapper ohne Kenntnisse der Seezeichen das > > Eintragen sogar einfacher, wenn er dort, wo solche festen Beziehungen > > bestehen, diese vorgibt. Das ist auch auf der ganzen Welt das gleiche, > > damit der deutsche Kapitän auch in Hong Kong sicher navigieren kann. > > Man hat sich im Rahmen der UN auf die Vereinheitlichung geeinigt. > > Nationale Ergänzungen sind zulässig, jedoch keine Abweichungen vom > > festgelegten Standard. > > Wenn das System wirklich so zwingend ist dann reicht als Tag ja > eigentlich cardianl_south? Eigentlich impliziert das Zeichen ja dann > schon alles oder? > Was aber wenn irgendwelche Bojenleger aus Maputo das dann eben doch > anders gemacht haben? Nun ja, vielleicht reicht es für diesen > (sicherlich seltnen) Spezialfall dann auch händisch das abweichende > Feuer in die Datenbank einzutragen. Die Editoren sind nur dazu dar, um gewisse Standards zu regulieren, alles andere kann mit josm direkt eingegeben werden. Natuerlich sollen die Standards so flexibel wie moeglich sein, ist jedoch nicht ganz einfach zu implementieren, daher sind Anregungen gerne gesehen > > > > > > > > Wozu die ganzen Regeln wenn sie mit Sicherheit nicht weltweit > > haargenau > > eingehalten werden. Das S57 System ist eh modular aufgebaut, > > genau wie > > das OSM Taggingschema. So ist das Licht des Leuchturms vom > > Turm an sich > > völlig unabhängig. Warum also im Editor künstliche > > Zusammenhänge > > aufbauen? > > > > Bei Leuchttürmen und Lateraltonnen( Steuerbordtonnen -- grün, spitzes > > Topzeichen; Backbordtonnen -- rot, rechteckiges Topzeichen; gilt nur > > für Betonnungsregion A[2]), trifft das zu, nicht aber auf das von Dir > > angeführte Beispiel der Kardinaltonnen. Mit anderen Worten, die > > Zusammenhänge sind nicht künstlich sondern zwingend, wenn vorhanden. > > DIe regeln sind fuer Otto-Normalverbraucher, alle anderen koennen sich gerne der sonstigen josm-Mitteln bedienen.
> Das mit dem festen Topzeichen im Lateralsystem ist mir bekannt. Hier > wäre aber gerade wegen der IALA A und B Regionen eine weitere > Aufspaltung der Tags IMHO besser geeignet. Warum im Editor Steuer- und > Backbord extra mit Farben verknüpfen? Das hat zur Folge das der Editor > wie aktuell der Fall eben nur für eine IALA- Region funktioniert. Wenn > ich die Farbe frei wählen kann dann muß ich als Mapper erst mal gar nix > über IALAs wissen, Sondern kann Otto Normalmapper eben die rote Tonne > von der Butterfahrt einfach eintragen. Wie schon gesagt, die Daten > müssen am Anfang ja nicht perfekt sein. Der nächste OSeaM Segler kommt > dann nächstes Jahr dran vorbei, freut sich daß da schon rudimentäre > Daten da sind und kann dann was verbessern. > > > Auch der Renderer könnte diese Modularität und Unabhängigkeit > > der einzelnen Tags voneinander berücksichtigen und eben das > > Licht und > > den Leuchtturm bzw. die Tonne unabhängig voneinander zeichnen. > > So hat > > man dann auch eine Möglichkeit mit den unvollständig erfassten > > Seezeichen, welche in OSM nun mal auch erfasst werden, > > umzugehen. Wenn > > ich tagsüber an einer Boje vorbeifahre, so kann ich nun mal > > nicht wissen > > wie die Lichtcharakteristik aussieht. Wenn ich Nachts > > vorbeikomme so > > erkenne ich die Lichter, kann aber eventuell nicht die Farbe > > oder Form > > der Tonne sehen. > > > > Wenn Du an einer Kardinaltonne vorbei kommst, dann kannst du das sehr > > wohl -- siehe oben. Die Frage ist nur, ob die Tonne tatsächlich > > befeuert ist (was man bei Tage nicht erkennen kann), nicht aber welche > > Kennung sie hat. Für Tonnen im Lateralsystem, hat auch eine grüne > > Tonne immer eine grüne Befeuerung und eine rote Tonne eine rote > > Befeuerung. Nur die Kennung der einzelnen Tonne ist hier nicht > > vorgegeben, damit man die Tonnen im Fahrwasser bei Nacht auch schön > > anhand ihrer Befeuerung unterscheiden und in der Seekarte wieder > > finden kann. IALAB wird sicherlich mittelfristig in toms integriert werden. Einzelne Besonderheiten muessen mit den josm-Mitteln eingegeben werden. Bei Besonderheiten kann ein Editor nur bedingt helfen. > > Verstehe, Danke für die Aufklärung. > > > Am Freitag, den 19.02.2010, 12:41 +0100 schrieb Olaf Hannemann: > > Hallo Christian, > > > > [...] > > > > > Es versucht die Seezeichen in eine OSM- > > > untypisches Raster zu pressen. Da werden z. B. Topzeichen feste > > > Tonnenfarben zugeordnet (Einzelgefahrzeichen etc.). Irgendwo auf der > > > Welt gibt's dann ein Einzelgefahrenzeichen mit gelber Tonnenfarbe > > oder > > > eine Kardinaltonne hat eine Lichtsequenz welche ich im Editor eben > > nicht > > > auswählen kann und dann geht der Zinnober wieder von vorne los. > > Warum > > > nicht mappen was wirklich da ist? > > > > Doch, die Farben sind fest vorgeben, siehe die Antwort von Falk. Die > > Farbe beschreibt die Bedeutung der Tonne. Wenn du an eine Ampel mit > > grünen, blauen und weißen Licht kommen würdest, hätte diese ja auch > > ihre eigentliche Funktion verloren. Du weist nicht wie du dich bei > > blauen Licht verhalten sollst.Das Topzeichen verdeutlicht durch seine > > Form noch einmal die Funktion der Tonne. So wie bei einer Ampel das > > rote Licht immer oben ist. Dies ist sehr hilfreich, wenn du z.B. im > > Dichten Nebel die Farbe nicht erkennen kannst. > > OK, ist schon klar, daß die Tonnen in Ihrer Grundform schon sehr > vorgegeben sind. Aber ist das wirklich immer so? Siehe IALA B, siehe > irgendwelche Tonnen in St. Petersburg die aus irgendwelchen Kanistern > gebastelt sind etc. Gerade da kann OSM seine Stärken doch ausspielen. > Wie wäre es mit einem Symbol für Freaktonnen. Auch ein Symbol für Tonnen > welche einfach sehr unvollständig getaggt sind wäre IMHO sinnvoll (also > Tonnen welche nur seamark=buoy haben). So ist der Butterfahrtmapper eben > nicht versucht Tags zu erfinden, nur daß er seine Tonne dann auch > dargestellt bekommt. Auch solche Kartensymbole sind dem nächsten Segler > hilfreich und besser als nix. Ziel ist es natürlich diese Platzhalter > symbole irgendwann durch vollständig getaggte Seezeichen zu ersetzen. > > > > > Auch der Renderer könnte diese Modularität und Unabhängigkeit > > > der einzelnen Tags voneinander berücksichtigen und eben das Licht > > und > > > den Leuchtturm bzw. die Tonne unabhängig voneinander zeichnen. So > > hat > > > man dann auch eine Möglichkeit mit den unvollständig erfassten > > > Seezeichen, welche in OSM nun mal auch erfasst werden, umzugehen. > > > > Mein Renderer (OpenSeaMap) tut doch genau dieses. Er stellt die Teile > > einer > > Tonne (Tonnenkörper, Topzeichen, Licht, Nebelhorn) einzeln dar. > > Erstellst du einen Knoten mit z.B. seamark:type = buoy_safe_water wird > > eine > > Tonne für das Sichere Fahrwasser dargestellt. Fügst du jetzt noch ein > > seamark:topmark:shape=sphere hinzu wird zusätzlich ein Topzeichen > > angezeigt. > > Fügst du ein seamark:light:colour=white hinzu wird zusätzlich das > > Symbol für das > > Licht angezeigt. Alle weiteren Angaben sind optional und dienen der > > weiteren > > Beschreibung des Seezeichens. > > Siehe oben- ab wann wird dein Renderer denn etwas darstellen? Schon bei > seamark=buoy oder braucht der Renderer mehr Infos? > Ein Restaurant wird ja auch dargestellt wenn es nur ein > amenity=restaurant hat. Der Name und die Art der Küche ist erstmal > wurscht. > > > > > > Ich denke ja auch nicht dass ein grafischer Editor nicht irgendwann > > von > > > Vorteil ist, aber warum nicht eine Zwischenlösung mit Vorlagen, > > damit > > > kann man wie auch sonst in OSM eine einigermaßen stabile Datenbasis > > > aufbauen und gleichzeitig bleibt man flexibel wenn die reale Welt > > nun > > > mal nicht den Normen entspricht. Das wäre rasch auf alle möglichen > > > Seezeichen ausweitbar. Ich warte z. B. immer noch eine Möglichkeit > > für > > > Leuchttürme, Baken und was es sonst noch so alles gibt. > > > > Der Online-Editor kann bereits Baken eintragen. Siehe "Bauart des > > Zeichens" die > > Einträge Spiere und Pricke. Leuchttürme brauchen noch ein wenig. > > Diese ganzen deutschen Bezeichnungen sind wirklich zum mäusemelken. Kann > man das nicht einfach english machen ;). > Ernsthaft: Sind die Spieren dann auch der richtige tag um die > Lateralfeuer an den Hafeneingängen zu taggen- also Leuchtfeuer welche an > Land stehen? > > > Ich habe mich mit den Vorlagen für den JOSM noch nicht weiter > > beschäftigt, mir > > wurde aber gesagt, dass unsere Syntax zu komplex sei, um das Proplem > > mit > > Vorlagen zu lösen. Daher hat der Werner angefangen das JOSM-Plugin zu > > entwickeln. > > Nun ja, habe gesehen das es wohl eine Vorlage für freie Tonne tags gibt. > das müsste man halt etwas ummodeln und ggf. verfeinern. > > Freue mich auf Rückmeldung deinerseits, > > Christian > > > > _______________________________________________ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-de > _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
