Re: [Talk-de] CMYK und RGB Farben - Standardisierung in OSM
Am 05.06.2013 02:46, schrieb Tobias Conradi: 2013/6/5 Stefan Keller sfkel...@gmail.com: Man erfasst was man in der Realität draussen sieht. Buslinien sieht man nicht, ausser auf Netzplänen. Ich hab Buslinien durchaus schon - und zwar häufiger - eingetragen, indem ich mich zunächst reingesetzt habe und dabei das GPS hab loggen lassen. Damit sehe ich zwar nicht die Buslinie, aber kann sie sehr wohl nachvollziehen. Trotzdem gibt es Linien in OSM. Manche Relationen: http://www.wikidata.org/wiki/Q99691 (U1 Berlin) linkt zu : http://www.openstreetmap.org/?relation=58767 sogar ohne Kartendarstellung. Mehr Infos dann unter http://www.openstreetmap.org/browse/relation/58767 Die Darstellung gibt es sehr wohl, jedoch in Form einzelner Darstellungen der einzelnen Routen-Varianten und -Richtungen, z.B. http://www.openstreetmap.org/browse/relation/2669205 Und dort gibt es eine Farbangabe. Wenn man da keine will, dann könnte man das vielleicht technisch unterbinden, bzw. erstmal irgendwo definieren. Warum sollte ausgerechnet dieser Fall (Farben von ÖPNV-Linien) dazu führen, dass technische Hilfsmittel herangezogen werden, um ein bestimmtes Tagging zu behindern? Eine Farbe, die nirgendwo genutzt wird, stört auch niemanden. Eine Farbe, die nirgendwo genutzt wird, wird auch seltener eingetragen werden. Wird die Farbe irgendwo genutzt durch irgendeine Karte, dann ist das berechtigt und erst recht kein Grund, das zu unterbinden. Wenn man keine will, dann nutzt/erstellt man (sich? anderen? allen?) einen Kartenstil, der die Farbe nicht nutzt, und fertig. Wenn man eine will, kann man um die Bandbreite der Werte zu reduzieren, definieren welche Werte eingetragen werden sollen. Das war die Idee von CMYK und RGB Farben - Standardisierung in OSM. Hier kommen wir zum Kern des Threads: Es ist eben abzuwägen: - Ein Farbschema festlegen (z.B. RGB) führt dazu, dass Umwandlungen aus/in einige andere Farbschemata ungenau werden, es kommt also zu mehr oder weniger falschen Werten (was IMHO die meisten Mapper und die meisten OSM-Anwendungsfälle kaum stören dürfte, weil die Genauigkeit der Farben nicht sooo hoch sein muss). - Mehrere/viele/alle Farbschemata zu erlauben verlangt jeder auswertenden Instanz (Renderer...) ab, diese auch alle zu kennen und zumeist, die ungenaue Umwandlung dann vorzunehmen. Es finden sich also die Dimensionen: - Aufwand für das Eintragen durch Mapper - Aufwand für das Verifizieren und korrigiern durch Mapper - Aufwand und Möglichkeit, die Daten auszuwerten im Rendering - Bedarf an Genauigkeit der Farben (z.B. reichen die ~64 benannten Farben aus Windows aus? oder sowas) Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK / RGB - Versuch einer Zusammenfassung
On 05/giu/2013, at 02:56, Tobias Conradi mail.2...@tobiasconradi.com wrote: Mir ist nicht klar, für was genau diese Farben-Normierung dient Bandbreite der möglichen Werte reduzieren, möglichst eine eindeutige Abbildung. Dadurch Vorhersagbarkeit der Werte und Übereinstimmung mit Farbwerten in anderen Datenquellen. bis auf Bandbreite der Möglichkeiten reduzieren sind das allerdings allesamt Argumente gegen eine Normierung auf RGB. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK / RGB - Versuch einer Zusammenfassung
Tobias Conradi mail.2...@tobiasconradi.com wrote: Bandbreite der möglichen Werte reduzieren, möglichst eine eindeutige Abbildung. Dadurch Vorhersagbarkeit der Werte und Übereinstimmung mit Farbwerten in anderen Datenquellen. Dir ist aber schon klar, dass es Eindeutigkeit in croudsourcing Projekten wie OSM sowieso nie geben wird? Ich finde das ja ehrlich gesagt alles massiv überspezifiziert. Einfach die Klartextnamen aus rgb.txt verwenden und gut iss. Gruss Sven -- If you can spend five minutes on the Internet and do not run Linux, you're a genius. (Dirk Hohndel) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Widersprüche zwischen Wiki-Definition und Mapnik-Rendering
Am Mittwoch, den 05.06.2013, 01:47 +0200 schrieb Martin Koppenhoefer: Am 5. Juni 2013 01:36 schrieb Stephan Wolff s.wo...@web.de: Mangelt es dem Mapnik-Team nur an Zeit oder besteht Uneinigkeit in der korrekten Definition der Tags? Würde es helfen, eine verbesserte osm2pgsql-Konfiguration zu erstellen? Wem könnte man diese schicken? Das Problem ist, wie osm2pgsql arbeitet, man kann nur keys als Fläche zuordnen, aber nicht k/v-Paare, d.h. im Zweifel wird man eher ein Liniendefault setzen und nur mit area=yes auf Fläche gehen, weil sonst so was wie bei leisure=track passiert (leisure wird immer als area angesehen). Als Lösung kann man auf einen Area-Datentyp hoffen, oder darauf, dass man auch k/v-Kombinationen in osm2pgsql styles definieren kann. Oder z.B. einen anderen Importer verwenden, Imposm kann das vielleicht? osm2postgresql oder besser gleich osmosis, viel flexibler osm2pgsql filtert im Vorwege zu viel weg. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK und RGB Farben - Standardisierung in OSM
2013/6/5 Peter Wendorff wendo...@uni-paderborn.de: Am 05.06.2013 02:46, schrieb Tobias Conradi: 2013/6/5 Stefan Keller sfkel...@gmail.com: Man erfasst was man in der Realität draussen sieht. Buslinien sieht man nicht, ausser auf Netzplänen. Ich hab Buslinien durchaus schon - und zwar häufiger - eingetragen, indem ich mich zunächst reingesetzt habe und dabei das GPS hab loggen lassen. Damit sehe ich zwar nicht die Buslinie, aber kann sie sehr wohl nachvollziehen. Trotzdem gibt es Linien in OSM. Manche Relationen: http://www.wikidata.org/wiki/Q99691 (U1 Berlin) linkt zu : http://www.openstreetmap.org/?relation=58767 sogar ohne Kartendarstellung. Mehr Infos dann unter http://www.openstreetmap.org/browse/relation/58767 Die Darstellung gibt es sehr wohl, Jetzt bin ich ja gespannt. jedoch in Form einzelner Darstellungen der einzelnen Routen-Varianten und -Richtungen, z.B. http://www.openstreetmap.org/browse/relation/2669205 Also doch nicht. Und dort gibt es eine Farbangabe. Wenn man da keine will, dann könnte man das vielleicht technisch unterbinden, bzw. erstmal irgendwo definieren. Warum sollte ausgerechnet dieser Fall (Farben von ÖPNV-Linien) dazu führen, dass technische Hilfsmittel herangezogen werden, um ein bestimmtes Tagging zu behindern? Weil ausgerechnet dieser Fall angeführt wurde. Eine Farbe, die nirgendwo genutzt wird, stört auch niemanden. Das ist wohl wahr, nur kenne ich keine solche. Und sobald Du eine benennst, ist sie genutzt. Eine Farbe, die nirgendwo genutzt wird, wird auch seltener eingetragen werden. So selten, dass man von gar nicht reden würde. Denn würde sie eingetragen werden, würde sie ja genutzt werden. Wird die Farbe irgendwo genutzt durch irgendeine Karte, dann ist das berechtigt und erst recht kein Grund, das zu unterbinden. Eine in der Vergangenheit erfolgte Handlung (irgendwo Nutzung) kann man auch gar nicht unterbinden. Wenn man keine will, dann nutzt/erstellt man (sich? anderen? allen?) einen Kartenstil, der die Farbe nicht nutzt, und fertig. Oder man löscht alle Farbtags in OSM .. und fertig. Wenn man eine will, kann man um die Bandbreite der Werte zu reduzieren, definieren welche Werte eingetragen werden sollen. Das war die Idee von CMYK und RGB Farben - Standardisierung in OSM. Hier kommen wir zum Kern des Threads: Es ist eben abzuwägen: - Ein Farbschema festlegen (z.B. RGB) Dies ist bereits festgelegt: http://wiki.openstreetmap.org/wiki/Key:colour The value should be: * an RGB color code (hex triplet) * a CSS color name führt dazu, dass Umwandlungen aus/in einige andere Farbschemata ungenau werden, es kommt also zu mehr oder weniger falschen Werten (was IMHO die meisten Mapper und die meisten OSM-Anwendungsfälle kaum stören dürfte, weil die Genauigkeit der Farben nicht sooo hoch sein muss). Und was stört in einem solchen Fall wo sie nicht sooo hoch sein muss, eine höhre Genauigkeit? Es finden sich also die Dimensionen: - Aufwand für das Eintragen durch Mapper - Aufwand für das Verifizieren und korrigiern durch Mapper - Aufwand und Möglichkeit, die Daten auszuwerten im Rendering - Bedarf an Genauigkeit der Farben (z.B. reichen die ~64 benannten Farben aus Windows aus? oder sowas) Neben Aufwand gibt es noch Ertrag/Nutzen. Und der ist bei höherer Bestimmtheit der schon vorhandenen RGB-triplets höher. Wenn für Verkehrslinien keine RGB-triplets als Wertangaben existieren sollen, sondern nur benannte CSS-RGB-Farben, dann kann man das im Wiki definieren und/oder technisch ausschließen. Dies ist zur Zeit nicht der Fall. -- 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] CMYK / RGB - Versuch einer Zusammenfassung
2013/6/5 Martin Koppenhoefer dieterdre...@gmail.com: Mir ist nicht klar, für was genau diese Farben-Normierung dient Bandbreite der möglichen Werte reduzieren, möglichst eine eindeutige Abbildung. Dadurch Vorhersagbarkeit der Werte und Übereinstimmung mit Farbwerten in anderen Datenquellen. bis auf Bandbreite der Möglichkeiten reduzieren sind das allerdings allesamt Argumente gegen eine Normierung auf RGB. Beweisführung? -- 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] CMYK / RGB - Versuch einer Zusammenfassung
2013/6/5 Sven Geggus li...@fuchsschwanzdomain.de: Tobias Conradi mail.2...@tobiasconradi.com wrote: Bandbreite der möglichen Werte reduzieren, möglichst eine eindeutige Abbildung. Dadurch Vorhersagbarkeit der Werte und Übereinstimmung mit Farbwerten in anderen Datenquellen. Dir ist aber schon klar, dass es Eindeutigkeit in croudsourcing Projekten wie OSM sowieso nie geben wird? Nein. Ich finde das ja ehrlich gesagt alles massiv überspezifiziert. Einfach die Klartextnamen aus rgb.txt verwenden und gut iss. Wo befindet sich diese Datei um den Wahrheitsgehalt der Aussage überprüfen zu können? -- 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] CMYK und RGB Farben - Standardisierung in OSM
Am Mittwoch, den 05.06.2013, 08:31 +0200 schrieb Peter Wendorff: Am 05.06.2013 02:46, schrieb Tobias Conradi: Und dort gibt es eine Farbangabe. Wenn man da keine will, dann könnte man das vielleicht technisch unterbinden, bzw. erstmal irgendwo definieren. Warum sollte ausgerechnet dieser Fall (Farben von ÖPNV-Linien) dazu führen, dass technische Hilfsmittel herangezogen werden, um ein bestimmtes Tagging zu behindern? Eine Farbe, die nirgendwo genutzt wird, stört auch niemanden. Eine Farbe, die nirgendwo genutzt wird, wird auch seltener eingetragen werden. Wird die Farbe irgendwo genutzt durch irgendeine Karte, dann ist das berechtigt und erst recht kein Grund, das zu unterbinden. +1 Wenn man keine will, dann nutzt/erstellt man (sich? anderen? allen?) einen Kartenstil, der die Farbe nicht nutzt, und fertig. Wenn man eine will, kann man um die Bandbreite der Werte zu reduzieren, definieren welche Werte eingetragen werden sollen. Das war die Idee von CMYK und RGB Farben - Standardisierung in OSM. Hier kommen wir zum Kern des Threads: Es ist eben abzuwägen: - Ein Farbschema festlegen (z.B. RGB) führt dazu, dass Umwandlungen aus/in einige andere Farbschemata ungenau werden, es kommt also zu mehr oder weniger falschen Werten +1 (was IMHO die meisten Mapper und die meisten OSM-Anwendungsfälle kaum stören dürfte, weil die Genauigkeit der Farben nicht sooo hoch sein muss). Wie schon mehrfach geschrieben, es kommt auf den Anwendungsfall an. Für Web +1, für Print -1 / 0 - Mehrere/viele/alle Farbschemata zu erlauben verlangt jeder auswertenden Instanz (Renderer...) ab, diese auch alle zu kennen und zumeist, die ungenaue Umwandlung dann vorzunehmen. -1 warum? Es reicht, wenn die Instanz das auswertet, was sie braucht / kennt. Wenn RGB reicht, wertet die Instanz RGB aus. Wenn nur RAL eingetragen ist, erscheint die Farbe eben als grau. colour:rgb=dark_blue colour:ral=night_blue_26 so what? Die Instanz _kann_ auswerten, muss aber nicht. Es finden sich also die Dimensionen: - Aufwand für das Eintragen durch Mapper Siehe mein Vorschlag mit im Wiki zu definierenden Farbnamen - Aufwand für das Verifizieren und korrigiern durch Mapper Ist dann gering - Aufwand und Möglichkeit, die Daten auszuwerten im Rendering Sache der Instanz, bei verschiedenen Schemata relativ einfach. - Bedarf an Genauigkeit der Farben (z.B. reichen die ~64 benannten Farben aus Windows aus? oder sowas) Die können gerne im Wiki eingetragen werden. Aber bitte nicht davon ausgehen, dass die jeder kennt. Windows ist nur eins der eingesetzten OS. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK und RGB Farben - Standardisierung in OSM
Am Mittwoch, den 05.06.2013, 13:09 +0200 schrieb Tobias Conradi: 2013/6/5 Peter Wendorff wendo...@uni-paderborn.de: Wenn man keine will, dann nutzt/erstellt man (sich? anderen? allen?) einen Kartenstil, der die Farbe nicht nutzt, und fertig. Oder man löscht alle Farbtags in OSM .. und fertig. ??? WIE BITTE ??? An dieser Stelle habe ich mich wohl verlesen?! Wenn man eine will, kann man um die Bandbreite der Werte zu reduzieren, definieren welche Werte eingetragen werden sollen. Das war die Idee von CMYK und RGB Farben - Standardisierung in OSM. Hier kommen wir zum Kern des Threads: Es ist eben abzuwägen: - Ein Farbschema festlegen (z.B. RGB) Dies ist bereits festgelegt: http://wiki.openstreetmap.org/wiki/Key:colour The value should be: * an RGB color code (hex triplet) * a CSS color name s/festgelegt/vorgeschlagen/g Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK und RGB Farben - Standardisierung in OSM
2013/6/5 Wolfgang Hinsch osm-lis...@ivkasogis.de: Am Mittwoch, den 05.06.2013, 13:09 +0200 schrieb Tobias Conradi: 2013/6/5 Peter Wendorff wendo...@uni-paderborn.de: Wenn man keine will, dann nutzt/erstellt man (sich? anderen? allen?) einen Kartenstil, der die Farbe nicht nutzt, und fertig. Oder man löscht alle Farbtags in OSM .. und fertig. ??? WIE BITTE ??? An dieser Stelle habe ich mich wohl verlesen?! Ich weiß ja nicht was Du gelesen hast :-) Wenn das einzige Ziel ist, keine Farben zu haben, dann ist Löschen der Farben wohl zielführend, nicht? Hier kommen wir zum Kern des Threads: Es ist eben abzuwägen: - Ein Farbschema festlegen (z.B. RGB) Dies ist bereits festgelegt: http://wiki.openstreetmap.org/wiki/Key:colour ... s/festgelegt/vorgeschlagen/g Annahme: Vor der Festlegung von RGB wurde RGB vorgeschlagen. Schlußfolgerung: Auch das Vorschlagen von RGB ist schon geschehen. -- 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] CMYK / RGB - Versuch einer Zusammenfassung
Hallo Tobias. Am 05.06.2013 13:10, schrieb Tobias Conradi: 2013/6/5 Martin Koppenhoefer dieterdre...@gmail.com: Mir ist nicht klar, für was genau diese Farben-Normierung dient Bandbreite der möglichen Werte reduzieren, möglichst eine eindeutige Abbildung. Dadurch Vorhersagbarkeit der Werte und Übereinstimmung mit Farbwerten in anderen Datenquellen. bis auf Bandbreite der Möglichkeiten reduzieren sind das allerdings allesamt Argumente gegen eine Normierung auf RGB. Beweisführung? Dieses kurz-mal-mit-einem-wort-den-Ball-zurückspielen nervt wirklich irgendwann, sorry. Was willst du denn jetzt bewiesen haben? -Bandbreite möglicher Werte: da hat Martin dir recht gegeben -eindeutige Abbildung: Lies dich mal durch die verwandten Diskussionen der letzten Tage und stelle selbst fest, dass offensichtlich z.B. zwischen RAL und RGB keine eindeutige Abbildung existiert, bzw. dass da unterschiedliche Konvertierungstabellen/(Algorithmen?) existieren. Wenn aber die Abbildung nicht eindeutig und klar definiert ist (weil sie widersprüchlich mehrfach definiert ist), dann ist eben eine eindeutige Abbildung nach Normierung auf RGB nicht möglich (es sei denn, man einigt sich dabei auf eine Konvertierung - aber welche?) - Vorhersagbarkeit der Werte und Übereinstimmung mit Farbwerten in anderen Datenquellen: Kann man IMHO als Argument sowohl für als auch gegen Normierung auf RGB auslegen. Pro nur-RGB daran: ein Vergleich zweier Werte führt zumindest immer zum gleichen Ergebnis, weil keine Umwandlung zum Vergleichen notwendig ist. Contra nur-RGB: Da ja (s.o.) die eindeutige Zuordnung schon beim Eintragen nicht als gegeben angenommen werden kann, sind zwei RGB-Werte, die zwei Mapper aus identischem RAL-Code umgewandelt haben, nicht zwingend gleich, so dass ein Vergleichen schwierig ist. Martins Aussagen waren erstmal eine Meinung - seine Einschätzung, wofür diese Argumente taugen. Eine Einschätzung beweisen zu müssen ist erstmal... - komisch. Mit Argumenten untermauern: okay, ja - hab ich hiermit glaub ich getan. Beweisen? Wieso? In einer Argumentation muss ich erstmal nicht beweisen, solange ich mir einig bin, und da wir hier nicht Mathematik, sondern Konversation betreiben, muss ich für Meinungen auch keinen wasserdichten, logisch 100% schlüssigen Beweis abliefern, sondern auf Nachfrage begründen, oder Gegenargumente entkräftigen/widerlegen. Ich hab jetzt hier 'ne halbe Bildschirmseite Begründungen geschrieben, die erstmal kaum jemanden interessieren dürften - außer hoffentlich wenigstens dir, weil du gefragt hast. Wenn das bei jeder Meinungsäußerung als Rattenschwanz dranhängt, liest hier wirklich niemand mehr alle Mails. Analogie: Der Satz des Pythagoras gilt. - du würdest schreien: Beweisführung? - aber eigentlich sind sich fast alle einig, dass es stimmt. Einen Beweis mitzuliefern ist also nur notwendig, wenn jemand zurückfragt, und das aber bitte konkret, und nicht mit einem Wort totgeschlagen. Warum soll sich jemand die Mühe machen, dir einen Beweis zu liefern, wenn Du dich auf - mehrfach identisch - ein einziges Wort begrenzt? Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK und RGB Farben - Standardisierung in OSM
Am 05.06.2013 13:45, schrieb Tobias Conradi: 2013/6/5 Wolfgang Hinsch osm-lis...@ivkasogis.de: Am Mittwoch, den 05.06.2013, 13:09 +0200 schrieb Tobias Conradi: 2013/6/5 Peter Wendorff wendo...@uni-paderborn.de: Wenn man keine will, dann nutzt/erstellt man (sich? anderen? allen?) einen Kartenstil, der die Farbe nicht nutzt, und fertig. Oder man löscht alle Farbtags in OSM .. und fertig. ??? WIE BITTE ??? An dieser Stelle habe ich mich wohl verlesen?! Ich weiß ja nicht was Du gelesen hast :-) Wenn das einzige Ziel ist, keine Farben zu haben, dann ist Löschen der Farben wohl zielführend, nicht? Niemand hat argumentiert, es sollte keine Farben in OSM geben. Mit welchem Recht sollte irgendein Nutzer (z.B. Kartenstil-Entwickler) entscheiden, dass niemand die Farben will? Wenn ich auf meiner Karte keine Farben anzeigen will, nutze ich sie nicht. Wenn Hans Huckebein eine ÖPNV-Karte machen und darin die colour-Tags zur Einfärbung der Linien nutzen will, kann er das tun. Mein Ziel ist hier, ÖPNV-Linien ohne Farben darzustellen, und möglicherweise meine Datenbank zu schonen (indem ich die Farb-Attribute nicht importiere), aber dafür muss ich niemanden anderen an der Verwendung des Attributs hindern durch Löschung, wie du sie vorschlägst. Hier kommen wir zum Kern des Threads: Es ist eben abzuwägen: - Ein Farbschema festlegen (z.B. RGB) Dies ist bereits festgelegt: http://wiki.openstreetmap.org/wiki/Key:colour ... s/festgelegt/vorgeschlagen/g Annahme: Vor der Festlegung von RGB wurde RGB vorgeschlagen. Schlußfolgerung: Auch das Vorschlagen von RGB ist schon geschehen. Ich sehe hier nur eine Wiki-Seite. Kein Proposal, keine Abstimmung, kein gar nichts. Eine Festlegung in OSM sieht anders aus - wenn es sie denn überhaupt gibt. Natürlich muss nicht alles durch einen formalen Proposal-Tag gehen, aber das als festgelegt zu bezeichnen, wenn es ganz offensichtlichen Dissenz gibt (wie du hoffentlich mittlerweile gemerkt hast), und es keine Abstimmung gegeben hat (nichtmal eine kleine, wie es sie häufig gibt), kann nun von einer Festlegung wirklich nicht die Rede sein. Ansonsten könnte ich mal - spezifischer als du bisher Beweisführung! schreien, indem ich frage: Wo ist das denn FESTGELEGT? Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK / RGB - Versuch einer Zusammenfassung
On 05/giu/2013, at 13:10, Tobias Conradi mail.2...@tobiasconradi.com wrote: Bandbreite der möglichen Werte reduzieren, möglichst eine eindeutige Abbildung. Dadurch Vorhersagbarkeit der Werte und Übereinstimmung mit Farbwerten in anderen Datenquellen. bis auf Bandbreite der Möglichkeiten reduzieren sind das allerdings allesamt Argumente gegen eine Normierung auf RGB. Beweisführung? s.o. im Thread m ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK / RGB - Versuch einer Zusammenfassung
2013/6/5 Peter Wendorff wendo...@uni-paderborn.de: Hallo Tobias. Am 05.06.2013 13:10, schrieb Tobias Conradi: 2013/6/5 Martin Koppenhoefer dieterdre...@gmail.com: Mir ist nicht klar, für was genau diese Farben-Normierung dient Bandbreite der möglichen Werte reduzieren, möglichst eine eindeutige Abbildung. Dadurch Vorhersagbarkeit der Werte und Übereinstimmung mit Farbwerten in anderen Datenquellen. bis auf Bandbreite der Möglichkeiten reduzieren sind das allerdings allesamt Argumente gegen eine Normierung auf RGB. Beweisführung? Dieses kurz-mal-mit-einem-wort-den-Ball-zurückspielen nervt wirklich irgendwann, sorry. Dieses lang-mal-irgendwas-behaupten nicht? Was willst du denn jetzt bewiesen haben? Warum Argumente gegen Normierung sprechen. Denn sie waren ja alle als für gedacht. -Bandbreite möglicher Werte: da hat Martin dir recht gegeben -eindeutige Abbildung: Lies dich mal durch die verwandten Diskussionen der letzten Tage und stelle selbst fest, dass offensichtlich z.B. zwischen RAL und RGB keine eindeutige Abbildung existiert, Lies du mal und stelle fest es gibt. Es gibt mehrere. bzw. dass da unterschiedliche Konvertierungstabellen/(Algorithmen?) existieren. Wählt man eine, dann hat man eine eindeutige Abbildung. Wenn aber die Abbildung nicht eindeutig und klar definiert ist (weil sie widersprüchlich mehrfach definiert ist), dann ist eben eine eindeutige Abbildung nach Normierung auf RGB nicht möglich (es sei denn, man einigt sich dabei auf eine Konvertierung - aber welche?) Ich habe einen Vorschlag für CMYK zu RGB gemacht und begründet. CMYK ist das einzige System von dem ich weiß dass ein Verkehrsverbund es nutzt. Von RAL ist mir das nicht bekannt. - Vorhersagbarkeit der Werte und Übereinstimmung mit Farbwerten in anderen Datenquellen: Kann man IMHO als Argument sowohl für als auch gegen Normierung auf RGB auslegen. Pro nur-RGB daran: ein Vergleich zweier Werte führt zumindest immer zum gleichen Ergebnis, weil keine Umwandlung zum Vergleichen notwendig ist. Contra nur-RGB: Da ja (s.o.) die eindeutige Zuordnung schon beim Eintragen nicht als gegeben angenommen werden kann, sind zwei RGB-Werte, die zwei Mapper aus identischem RAL-Code umgewandelt haben, nicht zwingend gleich, so dass ein Vergleichen schwierig ist. Ich hatte kein nur-RGB vorgeschlagen. Der Vorschlag lautete nur, wenn RGB, dann eine eindeutige Herleitung. Martins Aussagen waren erstmal eine Meinung - seine Einschätzung, wofür diese Argumente taugen. Ohne Beweisführung :-) Eine Einschätzung beweisen zu müssen ist erstmal... - komisch. Martin hat wahrscheinlich irgendetwas im (Hinter-)Kopf gehabt, als er seinen Text schrieb. Diese Hintergedanken wollte ich hervorlocken. Es können da ja Denkfehler drinstecken. Mit Argumenten untermauern: okay, ja - hab ich hiermit glaub ich getan. Und ich habe gleich einige Dinge dazu ergänzt. Beweisen? Wieso? Damit die Behauptungen mehr Sinn ergeben. In einer Argumentation muss ich erstmal nicht beweisen, Dass jemand etwas muss, ist m.E. schwer zu beweisen. solange ich mir einig bin, und da wir hier nicht Mathematik, sondern Konversation betreiben, muss ich für Meinungen auch keinen wasserdichten, logisch 100% schlüssigen Beweis abliefern, sondern auf Nachfrage begründen, oder Gegenargumente entkräftigen/widerlegen. Eine solche Nachfrage war mein Beweisführung? Ich hab jetzt hier 'ne halbe Bildschirmseite Begründungen geschrieben, die erstmal kaum jemanden interessieren dürften Mich ja :-) - außer hoffentlich wenigstens dir, weil du gefragt hast. :-) Analogie: Der Satz des Pythagoras gilt. - du würdest schreien: Beweisführung? Mmmh, schreien oder schreiben? - aber eigentlich sind sich fast alle einig, dass es stimmt. Einen Beweis mitzuliefern ist also nur notwendig, wenn jemand zurückfragt, und das aber bitte konkret, und nicht mit einem Wort totgeschlagen. Warum soll sich jemand die Mühe machen, dir einen Beweis zu liefern, wenn Du dich auf - mehrfach identisch - ein einziges Wort begrenzt? Weil er seine in den Raum gestellten Behauptungen untermauern will, da sie nicht den Rang eines Satzes des Pythagoras haben, auf dessen Herleitung man auch einfach mit einem Link zu Wikipedia https://de.wikipedia.org/wiki/Satz_des_Pythagoras verweisen kann. -- 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] CMYK / RGB - Versuch einer Zusammenfassung
On 05/giu/2013, at 14:04, Peter Wendorff wendo...@uni-paderborn.de wrote: Kann man IMHO als Argument sowohl für als auch gegen Normierung auf RGB auslegen. Pro nur-RGB daran: ein Vergleich zweier Werte führt zumindest immer zum gleichen Ergebnis, weil keine Umwandlung zum Vergleichen notwendig ist. Contra nur-RGB: Da ja (s.o.) die eindeutige Zuordnung schon beim Eintragen nicht als gegeben angenommen werden kann, sind zwei RGB-Werte, die zwei Mapper aus identischem RAL-Code umgewandelt haben, nicht zwingend gleich, so dass ein Vergleichen schwierig ist. +1 und -Konversion ist nicht umkehrbar -nicht alle Farben sind in RGB darstellbar -offizielle Festlegungen sind z.T. nicht in RGB (wo bleibt da dann die Vergleichbarkeit?) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK / RGB - Versuch einer Zusammenfassung
2013/6/5 Martin Koppenhoefer dieterdre...@gmail.com: -Konversion ist nicht umkehrbar Ich nannte Eindeutigkeit und nicht Eineindeutigkeit. -nicht alle Farben sind in RGB darstellbar Das spricht nicht gegen eine eindeutige Abbildung im RGB-Raum -offizielle Festlegungen sind z.T. nicht in RGB (wo bleibt da dann die Vergleichbarkeit?) Vergleichbarkeit wurde von mir nicht angeführt. -- 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] CMYK / RGB - Versuch einer Zusammenfassung
On 05/giu/2013, at 14:52, Tobias Conradi mail.2...@tobiasconradi.com wrote: Weil er seine in den Raum gestellten Behauptungen untermauern will, da sie nicht den Rang eines Satzes des Pythagoras haben, auf dessen Herleitung man auch einfach mit einem Link zu Wikipedia https://de.wikipedia.org/wiki/Satz_des_Pythagoras verweisen kann. ein bisschen WP. lesen könnte Dir hier vielleicht auch helfen http://de.m.wikipedia.org/wiki/RGB-Farbraum z.B.: Für digitale Bilddaten eignet sich der RGB-Farbraum lediglich zur Darstellung am Bildschirm und den verwandten Gerätetypen. Bilddaten für den Druck (Offsetdruck, Siebdruck, Digitaldruck) sind in einem subtraktiven Farbmodell zu reproduzieren (CMY, CMYK) oder: Im RGB-Farbraum sind nicht alle Farbvalenzen enthalten. Insbesondere die gesättigten Spektralfarben erfordern negative Wiedergabeanteile (äußere Farbmischung), das wäre fehlendes Licht. oder: Ein RGB-Farbraum ist ein auf wenige, definierte Parameter begrenzter Ausschnitt der Wirklichkeit. Die Wahrnehmung eines „bunten“ Lichtes, einer „Oberfläche“, umfasst weitere Effekte. So könnte die Definition einer Farbe durch drei Zahlen die falsche Erwartung wecken, eine Farbe wäre in ihrer Wahrnehmung absolut bestimmt. Tatsächlich ist die Farbwirkung einer numerisch bestimmten RGB-Farbe dagegen vom konkret vorhandenen technischen System abhängig, das diese Farbe wiedergibt oder aufnimmt, und auch von den internen und externen Umgebungsbedingungen. Ein Beispiel: Die Farbwerte 100 % Rot, 50 % Grün und 0 % Blau (rgb = 255,127,0) ergeben ein Orange, die Nuance des Orange kann auch bei guter Voreinstellung auf verschiedenen Wiedergabegeräten sehr unterschiedlich aussehen. und auch: Es ist also für eine gute Farbdarstellung wichtig zu wissen, welche RGB-Norm eingesetzt wurde. alle vg. Zitate von der o.g. Wikip.seite, interessant ist aber ggf auch http://de.m.wikipedia.org/wiki/Farbreproduktion und die Seite zu CMYK und die zu RAL oder pantone Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK / RGB - Versuch einer Zusammenfassung
On 05/giu/2013, at 14:56, Tobias Conradi mail.2...@tobiasconradi.com wrote: -nicht alle Farben sind in RGB darstellbar Das spricht nicht gegen eine eindeutige Abbildung im RGB-Raum wenn einem eindeutig unzureichend ausreicht... Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK und RGB Farben - Standardisierung in OSM
2013/6/5 Peter Wendorff wendo...@uni-paderborn.de: Am 05.06.2013 13:45, schrieb Tobias Conradi: 2013/6/5 Wolfgang Hinsch osm-lis...@ivkasogis.de: Am Mittwoch, den 05.06.2013, 13:09 +0200 schrieb Tobias Conradi: 2013/6/5 Peter Wendorff wendo...@uni-paderborn.de: Wenn man keine will, dann nutzt/erstellt man (sich? anderen? allen?) einen Kartenstil, der die Farbe nicht nutzt, und fertig. Oder man löscht alle Farbtags in OSM .. und fertig. .. Wenn das einzige Ziel ist, keine Farben zu haben, dann ist Löschen der Farben wohl zielführend, nicht? Niemand hat argumentiert, es sollte keine Farben in OSM geben. http://lists.openstreetmap.org/pipermail/talk-de/2013-June/102605.html primär Vektordatenbank, Farben kaum eine Rolle, erst beim Rendern Darufhin habe ich gesagt [Für die U1 in Berlin] gibt es eine Farbangabe. Wenn man da keine will, dann könnte man das vielleicht technisch unterbinden, bzw. erstmal irgendwo definieren. Dann wurde gesagt, wenn man keine will, dann macht man das im Kartenstil und fertig. Das habe ich wieder zurückgedreht auf, dann kann man die auch in OSM löschen. Es ging ja nicht darum die nur beim Rendern zu unterdrücken, sondern um die konkreten Tags in der DB. Mit welchem Recht sollte irgendein Nutzer (z.B. Kartenstil-Entwickler) entscheiden, dass niemand die Farben will? Das kann niemand entscheiden. Aber es kann jemand entscheiden, dass sie nicht mehr in OSM gespeichert wird. Rechte dazu haben sicher einige Personen, so wie manche Personen ja auch im Wiki oder in den Emailarchiven Löschrechte haben, haben sicher auch manche Personen Softwareschreibrechte. Wenn Hans Huckebein eine ÖPNV-Karte machen und darin die colour-Tags zur Einfärbung der Linien nutzen will, kann er das tun. Klar. Mein Ziel ist hier, ÖPNV-Linien ohne Farben darzustellen, Gut. Dann gehörst Du nicht zu denen die von meinem Vorschlag zur Standardisierung direkt profitieren. Hier kommen wir zum Kern des Threads: Es ist eben abzuwägen: - Ein Farbschema festlegen (z.B. RGB) Dies ist bereits festgelegt: http://wiki.openstreetmap.org/wiki/Key:colour Annahme: Vor der Festlegung von RGB wurde RGB vorgeschlagen. Schlußfolgerung: Auch das Vorschlagen von RGB ist schon geschehen. Ich sehe hier nur eine Wiki-Seite. Kein Proposal, keine Abstimmung, kein gar nichts. Eine Festlegung in OSM sieht anders aus Wie? Natürlich muss nicht alles durch einen formalen Proposal-Tag gehen, aber das als festgelegt zu bezeichnen, wenn es ganz offensichtlichen Dissenz gibt (wie du hoffentlich mittlerweile gemerkt hast), Ich sehe weder auf der Wikiseite einen Dissenz noch in der realen Verwendung wie unter http://taginfo.openstreetmap.org/keys/colour#values einsehbar. und es keine Abstimmung gegeben hat (nichtmal eine kleine, wie es sie häufig gibt), Gibt es eine offizielle List über alle Abstimmungen anhand derer sich Deine Aussage überprüfen lässt? kann nun von einer Festlegung wirklich nicht die Rede sein. Eine Festlegung kann auch ohne Abstimmung erfolgen. Es genügt eine Person. Ansonsten könnte ich mal - spezifischer als du bisher Beweisführung! schreien, schreien? indem ich frage: Wo ist das denn FESTGELEGT? http://wiki.openstreetmap.org/wiki/Key:colour The value should be: * an RGB color code (hex triplet) ... * a CSS color name -- 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] CMYK / RGB - Versuch einer Zusammenfassung
2013/6/5 Martin Koppenhoefer dieterdre...@gmail.com: On 05/giu/2013, at 14:52, Tobias Conradi mail.2...@tobiasconradi.com wrote: Weil er seine in den Raum gestellten Behauptungen untermauern will, da sie nicht den Rang eines Satzes des Pythagoras haben, auf dessen Herleitung man auch einfach mit einem Link zu Wikipedia https://de.wikipedia.org/wiki/Satz_des_Pythagoras verweisen kann. ein bisschen WP. lesen könnte Dir hier vielleicht auch helfen http://de.m.wikipedia.org/wiki/RGB-Farbraum z.B.: Für digitale Bilddaten eignet sich der RGB-Farbraum lediglich zur Darstellung am Bildschirm und den verwandten Gerätetypen. Bilddaten für den Druck (Offsetdruck, Siebdruck, Digitaldruck) sind in einem subtraktiven Farbmodell zu reproduzieren (CMY, CMYK) oder: Im RGB-Farbraum sind nicht alle Farbvalenzen enthalten. Insbesondere die gesättigten Spektralfarben erfordern negative Wiedergabeanteile (äußere Farbmischung), das wäre fehlendes Licht. oder: Ein RGB-Farbraum ist ein auf wenige, definierte Parameter begrenzter Ausschnitt der Wirklichkeit. Die Wahrnehmung eines „bunten“ Lichtes, einer „Oberfläche“, umfasst weitere Effekte. So könnte die Definition einer Farbe durch drei Zahlen die falsche Erwartung wecken, eine Farbe wäre in ihrer Wahrnehmung absolut bestimmt. Tatsächlich ist die Farbwirkung einer numerisch bestimmten RGB-Farbe dagegen vom konkret vorhandenen technischen System abhängig, das diese Farbe wiedergibt oder aufnimmt, und auch von den internen und externen Umgebungsbedingungen. Ein Beispiel: Die Farbwerte 100 % Rot, 50 % Grün und 0 % Blau (rgb = 255,127,0) ergeben ein Orange, die Nuance des Orange kann auch bei guter Voreinstellung auf verschiedenen Wiedergabegeräten sehr unterschiedlich aussehen. und auch: Es ist also für eine gute Farbdarstellung wichtig zu wissen, welche RGB-Norm eingesetzt wurde. alle vg. Zitate von der o.g. Wikip.seite, interessant ist aber ggf auch http://de.m.wikipedia.org/wiki/Farbreproduktion und die Seite zu CMYK und die zu RAL oder pantone Habe in Deinen Zitaten nichts neues gesehen und sehe auch nicht, dass sie irgendeine meiner in den letzten zwei Wochen gemachten Behauptungen widerlegen. Sollte ein Zitat einer von mir aufgestellten Behauptung widersprechen, bitte ich um ein Zitat der Behauptung. -- 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] CMYK und RGB Farben - Standardisierung in OSM
On 05/giu/2013, at 15:16, Tobias Conradi mail.2...@tobiasconradi.com wrote: Aber es kann jemand entscheiden, dass sie nicht mehr in OSM gespeichert wird. so, wer denn? m ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK und RGB Farben - Standardisierung in OSM
On 05/giu/2013, at 15:16, Tobias Conradi mail.2...@tobiasconradi.com wrote: Eine Festlegung in OSM sieht anders aus Wie? in erster Linie ist es immer ein weitgehender Konsens oder zumindest akzeptierter Kompromiss Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK / RGB - Versuch einer Zusammenfassung
2013/6/5 Martin Koppenhoefer dieterdre...@gmail.com: -nicht alle Farben sind in RGB darstellbar Das spricht nicht gegen eine eindeutige Abbildung im RGB-Raum wenn einem eindeutig unzureichend ausreicht... http://lists.openstreetmap.org/pipermail/talk-de/2013-May/102567.html 5) erlaubt nur RGB. Wenn jemand mehr als RGB möchte, dann ist dies ausserhalb dessen, was mein Standardisierungsvorschlag erreichen möchte. Eindeutige Abbildung im RGB-Raum war als Gegensatz zu nicht eindeutiger Abbildung im RGB-Raum gemeint. Und RGB meint hier letztlich immer sRGB. https://de.wikipedia.org/wiki/SRGB http://www.w3.org/Graphics/Color/sRGB.html -- 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] CMYK und RGB Farben - Standardisierung in OSM
2013/6/5 Martin Koppenhoefer dieterdre...@gmail.com: Eine Festlegung in OSM sieht anders aus Wie? in erster Linie ist es immer ein weitgehender Konsens Ein Konsens ist nach meinem Verständnis der deutschen Sprache keine Festlegung. oder zumindest akzeptierter Kompromiss Ein akzeptierter Kompromiss ist nach meinem Verständnis der deutschen Sprache keine Festlegung. -- 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] CMYK und RGB Farben - Standardisierung in OSM
Am 05.06.2013 15:16, schrieb Tobias Conradi: 2013/6/5 Peter Wendorff wendo...@uni-paderborn.de: und es keine Abstimmung gegeben hat (nichtmal eine kleine, wie es sie häufig gibt), Gibt es eine offizielle List über alle Abstimmungen anhand derer sich Deine Aussage überprüfen lässt? Andersherum wird ein Schuh draus: Kannst Du eine Festlegung durch Abstimmung belegen? Üblicherweise steht sowas auf der Wikiseite in Form einer Abstimmung mit drauf (oder auf einer verwandten Wikiseite, die dann normalerweise verlinkt ist. kann nun von einer Festlegung wirklich nicht die Rede sein. Eine Festlegung kann auch ohne Abstimmung erfolgen. Es genügt eine Person. Klar - aber eine Festlegung durch eine Person ist wie die Befestigung eines 200kg-Bilderrahmens an einem einzigen kleinen Nagel: Man muss damit rechnen, dass das Bild wieder runterfällt oder die Festlegung eben nicht auf eine breite Mehrheit stößt. indem ich frage: Wo ist das denn FESTGELEGT? http://wiki.openstreetmap.org/wiki/Key:colour The value should be: * an RGB color code (hex triplet) ... * a CSS color name Die Vorgehensweise mit Proposal kennst Du aber? Ich weiß, sie ist nicht zwingend notwendig. Ich weiß auch, dass Proposals nur dadurch nicht zwingend besser werden oder eine höhere Relevanz genießen. Aber Ins Wiki schreiben kann jeder jederzeit beinahe alles, was er/sie/es will. Der colour-Tag ist so entsprechend dokumentiert worden, aber ob es sich dabei um eine Festlegung eine Meinung oder die Dokumentation der Verwendung durch einzelne handelt, ist zumindest nicht überprüfbar. Wenn dir eine Wiki-Seite reicht, kann ich dir gerne blödsinnige Wikiseiten suchen, die einfach niemanden im Detail interessieren, was der einzige Grund ist, warum sie nicht längst geändert oder gelöscht oder als abgestimmt und als abgelehnt dokumentiert markiert sind (siehe http://wiki.openstreetmap.org/wiki/Category:Proposed_features_%22Rejected%22 ). Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Datenmodell für Signalzeitenplan
Hallo, ich möchte Euch bitten den Vorschlag Traffic Lights Program http://wiki.openstreetmap.org/wiki/DE:Proposed_features/GLOSA auf der Diskussionsseite zu kommentieren/verbessern. Meine früheren Beiträge zum Thema: http://lists.openstreetmap.org/pipermail/talk-de/2013-February/100910.html http://forum.openstreetmap.org/viewtopic.php?id=20041 http://lists.openstreetmap.org/pipermail/talk/2013-May/067074.html Gruß Martin signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK und RGB Farben - Standardisierung in OSM
2013/6/5 Peter Wendorff wendo...@uni-paderborn.de: Am 05.06.2013 15:16, schrieb Tobias Conradi: 2013/6/5 Peter Wendorff wendo...@uni-paderborn.de: und es keine Abstimmung gegeben hat (nichtmal eine kleine, wie es sie häufig gibt), Gibt es eine offizielle List über alle Abstimmungen anhand derer sich Deine Aussage überprüfen lässt? Andersherum wird ein Schuh draus: Kannst Du eine Festlegung durch Abstimmung belegen? Nein, daher hatte ich auch geschrieben Annahme: ... Du hast behauptet es hätte keine gegeben. kann nun von einer Festlegung wirklich nicht die Rede sein. Eine Festlegung kann auch ohne Abstimmung erfolgen. Es genügt eine Person. Klar - aber eine Festlegung durch eine Person ist wie die Befestigung eines 200kg-Bilderrahmens an einem einzigen kleinen Nagel: Man muss damit rechnen, dass das Bild wieder runterfällt oder die Festlegung eben nicht auf eine breite Mehrheit stößt. Definition in RGB existiert auf dieser Seite seit 2010 http://wiki.openstreetmap.org/w/index.php?title=Key:colouroldid=465809 brown, green, red, white, gray, blue, yellow, black haben laut http://taginfo.openstreetmap.org/keys/colour#values einen Anteil von mehr als 66% an den Tagwerten. Sie sind alle als CSS3 color unter http://www.w3.org/TR/css3-color/#svg-color aufgeführt. indem ich frage: Wo ist das denn FESTGELEGT? http://wiki.openstreetmap.org/wiki/Key:colour The value should be: * an RGB color code (hex triplet) ... * a CSS color name Die Vorgehensweise mit Proposal kennst Du aber? Nein. Aber ich sehe jetzt: http://wiki.openstreetmap.org/wiki/Creating_a_proposal Danke. Aber Ins Wiki schreiben kann jeder jederzeit beinahe alles, was er/sie/es will. OK. Der colour-Tag ist so entsprechend dokumentiert worden, aber ob es sich dabei um eine Festlegung eine Meinung oder die Dokumentation der Verwendung durch einzelne handelt, ist zumindest nicht überprüfbar. Zumindest nicht allein auf dieser Seite. Wenn dir eine Wiki-Seite reicht, kann ich dir gerne blödsinnige Wikiseiten suchen, die einfach niemanden im Detail interessieren, was der einzige Grund ist, warum sie nicht längst geändert oder gelöscht oder als abgestimmt und als abgelehnt dokumentiert markiert sind OK. Danke. Wenn ich http://wiki.openstreetmap.org/wiki/Keys The value [...] describes its accompanying key. sehe, glaube ich gern, dass solche Seiten existieren. colour=black Black beschreibt den Key colour? (siehe http://wiki.openstreetmap.org/wiki/Category:Proposed_features_%22Rejected%22 ). Diese sind ja immerhin als rejected kategorisiert. Also wenn Key:colour keine offizielle Beschreibung für den Key colour enthält, dann gibt es wohl keine? -- 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] CMYK und RGB Farben - Standardisierung in OSM
Am 05.06.2013 um 15:46 schrieb Peter Wendorff wendo...@uni-paderborn.de: Wenn dir eine Wiki-Seite reicht, kann ich dir gerne blödsinnige Wikiseiten suchen, die einfach niemanden im Detail interessieren, was der einzige Grund ist, warum sie nicht längst geändert oder gelöscht oder als abgestimmt und als abgelehnt dokumentiert markiert sind (siehe http://wiki.openstreetmap.org/wiki/Category:Proposed_features_%22Rejected%22 ). Wobei selbst ein Eintrag auf dieser Liste nicht immer eindeutig ist, z.B. hier: http://wiki.openstreetmap.org/wiki/Proposed_features/Incline Nur weil es damals 2007 noch nicht möglich war, 15 Leute zur Abstimmung zu bewegen, heißt das ja noch nicht, dass dieser Vorschlag auch in der Zwischenzeit von den Mappern abgelehnt wird: http://taginfo.openstreetmap.org/keys/incline Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK / RGB - Versuch einer Zusammenfassung
Tobias Conradi mail.2...@tobiasconradi.com wrote: Dir ist aber schon klar, dass es Eindeutigkeit in croudsourcing Projekten wie OSM sowieso nie geben wird? Nein. Dann solltest du Dir das dringend klarmachen, denn sonst kämpfst Du gegen Windmühlen? Ich finde das ja ehrlich gesagt alles massiv überspezifiziert. Einfach die Klartextnamen aus rgb.txt verwenden und gut iss. Wo befindet sich diese Datei um den Wahrheitsgehalt der Aussage überprüfen zu können? Auf einem brauchbaren Betriebssystem unter /etc/X11/rgb.txt http://en.wikipedia.org/wiki/X11_color_names Im wesentlichen sind das definierte sprechende Namen für RGB Farbwerte. Da das Web aus dem Unix Dunstkreis stammt wird das AFAIK auch in HTML so verwendet. Gruss Sven -- Der normale Bürger ist nicht an der TU Dresden und schreibt auch nicht mit mutt. (Ulli Kuhnle in de.comp.os.unix.discussion) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Linie endet an Gebiet
Hallo alle zusammen ! Ich bin gerade dabei mich in ins Kartenerstellen einzuarbeiten und habe ein Problem. Ich habe die Straße Stettiner Straße korrigiert udn erhalte von JOSM die Warnung: Linie endet an Gebiet Ich habe leider keine Ahnung wie ich das Problem lösen soll da ich nicht verstehe was hier kaputt sein soll. Ich bitte um Hilfe. Ort: 23669 Timmendorfer Strand, Königsberger Straße auf Stettiner Straße Grüße Zafe ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK / RGB - Versuch einer Zusammenfassung
Am 5. Juni 2013 16:42 schrieb Sven Geggus li...@fuchsschwanzdomain.de: Im wesentlichen sind das definierte sprechende Namen für RGB Farbwerte. Interessanterweise ist in dieser Datei Silber und Grau dasselbe ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK / RGB - Versuch einer Zusammenfassung
2013/6/5 Sven Geggus li...@fuchsschwanzdomain.de: Tobias Conradi mail.2...@tobiasconradi.com wrote: Dir ist aber schon klar, dass es Eindeutigkeit in croudsourcing Projekten wie OSM sowieso nie geben wird? Nein. Dann solltest du Dir das dringend klarmachen, denn sonst kämpfst Du gegen Windmühlen? Nur wenn jede Kampf für eine Sache, der nicht mit einem Sieg endet ein Kampf gegen Windmühlen ist, läge ein solcher Kampf gegen Winmühlen vor, falls es nie zu Eindeutigkeit in crowdsourcing Projekten wie OSM kommt. Ich finde das ja ehrlich gesagt alles massiv überspezifiziert. Einfach die Klartextnamen aus rgb.txt verwenden und gut iss. Wo befindet sich diese Datei um den Wahrheitsgehalt der Aussage überprüfen zu können? Auf einem brauchbaren Betriebssystem unter /etc/X11/rgb.txt Auf einem von mir gebrauchten System nicht gefunden. http://en.wikipedia.org/wiki/X11_color_names Im wesentlichen sind das definierte sprechende Namen für RGB Farbwerte. OK. Wie wandelt man einen von einem Verkehrsunternehmen gegebenen CMYK-Wert in einen solchen sprechenden Namen um? Würfeln? Oder mit Hilfe einer eindeutigen Abbildung? Da das Web aus dem Unix Dunstkreis stammt wird das AFAIK auch in HTML so verwendet. Nicht laut dem Artikel http://en.wikipedia.org/wiki/X11_color_names -- 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] Linie endet an Gebiet
MVX m...@gulli.com wrote: Ich habe die Straße Stettiner Straße korrigiert udn erhalte von JOSM die Warnung: Linie endet an Gebiet Rechtklick auf den Fehler und Zoom auf Problem (oder ähnliche Formulierung), um die betroffenen Objekte zu sehen. Warnungen sind nur mögliche aber keine zwingenden Fehler und können übergangen werden. Offenbar waren die Programmierer von JOM der Meinung, dass an Gebieten endende Linien Fehlerpotential haben. Endet aber beispielsweise ein Fußweg am Eingang eines Gebäudes, so ist da nichts zu bemängeln. Wäre es eine Autobahn, wird das Ganze schon fraglicher. Genaueres kann hier nur gesagt werden, wenn Du die IDs der betroffenen Objekte nennst. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK / RGB - Versuch einer Zusammenfassung
Tobias Conradi mail.2...@tobiasconradi.com wrote: Auf einem von mir gebrauchten System nicht gefunden. Na ja, auf Windows gibts das nicht, aber jedes Unix mit X11 hat das irgendwo. OK. Wie wandelt man einen von einem Verkehrsunternehmen gegebenen CMYK-Wert in einen solchen sprechenden Namen um? Ehrlich gesagt ist mir das völlig egal, denn OSM hat wirklich wichtigere Probleme zu lösen als dieses obskure Nieschenthema von ÖPNV Farben die ohnehin nicht mal jeder verwendet. Daher ist das mein letzes Posting zu diesem Thema. Da das Web aus dem Unix Dunstkreis stammt wird das AFAIK auch in HTML so verwendet. Nicht laut dem Artikel http://en.wikipedia.org/wiki/X11_color_names Aha, wo wir also schon beim haare Spalten sind: The first versions of Mosaic and Netscape Navigator used the X11 colors as the basis for the Web colors list Leider erläutert der Artikel some changes nicht näher. Ich habe aber in der Praxis noch keine Unterschiede zwischen CSS und rgb.txt festgestellt. Gruss Sven -- We just typed make (Stephen Lambrigh, Director of Server Product Marketing at Informix about porting their Database to Linux) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Linie endet an Gebiet
Hi, du meinst das hier? http://www.openstreetmap.org/?lat=53.988759lon=10.766189zoom=18layers=M In der aktuellen Fassung ist hier nichts falsch. Was hast du denn geändert? erhalte von JOSM die Warnung: Linie endet an Gebiet Diese Meldung bedeutet, dass die Straße mit einem landuse oder anderen Fläche verbunden ist, die kein highway=* ist. Hmm.. Wenn ich mir das BING -Bild hier anschaue ist das landuse=gras der Fläche entlang der Danziger Allee falsch, das sind doch offenbar Parkplätze und Bäume. Gruß, Micha. On Wednesday 05 June 2013 16:51:35 MVX wrote: Hallo alle zusammen ! Ich bin gerade dabei mich in ins Kartenerstellen einzuarbeiten und habe ein Problem. Ich habe die Straße Stettiner Straße korrigiert udn erhalte von JOSM die Warnung: Linie endet an Gebiet Ich habe leider keine Ahnung wie ich das Problem lösen soll da ich nicht verstehe was hier kaputt sein soll. Ich bitte um Hilfe. Ort: 23669 Timmendorfer Strand, Königsberger Straße auf Stettiner Straße Grüße Zafe ___ 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] Linie endet an Gebiet
Ahh okay, dann scheint ja alles gut zu sein. Vielen Dank schon einmal. Hier trotzdem nochmal die IDs: * 36775954 * 136489404 Grüße Zafe Am 05.06.2013 17:53, schrieb Tirkon: MVX m...@gulli.com wrote: Ich habe die Straße Stettiner Straße korrigiert udn erhalte von JOSM die Warnung: Linie endet an Gebiet Rechtklick auf den Fehler und Zoom auf Problem (oder ähnliche Formulierung), um die betroffenen Objekte zu sehen. Warnungen sind nur mögliche aber keine zwingenden Fehler und können übergangen werden. Offenbar waren die Programmierer von JOM der Meinung, dass an Gebieten endende Linien Fehlerpotential haben. Endet aber beispielsweise ein Fußweg am Eingang eines Gebäudes, so ist da nichts zu bemängeln. Wäre es eine Autobahn, wird das Ganze schon fraglicher. Genaueres kann hier nur gesagt werden, wenn Du die IDs der betroffenen Objekte nennst. ___ 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] Linie endet an Gebiet
Am 05.06.2013 16:51, schrieb MVX: Hallo alle zusammen ! Ich bin gerade dabei mich in ins Kartenerstellen einzuarbeiten und habe ein Problem. Ich habe die Straße Stettiner Straße korrigiert udn erhalte von JOSM die Warnung: Linie endet an Gebiet Ich habe leider keine Ahnung wie ich das Problem lösen soll da ich nicht verstehe was hier kaputt sein soll. Ich bitte um Hilfe. Ort: 23669 Timmendorfer Strand, Königsberger Straße auf Stettiner Straße Grüße Zafe ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Hallo Zafe, nimm nachfolgendes Video als Anleitung, um unerwünschte Linien aus zu filtern: * O http://youtu.be/zGT3Eco6vZASM Tutorial No 02 - Die OpenStreetMap-Karte in JOSM übersichtler machen (Linien filtern) http://youtu.be/zGT3Eco6vZA Gruß -Franz- weitere Videos von Skobbler gitbt es *hier* https://www.youtube.com/user/tutorialsbyskobbler ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Linie endet an Gebiet
Hallo, Am Mittwoch, den 05.06.2013, 16:51 +0200 schrieb MVX: Hallo alle zusammen ! Ich bin gerade dabei mich in ins Kartenerstellen einzuarbeiten und habe ein Problem. Ich habe die Straße Stettiner Straße korrigiert udn erhalte von JOSM die Warnung: Linie endet an Gebiet Ich habe leider keine Ahnung wie ich das Problem lösen soll da ich nicht verstehe was hier kaputt sein soll. Ich bitte um Hilfe. Ort: 23669 Timmendorfer Strand, Königsberger Straße auf Stettiner Straße es ist für alle hilfreich, wenn du die ID-Nummer mindestens eines der Objekte angibst oder wenigstens einen Perma-Link im Mapnik. Ich habe die Stelle gefunden. Es ist alles in Ordnung, wenngleich die Grünfläche innerhalb der Danziger Allee nicht unbedingt im Mainstream getaggt ist. Die Grünfläche (Gebiet) wird auf 3 Seiten durch die Danziger Allee und auf der Südseite durch die Stettiner Straße begrenzt. Es ist eigentlich in Fehler in der Fehlerprüfung von josm, der erkennen sollte, dass es sehr wohl einen weiterführenden Weg gibt. In dem Fall sollte er das Gebiet unbeachtet lassen. Ca. 80% der Warnungen von josm kann man getrost wegklicken, aber der Anfänger weiß natürlich nicht, welche... Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Linie endet an Gebiet
Okay, dann liegt das Problem nur daran das die Straße an einer landuse Fläche grenzt. Die Karte an der Stelle müsste mal detaillierter werden. In Wirklichkeit ist das eine Rasenfläche mit Bäumen und 2 Parkflächen für ein paar Autos. Immerhin sind die Straßen nun schon einmal die richtigen. @ Franz-Josef Rüther: Danke für die Videos ! Sind Hilfreich Grüße Zafe Am 05.06.2013 18:02, schrieb Michael Hufer: Hi, du meinst das hier? http://www.openstreetmap.org/?lat=53.988759lon=10.766189zoom=18layers=M In der aktuellen Fassung ist hier nichts falsch. Was hast du denn geändert? erhalte von JOSM die Warnung: Linie endet an Gebiet Diese Meldung bedeutet, dass die Straße mit einem landuse oder anderen Fläche verbunden ist, die kein highway=* ist. Hmm.. Wenn ich mir das BING -Bild hier anschaue ist das landuse=gras der Fläche entlang der Danziger Allee falsch, das sind doch offenbar Parkplätze und Bäume. Gruß, Micha. On Wednesday 05 June 2013 16:51:35 MVX wrote: Hallo alle zusammen ! Ich bin gerade dabei mich in ins Kartenerstellen einzuarbeiten und habe ein Problem. Ich habe die Straße Stettiner Straße korrigiert udn erhalte von JOSM die Warnung: Linie endet an Gebiet Ich habe leider keine Ahnung wie ich das Problem lösen soll da ich nicht verstehe was hier kaputt sein soll. Ich bitte um Hilfe. Ort: 23669 Timmendorfer Strand, Königsberger Straße auf Stettiner Straße Grüße Zafe ___ 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 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Widersprüche zwischen Wiki-Definition und Mapnik-Rendering
Am 05.06.2013 01:47, schrieb Martin Koppenhoefer: Das Problem ist, wie osm2pgsql arbeitet, man kann nur keys als Fläche zuordnen, aber nicht k/v-Paare, d.h. im Zweifel wird man eher ein Liniendefault setzen und nur mit area=yes auf Fläche gehen, weil sonst so was wie bei leisure=track passiert (leisure wird immer als area angesehen). Als Lösung kann man auf einen Area-Datentyp hoffen, oder darauf, dass man auch k/v-Kombinationen in osm2pgsql styles definieren kann. Oder z.B. einen anderen Importer verwenden, Imposm kann das vielleicht? Danke für die schnelle Antwort. Es war mir nicht klar, dass osm2pgsql diese Einschränkung hat. Es ist schade, dass ein Tool, welches für die Hauptkarte wichtig ist, die elementaren Definitionen nicht korrekt umsetzen kann. Trotzdem sollte es doch möglich sein, Objekte wie highway=services, highway=rest_area und railway=station, die in der line-Datenbanktabelle landen, aber nur als Fläche definiert sind, auch als Fläche zu rendern. Für leisure=track könnte man trotz Flächenzuordnung nur die Außenlinie ohne Füllung malen. Dann hätte man trotz der falschen Zuordnung durch osm2pgsql eine korrekte Kartendarstellung. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK und RGB Farben - Standardisierung in OSM
Am 05.06.2013 16:26, schrieb Tobias Conradi: 2013/6/5 Peter Wendorff wendo...@uni-paderborn.de: Am 05.06.2013 15:16, schrieb Tobias Conradi: 2013/6/5 Peter Wendorff wendo...@uni-paderborn.de: und es keine Abstimmung gegeben hat (nichtmal eine kleine, wie es sie häufig gibt), Gibt es eine offizielle List über alle Abstimmungen anhand derer sich Deine Aussage überprüfen lässt? Andersherum wird ein Schuh draus: Kannst Du eine Festlegung durch Abstimmung belegen? Nein, daher hatte ich auch geschrieben Annahme: ... Du hast behauptet es hätte keine gegeben. Um mal dein Selbst-Zitat zu vervollständigen: Annahme: Vor der Festlegung von RGB wurde RGB vorgeschlagen. Schlußfolgerung: Auch das Vorschlagen von RGB ist schon geschehen. Du definierst etwas als Festlegung unter der Annahme, es hätte vorher einen Vorschlag gegeben. Fakt ist eine Wiki-Seite, die weder als Vorschlag noch als abgestimmte Festlegung deklariert (geschweige denn belegt ist). In OSM ist üblich: - Einfach mal machen (ohne Dokumentation) - Dokumentation dessen, was da, aber noch nicht dokumentiert ist - Proposal mit dem Ablauf: - Draft: Entwurfszeit - RFC: Nach Meinungen fragen - das iteriert dann beliebig häufig, wenn Meinungen, Kommentare, Vorschläge eingearbeitet werden - Abstimmung - evtl. trotzdem nochmal Rücksetzung bei neuen Einwänden/Vorschlägen... - Annahme durch Abstimmen oder - Ablehnung durch Abstimmen, dann oft zurück auf einen der vorigen Schritte. Alle diese Schritte manifestieren sich üblicherweise auf der/einer Wiki-Seite, da die Bearbeitung derselben das Mittel der Wahl zur Stimmabgabe und die Bearbeitung der zugehörigen Talk-Seite eines der Mittel für Meinungen und Kommentare dazu ist. In diesem Fall fehlt eine Diskussion auf der Talk-seite genauso wie ein Proposal-Template, eine Abstimmung oder sonstwas in der Art. Eine Festlegung durch ich lege eine Seite an und die Seite wird durch niemanden beanstandet ist glaub ich bei der Mehrheit nicht akzeptabel - sobald jemand das als Fakt und Festlegung heranziehen will, um Regeln daraus abzuleiten. Als Dokumentation und Diskussionsgrundlage für eine spätere Einigung immer und gerne - aber eben nicht als Regel/Gesetz. Der colour-Tag ist so entsprechend dokumentiert worden, aber ob es sich dabei um eine Festlegung eine Meinung oder die Dokumentation der Verwendung durch einzelne handelt, ist zumindest nicht überprüfbar. Zumindest nicht allein auf dieser Seite. Wenn dir eine Wiki-Seite reicht, kann ich dir gerne blödsinnige Wikiseiten suchen, die einfach niemanden im Detail interessieren, was der einzige Grund ist, warum sie nicht längst geändert oder gelöscht oder als abgestimmt und als abgelehnt dokumentiert markiert sind OK. Danke. Wenn ich http://wiki.openstreetmap.org/wiki/Keys The value [...] describes its accompanying key. sehe, glaube ich gern, dass solche Seiten existieren. colour=black Black beschreibt den Key colour? Schwarz beschreibt die Farbe, ja. Ein Haus hat eine Farbe (hat den key color), und Wie ist die Farbe? Schwarz! = Schwarz beschreibt die Eigenschaft Farbe. (siehe http://wiki.openstreetmap.org/wiki/Category:Proposed_features_%22Rejected%22 ). Diese sind ja immerhin als rejected kategorisiert. Also wenn Key:colour keine offizielle Beschreibung für den Key colour enthält, dann gibt es wohl keine? So ungefähr. Das muss ja auch nicht heißen, dass das falsch ist, es muss nichtmal unbedingt heißen, dass deine Meinung dazu falsch ist (die sich zufällig auch aus dem aktuellen Text im Wiki herleiten lässt), aber es heißt eben auch nicht unbedingt, dass das so feststehend die Regel ist. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK / RGB - Versuch einer Zusammenfassung
2013/6/5 Sven Geggus li...@fuchsschwanzdomain.de: Tobias Conradi mail.2...@tobiasconradi.com wrote: OK. Wie wandelt man einen von einem Verkehrsunternehmen gegebenen CMYK-Wert in einen solchen sprechenden Namen um? Ehrlich gesagt ist mir das völlig egal, Dann ist Deine Abbildung im Gegensatz zu der von mir vorgeschlagenen nicht eindeutig. Eine allgemein als Lila bekannte Linie könnte bei Dir den Wert 00 http://www.colorcombos.com/colors/00 -- 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] Datenmodell für Signalzeitenplan
Martin Schafran mar...@ampelmeter.com wrote: ich möchte Euch bitten den Vorschlag Traffic Lights Program http://wiki.openstreetmap.org/wiki/DE:Proposed_features/GLOSA auf der Diskussionsseite zu kommentieren/verbessern. Meine früheren Beiträge zum Thema: http://lists.openstreetmap.org/pipermail/talk-de/2013-February/100910.html http://forum.openstreetmap.org/viewtopic.php?id=20041 http://lists.openstreetmap.org/pipermail/talk/2013-May/067074.html Sorry, aber das ist vollkommen unbrauchbar für OSM, da von der großen Mehrheit der Mapper nicht umsetzbar. Wir haben mit den ÖPNV Schemata prominente Vertreter, wo das Ganze auch nicht funktioniert. Der ÖPNV wird inzwischen in unzähligen Varianten gemappt und verbrennt dabei jede Menge Tags. Möglicherweise kann man solche aufwendigen Konstrukte in einer Firma mit entsprechend vorgebildeten und auf die Konzepte geschulten Mitarbeitern einführen. Aber in einer Community wie OSM haben sie IMHO nichts zu suchen. Wenn man schon über etwas abstimmen lässt, sollte man wenigstens darüber nachdenken, dass nicht nur die kleine Gruppe der Diskutanten, sondern auch Tausende fachfremde Mapper dies umsetzen sollen, die keinerlei Informatik- oder Mathematikausbildung genossen haben. Aber ohne diese Mapper funktioniert OSM nicht. Zudem werden hier unnötigerweise Bezeichnungen für Tags und damit Ressourcen verbrannt, die an anderer Stelle nicht mehr zur Verfügung stehen. Außerdem ist das Wiki dann bald eine Müllhalde voller Fast-Leichen-Proposals, deren punktuelle Anwendung in der Datenbank lediglich darauf stoßende Mapper abschreckt, wenn sie einfache Änderungen deswegen nicht mehr durchführen können. Ja ich weiß: OSM ist frei und jeder soll in die OSM eintragen, was er möchte. Aber wenn die Betätigung Weniger zu einer Behinderung Vieler führt, muss über die Verteilung der Ressourcen nachgedacht werden. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] osm website: Schnellsuche Firefox
Aus irgend einem Grund funktioniert es nicht mit Firefox eine Schnellsuche für
OSM anzulegen. Das ist schade, ich würde gerne in die adresszeile osm
{adresse} ingeben können und dann gleich zur ergebnisseite zu gelangen.
für nicht firefox user: über die schnellsuche (kontextmenü auf ein
formularfeld) lassen sich shortcuts anlegen, die man dann direkt in die
adresszeile eingeben kann.
m.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK / RGB - Versuch einer Zusammenfassung
On 05.06.2013 17:53, Sven Geggus wrote: Leider erläutert der Artikel some changes nicht näher. Doch, in der Tabelle der Farbnamen findet man die Unterschiede: Gray, Green, Maroon und Purple sind beim W3C anders definiert als bei X11 und die Farben Lime und Silver gibt es nur beim W3C. Gruß, Mark ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK und RGB Farben - Standardisierung in OSM
2013/6/5 Peter Wendorff wendo...@uni-paderborn.de: Am 05.06.2013 16:26, schrieb Tobias Conradi: 2013/6/5 Peter Wendorff wendo...@uni-paderborn.de: Am 05.06.2013 15:16, schrieb Tobias Conradi: 2013/6/5 Peter Wendorff wendo...@uni-paderborn.de: und es keine Abstimmung gegeben hat (nichtmal eine kleine, wie es sie häufig gibt), Diese Behauptung ist immer noch unbelegt. Kannst Du eine Festlegung durch Abstimmung belegen? Nein, daher hatte ich auch geschrieben Annahme: ... Du hast behauptet es hätte keine gegeben. Um mal dein Selbst-Zitat zu vervollständigen: Annahme: Vor der Festlegung von RGB wurde RGB vorgeschlagen. Schlußfolgerung: Auch das Vorschlagen von RGB ist schon geschehen. Du definierst etwas als Festlegung unter der Annahme, es hätte vorher einen Vorschlag gegeben. Nein. Fakt ist eine Wiki-Seite, die weder als Vorschlag noch als abgestimmte Festlegung deklariert (geschweige denn belegt ist). OK. Da steht also im offiziellen OSM Wiki The value should be: ..., es ist aber nicht belegt, dass dies stimmt. In OSM ist üblich: - Einfach mal machen (ohne Dokumentation) - Dokumentation dessen, was da, aber noch nicht dokumentiert ist - Proposal mit dem Ablauf: - Draft: Entwurfszeit - RFC: Nach Meinungen fragen - das iteriert dann beliebig häufig, wenn Meinungen, Kommentare, Vorschläge eingearbeitet werden - Abstimmung - evtl. trotzdem nochmal Rücksetzung bei neuen Einwänden/Vorschlägen... - Annahme durch Abstimmen oder - Ablehnung durch Abstimmen, dann oft zurück auf einen der vorigen Schritte. Alle diese Schritte manifestieren sich üblicherweise auf der/einer Wiki-Seite, da die Bearbeitung derselben das Mittel der Wahl zur Stimmabgabe und die Bearbeitung der zugehörigen Talk-Seite eines der Mittel für Meinungen und Kommentare dazu ist. Ausser Schritt 1. In diesem Fall fehlt eine Diskussion auf der Talk-seite genauso wie ein Proposal-Template, eine Abstimmung oder sonstwas in der Art. Vielleicht ist es noch ein Schritt, den Du nicht kanntest. http://wiki.openstreetmap.org/wiki/Proposed_features This page describes the proposal process, which is one of multiple ways to introduce [...] new features. Eine Festlegung durch ich lege eine Seite an und die Seite wird durch niemanden beanstandet ist glaub ich bei der Mehrheit nicht akzeptabel - sobald jemand das als Fakt und Festlegung heranziehen will, um Regeln daraus abzuleiten. Als Dokumentation und Diskussionsgrundlage für eine spätere Einigung immer und gerne - aber eben nicht als Regel/Gesetz. Da ist ein Text, der sagt seit 2010 should. Und hinter should kommt nie etwas anders als ein sRGB Wert. Das war's. Es kann ein Witz sein den sich jemand erlaubt, es kann irgendwas sein. Eine Festlegung soll es aber nicht sein. Dafür was eine Festlegung sein soll, wurde keine offizielle OSM Seite zitiert. Dann nehm ich mal den Duden http://www.duden.de/rechtschreibung/Festlegung Synonyme: Aufstellung, Bestimmung, Ordnung, Regel should be ist für mich eindeutig eine Festlegung, Bestimmung, Regel. Wenn ich http://wiki.openstreetmap.org/wiki/Keys The value [...] describes its accompanying key. sehe, glaube ich gern, dass solche Seiten existieren. colour=black Black beschreibt den Key colour? Schwarz beschreibt die Farbe, ja. Ein Haus hat eine Farbe (hat den key color), und Wie ist die Farbe? Schwarz! = Schwarz beschreibt die Eigenschaft Farbe. Wenn kein Objekt angegeben ist, dann lautet die Antwort auf die Frage, wie ist die Farbe: Einer von 3247 Werten. Quelle: http://taginfo.openstreetmap.org/keys/colour#overview Black ist nur bedingt korrekt, somit keine Beschreibung des Keys. Also wenn Key:colour keine offizielle Beschreibung für den Key colour enthält, dann gibt es wohl keine? So ungefähr. Das muss ja auch nicht heißen, dass das falsch ist, es muss nichtmal unbedingt heißen, dass deine Meinung dazu falsch ist (die sich zufällig auch aus dem aktuellen Text im Wiki herleiten lässt), aber es heißt eben auch nicht unbedingt, dass das so feststehend die Regel ist. Das es zur Zeit die Regel ist ergibt sich aus http://taginfo.openstreetmap.org/keys/colour#values Ich sehe nur Werte wie sie hinter should be angegeben 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] osm website: Schnellsuche Firefox
Versuch mal das entsprechende Lesezeichen manuell auf
http://www.openstreetmap.org/?query=%s; zu setzen (statt
http://www.openstreetmap.org/geocoder/search;).
PS: Das gleiche Feature gibt es auch im Opera - super praktisch!
Am 05.06.2013, 18:47 Uhr, schrieb Max abonneme...@revolwear.com:
Aus irgend einem Grund funktioniert es nicht mit Firefox eine
Schnellsuche für OSM anzulegen. Das ist schade, ich würde gerne in die
adresszeile osm {adresse} ingeben können und dann gleich zur
ergebnisseite zu gelangen.
für nicht firefox user: über die schnellsuche (kontextmenü auf ein
formularfeld) lassen sich shortcuts anlegen, die man dann direkt in die
adresszeile eingeben kann.
m.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK und RGB Farben - Standardisierung in OSM
Am 05.06.2013 19:17, schrieb Tobias Conradi: In diesem Fall fehlt eine Diskussion auf der Talk-seite genauso wie ein Proposal-Template, eine Abstimmung oder sonstwas in der Art. Vielleicht ist es noch ein Schritt, den Du nicht kanntest. http://wiki.openstreetmap.org/wiki/Proposed_features Jetzt führst du eine Quelle an die deine Aussage nichtmal stützt? Ich sehe da für ein Proposal die Schritte: Draft, Proposed, Voting, Approved or rejected, Post-vote clean-up Schon beim Draft wird das Proposal-Template (mit Status Draft) eingefügt, das dann auch bleibt bis zum Approved/rejected. Im Post-Vote wird die Proposal-Seite so gelassen und die Key-Page hinzugefügt, die beiden Seiten sollten dabei in beide Richtungen verlinkt werden - was hier nicht geschehen ist. Und nicht nur fehlt der Link, ich kann die Proposal-Seite auch sonst nirgendwo finden. Also: - Draft, proposed, Voting, Approved und rejected müssten demnach dann ein Proposal_template haben, - Post-vote müsste einen Link zu einem Proposal mit dem Status approved oder rejected haben. Da das jeweils fehlt, weiß ich nicht, welchen Schritt du meinst, den ich übersehen haben sollte. This page describes the proposal process, which is one of multiple ways to introduce [...] new features. Stimmt. Aber to introduce a feature ist nicht Ein Merkmal FESTLEGEN, sondern ein Merkmal EINFÜHREN, und eine Einführung ohne Abstimmung etc. ist eben keine Festlegung, auf die irgendjemand sich beziehen sollte, um seine Meinung durchzusetzen (zu argumentieren ja, daraus zwingend durchzusetzen nein). Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] osm website: Schnellsuche Firefox
Super, danke! Funktioniert :) Gruß René ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wochennotiz Nr. 150 28.5.-3.6.2013
Hallo, die Wochennotiz Nr. 150 mit allen wichtigen Neuigkeiten aus der OpenStreetMap Welt ist da: http://blog.openstreetmap.de/2013/06/wochennotiz-nr-150/ Viel Spaß beim Lesen! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenmodell für Signalzeitenplan
Am Mittwoch, den 05.06.2013, 18:36 +0200 schrieb Tirkon: Martin Schafran mar...@ampelmeter.com wrote: ich möchte Euch bitten den Vorschlag Traffic Lights Program http://wiki.openstreetmap.org/wiki/DE:Proposed_features/GLOSA auf der Diskussionsseite zu kommentieren/verbessern. Meine früheren Beiträge zum Thema: http://lists.openstreetmap.org/pipermail/talk-de/2013-February/100910.html http://forum.openstreetmap.org/viewtopic.php?id=20041 http://lists.openstreetmap.org/pipermail/talk/2013-May/067074.html Sorry, aber das ist vollkommen unbrauchbar für OSM, da von der großen Mehrheit der Mapper nicht umsetzbar. Wir haben mit den ÖPNV Schemata prominente Vertreter, wo das Ganze auch nicht funktioniert. Der ÖPNV wird inzwischen in unzähligen Varianten gemappt und verbrennt dabei jede Menge Tags. Möglicherweise kann man solche aufwendigen Konstrukte in einer Firma mit entsprechend vorgebildeten und auf die Konzepte geschulten Mitarbeitern einführen. Aber in einer Community wie OSM haben sie IMHO nichts zu suchen. Wenn man schon über etwas abstimmen lässt, sollte man wenigstens darüber nachdenken, dass nicht nur die kleine Gruppe der Diskutanten, sondern auch Tausende fachfremde Mapper dies umsetzen sollen, die keinerlei Informatik- oder Mathematikausbildung genossen haben. Aber ohne diese Mapper funktioniert OSM nicht. Zudem werden hier unnötigerweise Bezeichnungen für Tags und damit Ressourcen verbrannt, die an anderer Stelle nicht mehr zur Verfügung stehen. Das mit der tag-Verbrennung sehe ich eigentlich nicht so. Die sind doch reichlich speziell, da verirrt sich so leicht keiner in den Namensraum. Ansonsten +1 Ich halte das Ganze schon von der Idee her für Unsinn. Vor 15 Jahren hätte man so etwas machen können, wenn man die Technik gehabt hätte. Heute haben wir die Technik, aber die Ampeln werden zu kompliziert. In der Sache dürfte das so zuverlässig sein, wie der Wetterbericht um 1970. Die Feuerwehr pumpte einen halben Meter heiter bis wolkig aus dem Keller :-) Die Ampeln werden immer mehr von der Verkehrslage, öffentlichen Verkehrsmitteln, der Feuerwehr, Staatsbesuchern und weiß der Himmel noch wem gesteuert. Sogar für Regenwetter und Schneefall gibt es Anpassungen. Selbst mit direktem Zugriff auf die Software dürfte eine Vorhersage heute schon fraglich, aber in naher Zukunft reine Kaffeesatzleserei sein. Sinnvoller wäre eine Art Vorsignal. Wenn du jetzt Tempo 48 hälst, hast du an der nächsten Ampel grün. Das müsste aber an der Straße stehen und vom Ampelrechner gesteuert werden. So was gab es sogar schon mal. Alles andere hört sich schön an, funktioniert aber nur noch, wenn überhaupt, an einer abnehmenden Zahl von Ampeln. Unabhängig davon schlage ich vor, das als separates Projekt außerhalb von OSM zu machen. Durch die TMC-Geschichte haben wir genügend tags, um die Ampeln zu referenzieren. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Widersprüche zwischen Wiki-Definition und Mapnik-Rendering
On 05/giu/2013, at 18:26, Stephan Wolff s.wo...@web.de wrote: Trotzdem sollte es doch möglich sein, Objekte wie highway=services, highway=rest_area und railway=station, die in der line-Datenbanktabelle landen, aber nur als Fläche definiert sind, auch als Fläche zu rendern. wenn area=yes getaggt ist sollte das so sein dass sie als Fläche gerendert werden Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wochennotiz Nr. 150 28.5.-3.6.2013
On Wed, 5 Jun 2013, Gehling Marc wrote: Hallo, die Wochennotiz Nr. 150 mit allen wichtigen Neuigkeiten aus der OpenStreetMap Welt ist da: http://blog.openstreetmap.de/2013/06/wochennotiz-nr-150/ Viel Spaß beim Lesen! Vielen Dank, hatte ich! Ich denke ich spreche fuer die OSM Community wenn ich behaupte, dass die Wochennotizen seit langer Zeit ein informativer und gut aufbereiteter News-Aggregator sind. Dickes Lob! Das Thema zum Artikel 'Hausnummern mappen und Internetverweigerer' kommt sicher einigen bekannt vor. Ich bin diesbezueglich deshalb auch gerade wieder mal dabei, ein wenig PR Arbeit anzustossen. Konkret, den OSM Flyer zu ueberarbeiten und mit etwas frischem, weniger 'nerdigem' Text aufzupeppen. @Frederik: Dein Flyer war und ist ne super Vorlage und ich hoffe Du verstehst diese Wortwahl als positives Feedback ;) Ich denke wir sind an vielen Orten - wie im Artikel beschrieben - an einem Punkt angekommen, wo die Leute neugierig, nervoes oder abweisend reagieren. Weil eben immer mehr Details bis an die Grundstuecksgrenze gemapped werden. Stichwort Google Streetview und die Presse darueber, etc. Diese Hemmschwelle zu ueberschreiben und das mit ein paar Zeilen auf einem Flyer zu kommunizieren ist nicht einfach. Deshalb: Wenn jemand in diesem Bereich der 'Aufklaerungsarbeit' noch Erfahrungen beisteuern kann, dann taete mich das interessieren. Merci - A.___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wochennotiz Nr. 150 28.5.-3.6.2013
Wäre es vlt. möglich und sinnvoll den neuen Text im Forum zur Diskussion zu stellen und zur Mitarbeit aufzufordern? Ich denke, es wird sicherlich ein großes Durcheinander geben, den viele Köche verderben bekanntlich den Brei ;-) Aber die eine oder andere Idee oder Anmerkung wird garantiert dabei heraus kommen... Gruß René ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
