Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
Hallo Um es nochmals zu betonen: Bei der Datenerfassung mit OSM geht es nicht darum Pläne (bzw. deren Inhalte) zu erfassen, sondern das was man draussen sieht und mit GPS und Kamera festhalten kann. Eine S-Bahn-Linie ist natürlich immer auch beschriftet typischerweise mit einer Zahlen-/Buchstaben-Kombination und einer gut von anderen S-Bahnlinien unterscheidbaren Hintergrundfarbe. Primär wird aber der Name erfasst, z.B. S5, oder S-7. Dieses Attribut (Tag) kann man dann auf verschieden Arten nutzen - und letztlich auch darstellen - von mir aus mit den offiziellen Farben des Bahnbetreibers. Das ist dann aber sog. Styling-Information, die eher zum Kartenprodukt gehört. Dieses Wiki hier beschreibt aber meiner Meinung nach nicht Kartenprodukte, sondern dokumentiert primär OSM-Objekte der OSM-Datenbank. LG, Stefan Am 2. Juni 2013 00:22 schrieb Tobias Conradi mail.2...@tobiasconradi.com: On Sat, Jun 1, 2013 at 8:36 PM, Martin Koppenhoefer dieterdre...@gmail.com wrote: mein Punkt war, wenn man sich schon die Mühe macht, und nachforscht bzw. wie hier eine Anfrage beim Betreiber stellt (was ich auf keinen Fall erwarten würde), dann kann man das Ergebnis auch so in OSM eintragen, und nicht nur das in ein anderes Farbsystem gewandelte, insbesondere wenn die Konversion irreversibel ist. Wenn colour nicht der tag ist, dann vielleicht official_colour oder so. OK! :-) -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com ___ 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
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
Am 29.05.2013 16:17, schrieb Tobias Conradi: Den Teil über RGB kann man ruhigen Gewissens aus dem Wiki streichen, hat mit der Realität nichts zu tun, siehe http://taginfo.openstreetmap.org/keys/colour#values Den Teil über RGB (hex triplet) kann man ruhigen Gewissens nicht aus dem Wiki streichen, denn in der Realität werden RGB-Werte genutzt, siehe http://taginfo.openstreetmap.org/keys/colour#values z.B.: #79b51d count: 450 Man beachte, dass die Top acht Werte deutlich mehr als 80% ausmachen und alle textuelle Argumente haben. Bittte etwas vorsichtiger mit halbgaren Argumenten: das Beispiel oben sind mal gerade 0,5% der Tags (und das ist schon einer der prozentual größten Tags mit RGB-Angabe)... Just my 2 cents, Michael. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
2013/6/1 Michael Kugelmann michaelk_...@gmx.de: Am 29.05.2013 16:17, schrieb Tobias Conradi: Den Teil über RGB kann man ruhigen Gewissens aus dem Wiki streichen, hat mit der Realität nichts zu tun, siehe http://taginfo.openstreetmap.org/keys/colour#values Den Teil über RGB (hex triplet) kann man ruhigen Gewissens nicht aus dem Wiki streichen, denn in der Realität werden RGB-Werte genutzt, siehe http://taginfo.openstreetmap.org/keys/colour#values z.B.: #79b51d count: 450 Man beachte, dass die Top acht Werte deutlich mehr als 80% ausmachen und alle textuelle Argumente haben. Das braucht man nicht beachten. Es ist irrelevant. Es genügt ein einziger Wert um die Behauptung hat mit der Realität nichts zu tun, siehe http://taginfo.openstreetmap.org/keys/colour#values; zu widerlegen. Bittte etwas vorsichtiger mit halbgaren Argumenten: Meinst Du Deine Argumentation ist zumindest halbgar? das Beispiel oben sind mal gerade 0,5% der Tags (und das ist schon einer der prozentual größten Tags mit RGB-Angabe)... Bei den 6-stelligen Hex triplets gibt es 16^6 = 16777216 Permutationen http://de.wikipedia.org/wiki/Permutation 1/ 16777216 1/200 = 0,5%. Wenn ein Wert mit 0.5% Anteil an der Gesamtmenge der Tags auftritt, dann ist dies 16777216/200 mal so oft wie bei Gleichverteilung. Analogie: Nach der 0,5%-kann-man-Streichen-Logik, ergibt sich, dass in Deutschland keine Bielefelder leben, da 327199 / 8000 = 0.0040899875 0.5%. Dies gilt dann auch für Germering, und für die Teilmenge Michael Kugelmann (MichaelK). Zahlen aus: http://de.wikipedia.org/wiki/Bielefeld https://www.google.com/search?q=327199+%2F+8000 Mit der angeführten Grenze (Top-tags alleine haben schon mehr als 80%), kann man Bewohner ganzer Bundesländer oder eine 20% Minderheit seiner Wahl mit streichen, hat mit der Realität nichts zu tun behandeln. -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
On 01/giu/2013, at 18:36, Tobias Conradi mail.2...@tobiasconradi.com wrote: Bei den 6-stelligen Hex triplets gibt es 16^6 = 16777216 Permutationen http://de.wikipedia.org/wiki/Permutation 1/ 16777216 1/200 = 0,5%. mein Punkt war, wenn man sich schon die Mühe macht, und nachforscht bzw. wie hier eine Anfrage beim Betreiber stellt (was ich auf keinen Fall erwarten würde), dann kann man das Ergebnis auch so in OSM eintragen, und nicht nur das in ein anderes Farbsystem gewandelte, insbesondere wenn die Konversion irreversibel ist. Wenn colour nicht der tag ist, dann vielleicht official_colour oder so. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
Hallo, vielleich bekommen wir die Kuh ein Stück näher ans Ufer, wenn der Key colour aufgesplittet wird: colour:rgb:text=pinguinrosa colour:rgb:codecs=http://wiki.openstreetmap.de/colour_rgb_codecs (Beispiel) Auf der Seite steht dann eine Definition und ein entsprechender Code für die Farben. Farben, die dort (noch) nicht definiert sind, können direkt angegeben werden: colour:rgb:code=0x403020 Wenn jemand den Code nachgetragen hat, kann er ggf. das tag entsprechend anpassen Ebenso andere Farbmodelle colour:ral:text=schokolandenkeks_braun_05 colour:ral:codecs=http://wiki.openstreetmap.de/colour_ral_codecs bzw: colour:ral:code=0x2208e3ßarhva0ß93r Auf den entsprechenden Codecs (nenn ich jetzt mal so) Seiten im Wiki stehen dann die Wertepaare im Idealfall so, dass man die Seite runterkopieren und in eine lokale Datenbank einfügen kann: schokoladenkeks_braun_05 = 0xafdjih4jnga09ujaöäjk schokoladenkeks_braun_06 = 0x094r5nklöäa0f98ga Wer später noch was dazwischen fügen will, kann dann immer noch schokoladenkeks_braun_055 nehmen. Vielleicht lässt man auch immer 100 Nummern Platz für spätere Ergänzungen. Wenn jemand mit einem Farbnamen so gar nicht umgehen will, ergänzt er die Tabelle eben um einen weiteren Namen mit gleicher Farbe. Das ist zwar eigentlich überflüssig, vermeidet aber den OSM-üblichen Streit um tags. Wenn die Tabelle geladen werden kann, ist es der Anwendung egal. Wir haben dann ein eigenes Farbschema, dass dem Mapper in der DB zumindest eine Idee liefert, um was für eine Farbe es sich handeln könnte und gleichzeitig trotzdem einen technisch verwertbaren Farbwert. Wenn es offizielle Farbnamen gibt, kann man sie ja in die Tabelle eintragen, falls das nicht irgendwo verboten wird. Wenn es eine offizielle Quelle für die Farbauswahl gibt: colour:ral:source = www.firmaxx.de/farbverwaltung/public Damit lasen sich mehrere Farbschemen unabhängig voneinander verwalten, der Mapper versteht, um was es geht, der Anwender für das Web bekommt seine RGB-Farbe, der Drucker seine RAL-oder-was-auch-immer-Farbe, und niemand ist gezwungen, irgend etwas für das Eintragen umzurechnen. Es steht natürlich jedem Mapper frei, Farben einzutragen oder auch nicht oder nur in einem der Schemen. (Alle Angaben sind nur prinzipielle Beispiele, ich habe nichts nachgeschlagen). Eventuell könnte man das ganze dann auch noch in einer Vorlage für josm auswerten und z.B. für die Vorauswahl Blautöne RAL die im Wiki definierten Namen anbieten, ggf. vielleicht noch mit einem einigermaßen passenden Farbton aus Animation. Gruß, Wolfgang Am Donnerstag, den 30.05.2013, 15:55 +0200 schrieb Martin Koppenhöfer: Am 30.05.2013 um 15:05 schrieb Tobias Conradi mail.2...@tobiasconradi.com: Das ist das was bei der Konversion via ECI nocht fehlt. Wenn man aber nur RAL vorgibt, dann erhält man Werte wie hier zu sehen: http://anna.info/wiki/RAL_5017 irgendwelche Blautöne. RAL ist durchaus eindeutig definiert, es gibt da Farbfächer, Farbbibliotheken, Lacke, etc, m.E. sollte der Tag in osm in diesem Fall de:verkehrsblau oder traffic_blue oder RAL_5017 od. ähnlich sein (da das die festgelegte Farbe ist), dann kann sich der Auswerter selbst entscheiden, ob er das in irgendeinem Blau oder sonstwie darstellt, oder das richtige nimmt, vor allem wenn er vorhat, das zu drucken, weil auf Bildschirmen ist korrekte Farbwiedergabe sowieso nicht üblich bzw. möglich. RGB kommt mir nach wie vor aufgrund der Einschränkungen hinsichtlich der darstellbaren Farben nicht als glückliche Wahl vor, welches RGB ist dabei auch bisher noch gar nicht definiert... Gruß, Martin ___ 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
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
On Sat, Jun 1, 2013 at 8:36 PM, Martin Koppenhoefer dieterdre...@gmail.com wrote: mein Punkt war, wenn man sich schon die Mühe macht, und nachforscht bzw. wie hier eine Anfrage beim Betreiber stellt (was ich auf keinen Fall erwarten würde), dann kann man das Ergebnis auch so in OSM eintragen, und nicht nur das in ein anderes Farbsystem gewandelte, insbesondere wenn die Konversion irreversibel ist. Wenn colour nicht der tag ist, dann vielleicht official_colour oder so. OK! :-) -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
Am Donnerstag, den 30.05.2013, 07:49 +0200 schrieb RainerU: Am 30.05.2013 04:01, schrieb Tobias Conradi: 2013/5/29 RainerU ra...@sfr.fr: Letztendlich geht es dabei immer darum, eine mit einer Linie assoziierte Information in genau der Farbe darzustellen, die auch der Verkehrsbetrieb in seinen Veröffentlichungen benutzt. Mir fehlt noch der Anwendungsfall, wo das sinnvoll oder notwendig ist. Z.B. einen Stadtplan herausgeben, auf dem die U-Bahnlinien in der Linienfarbe dargestellt sind. Meine Frage ist: warum ist es sinnvoll/notwendig auf einem derartigen Plan die Linien genau in derselben Farbe darzustellen, wie das der Verkehrsbetrieb auf seinen eigenen Plänen macht? Weil im professionellen Druck die Farbe auf jedem Dokument gleich aussehen soll. Wenn man die Farbe schon hat, sollte man sie auch benutzen, und wenn der Plan einigermaßen vernünftig aussehen soll, muss es schon die genau richtige Farbe sein. Die Welt des Druckens ist _völlig_ anders als die des Web. Wer damit noch nichts zu tun hatte, kann sich das einfach nicht vorstellen. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
Am Donnerstag, den 30.05.2013, 01:08 +0200 schrieb Frederik Ramm: Hi, On 05/29/2013 03:26 PM, Wolfgang Hinsch wrote: Für andere dagegen ein echter Wenigerwert: Ich kann aus dem Kopf RGB-Werte ungefähr überprüfen, aber CYK aus dem Stehgreif nicht, und ehrlich gesagt: besser, da steht light red, oder yellow green und ich kann ungefähr sagen, dass das passt (und es sonst als Fehler markieren), als dass irgendein Mapper X eine Farbtabelle kennt, die er abtippen kann. Die stehen dann drin und wenn er sich vertippt hat, merkt das niemand - für die nächsten Jahre. -1 Das ist eine etwas seltsame Argumentation. Nur weil ich etwas nicht selbst aus dem Stand prüfen kann, darf es nicht in OSM eingetragen werden. Peter hat sich da vielleicht etwas ungeschickt ausgedrueckt. Aber im Grunde gilt schon, dass wir moechten, dass die Informationen in unserer Datenbank vor Ort ueberpruefbar sind. Das bedeutet vor allem, dass wir einer ist-Information Vorrang vor einer soll-Information einraeumen - wenn der Parkplatzbetreiber sagt, da sind 40 Stellplaetze, aber vor Ort sieht man nur 38, dann taggen wir die - denn die sind ueberpruefbar, die 40 sind es nicht. Wenn vor dem Parkplatz ein großes Schild steht Hier sind 40 Parkplätze werden vermutlich 98% der Mapper 40 Plätze taggen (besonders, wenn noch eine Null folgt ;) Wenn der Verkehrsbetrieb dem einen Mapper die Farbdefinitionen zur OSM-Veröffentlichung gibt, wird er sie dem anderen Mapper nicht vorenthalten. Insofern sind die Daten problemlos überprüfbar. Im Übrigen könnte man auch den gedruckten Plan zu Rate ziehen und mit einem Farbmessgerät die Farbe überprüfen. Wenn in Tokio ein Papierkorb gemappt wird, ist für mich in HH die Überprüfung wesentlich aufwändiger. Im Übrigen verstehe ich die Diskussion hier nicht im Mindesten. Wo ist das Problem, wenn ein Mapper eine Information, die wahr ist, die überprüft werden kann, und die er für relevant hält, einträgt? Es geht nicht darum, die Farben _NUR_, sondern _AUCH_ in der vom Herausgeber gewählten Form einzutragen. Wir sind doch nicht bei Wikipedia-de. Das gleiche wuerde auch zutreffen, wenn man die Linienfarbe einer OePNV-Linie taggt. Wie kann man die vor Ort pruefen? Entweder mit Augenschein (colour:red) oder vielleicht, indem man mit seinem Smartphone ein Foto eines Schildes macht und da dann einen Wert in beliebigem Farbmodell abliest. Dabei ergibt sich eine Mess-Unschaerfe, genau wie beim Aufzeichnen einer Position mit dem GPS - that's life. Wenn ein Mapper farbenblind ist (z.B. 10% der männlichen Bevölkerung ist rot/grün-blind) kann er das auch nicht prüfen. Und was für den einen noch orange ist, ist dem anderen orange-rot, dem nächsten rot-orange und dann kommt jemand mit orange-gelb oder rötliches ocker ... . Super und klar objektiv prüfbar. Was die BVG in ihrem Corporate-Identity-Dokument drinstehen hat, ist fuer uns von minderer Relevanz, und Unterschiede, die so klein sind, dass sie unterhalb der mit dem iPhone in der Daemmerung von schraeg unten fotografiert-Unschaerfe liegen, sind nicht wichtig, weil nicht pruefbar. Wer eine Karte mit offiziellen garantiert richtigen Farben machen will, der sollte sich eine offizielle Tabelle besorgen und dann aus OSM lediglich die Linienbezeichnungen entnehmen und mit der offiziellen Tabelle abgleichen. Dann fliegen sofort alle Briefkästen, Papierkörbe, Hundekottütenspender, Waldwege ... etc etc raus, denn die kann ich auch nicht einfach so prüfen, die sind im Luftbild nicht sichtbar. Eine theoretisch moegliche Vor-Ort-Pruefung reicht ja. Eine praktisch mögliche Nachfrage nicht?? Gruß, Wolfgang ps.: Wie überprüft Ihr eigentlich die Postleitzahlen vor Ort? Das sind nur von einer Privatfirma herausgegebene Ordnungsnummern. Da habe ich auch noch kein Schild gesehen. Ebenso Wahlkreise, etc etc. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
2013/5/30 Wolfgang Hinsch osm-lis...@ivkasogis.de: Am Donnerstag, den 30.05.2013, 07:49 +0200 schrieb RainerU: Meine Frage ist: warum ist es sinnvoll/notwendig auf einem derartigen Plan die Linien genau in derselben Farbe darzustellen, wie das der Verkehrsbetrieb auf seinen eigenen Plänen macht? Weil im professionellen Druck die Farbe auf jedem Dokument gleich aussehen soll. Wenn man die Farbe schon hat, sollte man sie auch benutzen, und wenn der Plan einigermaßen vernünftig aussehen soll, muss es schon die genau richtige Farbe sein. Die Welt des Druckens ist _völlig_ anders als die des Web. Wer damit noch nichts zu tun hatte, kann sich das einfach nicht vorstellen. Ich weiß nicht einmal, ob man eine Gleichheit mit VBB-Materialien, mit der von mir vorgeschlagenen Methode erreicht. Die Methode würde es jedoch erlauben vorherzusagen, was bei CMYK definierten Farben bei OSM auf RGB-Ebene überhaupt rauskommen soll. Der Methode fehlt allerdings noch eine Matchingtabelle, wie auf der Seite http://anna.info/wiki/ISO_Coated_v2_300%25_(ECI) zu sehen unterscheiden sich die RGB die auf der OSM-Berlin-Liste gepostet wurden, von denen mit codecrete bestimmten. Und ich sehe bei dem Rot einen Unterschied. Das ist das was bei der Konversion via ECI nocht fehlt. Wenn man aber nur RAL vorgibt, dann erhält man Werte wie hier zu sehen: http://anna.info/wiki/RAL_5017 irgendwelche Blautöne. Und wer nicht einmal RAL vorgibt, sondern blau, der erhält noch mehr. Wenn jemand nur irgendein Blau will, und mit Hextriplets, die ja laut http://wiki.openstreetmap.org/wiki/Key:colour erlaubt sind, umgehen kann, dann hat er dieses irgendein blau ja auch, wenn jemand anderes ein eindeutiges Hex triplet wählt. Mit codecrete berechnet, wäre der Wert für die S3 in Berlin 006FB3 und für die Regionalzüge die laut VBB CMYK 100 50 0 0 haben, wäre der Wert 0074B7. Und wenn ich eine Legende erstelle, vielleicht ausserhalb OSM, dann kann ich die auch mit 006FB3 erstellen und erhalte im Druck oder im Web jeweils genau die gleiche Farbe wie bei OSM-erzeugten Material. -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
Bei den Farben hat man mehrere Nutzungsmöglichkeiten bzw. auch Möglichkeiten der Genauigkeit. Ein Großteil der Farben als String kommen wahrscheinlich aus der Richtung Parkbänke (josm-Vorlage) und Fassadenfarbe. Bei beiden Richtungen ist es nicht sinnvoll, den genauen Farbton anzugeben. Selbst wenn man ihn aktuell mit einer Farbtafel genau bestimmt, ist es nach kurzer Zeit schon wieder einen Hauch dreckiger oder blasser geworden. In den Fällen reicht es dann auch aus zu sagen, die Fassade ist weiß oder hell gelb und das Dach ist rot. Bei den Linienplänen sieht die Sache schon anders aus. Hier gibt es so eine Verwitterung nicht, deshalb halte ich es hier auch für sinnvoll, dass man den exakten Wert in die DB einträgt. Ob den nun am Ende der Auswerter nutzt oder nicht, ist ja seine Sache. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
Am 30.05.2013 um 15:05 schrieb Tobias Conradi mail.2...@tobiasconradi.com: Das ist das was bei der Konversion via ECI nocht fehlt. Wenn man aber nur RAL vorgibt, dann erhält man Werte wie hier zu sehen: http://anna.info/wiki/RAL_5017 irgendwelche Blautöne. RAL ist durchaus eindeutig definiert, es gibt da Farbfächer, Farbbibliotheken, Lacke, etc, m.E. sollte der Tag in osm in diesem Fall de:verkehrsblau oder traffic_blue oder RAL_5017 od. ähnlich sein (da das die festgelegte Farbe ist), dann kann sich der Auswerter selbst entscheiden, ob er das in irgendeinem Blau oder sonstwie darstellt, oder das richtige nimmt, vor allem wenn er vorhat, das zu drucken, weil auf Bildschirmen ist korrekte Farbwiedergabe sowieso nicht üblich bzw. möglich. RGB kommt mir nach wie vor aufgrund der Einschränkungen hinsichtlich der darstellbaren Farben nicht als glückliche Wahl vor, welches RGB ist dabei auch bisher noch gar nicht definiert... Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
2013/5/30 Martin Koppenhöfer dieterdre...@gmail.com: RAL ist durchaus eindeutig definiert, es gibt da Farbfächer, Farbbibliotheken, Lacke, etc, m.E. sollte der Tag in osm in diesem Fall de:verkehrsblau oder traffic_blue oder RAL_5017 od. ähnlich sein (da das die festgelegte Farbe ist), Ist es laut VBB-Angabe und wie im Betreff der Email angegeben nicht. Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition dann kann sich der Auswerter selbst entscheiden, ob er das in irgendeinem Blau oder sonstwie darstellt, oder das richtige nimmt, vor allem wenn er vorhat, das zu drucken, weil auf Bildschirmen ist korrekte Farbwiedergabe sowieso nicht üblich bzw. möglich. Selbst wenn korrekt nicht möglich ist, kann man in OSM trotzdem durch ein eindeutiges CMYK-RGB-Mapping erzeugte Werte speichern. RGB kommt mir nach wie vor aufgrund der Einschränkungen hinsichtlich der darstellbaren Farben nicht als glückliche Wahl vor, http://wiki.openstreetmap.org/wiki/Key:colour lässt nichts anderes als RGB zu. Dies zu ändern geht über Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition und http://lists.openstreetmap.org/pipermail/talk-de/2013-May/102394.html hinaus. Das kann ja zusätzlich noch geändert werden. Meine Vorschlag bezieht sich nur auf ein Füllen der vorhandenen Variablen mit standardisierten Werten, die im definierten Wertebereich liegen. welches RGB ist dabei auch bisher noch gar nicht definiert... Doch: http://wiki.openstreetmap.org/wiki/Key:colour RGB color code linkt zu http://en.wikipedia.org/wiki/Web_colors Web colors have an unambiguous colorimetric definition, sRGB -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
Hi. Irgendwie finde ich diese Farbendiskussion hier ziemlich blödsinnig. Selbst wenn die Farben extrem ähnlich wären, aber nicht gleich, würde vermutlich Verkehrsblau für beide reichen. Ein Farbcode, der sich minimal unterscheidet, hilft auf keiner Karte weiter. Wozu bitte sollen wir Farben in OSM taggen? Einige meinten, gar nicht, denn geodaten sinds nicht. Ich denke, Farben für Linien sind nicht unbedingt schlecht, zumindest dann nicht, wenn die Farben eindeutig den Linien zugeordnet sind. Manchmal ist das ja nicht der Fall sondern die Linien werden nur je Plan farblich unterschieden. Wenn es also eine Zuordnung von Farben zu Linien gibt in der Realität, dann kann es z.B. für Nahverkehrskarten sinnvoll sein, diese Farben auch zu kennen und entsprechend nutzen zu können. Aber minimal unterschiedliche Farben kann kein Nutzer mehr unterscheiden. Wenn also unterschiedliche Farbsysteme genutzt werden, nur um diese minimalen Unterschiede zu erfassen, dann ist doch irgendwas falsch. Alleine die Farbwahrnehmung auf unterschiedlichen Displays, unterschiedlichen Ausdrucken, Ausdrucken, die in der Sonne gehangen haben für eine Weile, Ausdrucken unter unterschiedlicher Beleuchtung (Halogen gegen Glühbirne gegen LED gegen Sonnenlicht) ist stärker als die Abweichung durch verschiedene Farbsysteme. Für die Berliner Farbskala vermute ich, dass diese minimalen Unterschiede einfach daher kommen, dass unterschiedliche Unternehmen sie definieren, einmal die Bahn (Bahn-Regionalverkehr) und andererseits die BVG (S- und U-Bahn). Das müssen wir nicht unbedingt angleichen, aber ehrlich gesagt: wenn wir eine solche Tabelle nicht hätten, sondern nur 'nen (ausgedruckten) Liniennetzplan mit farblich eingezeichneten Linien, dann wäre es IMHO auch völlig legitim, die Farben einfach nach Augenmaß mit 'ner Farbpalette rauszufinden und den RGB-Hex-Wert anzugeben. Warum also komplizierter machen, nur weil irgendwer von euch über so 'ne Tabelle gestolpert ist? ...oder sehe ich irgendeine Anwendung der genau korrekten offiziellen Farbcodes nicht? in der Praxis wäre das völlig ausreichend. Gruß Peter Am 29.05.2013 05:04, schrieb Tobias Conradi: http://www.openstreetmap.org/browse/changeset/16152289 Tags: comment = Farben der Berliner U-Bahn an die offiziellen RAL Werte angepasst. created_by = JOSM/1.5 (5836 en) Mac OS X --- Durch das anscheinend benutzte Verfahren https://lists.openstreetmap.de/pipermail/berlin/2013-May/000607.html 1) Nimm RAL-Wert aus VBB PDF 2) Nimm RGB aus http://www.arraydesign.co.uk/resources/graphical/RAL%20colour%20profile.pdf werden Werte angeglichen, die in CMYK verschieden sind, z.B. RB74 CMYK 100 50 0 0 S3 CMYK 100 50 0 5 ist beides Verkehrsblau RAL 5017. Quelle: http://wiki.openstreetmap.org/w/images/a/a7/Linienfarben_SPNV.PDF Das PDF von arraydesign gibt für RAL 5017 CMYK 100 20 5 40 RGB 14 81 141 HEX #0E518D Dieser Werte ist mindestens seit 2013-05-16 für die S3 in Berlin online: http://www.openstreetmap.org/browse/relation/28314 http://www.openstreetmap.org/api/0.6/changeset/16152132/download http://www.codecrete.net/CMYK gibt für die eben genannten drei CMYK-Werte folgende RGB-Werte: #0074b7 #006fb3 #00658b ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
Hi, Am Wed, 29 May 2013 08:33:11 +0200 schrieb Peter Wendorff wendo...@uni-paderborn.de: ...oder sehe ich irgendeine Anwendung der genau korrekten offiziellen Farbcodes nicht? in der Praxis wäre das völlig ausreichend. Das sehe ich auch so. Die offiziellen Farben einer Buslinie, die mit colour getaggt werden sollen, haben nichts mit offiziell festgelegten Farbcodes für die Linienpläne zu tun. colour ist gemacht für Städte wie Jönköping. Dort sagt man im Alltag nehmen sie die Linie Rot. Dass das die Linie 1 ist, wissen die meisten vermutlich garnicht. Nur die aus der Stadt heraus führenden Busse werden dort im Alltag mit Nummern bezeichnet. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
Hallo, Am Mittwoch, den 29.05.2013, 08:33 +0200 schrieb Peter Wendorff: Hi. Irgendwie finde ich diese Farbendiskussion hier ziemlich blödsinnig. Selbst wenn die Farben extrem ähnlich wären, aber nicht gleich, würde vermutlich Verkehrsblau für beide reichen. Ein Farbcode, der sich minimal unterscheidet, hilft auf keiner Karte weiter. Wir machen nicht eine Karte, sondern eine Datenbank. [...] Warum also komplizierter machen, nur weil irgendwer von euch über so 'ne Tabelle gestolpert ist? ...oder sehe ich irgendeine Anwendung der genau korrekten offiziellen Farbcodes nicht? in der Praxis wäre das völlig ausreichend. Die Farben kommen dann ins Spiel, wenn ein Auswerter und die Druckindustrie aufeinander treffen. Der ist dann froh, einen Anhaltspunkt zu haben, um die Farben in das System umrechnen zu können, dass die Druckerei braucht. Du hast bestimmt schon bemerkt, dass eine Farbe auf jedem Bildschirm und jedem Drucker etwas anders aussieht. Normalerweise ist das ziemlich egal, aber für offizielle Drucke müssen die Farben schon genau passen. Ich meine, es ist sinnvoll, festgelegte Farben so einzutragen, wie sie definiert sind, wenn der Mapper die Information hat. Eine Übertragung in andere Systeme bleibt dem Auswerter überlassen. Letztlich bleibt es Entscheidung des Mappers, ob er die Farbcodes eintragen will. Wenn er es macht, ist das aber für einige ein echter Mehrwert. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
Am 29. Mai 2013 10:05 schrieb Wolfgang Hinsch osm-lis...@ivkasogis.de: Ich meine, es ist sinnvoll, festgelegte Farben so einzutragen, wie sie definiert sind, wenn der Mapper die Information hat. Eine Übertragung in andere Systeme bleibt dem Auswerter überlassen. +1 Letztlich bleibt es Entscheidung des Mappers, ob er die Farbcodes eintragen will. Wenn er es macht, ist das aber für einige ein echter Mehrwert. +1 Auch sind die Unterschiede nur zum Teil marginal, es kommt auf die Farbe an, manche Farben kann man gar nicht darstellen in bestimmten Farbräumen. Wenn z.B. gold als Farbe festgelegt ist, dann ist jede Umrechnung nach RGB unzureichend. Ich stimme aber auch z.T. mit Peter überein, wenn gold oder verkehrsblau festgelegt ist, dann sollte man das ruhig so (oder in der engl. Entsprechung) in den tag schreiben, ohne es in irgendein Farbcodierungssystem umzurechnen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
Am 29.05.2013 10:05, schrieb Wolfgang Hinsch: Hallo, Am Mittwoch, den 29.05.2013, 08:33 +0200 schrieb Peter Wendorff: Hi. Irgendwie finde ich diese Farbendiskussion hier ziemlich blödsinnig. Selbst wenn die Farben extrem ähnlich wären, aber nicht gleich, würde vermutlich Verkehrsblau für beide reichen. Ein Farbcode, der sich minimal unterscheidet, hilft auf keiner Karte weiter. Wir machen nicht eine Karte, sondern eine Datenbank. [...] Warum also komplizierter machen, nur weil irgendwer von euch über so 'ne Tabelle gestolpert ist? ...oder sehe ich irgendeine Anwendung der genau korrekten offiziellen Farbcodes nicht? in der Praxis wäre das völlig ausreichend. Die Farben kommen dann ins Spiel, wenn ein Auswerter und die Druckindustrie aufeinander treffen. Der ist dann froh, einen Anhaltspunkt zu haben, um die Farben in das System umrechnen zu können, dass die Druckerei braucht. Du hast bestimmt schon bemerkt, dass eine Farbe auf jedem Bildschirm und jedem Drucker etwas anders aussieht. Normalerweise ist das ziemlich egal, aber für offizielle Drucke müssen die Farben schon genau passen. Ja, das hab ich bemerkt (ich meine, ich hätte es sogar in meiner Mail so oder so ähnlich als Argument eben GEGEN genaue Farbdefinitionen gebraucht). Wenn das normalerweise egal ist, nur für offizielle Drucke der offiziellen Farben nicht - dann nimmt man für diese offiziellen Drucke auch offizielle Daten, also ist OSM normalerweise aus dem Spiel. Ich kann mir noch vorstellen, dass Linien in den offiziellen Linienfarben auf einer OSM-Karte eingezeichnet werden sollen, aber auch dann würde ich als Ausführender dafür eine offizielle Tabelle nehmen und die ref aus OSM heranziehen, nicht Farbwerte, die in OSM so getagged sind. Ausnahme: es ist nicht so wichtig - aber dann sind auch generische(re) Farbnamen oder geringe Abweichungen einfach zu verkraften. Ich meine, es ist sinnvoll, festgelegte Farben so einzutragen, wie sie definiert sind, wenn der Mapper die Information hat. Eine Übertragung in andere Systeme bleibt dem Auswerter überlassen. Letztlich bleibt es Entscheidung des Mappers, ob er die Farbcodes eintragen will. Wenn er es macht, ist das aber für einige ein echter Mehrwert. Für andere dagegen ein echter Wenigerwert: Ich kann aus dem Kopf RGB-Werte ungefähr überprüfen, aber CYK aus dem Stehgreif nicht, und ehrlich gesagt: besser, da steht light red, oder yellow green und ich kann ungefähr sagen, dass das passt (und es sonst als Fehler markieren), als dass irgendein Mapper X eine Farbtabelle kennt, die er abtippen kann. Die stehen dann drin und wenn er sich vertippt hat, merkt das niemand - für die nächsten Jahre. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
Am 29.05.2013 09:00, schrieb Wilhelm Spickermann: Hi, Am Wed, 29 May 2013 08:33:11 +0200 schrieb Peter Wendorff wendo...@uni-paderborn.de: ...oder sehe ich irgendeine Anwendung der genau korrekten offiziellen Farbcodes nicht? in der Praxis wäre das völlig ausreichend. Das sehe ich auch so. Die offiziellen Farben einer Buslinie, die mit colour getaggt werden sollen, haben nichts mit offiziell festgelegten Farbcodes für die Linienpläne zu tun. colour ist gemacht für Städte wie Jönköping. Dort sagt man im Alltag nehmen sie die Linie Rot. Dass das die Linie 1 ist, wissen die meisten vermutlich garnicht. Nur die aus der Stadt heraus führenden Busse werden dort im Alltag mit Nummern bezeichnet. Wobei das eben die rote Linie ist, und nicht die #ff0242-e Linie oder so'n Blödsinn, auch nicht die bordeaux-rote Linie oder die mit-leichtem-orangestich-rote Linie. Genaue Farbcodes dürften gegenüber einer sinnvoll eingeschränkten Tabelle keinen Mehrwert bieten (außer im offiziellen Bereich, siehe andere Mail in diesem Thread). Was also spricht gegen: - weiß - grau - schwarz - rot - gelb - grün - blau - orange - lila - rosa - braun vielleicht ergänzt jeweils um eine Variante mit hell- und dunkel. Das entspricht dann ungefähr den vordefinierten benannten Farben, die es auch in Web und so gibt. Wie gesagt: Offizielle Farbcodes schön und gut - aber da wird OSM vermutlich selten als Quelle genutzt, und für inoffizielle Farben sind Farbnamen sinnvoller. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
2013/5/29 Peter Wendorff wendo...@uni-paderborn.de: Selbst wenn die Farben extrem ähnlich wären, aber nicht gleich, würde vermutlich Verkehrsblau für beide reichen. Verkehrsblau ist kein erlaubter Wert im HTML/CSS (RGB)-Farbsystem. Ein Farbcode, der sich minimal unterscheidet, hilft auf keiner Karte weiter. Und daher der Vorschlag dafür zu sorgen, dass sich die Farbcodes nicht minimal unterscheiden: http://lists.openstreetmap.org/pipermail/talk-de/2013-May/102394.html [Talk-de] CMYK und RGB Farben - Standardisierung in OSM Tobias Conradi mail.2012 at tobiasconradi.com So Mai 26 15:23:00 UTC 2013 -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
2013/5/29 Wilhelm Spickermann o...@spickermann-d.de: Die offiziellen Farben einer Buslinie, die mit colour getaggt werden sollen, haben nichts mit offiziell festgelegten Farbcodes für die Linienpläne zu tun. Beweisführung? colour ist gemacht für Städte wie Jönköping. Dort sagt man im Alltag nehmen sie die Linie Rot. Dass das die Linie 1 ist, wissen die meisten vermutlich garnicht. Nur die aus der Stadt heraus führenden Busse werden dort im Alltag mit Nummern bezeichnet. Wo ist das definiert? Ich finde nur: http://wiki.openstreetmap.org/wiki/Key:colour The value should be: an RGB color code (hex triplet) -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
2013/5/29 Wolfgang Hinsch osm-lis...@ivkasogis.de: Warum also komplizierter machen, nur weil irgendwer von euch über so 'ne Tabelle gestolpert ist? ...oder sehe ich irgendeine Anwendung der genau korrekten offiziellen Farbcodes nicht? in der Praxis wäre das völlig ausreichend. Die Farben kommen dann ins Spiel, wenn ein Auswerter und die Druckindustrie aufeinander treffen. Sogar schon vorher, siehe: http://anna.info/wiki/RAL_5017 - ich sehe dort vier verschiedene Farbtöne. Du hast bestimmt schon bemerkt, dass eine Farbe auf jedem Bildschirm und jedem Drucker etwas anders aussieht. Normalerweise ist das ziemlich egal, aber für offizielle Drucke müssen die Farben schon genau passen. Ich habe hier eine Karte von einem Tangofestival vor mir, da hat das U-Symbol ein blau und alle Linien ein anderes blau. Ich meine, es ist sinnvoll, festgelegte Farben so einzutragen, wie sie definiert sind, wenn der Mapper die Information hat. Eine Übertragung in andere Systeme bleibt dem Auswerter überlassen. Kannst Du dann vielleicht die zum Thema Auswerter gestellten Fragen beantworten: http://lists.openstreetmap.org/pipermail/talk-de/2013-May/102425.html ? Letztlich bleibt es Entscheidung des Mappers, ob er die Farbcodes eintragen will. Wenn er es macht, ist das aber für einige ein echter Mehrwert. Was RGB-Werte betrifft, sehe ich für mich keinen Mehrwert, wenn diese nicht standardisiert eingetragen werden. Es kann sogar eher ein Nachteil sein, denn der Wert für das Blau der S3 in Berlin ist dreifach in http://www.openstreetmap.org/api/0.6/changeset/16152132/download gespeichert (tag k=colour v=#0E518D/ ) und könnte demzufolge, selbst bei Einhaltung aller OSM-Richtlinien, drei verschiedene Werte für die S3 annehmen, weil kein OSM-Konvertierungsstandard für die offiziellen VBB-CMYK-Farben existiert. -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
2013/5/29 Martin Koppenhoefer dieterdre...@gmail.com: Am 29. Mai 2013 10:05 schrieb Wolfgang Hinsch osm-lis...@ivkasogis.de: Ich meine, es ist sinnvoll, festgelegte Farben so einzutragen, wie sie definiert sind, wenn der Mapper die Information hat. Eine Übertragung in andere Systeme bleibt dem Auswerter überlassen. +1 -2 Die Fragen dazu sind nicht beanwortet http://lists.openstreetmap.org/pipermail/talk-de/2013-May/102425.html http://wiki.openstreetmap.org/wiki/Key:colour The value should be: an RGB color code (hex triplet) Auch sind die Unterschiede nur zum Teil marginal, es kommt auf die Farbe an, manche Farben kann man gar nicht darstellen in bestimmten Farbräumen. Wenn z.B. gold als Farbe festgelegt ist, dann ist jede Umrechnung nach RGB unzureichend. Ich stimme aber auch z.T. mit Peter überein, wenn gold oder verkehrsblau festgelegt ist, dann sollte man das ruhig so (oder in der engl. Entsprechung) in den tag schreiben, ohne es in irgendein Farbcodierungssystem umzurechnen. Erinnerung an Betreff dieses Threads: Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition Verkehrsblau und Gold sind keine offiziellen CMYK-Definitionen. http://de.wikipedia.org/wiki/CMYK-Farbmodell -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
Am Mittwoch, den 29.05.2013, 12:52 +0200 schrieb Peter Wendorff: Am 29.05.2013 10:05, schrieb Wolfgang Hinsch: Hallo, Wenn das normalerweise egal ist, nur für offizielle Drucke der offiziellen Farben nicht - dann nimmt man für diese offiziellen Drucke auch offizielle Daten, also ist OSM normalerweise aus dem Spiel. Und für eine Übersicht klappert man xx Unternehmen an, fragt nach Farben, die man sonst sofort verwenden könnte. Spätestens nach der 100. Anfrage fragen sich bestimmt einige, ob die bei OSM noch gesund sind. Haben eine Datenbank und fragen ständig nach... Ich kann mir noch vorstellen, dass Linien in den offiziellen Linienfarben auf einer OSM-Karte eingezeichnet werden sollen, aber auch dann würde ich als Ausführender dafür eine offizielle Tabelle nehmen und die ref aus OSM heranziehen, nicht Farbwerte, die in OSM so getagged sind. Ausnahme: es ist nicht so wichtig - aber dann sind auch generische(re) Farbnamen oder geringe Abweichungen einfach zu verkraften. Ich meine, es ist sinnvoll, festgelegte Farben so einzutragen, wie sie definiert sind, wenn der Mapper die Information hat. Eine Übertragung in andere Systeme bleibt dem Auswerter überlassen. Letztlich bleibt es Entscheidung des Mappers, ob er die Farbcodes eintragen will. Wenn er es macht, ist das aber für einige ein echter Mehrwert. Für andere dagegen ein echter Wenigerwert: Ich kann aus dem Kopf RGB-Werte ungefähr überprüfen, aber CYK aus dem Stehgreif nicht, und ehrlich gesagt: besser, da steht light red, oder yellow green und ich kann ungefähr sagen, dass das passt (und es sonst als Fehler markieren), als dass irgendein Mapper X eine Farbtabelle kennt, die er abtippen kann. Die stehen dann drin und wenn er sich vertippt hat, merkt das niemand - für die nächsten Jahre. -1 Das ist eine etwas seltsame Argumentation. Nur weil ich etwas nicht selbst aus dem Stand prüfen kann, darf es nicht in OSM eingetragen werden. Dann fliegen sofort alle Briefkästen, Papierkörbe, Hundekottütenspender, Waldwege ... etc etc raus, denn die kann ich auch nicht einfach so prüfen, die sind im Luftbild nicht sichtbar. Wenn mir eine Farbe merkwürdig vorkommt, kann ich nachfragen. Wir tragen nämlich nur Sachen ein, die wir eintragen dürfen. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
Am 29.05.2013 um 15:16 schrieb Tobias Conradi mail.2...@tobiasconradi.com: 2013/5/29 Martin Koppenhoefer dieterdre...@gmail.com: Am 29. Mai 2013 10:05 schrieb Wolfgang Hinsch osm-lis...@ivkasogis.de: Ich meine, es ist sinnvoll, festgelegte Farben so einzutragen, wie sie definiert sind, wenn der Mapper die Information hat. Eine Übertragung in andere Systeme bleibt dem Auswerter überlassen. +1 -2 Die Fragen dazu sind nicht beanwortet http://lists.openstreetmap.org/pipermail/talk-de/2013-May/102425.html http://wiki.openstreetmap.org/wiki/Key:colour The value should be: an RGB color code (hex triplet) Den Teil über RGB kann man ruhigen Gewissens aus dem Wiki streichen, hat mit der Realität nichts zu tun, siehe http://taginfo.openstreetmap.org/keys/colour#values Entweder man nimmt einen Key und setzt das entspr. Farbsystem in den Wert also so was wie colour=rgb#ff / white / cmyk 0,0,0,0 / RAL 9003 / RAL Signalweiß etc Oder man setzt das Farbsystem in den Key, colour:rgb=* etc Ich wäre für ersteres, weil man mehr als eine Angabe im Prinzip nicht braucht. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
Am 29.05.2013 um 12:52 schrieb Peter Wendorff wendo...@uni-paderborn.de: Für andere dagegen ein echter Wenigerwert: Ich kann aus dem Kopf RGB-Werte ungefähr überprüfen, aber CYK aus dem Stehgreif nicht, Wieso nicht? Additive vs subtraktive Farbmischung, m.E. kann man sich CMYK einfacher vorstellen, weil es der Erfahrung des Mischens von Farben im Farbkasten entspricht, während es nicht so einfach ist, sich das Ergebnis aus der Mischung von verschiedenfarbigen Lichtern vorzustellen. und ehrlich gesagt: besser, da steht light red, oder yellow green und ich kann ungefähr sagen, dass das passt (und es sonst als Fehler markieren), als dass irgendein Mapper X eine Farbtabelle kennt, die er abtippen kann. Die stehen dann drin und wenn er sich vertippt hat, merkt das niemand - für die nächsten Jahre. Entweder es fällt auf, oder es macht auch nichts. Wenn da wirklich jahrelang Quatsch steht und es niemand merkt, dann ist es auch egal ;-) Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
Hi, das sehe ich nicht so. Ich erinnere mal kurz an 3D-Mapping, bei dem colour ebenfalls eine Rolle spielt. Zwar werden hierfür meist subkey's verwendet. Aber diese nutzen ebenso die Wikiseite colour als Ausgangsbasis. vgl.: http://taginfo.openstreetmap.org/keys/roof:colour#values http://taginfo.openstreetmap.org/keys/building:colour#values Und hier macht die Angabe von RGB wieder sinn. Gruß René Am 29. Mai 2013 15:43 schrieb Martin Koppenhöfer dieterdre...@gmail.com: Den Teil über RGB kann man ruhigen Gewissens aus dem Wiki streichen, hat mit der Realität nichts zu tun, siehe http://taginfo.openstreetmap.org/keys/colour#values [...] Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
2013/5/29 Martin Koppenhöfer dieterdre...@gmail.com: Am 29.05.2013 um 15:16 schrieb Tobias Conradi mail.2...@tobiasconradi.com: http://wiki.openstreetmap.org/wiki/Key:colour The value should be: an RGB color code (hex triplet) Den Teil über RGB kann man ruhigen Gewissens aus dem Wiki streichen, hat mit der Realität nichts zu tun, siehe http://taginfo.openstreetmap.org/keys/colour#values Den Teil über RGB (hex triplet) kann man ruhigen Gewissens nicht aus dem Wiki streichen, denn in der Realität werden RGB-Werte genutzt, siehe http://taginfo.openstreetmap.org/keys/colour#values z.B.: #79b51d count: 450 -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
Am 29.05.2013 14:45, schrieb Tobias Conradi: 2013/5/29 Peter Wendorff wendo...@uni-paderborn.de: Selbst wenn die Farben extrem ähnlich wären, aber nicht gleich, würde vermutlich Verkehrsblau für beide reichen. Verkehrsblau ist kein erlaubter Wert im HTML/CSS (RGB)-Farbsystem. Ein Farbcode, der sich minimal unterscheidet, hilft auf keiner Karte weiter. Und daher der Vorschlag dafür zu sorgen, dass sich die Farbcodes nicht minimal unterscheiden: http://lists.openstreetmap.org/pipermail/talk-de/2013-May/102394.html [Talk-de] CMYK und RGB Farben - Standardisierung in OSM Tobias Conradi mail.2012 at tobiasconradi.com So Mai 26 15:23:00 UTC 2013 Damit nimmst du aber an, dass derjenige, der das einträgt, zwingend die offiziellen Farben kennt. Ich redete eher davon, dass ich die Farben vom Fahrplanaushang kriege (oder soll ich sie dann gar nicht eintragen?). Also: Ich geh in die U-Bahn-Station, da hängt ein Fahrplan und ich sehe den, kann evtl. auch noch ein Foto davon machen. Selbst wenn ich - bei meiner Kamera 'nen vernünftigen Weißabgleich vorgenommen habe - die Beleuchtungsverhältnisse nicht ganz mies sind - keine Verfälschung durch Glasscheibe vorliegt etc., wird das Ergebnis Abweichungen haben, welchen Farbcode ich daraus jetzt entnehme: - per Pipette einen einzelnen pixelwert abfragen = immer schlecht bei Fotos - per Pipette gemittelt über einen Bereich, der insgesamt die Linie darstellt und für den Betrachter insofern korrekt aussieht = besser, aber vermutlich auch alles andere als optimal - per Augenmaß und Vergleich = kommt auf die eigene Farbwahrnehmungsfähigkeit an. Außer also im Sonderfall, dass ich die korrekten Farbwerte erhalte, ist es müßig, über geringfügige Abweichungen zu diskutieren, und um einen Farbwert verifizieren zu können (ohne zur Verifikation die Verkehrsbetriebe anschreiben zu müssen), muss ich in der lage sein, ihn als Farbe anzuzeigen. Damit kann ich sicher nicht unterscheiden, ob jetzt #ff oder #ff0005 der korrekte Wert ist, aber ich würde auch #ff0005 als korrekt anerkennen, weil es optisch praktisch nicht zu unterscheiden ist. Ich kann also hier nicht verifizieren, dass es korrekt ist, ich kann aber feststellen, dass es offensichtlich falsch ist, wenn die Linie eigentlich blau sein sollte. Die geringfügigen Abweichungen von Farbcodes werden wir haben - so oder so. Aber die offizielle Farbtabelle wäre eben auf jeden Fall zur Verifikation (!) durch den Mapper notwendig, und das ist eben nicht realistisch. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
Am 29.05.2013 um 16:17 schrieb Tobias Conradi mail.2...@tobiasconradi.com: 2013/5/29 Martin Koppenhöfer dieterdre...@gmail.com: Am 29.05.2013 um 15:16 schrieb Tobias Conradi mail.2...@tobiasconradi.com: http://wiki.openstreetmap.org/wiki/Key:colour The value should be: an RGB color code (hex triplet) Den Teil über RGB kann man ruhigen Gewissens aus dem Wiki streichen, hat mit der Realität nichts zu tun, siehe http://taginfo.openstreetmap.org/keys/colour#values Den Teil über RGB (hex triplet) kann man ruhigen Gewissens nicht aus dem Wiki streichen, denn in der Realität werden RGB-Werte genutzt, siehe http://taginfo.openstreetmap.org/keys/colour#values z.B.: #79b51d count: 450 Ja, vor allem da das Wiki ja auch noch Alternativen zu RGB zulässt. Müsste dann nur noch jemand aufschreiben was man in den Fällen macht, wo sich eine Farbe nicht darstellen lässt mit den im Wiki beschriebenen Varianten ;-). M.E. ist das was hierzu bisher entstanden ist, die Sicht von Programmierern, um möglichst einfach die Dinge auszuwerten, sozusagen ein Teil der Renderregeln in tags. Wenn wir eine db sind, die die Welt beschreiben will, dann sollten wir hier flexibler sein und es so gestalten, dass es für den Mapper am einfachsten ist und die Abbildung der Realität entspricht. Ähnlich verhält es sich z.B. mit Geschwindigkeitslimits in mph, die sollte man auch nicht in km/h umrechnen, weil sie eben in mph sind, und man immer was verliert beim Umrechnen (wobei der Verlust im Falle der Farben ggf. größer ausfallen kann). Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
Hi, Am Wed, 29 May 2013 14:51:23 +0200 schrieb Tobias Conradi mail.2...@tobiasconradi.com: colour ist gemacht für Städte wie Jönköping. Dort sagt man im Alltag nehmen sie die Linie Rot. Dass das die Linie 1 ist, wissen die meisten vermutlich garnicht. Nur die aus der Stadt heraus führenden Busse werden dort im Alltag mit Nummern bezeichnet. Wo ist das definiert? Ich finde nur: http://wiki.openstreetmap.org/wiki/Key:colour The value should be: an RGB color code (hex triplet) Bei http://wiki.openstreetmap.org/wiki/Relation:route findet man bei den Straßenbahnen (woanders ist die Formulierung weniger klar): The tram, subways and buses might have official colour identifiers in some cities. Es geht also um colour identifiers wie z.B. Rote Linie. Offiziell verstehe ich so, dass die Benennung mit Farben statt Nummern nicht nur eine Gewohnheit der Bevölkerung ist, sondern auch der Verkehrsbetriebe. Aber eigentlich ist es Quatsch, was ich hier rede. colour ist massiv im Gebrauch und die einzig jetzt noch vernünftige Frage ist: Was weiß man, wenn man colour=... vorfindet?. Zumindest für den ÖPNV neige ich zur Antwort gar nichts. Meist wollte der Mapper einfach gern diese Farbe in einer der ÖPNV-Karten sehen. Das Tag ist verbrannt. Bitte ignoriert, was ich zur Definition geschrieben habe. Trotzdem frohes Mappen Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
Am 29.05.2013 15:26, schrieb Wolfgang Hinsch: Am Mittwoch, den 29.05.2013, 12:52 +0200 schrieb Peter Wendorff: Am 29.05.2013 10:05, schrieb Wolfgang Hinsch: Wenn das normalerweise egal ist, nur für offizielle Drucke der offiziellen Farben nicht - dann nimmt man für diese offiziellen Drucke auch offizielle Daten, also ist OSM normalerweise aus dem Spiel. Und für eine Übersicht klappert man xx Unternehmen an, fragt nach Farben, die man sonst sofort verwenden könnte. Spätestens nach der 100. Anfrage fragen sich bestimmt einige, ob die bei OSM noch gesund sind. Haben eine Datenbank und fragen ständig nach... Es wäre sinnvoll, mal zu erklären, wozu das Erfassen der exakten Farben dienen soll, bevor man festlegt, in welcher Form man sie abspeichert. So wie ich es verstanden habe, geht es um Farben, welche von den Verkehrsbetrieben auf ihren Linienplänen verwendet werden, nicht aber um Farbcodes für die Linien, im Sinne von Linie 21 = die lilablassblaue Linie. Wenn ich damit richtig liege, dann würde es sich nur ein gestalterisches Mittel diese farbcodes Somit geht es darum, dass auf OSM-basierten Karten dieselben Farben verwendet werden wie auf dem Linienplan des jeweiligen Verkehrsbetriebs. Man nimmt damit dem Renderer die Mühe ab, bei einer Vielzahl von Linien einigermaßen unterscheidbare Farben auszuwählen. Das ist ganzs praktisch, aber mappen wir für den Renderer? Ein weiteres Ziel könnte sein, dass der Nutzer auf der OSM-Karte dieselben Farben wiederfindet wie auf der BVG-Karte. So ganz erschließt sich mir der Nutzen davon allerdings nicht. Schließlich werden die Farbcodes ja nicht auf den Fahrzeugen verwendet, und selbst wenn, dann wäre der Wiedererkennungsgrad sehr gering, da sich z.B. in Berlin manche der Farben nur im direkten Vergleich unterscheiden lassen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
Am 29.05.2013 15:58, schrieb Martin Koppenhöfer: Am 29.05.2013 um 12:52 schrieb Peter Wendorff wendo...@uni-paderborn.de: Für andere dagegen ein echter Wenigerwert: Ich kann aus dem Kopf RGB-Werte ungefähr überprüfen, aber CYK aus dem Stehgreif nicht, Wieso nicht? Additive vs subtraktive Farbmischung, m.E. kann man sich CMYK einfacher vorstellen, weil es der Erfahrung des Mischens von Farben im Farbkasten entspricht, während es nicht so einfach ist, sich das Ergebnis aus der Mischung von verschiedenfarbigen Lichtern vorzustellen. Vermutlich hab ich dafür einfach zu viel im Bereich Web mit Farben zu tun ;) Ist aber auch egal, welches System einem besser liegt oder nicht: Der Drucker wird mit CMYK besser was anfangen können, der Wasserfarbenmaler dagegen kennt schon kein Magenta und würde nochmal anders mischen (intuitiv). und ehrlich gesagt: besser, da steht light red, oder yellow green und ich kann ungefähr sagen, dass das passt (und es sonst als Fehler markieren), als dass irgendein Mapper X eine Farbtabelle kennt, die er abtippen kann. Die stehen dann drin und wenn er sich vertippt hat, merkt das niemand - für die nächsten Jahre. Entweder es fällt auf, oder es macht auch nichts. Wenn da wirklich jahrelang Quatsch steht und es niemand merkt, dann ist es auch egal ;-) Aber Werte, die nicht lesbar sind (durch den 0815-Mapper) werden eher ignoriert als solche, bei denen verstanden wird, was dahintersteckt. Farbwerte in irgendwelchen Farbsystemen (RGB eingeschlossen) zu definieren ist insofern nur sinnvoll, wenn zumindest die gängigen Editoren das auch auswerten können und als Farbe anzeigen. Tun sie das nicht, halte ich sprechende Farbnamen auf englisch, die man in 'ner Tabelle nachgucken und annähernd angeben kann, für zielführender auf allen Ebenen. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
Am Mittwoch, den 29.05.2013, 16:42 +0200 schrieb RainerU: Es wäre sinnvoll, mal zu erklären, wozu das Erfassen der exakten Farben dienen soll, bevor man festlegt, in welcher Form man sie abspeichert. So wie ich es verstanden habe, geht es um Farben, welche von den Verkehrsbetrieben auf ihren Linienplänen verwendet werden, nicht aber um Farbcodes für die Linien, im Sinne von Linie 21 = die lilablassblaue Linie. Wenn ich damit richtig liege, dann würde es sich nur ein gestalterisches Mittel diese farbcodes Somit geht es darum, dass auf OSM-basierten Karten dieselben Farben verwendet werden wie auf dem Linienplan des jeweiligen Verkehrsbetriebs. Man nimmt damit dem Renderer die Mühe ab, bei einer Vielzahl von Linien einigermaßen unterscheidbare Farben auszuwählen. Das ist ganzs praktisch, aber mappen wir für den Renderer? Nein, ich sehe nicht irgendeinen Renderer als Ziel. Mir geht es _nur_ darum, dass man die Farbe, falls irgendwo gebraucht, jederzeit korrekt herstellen könnte. Gehe mal in eine Druckerei und frage nach Farbdarstellungen und RGB. Ich habe überhaupt nichts dagegen, dass eine näherungsweise geeignete RGB-Farbe mit eingetragen wird. Ich möchte nur erreichen, dass der, der die korrekte (professionell brauchbare) Farbbezeichnung kennt, sie auch eintragen kann. Nicht als einzigen Eintrag, aber zusätzlich. Ein weiteres Ziel könnte sein, dass der Nutzer auf der OSM-Karte dieselben Farben wiederfindet wie auf der BVG-Karte. Vergiss in diesem Zusammenhang die OSM-Karte aus dem Web. Um die geht es mir überhaupt nicht. Dafür reicht der RGB-Wert immer aus. Aber es gibt noch viele Welten neben der Karte. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
Am 29.05.2013 16:48, schrieb Wolfgang Hinsch: Am Mittwoch, den 29.05.2013, 16:42 +0200 schrieb RainerU: Ein weiteres Ziel könnte sein, dass der Nutzer auf der OSM-Karte dieselben Farben wiederfindet wie auf der BVG-Karte. Vergiss in diesem Zusammenhang die OSM-Karte aus dem Web. Um die geht es mir überhaupt nicht. Dafür reicht der RGB-Wert immer aus. Aber es gibt noch viele Welten neben der Karte. Mit der OSM-Karte ist natürlich jede auf der Basis der OSM-Daten erzeugte Karte gemeint, das kann auch ein schematisierter Linienplan sein, oder auch eine Anwendung bei der der aktuelle Standort des Fahrzeugs in der entsprechenden Farbe angezeigt wird (was noch nicht mal die Verkehrsbetriebe in ihren RBLs machen). Letztendlich geht es dabei immer darum, eine mit einer Linie assoziierte Information in genau der Farbe darzustellen, die auch der Verkehrsbetrieb in seinen Veröffentlichungen benutzt. Mir fehlt noch der Anwendungsfall, wo das sinnvoll oder notwendig ist. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
Hi, On 05/29/2013 03:26 PM, Wolfgang Hinsch wrote: Für andere dagegen ein echter Wenigerwert: Ich kann aus dem Kopf RGB-Werte ungefähr überprüfen, aber CYK aus dem Stehgreif nicht, und ehrlich gesagt: besser, da steht light red, oder yellow green und ich kann ungefähr sagen, dass das passt (und es sonst als Fehler markieren), als dass irgendein Mapper X eine Farbtabelle kennt, die er abtippen kann. Die stehen dann drin und wenn er sich vertippt hat, merkt das niemand - für die nächsten Jahre. -1 Das ist eine etwas seltsame Argumentation. Nur weil ich etwas nicht selbst aus dem Stand prüfen kann, darf es nicht in OSM eingetragen werden. Peter hat sich da vielleicht etwas ungeschickt ausgedrueckt. Aber im Grunde gilt schon, dass wir moechten, dass die Informationen in unserer Datenbank vor Ort ueberpruefbar sind. Das bedeutet vor allem, dass wir einer ist-Information Vorrang vor einer soll-Information einraeumen - wenn der Parkplatzbetreiber sagt, da sind 40 Stellplaetze, aber vor Ort sieht man nur 38, dann taggen wir die - denn die sind ueberpruefbar, die 40 sind es nicht. Das gleiche wuerde auch zutreffen, wenn man die Linienfarbe einer OePNV-Linie taggt. Wie kann man die vor Ort pruefen? Entweder mit Augenschein (colour:red) oder vielleicht, indem man mit seinem Smartphone ein Foto eines Schildes macht und da dann einen Wert in beliebigem Farbmodell abliest. Dabei ergibt sich eine Mess-Unschaerfe, genau wie beim Aufzeichnen einer Position mit dem GPS - that's life. Was die BVG in ihrem Corporate-Identity-Dokument drinstehen hat, ist fuer uns von minderer Relevanz, und Unterschiede, die so klein sind, dass sie unterhalb der mit dem iPhone in der Daemmerung von schraeg unten fotografiert-Unschaerfe liegen, sind nicht wichtig, weil nicht pruefbar. Wer eine Karte mit offiziellen garantiert richtigen Farben machen will, der sollte sich eine offizielle Tabelle besorgen und dann aus OSM lediglich die Linienbezeichnungen entnehmen und mit der offiziellen Tabelle abgleichen. Dann fliegen sofort alle Briefkästen, Papierkörbe, Hundekottütenspender, Waldwege ... etc etc raus, denn die kann ich auch nicht einfach so prüfen, die sind im Luftbild nicht sichtbar. Eine theoretisch moegliche Vor-Ort-Pruefung reicht ja. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
2013/5/29 RainerU ra...@sfr.fr: Mit der OSM-Karte ist natürlich jede auf der Basis der OSM-Daten erzeugte Karte gemeint, Letztendlich geht es dabei immer darum, eine mit einer Linie assoziierte Information in genau der Farbe darzustellen, die auch der Verkehrsbetrieb in seinen Veröffentlichungen benutzt. Mir fehlt noch der Anwendungsfall, wo das sinnvoll oder notwendig ist. Z.B. einen Stadtplan herausgeben, auf dem die U-Bahnlinien in der Linienfarbe dargestellt sind. -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
2013/5/30 Frederik Ramm frede...@remote.org: Peter hat sich da vielleicht etwas ungeschickt ausgedrueckt. Aber im Grunde gilt schon, dass wir moechten, dass die Informationen in unserer Datenbank vor Ort ueberpruefbar sind. Wer ist wir? Es gibt hier sehr unterschiedliche Meinungen was wer möchte. Eine Linienfarbe ist per se nicht vor Ort überprüfbar, da sie ein gedankliches Konstrukt ist. Sven Geggus hat ja auch schon behauptet die Linien in seiner Gegend (KA) seien alle rostbraun. Das gleiche wuerde auch zutreffen, wenn man die Linienfarbe einer OePNV-Linie taggt. Wie kann man die vor Ort pruefen? Entweder mit Augenschein (colour:red) Nahverkehrslinien haben keine physische Erscheinung. oder vielleicht, indem man mit seinem Smartphone ein Foto eines Schildes macht und da dann einen Wert in beliebigem Farbmodell abliest. ein beliebiges Farbmodell kann dazu führen, dass selbst Nutzer die mit RGB, CMYK, CIELAB umgehen können, die Daten nicht nutzen können. Was die BVG in ihrem Corporate-Identity-Dokument drinstehen hat, ist fuer uns Wer ist uns? von minderer Relevanz, Das sehen mehrere Leute auf der OSM-Berlin Liste anders. Die VBB-Angaben wurden sogar als Grundlage für die derzeitigen OSM-Werte genommen. und Unterschiede, die so klein sind, dass sie unterhalb der mit dem iPhone in der Daemmerung von schraeg unten fotografiert-Unschaerfe liegen, sind nicht wichtig, weil nicht pruefbar. Die 6-stelligen RGB-hex triplets sind auf 6 Stellen prüfbar. Wer eine Karte mit offiziellen garantiert richtigen Farben machen will, der sollte sich eine offizielle Tabelle besorgen und dann aus OSM lediglich die Linienbezeichnungen entnehmen Begründung? -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
Am 30.05.2013 04:01, schrieb Tobias Conradi: 2013/5/29 RainerU ra...@sfr.fr: Letztendlich geht es dabei immer darum, eine mit einer Linie assoziierte Information in genau der Farbe darzustellen, die auch der Verkehrsbetrieb in seinen Veröffentlichungen benutzt. Mir fehlt noch der Anwendungsfall, wo das sinnvoll oder notwendig ist. Z.B. einen Stadtplan herausgeben, auf dem die U-Bahnlinien in der Linienfarbe dargestellt sind. Meine Frage ist: warum ist es sinnvoll/notwendig auf einem derartigen Plan die Linien genau in derselben Farbe darzustellen, wie das der Verkehrsbetrieb auf seinen eigenen Plänen macht? Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
http://www.openstreetmap.org/browse/changeset/16152289 Tags: comment = Farben der Berliner U-Bahn an die offiziellen RAL Werte angepasst. created_by = JOSM/1.5 (5836 en) Mac OS X --- Durch das anscheinend benutzte Verfahren https://lists.openstreetmap.de/pipermail/berlin/2013-May/000607.html 1) Nimm RAL-Wert aus VBB PDF 2) Nimm RGB aus http://www.arraydesign.co.uk/resources/graphical/RAL%20colour%20profile.pdf werden Werte angeglichen, die in CMYK verschieden sind, z.B. RB74 CMYK 100 50 0 0 S3 CMYK 100 50 0 5 ist beides Verkehrsblau RAL 5017. Quelle: http://wiki.openstreetmap.org/w/images/a/a7/Linienfarben_SPNV.PDF Das PDF von arraydesign gibt für RAL 5017 CMYK 100 20 5 40 RGB 14 81 141 HEX #0E518D Dieser Werte ist mindestens seit 2013-05-16 für die S3 in Berlin online: http://www.openstreetmap.org/browse/relation/28314 http://www.openstreetmap.org/api/0.6/changeset/16152132/download http://www.codecrete.net/CMYK gibt für die eben genannten drei CMYK-Werte folgende RGB-Werte: #0074b7 #006fb3 #00658b -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
