Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 8. Juni 2011 18:19 schrieb Garry garr...@gmx.de: Am 07.06.2011 16:42, schrieb Frederik Ramm: anderen aufzudiktieren, wie sie ihre Arbeit machen sollen. Das klingt aus Deinem Mund jetzt sehr paradox... naja, wenn ich naturgemäß auch mit dem Rest Deiner Mail weitgehend übereinstimme, hier widerspreche ich doch gern: Frederik ist prinzipiell ziemlich liberal und laisser-faire-mäßig unterwegs, da ist aus meiner Sicht nichts Paradoxes an seiner Aussage. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 09.06.2011 12:59, schrieb M∡rtin Koppenhoefer: Am 8. Juni 2011 18:19 schrieb Garrygarr...@gmx.de: Am 07.06.2011 16:42, schrieb Frederik Ramm: anderen aufzudiktieren, wie sie ihre Arbeit machen sollen. Das klingt aus Deinem Mund jetzt sehr paradox... naja, wenn ich naturgemäß auch mit dem Rest Deiner Mail weitgehend übereinstimme, hier widerspreche ich doch gern: Frederik ist prinzipiell ziemlich liberal und laisser-faire-mäßig unterwegs, da ist aus meiner Sicht nichts Paradoxes an seiner Aussage. Das Paradoxe ist dass er durch Androhung von Account-Sperren die Durchsetzung/Unterdrückung von Tags unterstützt... Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 9. Juni 2011 17:23 schrieb Garry garr...@gmx.de: Das Paradoxe ist dass er durch Androhung von Account-Sperren die Durchsetzung/Unterdrückung von Tags unterstützt... jetzt bin ich doch neugierig geworden, um welche Tags gehts da? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 07.06.2011 16:42, schrieb Frederik Ramm: Hallo, On 06/07/11 16:03, Garry wrote: Wer die Strasse bearbeiten möchte soll die Strasse bearbeiten können und wer die Waldgrenze bearbeiten möchte eben die Waldgrenze. Er sollte nicht genötigt werden beides anfassen zu müssen was er dann im Zweifelsfalls lassen wird - keine Verbesserung der Daten. Das ist jetzt mein allerletztes Statement zu diesem Thema, weil ich mich zu wiederholen beginne. Bitte lies das folgende aufmerksam durch, ich habe es Martin schon geschrieben, aber Du hast das offenbar nicht gelesen. Es ist eine Situation denkbar, in der die Strasse und der Waldrand als separate Linien nebeneinander gemappt sind, beide relativ grob, und in der eine Verfeinerung der Strasse dann dazu fuehrt, dass die Strasse den - immer noch grob gezeichneten - Wald stueckweise ueberlappt. Diese Information ist nicht vorhanden! Wenn beides grob gemappt ist dann hat man nicht mehr als die Information dass der Wald ungefähr an der Strasse auf hört. Das kann 20 und mehr Meter vor der Strasse sein, genauso aber erst einige Meter auf der anderen Strassenseite (eigentlich Nicht-Wald-Seite) wenn dort auch noch ein Baumstreifen steht. Der Mapper waere hier also genoetigt, um der Topologie Rechnung zu tragen, den Wald ebenfalls zu verfeinern; waere hingegen die Strasse zugleich der Waldrand, bliebe im diese Mehrarbeit erspart. Ist er nicht, er hat hier aus den OSM- Daten keine belastbare Information über die Topologie. Abgesehen davon ist diese Mehrarbeit überschaubar, insbesondere im Verhältniss zur sonst später nötigen Nacharbeit. Das, was Du schreibst, kann also je nach Situation mal als Argument fuer die eine und mal als Argument fuer die andere Art zu mappen dienen. Ich argumentiere dass man die Daten verbessern kann/darf/soll die man hat, notfalls zu Lasten der (vermeintlichen)Topologie, insbesondere dann wenn es um etwas nur grob erfasstes geht. Keine von beiden Arten ist besser; Dem widerspricht schon alleine die Mapper-Praxis dass doch einige nach anfänglicher Begeisterung für das zusammenlegen wieder davon abgekommen weil man sich zuviele Folge-Probleme einhandelt. es kommt auf die Gesamtsituation und auf den Mapper und auf die Umstaende an. Alles andere ist eine unzulaessige Vereinfachung und der Versuch, Eine unzulässige Vereinfachung ist die Vermischung von Daten die nicht zusammengehören nur weil sie zufällig und sporadisch stückweise ungefähr parallel laufen. Aber das hat ja Martin schon sehr schön erörtert.. anderen aufzudiktieren, wie sie ihre Arbeit machen sollen. Das klingt aus Deinem Mund jetzt sehr paradox... Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 06.06.2011 17:42, schrieb Frederik Ramm: Hallo, M?rtin Koppenhoefer wrote: das verstehe ich jetzt nicht, inwiefern man durch genauere Grenzen Dass eine als einzelne Linie gezeichnete Grenze genauer ist als die Verwendung der Strassengeometrie, ist mitnichten erwiesen. behindert werden kann, wo Flächen nicht mit Straßengraphen verbunden sind. Hättest Du da mal ein Beispiel? Nein, aber ich habe Leute sagen hoeren, was ich in meinem vorigen Posting schrieb: Dass jemand keine Lust hat, eine Strassengeometrie zu verfeinern, wenn sich dadurch tonnenweise Ueberschneidungen mit dem angrenzenden Wald ergeben und er die von Hand zusaetzlich korrigieren muss. Entweder es gibt solche Mapper, die sich behindert fuehlen. Dann sollen die von mir aus gern die Gegend so (um)mappen, dass sie gut damit arbeiten koennen. Oder es gibt sie nicht. Dann ist es auch recht. kann), da erfordert es der Respekt vor der Arbeit der anderen, dass man den persönlichen Stil etwas an das anpasst, was man schon vorfindet (solange es nur um Stil und nicht um Verbesserungen geht). Ja, das kommt sicher auf den Umfang der Aenderungen an. Einem Gebiet seinen persoenlichen Stil aufdruecken, weil man gerade mal im Vorbeifahren einen Briefkasten mappt, ist natuerlich nicht ok. andere Karten nutzen OSM probeweise sogar bis Z.21) , sehe ich nicht, inwiefern man einer Reduktion der Detaillierung Ich glaube, Du hast da eine etwas verkorkste Perspektive. Du scheinst anzunehmen, dass alles, was jemand vom Luftbild abmalt, automatisch hochgenau und detailliert ist. Ich wage mal die Behauptung: Der Fehler, in Metern, den ich einbaue, wenn ich den Strassen-Way als Begrenzung meines Waldes nehme, ist im Durchschnitt geringer als der Fehler, den ich einbaue, wenn ich das (Bing-)Luftbild nicht vorher ordentlich an GPS-Tracks justiere. Ja, das wird oft behauptet, aber je nach Art des weiteren Verfeinerns, dass man im Sinn hat, kann es eben auch genau andersrum sein. wenn man die Straßen zusätzlich als Flächen eintragen will, ist die Lage sicher eindeutig. Das ist eine ganz andere Baustelle. Aus meiner Sicht wird das in Städten auf jeden Fall kommen, weil man anders ein sauberes Rendering, das auch Informationen zur realen Form transportiert, nicht erhalten kann. Informationen zur realen Form zu transportieren, ist unter Umstaenden aber etwas anderes als sauberes Rendering. Und sauberes Rendering bekommt man ganz bestimmt auch ohne Strassen als Flaechen hin. Aber das ist, wie gesagt, wieder eine andere Geschichte. Eine Karte ist kein Luftbild. Auch eine sehr gute Karte nicht. da der Wald nichts mit der Straße zu tun hat, muss ich den auch nicht verfeinern, wenn ich an der Straße schraube. Andere muessen das vielleicht schon (wenn, wie oben geschildert, die verfeinerte Strasse sonst zuweilen den Wald ueberschneidet, was ja eher selten ist.) Klar, ein Zaun der an der Straße langläuft müsste evtl. verfeinert werden Wenn wir es mit einem Zaun zu tun haben, dann hoert das natuerlich auf, dass man die Strasse als Waldrand benutzen kann. Aber dann haben wir das gleiche Ding mit dem Zaun; man koennte dann einfach den Zaun als Waldrand benutzen, oder man koennte argumentieren, dies sei ungenau und der Zaun stehe ja ausserhalb des Waldes.. Ja, das behauptest Du immer wieder, aber das ist halt eine Beurteilung, die Du fuer Dich treffen kannst, aber nicht fuer andere Mapper; die werden eventuell davon eben nicht gebremst, sondern denen geht die Arbeit schneller von der Hand. sicher gehen einem manche Bearbeitungen schneller von der Hand, wenn man sie ungenau macht. Du behauptest immer wieder, dass es ungenauer sei, den Strassen-Way als Waldrand zu verwenden, aber das ist eine unzulaessige Verallgemeinerung. Oder sagen wir: Es ist vielleicht genauer, aber nicht richtiger - genauso wie eine Loesung mit fuenf Nachkommastellen in der Matheklausur genauer ist, aber nicht richtiger. Strassen werden potentiell genauer erfasst als Waldränder. Die Wälder haben in den Daten für die meisten einen ehr dekorativen Charakter während die Strassen- und Wegedaten intensiv genutzt werden. Wenn Du schon mit Deiner Matheklausur kommst - die Grundlagen des technischen Zeichen dass man ein genaues Mass nicht mit einem ungenauen Mass verkettet wenn man ein genaues Ergebniss haben möchte sind Dir bekannt? Wer die Strasse bearbeiten möchte soll die Strasse bearbeiten können und wer die Waldgrenze bearbeiten möchte eben die Waldgrenze. Er sollte nicht genötigt werden beides anfassen zu müssen was er dann im Zweifelsfalls lassen wird - keine Verbesserung der Daten. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Garry schrieb am 07.06.2011 16:03: Wer die Strasse bearbeiten möchte soll die Strasse bearbeiten können und wer die Waldgrenze bearbeiten möchte eben die Waldgrenze. Noch mal zur Erinnerung: Wir reden hier von dem Fall, wo ein Wald bis an eine Strasse heran reicht. = Waldgrenze = Strasse Es macht also keinerlei Sinn, ein Objekt genauer und ein Objekt weniger genau in der Datenbank haben zu wollen. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Hallo, On 06/07/11 16:03, Garry wrote: Wer die Strasse bearbeiten möchte soll die Strasse bearbeiten können und wer die Waldgrenze bearbeiten möchte eben die Waldgrenze. Er sollte nicht genötigt werden beides anfassen zu müssen was er dann im Zweifelsfalls lassen wird - keine Verbesserung der Daten. Das ist jetzt mein allerletztes Statement zu diesem Thema, weil ich mich zu wiederholen beginne. Bitte lies das folgende aufmerksam durch, ich habe es Martin schon geschrieben, aber Du hast das offenbar nicht gelesen. Es ist eine Situation denkbar, in der die Strasse und der Waldrand als separate Linien nebeneinander gemappt sind, beide relativ grob, und in der eine Verfeinerung der Strasse dann dazu fuehrt, dass die Strasse den - immer noch grob gezeichneten - Wald stueckweise ueberlappt. Der Mapper waere hier also genoetigt, um der Topologie Rechnung zu tragen, den Wald ebenfalls zu verfeinern; waere hingegen die Strasse zugleich der Waldrand, bliebe im diese Mehrarbeit erspart. Das, was Du schreibst, kann also je nach Situation mal als Argument fuer die eine und mal als Argument fuer die andere Art zu mappen dienen. Keine von beiden Arten ist besser; es kommt auf die Gesamtsituation und auf den Mapper und auf die Umstaende an. Alles andere ist eine unzulaessige Vereinfachung und der Versuch, anderen aufzudiktieren, wie sie ihre Arbeit machen sollen. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 5. Juni 2011 02:12 schrieb Frederik Ramm frede...@remote.org: M?rtin Koppenhoefer wrote: Es ist einfach keine gute Idee, landuses an Straßen zu hängen ;-) Kommt drauf an, beide Methoden haben ihre Vor- und Nachteile und ihre Berechtigung. Im Prinzip stimme ich dem auf kurze Zeit gesehen zu. Sicherlich hat (vor allem kurzfristig) auch das Wiederverwenden von Geometrie in der Nähe bestimmte Vorteile, trotzdem würden mich die Implikationen interessieren, die sich für den Mapper daraus ergeben: Meinst Du damit, dass sie gleichwertig sind, und dass es demzufolge in Ordnung ist, wenn man Stellen, wo jemand den Wald an der tatsächlichen Wald-Grenze enden lässt, vereinfacht / generalisiert (z.B. mit dem Hinweis, dass das die Verarbeitung beschleunigt bzw. den Speicherbedarf reduziert), indem man die Waldgrenze löscht und den Wald per Multipolygon über eine in der Nähe verlaufende Straße umdefiniert? Langfristig (und so habe ich die Aussage gemeint) ist es dennoch keine gute Idee m.E., weil wie erwähnt weiteres Verfeinern unnötig kompliziert wird (und je nach Größe der entstehenden Multipolygone neben der Ungenauigkeit auch erheblicher Verarbeitungsmehraufwand entsteht, da selbst kleine Kacheln ggf. riesige Multipolygone enthalten, die weit über den eigentlichen Kachelbereich hinaus gehen). M.E. bremst uns diese Mappingtechnik mittel- und langfristig eher, als dass es das Mapping vereinfacht und beschleunigt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 05.06.2011 00:28, schrieb Garry: Es kann genausogut die Strasse als auch der Wald falsch erfasst sein. Das eine dem anderen anzupassen ist also eine Mappen für den Renderer... Was hat das mit Mappen für den Renderer zu tun, Objekte im Verhältnis zueinander korrekt zu positionieren? Erfassungsungenauigkeiten gibt es immer, aber wenigstens die relative Lage kann man durch Beobachtung in der Realität korrekt eintragen. Genauso wie man auch vermeintliche Kurven im GPS-Track zu Geraden macht, wenn da eben keine Kurve ist. Und wenn die Straße genau die Grenze zwischen Wald und Wohngebiet darstellt, erfasst man eben die Straße. Wenn die Straße vom Verlauf her nicht korrekt aufgezeichnet ist, ist dann eben auch der Wald falsch. Es geht nicht um einen Waldrand, der 20 Meter von der Straße entfernt liegt und sinnvoll seperat erfasst werden kann. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Hi, On 06/06/11 12:12, M?rtin Koppenhoefer wrote: Meinst Du damit, dass sie gleichwertig sind, und dass es demzufolge in Ordnung ist, wenn man Stellen, wo jemand den Wald an der tatsächlichen Wald-Grenze enden lässt, vereinfacht / generalisiert (z.B. mit dem Hinweis, dass das die Verarbeitung beschleunigt bzw. den Speicherbedarf reduziert), indem man die Waldgrenze löscht und den Wald per Multipolygon über eine in der Nähe verlaufende Straße umdefiniert? Ja, aber nicht als Selbstzweck. Wenn jemand in einer Gegend etwas mappen will und in seiner Arbeit davon behindert wird, dass jemand anders jedes Polygon an seiner vermeintlich tatsaechlichen Grenzen enden liess, dann hat derjenige durchaus das Recht, das an den Stellen zu aendern, die er aus anderen Gruenden anfassen muss - eben weil es keine Frage von richtig oder falsch, sondern eine des persoenlichen Stils ist. Langfristig (und so habe ich die Aussage gemeint) ist es dennoch keine gute Idee m.E., weil wie erwähnt weiteres Verfeinern unnötig kompliziert wird Ja, das wird oft behauptet, aber je nach Art des weiteren Verfeinerns, dass man im Sinn hat, kann es eben auch genau andersrum sein. Wenn ich die Strassengeometrie verfeinere, bin ich vielleicht ganz froh, wenn die Waldgeometrie dabei automatisch mitverfeinert wird, statt dass ich jeden Zusatznode, den ich platziere, dreimal setzen muss. M.E. bremst uns diese Mappingtechnik mittel- und langfristig eher, als dass es das Mapping vereinfacht und beschleunigt. Ja, das behauptest Du immer wieder, aber das ist halt eine Beurteilung, die Du fuer Dich treffen kannst, aber nicht fuer andere Mapper; die werden eventuell davon eben nicht gebremst, sondern denen geht die Arbeit schneller von der Hand. Ich will in dieser Sache niemandem etwas vorschreiben, aber ich wehre mich auch dagegen, wenn *andere* hier Vorschriften aufstellen (a la na gut, voruebergehend darfst Du das so machen, aber Du musst Dir schon bewusst sein, dass das schlechter ist...). Deswegen widerspreche ich Dir auch dauernd, weil Du genau das so zwischen den Zeilen tust. Und die diversen Argumente dafuer, dass das eine richtiger sein sollte als das andere (... oder wachsen die Baeume bis zum Mittelstreifen?), halte ich fuer rhetorische Spitzfindigkeiten und nicht fuer echte Argumente. Das ist auf der gleichen Ebene wie ... oder willst Du etwa behaupten, diese Kurve hier bestehe aus genau 20 kleinen geraden Stuecken? - natuerlich tut sie das nicht, aber das hat ja auch keiner behauptet. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
On 06/06/11 12:12, M?rtin Koppenhoefer wrote: Meinst Du damit, dass sie gleichwertig sind, und dass es demzufolge in Ordnung ist, wenn man Stellen, wo jemand den Wald an der tatsächlichen Wald-Grenze enden lässt, vereinfacht / generalisiert (z.B. mit dem Hinweis, dass das die Verarbeitung beschleunigt bzw. den Speicherbedarf reduziert), indem man die Waldgrenze löscht und den Wald per Multipolygon über eine in der Nähe verlaufende Straße umdefiniert? Ja, aber nicht als Selbstzweck. Wenn jemand in einer Gegend etwas mappen will und in seiner Arbeit davon behindert wird, dass jemand anders jedes Polygon an seiner vermeintlich tatsaechlichen Grenzen enden liess, dann hat derjenige durchaus das Recht, das an den Stellen zu aendern, die er aus anderen Gruenden anfassen muss - eben weil es keine Frage von richtig oder falsch, sondern eine des persoenlichen Stils ist. das verstehe ich jetzt nicht, inwiefern man durch genauere Grenzen behindert werden kann, wo Flächen nicht mit Straßengraphen verbunden sind. Hättest Du da mal ein Beispiel? Den persönlichen Stil (gut dass Du es ansprichst) gibt es durchaus. Es ist unumgänglich gewisse Abstraktionen einzuführen. Wo man aber mit wenige Clicks stundenlange Arbeit von anderen kaputtmachen kann in einem Punkt, der wie Du sagst sowohl als auch richtig ist (sein kann), da erfordert es der Respekt vor der Arbeit der anderen, dass man den persönlichen Stil etwas an das anpasst, was man schon vorfindet (solange es nur um Stil und nicht um Verbesserungen geht). Dieses Thema ist da ganz gut vergleichbar mit der Frage, wie sog. straßenbegleitende Radwege gemappt werden sollen. Da ärgert es mich z.B. auch ziemlich, wenn (wie vor einiger Zeit geschehen) ein Mapper einen explizit gemappten Radweg (einschl. weiterer Details wie Fahrbahnoberfläche, kreuzende Einfahrten, leicht abweichende Verkehrsführung, etc., --- der Weg war da über Jahre und von zig Mappern weiterverfeinert) löscht und durch ein schnödes cycleway=track ersetzt. Auf die 2. Anfrage per PM antwortet der dann: da war kein Platz. Wie? Wo war da kein Platz? Dass die Topologie fürs Routing dadurch teilweise zerschossen wurde sei nur am Rande erwähnt (Zugang zu einem Fußgängerplatz der als Durchgang durch den Block auch von Fahrrädern genutzt wird). Es ist sicher eine Frage des Maßstabs (und der damit einhergehenden Generalisierung), wie man mappt. Der Maßstab wird in OSM durch die Genauigkeit dessen vorgegeben, was die Koordinaten hergeben, und evlt. von den bestehenden Renderings (Mapnik derzeit bis z.18 ca. 1:2000, andere Karten nutzen OSM probeweise sogar bis Z.21) , sehe ich nicht, inwiefern man einer Reduktion der Detaillierung und stärkeren Generalisierung im Bereich der Daten der Datenbank Positives abgewinnen könnte. Eine derart grobe Generalisierung wie man sie gelegentlich antrifft ist m.E. sinnvoll für z14 und weniger. Langfristig (und so habe ich die Aussage gemeint) ist es dennoch keine gute Idee m.E., weil wie erwähnt weiteres Verfeinern unnötig kompliziert wird Ja, das wird oft behauptet, aber je nach Art des weiteren Verfeinerns, dass man im Sinn hat, kann es eben auch genau andersrum sein. wenn man die Straßen zusätzlich als Flächen eintragen will, ist die Lage sicher eindeutig. Aus meiner Sicht wird das in Städten auf jeden Fall kommen, weil man anders ein sauberes Rendering, das auch Informationen zur realen Form transportiert, nicht erhalten kann. Wenn ich die Strassengeometrie verfeinere, bin ich vielleicht ganz froh, wenn die Waldgeometrie dabei automatisch mitverfeinert wird, statt dass ich jeden Zusatznode, den ich platziere, dreimal setzen muss. da der Wald nichts mit der Straße zu tun hat, muss ich den auch nicht verfeinern, wenn ich an der Straße schraube. Straßenkurven haben daher z.B. bei mir oft auch mehr Punkte als ein Waldrand. Klar, ein Zaun der an der Straße langläuft müsste evtl. verfeinert werden, aber diesen Zaun könnte ich nicht mal einzeichnen ohne dass ich einen Topologie-Fehler einbaue, solange die Nachbar-Fläche an der Straße hängt. M.E. bremst uns diese Mappingtechnik mittel- und langfristig eher, als dass es das Mapping vereinfacht und beschleunigt. Ja, das behauptest Du immer wieder, aber das ist halt eine Beurteilung, die Du fuer Dich treffen kannst, aber nicht fuer andere Mapper; die werden eventuell davon eben nicht gebremst, sondern denen geht die Arbeit schneller von der Hand. sicher gehen einem manche Bearbeitungen schneller von der Hand, wenn man sie ungenau macht. Ich will in dieser Sache niemandem etwas vorschreiben, aber ich wehre mich auch dagegen, wenn *andere* hier Vorschriften aufstellen (a la na gut, voruebergehend darfst Du das so machen, aber Du musst Dir schon bewusst sein, dass das schlechter ist...). ist meine ehrliche Meinung. (Habe ich durch das m.E. ja kenntlich gemacht). Ich schreibe nur deshalb auch immer wieder zu diesem Thema, weil ich zutiefst davon überzeugt bin, dass kleinere Teile besser
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Hallo, M?rtin Koppenhoefer wrote: das verstehe ich jetzt nicht, inwiefern man durch genauere Grenzen Dass eine als einzelne Linie gezeichnete Grenze genauer ist als die Verwendung der Strassengeometrie, ist mitnichten erwiesen. behindert werden kann, wo Flächen nicht mit Straßengraphen verbunden sind. Hättest Du da mal ein Beispiel? Nein, aber ich habe Leute sagen hoeren, was ich in meinem vorigen Posting schrieb: Dass jemand keine Lust hat, eine Strassengeometrie zu verfeinern, wenn sich dadurch tonnenweise Ueberschneidungen mit dem angrenzenden Wald ergeben und er die von Hand zusaetzlich korrigieren muss. Entweder es gibt solche Mapper, die sich behindert fuehlen. Dann sollen die von mir aus gern die Gegend so (um)mappen, dass sie gut damit arbeiten koennen. Oder es gibt sie nicht. Dann ist es auch recht. kann), da erfordert es der Respekt vor der Arbeit der anderen, dass man den persönlichen Stil etwas an das anpasst, was man schon vorfindet (solange es nur um Stil und nicht um Verbesserungen geht). Ja, das kommt sicher auf den Umfang der Aenderungen an. Einem Gebiet seinen persoenlichen Stil aufdruecken, weil man gerade mal im Vorbeifahren einen Briefkasten mappt, ist natuerlich nicht ok. andere Karten nutzen OSM probeweise sogar bis Z.21) , sehe ich nicht, inwiefern man einer Reduktion der Detaillierung Ich glaube, Du hast da eine etwas verkorkste Perspektive. Du scheinst anzunehmen, dass alles, was jemand vom Luftbild abmalt, automatisch hochgenau und detailliert ist. Ich wage mal die Behauptung: Der Fehler, in Metern, den ich einbaue, wenn ich den Strassen-Way als Begrenzung meines Waldes nehme, ist im Durchschnitt geringer als der Fehler, den ich einbaue, wenn ich das (Bing-)Luftbild nicht vorher ordentlich an GPS-Tracks justiere. Ja, das wird oft behauptet, aber je nach Art des weiteren Verfeinerns, dass man im Sinn hat, kann es eben auch genau andersrum sein. wenn man die Straßen zusätzlich als Flächen eintragen will, ist die Lage sicher eindeutig. Das ist eine ganz andere Baustelle. Aus meiner Sicht wird das in Städten auf jeden Fall kommen, weil man anders ein sauberes Rendering, das auch Informationen zur realen Form transportiert, nicht erhalten kann. Informationen zur realen Form zu transportieren, ist unter Umstaenden aber etwas anderes als sauberes Rendering. Und sauberes Rendering bekommt man ganz bestimmt auch ohne Strassen als Flaechen hin. Aber das ist, wie gesagt, wieder eine andere Geschichte. Eine Karte ist kein Luftbild. Auch eine sehr gute Karte nicht. da der Wald nichts mit der Straße zu tun hat, muss ich den auch nicht verfeinern, wenn ich an der Straße schraube. Andere muessen das vielleicht schon (wenn, wie oben geschildert, die verfeinerte Strasse sonst zuweilen den Wald ueberschneidet, was ja eher selten ist.) Klar, ein Zaun der an der Straße langläuft müsste evtl. verfeinert werden Wenn wir es mit einem Zaun zu tun haben, dann hoert das natuerlich auf, dass man die Strasse als Waldrand benutzen kann. Aber dann haben wir das gleiche Ding mit dem Zaun; man koennte dann einfach den Zaun als Waldrand benutzen, oder man koennte argumentieren, dies sei ungenau und der Zaun stehe ja ausserhalb des Waldes.. Ja, das behauptest Du immer wieder, aber das ist halt eine Beurteilung, die Du fuer Dich treffen kannst, aber nicht fuer andere Mapper; die werden eventuell davon eben nicht gebremst, sondern denen geht die Arbeit schneller von der Hand. sicher gehen einem manche Bearbeitungen schneller von der Hand, wenn man sie ungenau macht. Du behauptest immer wieder, dass es ungenauer sei, den Strassen-Way als Waldrand zu verwenden, aber das ist eine unzulaessige Verallgemeinerung. Oder sagen wir: Es ist vielleicht genauer, aber nicht richtiger - genauso wie eine Loesung mit fuenf Nachkommastellen in der Matheklausur genauer ist, aber nicht richtiger. Die Auswüchse, die sich aus den Relationen ergeben, wenn man erstmal ein paar Landkreise als ein Farmland kennzeichnet, und danach alles was nicht passt (und einem auffällt) wieder ausschließt (also landuse Relationen, die schon ein Jahr oder so alt sind), behindern die Entwicklung der Karte ungemein. Ja, da gibt es eine Menge Stilblueten, die ich auch nicht so prickelnd finde. Aber mit der Verwendung einer Strasse als Waldrand o.ae. hat das m.E. wieder nichts zu tun. Es geht nicht um rhetorische Spitzfindigkeiten, das Argument war, dass echte Flächengrößen mehr Informationen transportieren als durch Generalisierung vergrößerte. Der Unterschied duerfte im *Promillebereich* sein. 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] Konzept für Daten, Karte und Renderer
Am 6. Juni 2011 17:42 schrieb Frederik Ramm frede...@remote.org: Dass eine als einzelne Linie gezeichnete Grenze genauer ist als die Verwendung der Strassengeometrie, ist mitnichten erwiesen. OK, verstanden. Gut, es gibt im OSM-Umfeld natürlich _alles_ ;-) Auf dem Weg zu einer guten Annäherung ist man aber i.d.R. schon mit dem gröbsten Wald näher als mit gar keiner echten Flächengrenze. Dass jemand keine Lust hat, eine Strassengeometrie zu verfeinern, wenn sich dadurch tonnenweise Ueberschneidungen mit dem angrenzenden Wald ergeben und er die von Hand zusaetzlich korrigieren muss. Wieso sollte das jetzt ein Problem sein, wenn die Straße z.T. durch das Waldpolygon führt (bis es jemand richtet), während bei der anderen Methode die komplette Straße im Wald läuft? Man muss ja nicht alles alleine machen, diese tonnenweisen Überschneidungen haben keine negativen Auswirkungen, ausser, dass sie Ungenauigkeiten aufzeigen, die man zukünftig noch durch Verfeinerung beheben kann. Ich glaube, Du hast da eine etwas verkorkste Perspektive. Du scheinst anzunehmen, dass alles, was jemand vom Luftbild abmalt, automatisch hochgenau und detailliert ist. Ich wage mal die Behauptung: Der Fehler, in Metern, den ich einbaue, wenn ich den Strassen-Way als Begrenzung meines Waldes nehme, ist im Durchschnitt geringer als der Fehler, den ich einbaue, wenn ich das (Bing-)Luftbild nicht vorher ordentlich an GPS-Tracks justiere. Klar, die Lagegenauigkeit von Luftbildern ist nicht grundsätzlich gut, und Fehler aus der Orthorektifizierung des Luftbilds kann man auch durch nachträgliches Justieren (Verschieben) nicht mehr beheben. Da haben wir in Italien einen gewissen Vorsprung, weil wir mit dem PCN wirklich flächendeckend einheitliche Luftbilder haben (2006) und für manche Gebiete auch von 2008, die sehr gut positioniert und vorverarbeitet sind. Bing bietet einem im Vergleich in der Fläche deutlich weniger und schlechter (Position/Alter) (in Rom aber z.B. z21 was für Details schon nicht zu verachten ist). Viele Dinge kann man aber auch ohne Luftbilder genau zeichnen, oft sogar aus dem Gedächtnis (bzw. anhand von Fotos und Aufzeichnungen, die man vor Ort gemacht hat). Wie genau man mappt hat höchstens zu einem Teil mit den Bildern zu tun, die man als Vorlage hat, eher mit den Details, die einem bei der Begehung auffallen. wenn man die Straßen zusätzlich als Flächen eintragen will, ist die Lage sicher eindeutig. Das ist eine ganz andere Baustelle. m.E. ist das genau dieselbe Baustelle: wenn man jetzt alle Flächen an die Straßen hängt, wird man sie später alle wieder abhängen müssen. Informationen zur realen Form zu transportieren, ist unter Umstaenden aber etwas anderes als sauberes Rendering. Und sauberes Rendering bekommt man ganz bestimmt auch ohne Strassen als Flaechen hin. Aber das ist, wie gesagt, wieder eine andere Geschichte. jein, solange die Straßen regelmäßig sind, braucht man praktisch keine Straßenflächen (selbst Spurerweiterungen -reduktionen folgen ja Gesetzmäßigkeiten), wenn aber der Verkehrsraum seine Linearität verliert und zu einer weitgehend ungerichteten Fläche wird, dann geht es ohne natürlich nicht. Eine Karte ist kein Luftbild. Auch eine sehr gute Karte nicht. +1. Klar, ein Zaun der an der Straße langläuft müsste evtl. verfeinert werden Wenn wir es mit einem Zaun zu tun haben, dann hoert das natuerlich auf, dass man die Strasse als Waldrand benutzen kann. Aber dann haben wir das gleiche Ding mit dem Zaun; man koennte dann einfach den Zaun als Waldrand benutzen, oder man koennte argumentieren, dies sei ungenau und der Zaun stehe ja ausserhalb des Waldes.. jetzt wirst Du allerdings ein bisschen rhetorisch ;-) Ein Waldrand ist sicherlich nicht auf den cm oder einzelnen Meter genau zu bestimmen. Sofern man aber zwischen Wald und xy noch etwas anderes erkennen kann (dazu zähle ich auch z.B. Gestrüpp, einen Straßengraben oder anderen Wasserlauf, eine Böschung, etc.), ist in der vorläufig endgültigen Karte an dieser Stelle xy auch nicht mit dem Wald verbunden. Du behauptest immer wieder, dass es ungenauer sei, den Strassen-Way als Waldrand zu verwenden, aber das ist eine unzulaessige Verallgemeinerung. Oder sagen wir: Es ist vielleicht genauer, aber nicht richtiger - genauso wie eine Loesung mit fuenf Nachkommastellen in der Matheklausur genauer ist, aber nicht richtiger. Es freut mich schon, dass es wenigstens vielleicht (das bedeutet vermutlich - s. Anfang D. Mail -, wenn es sorgfältig gemacht ist?) genauer ist. Der Umkehrschluss ist dann, dass es (bei jeweils sorgfältiger Herangehensweise) ungenauer ist, wenn man die Straße verwendet. D.h. dass es zwar immer noch Gründe gibt, trotzdem die Straße zu verwenden (Ersparnis von Aufwand), aber - solange man eine genaue Karte anstrebt - dieser Zustand vermutlich eben doch nur ein Übergangszustand sein wird. Es geht nicht um rhetorische Spitzfindigkeiten, das Argument war, dass echte Flächengrößen mehr
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 06.06.2011 12:31, schrieb Sebastian Hohmann: Am 05.06.2011 00:28, schrieb Garry: Es kann genausogut die Strasse als auch der Wald falsch erfasst sein. Das eine dem anderen anzupassen ist also eine Mappen für den Renderer... Was hat das mit Mappen für den Renderer zu tun, Objekte im Verhältnis zueinander korrekt zu positionieren? Weil dieses korrekt nur eine grobe Annäherung ist. Ich will keine schöne Karte im Sinne von jede Fläche wird durch meinen Renderer lückenlos in schönen Farben eingefärbt sondern korrekte Daten in denen ich auch eine markante Waldrandkontur wiederfinde bzw. diese leicht eintragen kann. Erfassungsungenauigkeiten gibt es immer, aber wenigstens die relative Lage kann man durch Beobachtung in der Realität korrekt eintragen. Genauso wie man auch vermeintliche Kurven im GPS-Track zu Geraden macht, wenn da eben keine Kurve ist. Nun weiss Du aber nicht ob diese vermeintliche Kurve im Track real exisitiert oder tatsächlich ein Fehler Deines Receivers ist. Kleines Beispiel: hier wurde im Wald vor 2-3 Jahren eine Kurve begradigt. In den üblichen Luftbildern ist diese Begradigung noch nicht zu finden. Irgendjemand hat dann gemeint diese Kurve an ein hochauflösendes Luftbild anpassen zu müssen. Mit einem an der Strasse hängenden landuse wäre der Fehler nicht so schnell aufgefallen... Verkehrstechnisch macht diese Korrektur den Unterschied ob man die Strasse nur mit 60km/h oder mit 100km/h durchfahren kann. Und wenn die Straße genau die Grenze zwischen Wald und Wohngebiet darstellt, erfasst man eben die Straße. Wenn die Straße vom Verlauf her nicht korrekt aufgezeichnet ist, ist dann eben auch der Wald falsch. Eben - wenn ich genaue Daten von der Strasse habe dann habe ich die Daten von der Strasse und nicht die vom Wald. Daher möchte ich dann auch nur die Strasse anfassen und nicht den Wald. Genauso umgekehrt. Wenn ich Überschneidungen feststelle kann ich im Einzelfall immer noch gegebenfalls prüfen wo der Fehler liegt. Es geht nicht um einen Waldrand, der 20 Meter von der Straße entfernt liegt und sinnvoll seperat erfasst werden kann. Eine anhaltende, gleichförmig dicht am Strassenrand entlanglaufende Waldgrenze ist ehr die Ausnahme als die Regel. Da kommen immer wieder Parkbuchten, Einmündungen von Waldwegen, Bauwerke (dazu zähle ich auch Gräben, Dämme) etc. dazwischen die auch ein markantes Merkmal in der Karte allein durch das nichtvorhandensein von Bäumen darstellen können. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 03.06.2011 14:36, schrieb fly: Am 02.06.2011 18:54, schrieb Peter: Man kommt auf die Idee das Josm da einem viel Arbeit abnehmen könnte. z.B. 2 Objekte markieren und 'Alle gemeinsamen Punkte trennen' Oder auch mehrere Objekte als nur 2. So als Featurerequest. Müsste man noch bischen rumdenken und probieren ob es noch eine allgemeinere Möglichkeit gibt. z.B. 'Alle gemeinsamen Punkte markieren'. Danach dann 'trennen' aufrufen. Das hätte den Vorteil das man dann auch die gemeinsamen Punkte gemeinsam bewegen könnte. So hat man beide Fälle erledigt: Getrennte Punkte haben wollend oder halt gemeinsame Punkte. Vielleicht geht ja auch schon alles. Z.B. mit Filtern nur die beteiligten Objekte anzeigen lassen, dann alle Punkte markieren, dann trennen. Aber da kommt leicht zu viel dabei und es werden dann die falschen Dinge getrennt. Das Auftrennen ist bereits implementiert. Ja, das meinte ich im Absatz davor, kam nicht so gut rüber. Es funktioniert anders als ich dachte, tut aber besser als meine Idee. Man muß Punkte markieren + die Linie die jene Punkte als Kopien erhalten soll. Das Auswählen fehlt noch. Lieber modulare Funktionen die man kreativ zusammensetzt, bzw. per script zusammenkleben könnte (s.u.). Auf jeden Fall lohnt sich ein Blick auf den utils2-Plugin. Das tut es anscheinend in dem Fall nicht: http://wiki.openstreetmap.org/wiki/JOSM/Plugins/UtilsPlugin2 hab' es auch mal installiert und durchgeguckt. Falls man nicht fündig wird, ist wohl ein Enhancement-Ticket angebracht, wobei ein patch auch gerne gesehen wird. Ich brauch das zu selten:-) Wenn ich mal dazu komme mich in den josm code reinzugucken, java ansich ist keinerlei problem. Zeit und Energie ist immer Mangelware. Was ich mir leckerer vorstelle wäre sowas als javascript zu basteln. So wie greasmonkey eine reihe userscripte zum sharen oder im Wiki zu veröffentlichen. Beliebte kann man dann in den Kern übernehmen, sowas wie plugin-lite. Ob das gut wird weis ich nicht, bin mir aber recht sicher. Nachteil ist halt der Aufwand aussenrum: Man bräuchte Kram wie Fehlerconsole scriptdebugger etc. Rhino bringt das zwar mit, naja ok, es könnte reichen. Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 02.06.2011 15:50, schrieb Sebastian Hohmann: Am 31.05.2011 18:41, schrieb M∡rtin Koppenhoefer: Am 31. Mai 2011 18:26 schrieb Frederik Rammfrede...@remote.org: Von mir aus soll sich jeder das Leben so schwer machen, wie er will, solang er es nicht *anderen* schwer macht. das war ja der Ansatzpunkt: m.E. macht man den anderen das Leben schwer, wenn man Dinge verbindet, die gar nicht verbunden sind, und man für kleine Verfeinerungen erstmal die nicht zusammengehörigen Objekte mühsam auftrennen muss. Das kann aber auch andersrum passieren. Wenn man weiß die Straße bildet die Grenze zwischen z.B. Wald und Wohngebiet und man die Lage der Straße verfeinern will, ist es eventuell sogar erwünscht, dass sich die Flächen mitbewegen. Bei nicht verbundenen Dingen kann es dann aufwändiger sein, da man Das ist nur dann der Fall wenn der Wald schon voehrher falsch erfasst wurde und vorher am Verlauf der Strasse festgenageltwurde.. mehr einzelne Nodes korrigieren muss. Oder es ergeben sich sogar Fehler, wenn man die Flächen eben nicht auch korrigiert (dass z.B. eine Fläche über die Straße ragt, obwohl das in der Realität nicht der Fall ist). Man kann nur die Aussagetreffen dass die Strasse fälschlicherweise die Strasse überdeckt, mehr auch nicht, Es kann genausogut die Strasse als auch der Wald falsch erfasst sein. Das eine dem anderen anzupassen ist also eine Mappen für den Renderer... Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 03.06.2011 15:06, schrieb M∡rtin Koppenhoefer: Am 3. Juni 2011 14:36 schrieb flylowfligh...@googlemail.com: Das Auftrennen ist bereits implementiert. Auf jeden Fall lohnt sich ein Blick auf den utils2-Plugin. ja, das ist eine große Hilfe (davor war das Trennen mit komplexeren Operationen aus Löschen, Kopieren, Teilen und Einfügen ja eine rechte Qual), teilweise wird man aber Probleme mit Relationen bekommen (die nach dem Auftrennen beide Teile als Member haben). Es ist einfach keine gute Idee, landuses an Straßen zu hängen ;-) +1 Eine Fehlermeldung in josm Co währe sinnvoll wenn es trotzdem jemand versucht... Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Hallo, M?rtin Koppenhoefer wrote: Es ist einfach keine gute Idee, landuses an Straßen zu hängen ;-) Kommt drauf an, beide Methoden haben ihre Vor- und Nachteile und ihre Berechtigung. 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] Konzept für Daten, Karte und Renderer
Am 02.06.2011 18:54, schrieb Peter: Ja wird eklig. +1 Man kommt auf die Idee das Josm da einem viel Arbeit abnehmen könnte. z.B. 2 Objekte markieren und 'Alle gemeinsamen Punkte trennen' Oder auch mehrere Objekte als nur 2. So als Featurerequest. Müsste man noch bischen rumdenken und probieren ob es noch eine allgemeinere Möglichkeit gibt. z.B. 'Alle gemeinsamen Punkte markieren'. Danach dann 'trennen' aufrufen. Das hätte den Vorteil das man dann auch die gemeinsamen Punkte gemeinsam bewegen könnte. So hat man beide Fälle erledigt: Getrennte Punkte haben wollend oder halt gemeinsame Punkte. Vielleicht geht ja auch schon alles. Z.B. mit Filtern nur die beteiligten Objekte anzeigen lassen, dann alle Punkte markieren, dann trennen. Aber da kommt leicht zu viel dabei und es werden dann die falschen Dinge getrennt. Das Auftrennen ist bereits implementiert. Auf jeden Fall lohnt sich ein Blick auf den utils2-Plugin. Falls man nicht fündig wird, ist wohl ein Enhancement-Ticket angebracht, wobei ein patch auch gerne gesehen wird. Gruß fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 3. Juni 2011 14:36 schrieb fly lowfligh...@googlemail.com: Das Auftrennen ist bereits implementiert. Auf jeden Fall lohnt sich ein Blick auf den utils2-Plugin. ja, das ist eine große Hilfe (davor war das Trennen mit komplexeren Operationen aus Löschen, Kopieren, Teilen und Einfügen ja eine rechte Qual), teilweise wird man aber Probleme mit Relationen bekommen (die nach dem Auftrennen beide Teile als Member haben). Es ist einfach keine gute Idee, landuses an Straßen zu hängen ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 31.05.2011 18:41, schrieb M∡rtin Koppenhoefer: Am 31. Mai 2011 18:26 schrieb Frederik Rammfrede...@remote.org: Von mir aus soll sich jeder das Leben so schwer machen, wie er will, solang er es nicht *anderen* schwer macht. das war ja der Ansatzpunkt: m.E. macht man den anderen das Leben schwer, wenn man Dinge verbindet, die gar nicht verbunden sind, und man für kleine Verfeinerungen erstmal die nicht zusammengehörigen Objekte mühsam auftrennen muss. Das kann aber auch andersrum passieren. Wenn man weiß die Straße bildet die Grenze zwischen z.B. Wald und Wohngebiet und man die Lage der Straße verfeinern will, ist es eventuell sogar erwünscht, dass sich die Flächen mitbewegen. Bei nicht verbundenen Dingen kann es dann aufwändiger sein, da man mehr einzelne Nodes korrigieren muss. Oder es ergeben sich sogar Fehler, wenn man die Flächen eben nicht auch korrigiert (dass z.B. eine Fläche über die Straße ragt, obwohl das in der Realität nicht der Fall ist). Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Tachen Am 02.06.2011 15:50, schrieb Sebastian Hohmann: Das kann aber auch andersrum passieren. Wenn man weiß die Straße bildet die Grenze zwischen z.B. Wald und Wohngebiet und man die Lage der Straße verfeinern will, ist es eventuell sogar erwünscht, dass sich die Flächen mitbewegen. Wenn Du einmal in einem Stadteil oder Dorf das alles auseinander tröseln durftest weil da was zusammen gepappt war was nicht zusammen gehört und Du dann Dich auch gleich noch um zwei Radwegrelationen, vier Busrelationen und sonstige Flächenbezogene Relationen mit kümmern darfst wirst Du darüber möglicher Weise anders denken. Dann macht eine Kreuzung mal richtig Arbeit. Und auf der Karte siehst Du dann nicht mal das da was geändert werden (musste). Ich sehe das so wie meine Vorschreiber, ein Fläche gehört nicht an einen Weg. Mir vergeht bei solchen Konstrukten recht schnell die Lust inzwischen da überhaupt Hand anzulegen. -- Mit freundlichen Grüßen Carsten Schönert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Hi Am 02.06.2011 17:41, schrieb Carsten Schönert: Am 02.06.2011 15:50, schrieb Sebastian Hohmann: Das kann aber auch andersrum passieren. Wenn man weiß die Straße bildet die Grenze zwischen z.B. Wald und Wohngebiet und man die Lage der Straße verfeinern will, ist es eventuell sogar erwünscht, dass sich die Flächen mitbewegen. Wenn Du einmal in einem Stadteil oder Dorf das alles auseinander tröseln durftest weil da was zusammen gepappt war was nicht zusammen gehört und Du dann Dich auch gleich noch um zwei Radwegrelationen, vier Busrelationen und sonstige Flächenbezogene Relationen mit kümmern darfst wirst Du darüber möglicher Weise anders denken. Dann macht eine Kreuzung mal richtig Arbeit. Und auf der Karte siehst Du dann nicht mal das da was geändert werden (musste). Ich sehe das so wie meine Vorschreiber, ein Fläche gehört nicht an einen Weg. Mir vergeht bei solchen Konstrukten recht schnell die Lust inzwischen da überhaupt Hand anzulegen. Ja wird eklig. Man kommt auf die Idee das Josm da einem viel Arbeit abnehmen könnte. z.B. 2 Objekte markieren und 'Alle gemeinsamen Punkte trennen' Oder auch mehrere Objekte als nur 2. So als Featurerequest. Müsste man noch bischen rumdenken und probieren ob es noch eine allgemeinere Möglichkeit gibt. z.B. 'Alle gemeinsamen Punkte markieren'. Danach dann 'trennen' aufrufen. Das hätte den Vorteil das man dann auch die gemeinsamen Punkte gemeinsam bewegen könnte. So hat man beide Fälle erledigt: Getrennte Punkte haben wollend oder halt gemeinsame Punkte. Vielleicht geht ja auch schon alles. Z.B. mit Filtern nur die beteiligten Objekte anzeigen lassen, dann alle Punkte markieren, dann trennen. Aber da kommt leicht zu viel dabei und es werden dann die falschen Dinge getrennt. Die erste Idee oben scheint da ganz ok. Und vielleicht mal irgendwo aufschreiben wie das gemappt werden sollte und: Warum! Nur mit Verständnis kann man sich das merken und es wird eher befolgt. Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 31.05.2011 12:45, schrieb M∡rtin Koppenhoefer: eine Straßenmitte ist nie gleichzeitig ein Waldrand, von daher ist da schon vorher irgendwo ein Fehler. Wenn man die Sachen auf verschiedenen, getrennten Layern hat, dann kann man allerdings topologische Zusammenhänge gar nicht mehr herstellen, von daher geht das m.E. mit unserem Datenmodell sowieso nicht. Es spricht ja nichts dagegen dass man die verschiedene Layer gleichzeitig darstellt. Es würde aber Sinn machen dass man Layer die nichts miteinander zu tun haben nicht gleichzeitig bearbeiten kann um nicht genaue Daten (z.B. genauer Strassenmittenverlauf) wieder mit ungenauen Daten (grob abgezeichnerter Waldgrenzenverlauf) zu verschlimmbessern... Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Hallo, On 05/31/11 12:45, M∡rtin Koppenhoefer wrote: eine Straßenmitte ist nie gleichzeitig ein Waldrand, von daher ist da schon vorher irgendwo ein Fehler. Ich wehre mich gegen die Implikation, dass eine Generalisierung beim Mappen immer gleich ein Fehler sein muss. Viele Mapper verwenden tatsaechlich eine Strassengeometrie als Flaechenbegrenzung. Das ist voellig in Ordnung, genauso wie es voellig in Ordnung ist, eine zweigleisige Bahntrasse als einzigen railway=rail-Way zu zeichnen. Es ist eine Ungenauigkeit, die den aktuell zur Verfuegung stehenden Mitteln oder der Erfassungsgenauigkeit oder der Arbeitsbereitschaft des Mappers geschuldet ist. Es ist kein Fehler. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 31. Mai 2011 14:36 schrieb Frederik Ramm frede...@remote.org: Hallo, On 05/31/11 12:45, M∡rtin Koppenhoefer wrote: eine Straßenmitte ist nie gleichzeitig ein Waldrand, von daher ist da schon vorher irgendwo ein Fehler. Ich wehre mich gegen die Implikation, dass eine Generalisierung beim Mappen immer gleich ein Fehler sein muss. Viele Mapper verwenden tatsaechlich eine Strassengeometrie als Flaechenbegrenzung. Das ist voellig in Ordnung, genauso wie es voellig in Ordnung ist, eine zweigleisige Bahntrasse als einzigen railway=rail-Way zu zeichnen. Es ist eine Ungenauigkeit, die den aktuell zur Verfuegung stehenden Mitteln oder der Erfassungsgenauigkeit oder der Arbeitsbereitschaft des Mappers geschuldet ist. Es ist kein Fehler. OK, es ist eine Ungenauigkeit, die man je nach Bezugsmaßstab als topologischen Fehler werten kann, oder auch einfach nur als vorläufig grob gemappt, einverstanden. Prinzipiell bin ich bereit, Ungenauigkeiten, die z.B. aus der von Dir genannten geringen Arbeitsbereitschaft des Mappers bzw. der Erfassungsgenauigkeit resultieren, durchaus auch als Fehler zu werten --- natürlich ohne dass daraus gleich eine Anklage wird. Eine Straße ohne Namen, die eigentlich einen Namen hat, ist nicht falsch, während ein falsch geschriebener Name klar falsch ist. Mit der Topologie ist es ähnlich: nicht vorhandene Details (z.B. schludrig gezeichneter Waldrand) sind erstmal nur unvollständig, während falsch verbundene Dinge eben falsch sind. Weg-mitten können nie Flächenbegrenzungen sein, dass sollte eigentlich klar sein. Ob man es als Näherung akzeptieren will muss die Community abwägen. Auf der einen Seite steht das einfachere und schnellere Mappen, auf der anderen Seite führt diese Schludrigkeit zu falschen Flächengrößen und oft auch zu weiteren Topologiefehlern (z.B. wenn der Waldrand jetzt eingezäunt ist, machen manche einfach einen barrier=fence-tag an den Waldrand, der in diesem Fall dann mitten auf der Straße läuft, oder wenn weitere Objekte, die nicht zusammengehören, verbunden werden, z.B. eine Querstraße mit dem Landuse anstatt mit der Straße). Auch behindert es beim Ergänzen weiterer Details (wenn man aufnehmen will, was zwischen Straße und Wald liegt). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Hallo, On 05/31/11 15:14, M∡rtin Koppenhoefer wrote: Weg-mitten können nie Flächenbegrenzungen sein, dass sollte eigentlich klar sein. So, wie Du es geschrieben hast, mag das klar sein. Aber ein OSM-Way ist nicht die Wegmitte, sondern eine Naeherungsdarstellung fuer die gesamte Strasse. Frag jemanden, bis wohin der Wald geht, und derjenige sagt bis zur Landstrasse. Dann *ist* die Landstrasse die Flaechenbegrenzung, und es ist voellig in Ordnung, die Landstrasse zur Flaechenbegrenzung zu nehmen. Dass daraus dann etwas Falsches wird, wenn jemand den Way, der die Landstrasse repraesentiert, als die Mitte der Landstrasse interpretiert, das ist dessen Problem. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 31. Mai 2011 15:53 schrieb Frederik Ramm frede...@remote.org: Hallo, On 05/31/11 15:14, M∡rtin Koppenhoefer wrote: Weg-mitten können nie Flächenbegrenzungen sein, dass sollte eigentlich klar sein. So, wie Du es geschrieben hast, mag das klar sein. Aber ein OSM-Way ist nicht die Wegmitte, sondern eine Naeherungsdarstellung fuer die gesamte Strasse. jedenfalls bis jemand kommt, und die Straßenflächen auch noch explizit mappt (da gibt es ja einige, die das gerne wünschen bzw. wird es z.T. auch schon gemacht). Frag jemanden, bis wohin der Wald geht, und derjenige sagt bis zur Landstrasse. Dann *ist* die Landstrasse die Flaechenbegrenzung, und es ist voellig in Ordnung, die Landstrasse zur Flaechenbegrenzung zu nehmen. naja, sprachlich ist derjenige halt auf etwas angewiesen, was der andere wiedererkennen kann. Wenn ich jemanden frage: wo ist der Reichstag in Berlin?, und der sagt mir neben dem Brandenburger Tor, dann stimmt das ja auch ungefähr, aber trotzdem würde der Durchschnittsmapper es gerne genauer eintragen. Dass daraus dann etwas Falsches wird, wenn jemand den Way, der die Landstrasse repraesentiert, als die Mitte der Landstrasse interpretiert, das ist dessen Problem. Das Problem ist die Mischung von Graphen mit Flächen. Zwar ist das unter anderem Blickwinkel auch eine Stärke, aber inwiefern so ein Vorgehen in OSM gewünscht ist sollte man m.E. unter Abwägung der Vor- und Nachteile in der Community abstimmen, so dass man wenigstens eine klare Empfehlung abgeben kann - zu einer bestimmten Mappingweise kann man ja sowieso niemanden zwingen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Frederik Ramm schrieb am 31.05.2011 15:53: Aber ein OSM-Way ist nicht die Wegmitte, sondern eine Naeherungsdarstellung fuer die gesamte Strasse. Frag jemanden, bis wohin der Wald geht, und derjenige sagt bis zur Landstrasse. Dann *ist* die Landstrasse die Flaechenbegrenzung, und es ist voellig in Ordnung, die Landstrasse zur Flaechenbegrenzung zu nehmen. Dass daraus dann etwas Falsches wird, wenn jemand den Way, der die Landstrasse repraesentiert, als die Mitte der Landstrasse interpretiert, das ist dessen Problem. Sehe ich genauso. Nach meiner Meinung gehoert also nur ein Abstand zwischen die (als Linie erfasste) Strasse und eine Flaeche, wenn zwischen der Strasse und dieser Flaeche noch ein anderes Objekt liegt, dass man spaeter zu erfassen gedenkt. Bei einem Wald den Rand mit einer Genauigkeit einer Fahrbahnbreite den Rand festlegen zu wollen, ist sowieso muessig. Verlaeuft entlang der aeussersten Borke eines Stammes der Waldrand? Ober ist der am weitesten hinausragende Zweig der Rand des Waldes? Oder eine offizielle Flurstueckgrenze? Oder... Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 31. Mai 2011 16:26 schrieb Torsten Leistikow de_m...@gmx.de: Sehe ich genauso. Nach meiner Meinung gehoert also nur ein Abstand zwischen die (als Linie erfasste) Strasse und eine Flaeche, wenn zwischen der Strasse und dieser Flaeche noch ein anderes Objekt liegt, dass man spaeter zu erfassen gedenkt. wer ist man? Praktisch jede Straße hat einen Graben, vor allem, wenn durch einen Wald führt. Bei einem Wald den Rand mit einer Genauigkeit einer Fahrbahnbreite den Rand festlegen zu wollen, ist sowieso muessig. Verlaeuft entlang der aeussersten Borke eines Stammes der Waldrand? Ober ist der am weitesten hinausragende Zweig der Rand des Waldes? Oder eine offizielle Flurstueckgrenze? m.E. ein Missverständnis, es ging um topologische Präzision nicht darum, auf den cm genau den Waldrand angeben zu wollen. Dass wir z.T. Probleme damit haben, die Ränder von Flächen genau zu bestimmen, hat nichts damit zu tun, wie man Objekte untereinander miteinander verknüpft. Wenn man schon keine Lust hat, den Waldrand zu bestimmen, kann man genausogut (oder besser m.E.) einfach die Straße _durch_ den Wald führen, also den Wald dort überhaupt nicht teilen und dadurch den Generalisierungsgrad bereits angeben. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
M∡rtin Koppenhoefer schrieb am 31.05.2011 16:36: Praktisch jede Straße hat einen Graben, vor allem, wenn durch einen Wald führt. Dir ist schon klar, dass deine Formulierung impliziert, dass der Graben Teil der Strasse ist? Wenn man schon keine Lust hat, den Waldrand zu bestimmen, kann man genausogut (oder besser m.E.) einfach die Straße _durch_ den Wald führen, also den Wald dort überhaupt nicht teilen und dadurch den Generalisierungsgrad bereits angeben. Kann man auch. Haeufig bietet sich die Teilung des Waldes entlang von Strassen nur aus rein pragmatsichen Gruenden an. Interessanter sind sicherlich Faelle, wo nur auf beiden Seiten der Strasse unterschiedliche Objekte angrenzen. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 31. Mai 2011 16:53 schrieb Torsten Leistikow de_m...@gmx.de: Interessanter sind sicherlich Faelle, wo nur auf beiden Seiten der Strasse unterschiedliche Objekte angrenzen. ja, und wenn da nun auf der einen Seite ein Wald und auf der anderen ein Feld angeschlossen wird, dann grenzen die beiden in OSM direkt aneinander (gemeinsame Nodes), während Du in der Realität eine Straße _dazwischen_ hast. Klar, solche Fehler kann man auch durch Analyse beseitigen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Hallo, On 05/31/11 18:20, M∡rtin Koppenhoefer wrote: ja, und wenn da nun auf der einen Seite ein Wald und auf der anderen ein Feld angeschlossen wird, dann grenzen die beiden in OSM direkt aneinander (gemeinsame Nodes) Da sehe ich nun auch wieder gar kein Problem. Von mir aus soll sich jeder das Leben so schwer machen, wie er will, solang er es nicht *anderen* schwer macht. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 31. Mai 2011 18:26 schrieb Frederik Ramm frede...@remote.org: Von mir aus soll sich jeder das Leben so schwer machen, wie er will, solang er es nicht *anderen* schwer macht. das war ja der Ansatzpunkt: m.E. macht man den anderen das Leben schwer, wenn man Dinge verbindet, die gar nicht verbunden sind, und man für kleine Verfeinerungen erstmal die nicht zusammengehörigen Objekte mühsam auftrennen muss. Oder wenn man Multipolygonmonster für landuse=residential (etc.) anlegt, wo klare Flächen ausreichend wären. Auf dem Land mag das noch eher angehen, da man sowieso erstmal nicht flächendeckend von einer hohen Detaillierung ausgehen kann, aber in der Stadt führt das oft dazu, dass sich Folgefehler einschleichen. M.E. ist das Mappen von Flächen in ihren wahren Grenzen die Methode, die am besten skaliert und sich am einfachsten weitermappen lässt. Multipolygone, wie oft gesehen z.B. für landuses, entwickeln sich im Laufe des Mappens immer mehr zu unübersichtlichen Monstern (die kaum von einem neuen Mapper durchdrungen werden können), während meistens klare schlichte Flächen ausreichend und aussagekräftiger wären. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
M∡rtin Koppenhoefer schrieb am 31.05.2011 18:20: ja, und wenn da nun auf der einen Seite ein Wald und auf der anderen ein Feld angeschlossen wird, dann grenzen die beiden in OSM direkt aneinander (gemeinsame Nodes), während Du in der Realität eine Straße _dazwischen_ hast. Klar, solche Fehler kann man auch durch Analyse beseitigen. Guter Punkt. Wenn man die Flaechen bis zur (linienfoermigen) Strasse eintraegt, dann kann man in der Auswertung erkennen, dass Strasse und Flaeche gemeinsame Knotenpunkte haben und daraus kann man die Topologie konstruieren. Wenn man dagegen die Flaeche in einem Abstand von der Strassenlinie enden laesst, ist man in der Auswertung ziemlich aufgeschmissen. Nachteil von diesem Argument ist leider, dass die logische Schlussfolgerung daraus ist, Flaechen grundsaetzlich als Multipolygon einzutragen, damit man die einzelnen Grenzlinien gleich fertig geliefert bekommt. Das kann man allerdings dadurch entkraeften, dass man so eine Wer-grenzt-an-wen-Analyse normalerweise nicht braucht, die reinen Flaechenauswertungen mit diesem Ansatz aber erheblich aufwendiger macht. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 28.05.2011 09:41, schrieb Peter Wendorff: Wir haben keinen Plasberg hier (oder? :D), aber ein Antrag an den erweiterten Faktencheck: Man untersuche mal die OSM-Datenbank auf Überschneidungen von Tags und Tag-Gruppen. Also: - Überschneiden sich landuses tatsächlich weitgehend NICHT mit highways? wenn doch, ist das ein Fehler oder eigentlich korrekt? Wenn es korrekt ist, ist hier der Layer eigentlich nicht machbar. - Analog zu Routing-relevanten Tags (also im weitesten Sinne highway=*) Wenn noch mehr Kapazität da wäre, würde ich weiter fragen - obwohl ich mir spätestens hier eigentlich auch selbst eine Antwort geben kann: - Sind gleichzeitige (im Sinne von in-einem-changeset-getätigte) Änderungen an nur geometrisch naheliegenden Objekten (z.b. landuse und highway) voneinander unabhängig? Ich behaupte, das sind sie häufig nicht: Ich verschiebe den Weg und korrigiere die angrenzenden Flächen entsprechend (denn das Feld geht bis zum Straßenrand und auf der anderen Seite beginnt direkt neben der Straße das Fabrikgelände). Vielleicht (!) bis zum Strassenrand, aber einen Randstreifen gibt es praktisch immer und ein highway = xx bezeichnet (als Linie) niemals einen Strassenrand sondern näherungsweise die Fahrbahn/Fahrstreifenmitte. Trennt man jetzt aber die Layer, dann erschwert man dieses simultane Bearbeiten - und versteckt die dadurch provozierten Fehler eher vor dem Nutzer. Nein, man verhindert somit dass sich ein Fehler auf den anderen Layer automatisch überträgt. Wenn ich z.b. eine Waldfläche bearbeite um die Konturen detaillierter zu erfassen ist es äusserst lästig wenn eine Strasse daran klebt. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 27.05.2011 19:46, schrieb Heiko Jacobs: Am 27.05.2011 14:07, schrieb Peter Wendorff: Am 27.05.2011 12:20, schrieb Markus: Ich könnte mir das so vorstellen: Mapper E-Verarbeitungsschicht DB ... Da hast du mich falsch verstanden! Ich bin für Mapper DB ... Die Daten des Mappers (1) werden von einem intelligenten Editor entgegengenommen und vorverarbeitet und in die Eingangs-Verarbeitungsschicht gespeichert (2). so intelligent kann die Schicht nicht sein, dass dadurch keine Informationen verloren gehen. Außerdem ist einiges in dem Bereich nicht sinnvollerweise bei jedem Upload durchzuführen. Ich wäre auch vorsichtig, allzu viel in die E-Schicht zu packen. Eins jedoch sollten Editoren -- oder wenn die es nicht machen -- die Eingangschicht der DB machen: Splits und Vereinigungen erkennen und eine saubere Historie auch für diese erzeugen. Das ist nicht nur DER Knackpunkt der Relizenzierung (ohne saubere Historie auch bei Splits und Vereinigungen ist die rechtlich angreifbar), sondern auch ganz generell lästig, wenn man die Entstehungsgeschichte eines Objekts verfolgen möchte, wann und von wem und warum bspw. Tag X drangehängt wurde an die Y-Straße ... +10! Ja, ganz klar - das fehlt bisher in API und Editoren völlig. Allerdings hilft das auch nur zum Teil: Bei der Beobachtung mancher Mapper (und etlicher Changesets) ist mir aufgefallen, dass oft eben nicht gelöscht + neu angelegt wird, sondern mal eben wiederverwendet, verschoben und umgewidmet wird. Da soll eine Wiese gelöscht und ein Gebäude hinzugefügt werden - dann nimmt man den way der Wiese, arrangiert die Nodes des way neu und vergibt neue Tags - das kann beim besten Willen kein Editor als neues Objekt erkennen. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Wir haben keinen Plasberg hier (oder? :D), aber ein Antrag an den erweiterten Faktencheck: Man untersuche mal die OSM-Datenbank auf Überschneidungen von Tags und Tag-Gruppen. Also: - Überschneiden sich landuses tatsächlich weitgehend NICHT mit highways? wenn doch, ist das ein Fehler oder eigentlich korrekt? Wenn es korrekt ist, ist hier der Layer eigentlich nicht machbar. - Analog zu Routing-relevanten Tags (also im weitesten Sinne highway=*) Wenn noch mehr Kapazität da wäre, würde ich weiter fragen - obwohl ich mir spätestens hier eigentlich auch selbst eine Antwort geben kann: - Sind gleichzeitige (im Sinne von in-einem-changeset-getätigte) Änderungen an nur geometrisch naheliegenden Objekten (z.b. landuse und highway) voneinander unabhängig? Ich behaupte, das sind sie häufig nicht: Ich verschiebe den Weg und korrigiere die angrenzenden Flächen entsprechend (denn das Feld geht bis zum Straßenrand und auf der anderen Seite beginnt direkt neben der Straße das Fabrikgelände). Trennt man jetzt aber die Layer, dann erschwert man dieses simultane Bearbeiten - und versteckt die dadurch provozierten Fehler eher vor dem Nutzer. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 27.05.2011 21:59, schrieb Torsten Leistikow: Henning Scholland schrieb am 27.05.2011 20:28: Von einer solchen Abstufung halte ich nichts. Schließlich soll der Renderer (und der Programmierer dahinter) entschieden wann er was darstellt. +1 Die Entscheidung liegt ja auch weiterhin bei dem Renderer. Er ist ja nicht gezwungen die Hilfstags auszuwerten, und wenn er es tut, dann kann er das ja auch fuer verschiedene Elemente unterschiedlich handhaben. Eine Karte fuer Radfahrer koennte so z.B. Radwege immer darstellen wollen, eine Karte fuer Autofahrer wuerde sich in diesem Falle anders entscheiden, und bei Gleisen wuerde es beiden reichen, nur eins von mehreren parallel darzustellen. Das Tag ist ja keine verbindliche Vorgabe fuer die Renderer, sondern es ist nur ein Hilfmittel, um den Auswerteprogrammen das Weglassen von Objekten zu erleichtern. Es ist nur ein Hilfsmittel, das stimmt, aber solange die Renderer auf strikten Regeln arbeiten müssen, wird es Leute geben, die den Weg zu Oma auf der Deutschlandkarte sehen müssen, und deshalb jede noch so kleine Straße auf dem Weg als besonders wichtig einstufen. Klar - man kann die Regeln des Renderers anpassen und das da eben nicht mehr machen; aber für JEDE Berücksichtigung solcher Tags wird es früher oder später jemanden geben, der sie ausnutzt, um die Standardkarte den eigenen Wünschen entsprechend umzugestalten, und eben nicht selbst zu rendern. Hier zeigt sich eben auch (mal wieder), dass das Konzept von der OSM-Standardkarte als in erster Linie Proof-of-Konzept und Mapper-Hilfe nicht ganz wasserdicht ist: Die hier sinnvolle Demonstration zusätzlicher Möglichkeiten widerspricht eigentlich dem Ansatz, Hilfe für Mapper und Einstiegspunkt für das Finden vieler Fehler zu sein, wäre aber ein Glanzpunkt, was die Konzept-Implementierung angeht. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 27.05.2011 20:28, schrieb Henning Scholland: Im Falle vom Fußweg/Radweg/Straße bspw. könnte man kennzeichnen, dass der Radweg und der Fußweg zur Straße gehören und nicht einen eigenständigen Weg bilden. Das ist eine Info, die auch zum (Rad-)Routen nützlich ist. Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Peter Wendorff schrieb am 28.05.2011 09:50: Es ist nur ein Hilfsmittel, das stimmt, aber solange die Renderer auf strikten Regeln arbeiten müssen, wird es Leute geben, die den Weg zu Oma auf der Deutschlandkarte sehen müssen, und deshalb jede noch so kleine Straße auf dem Weg als besonders wichtig einstufen. So ganz hast du die Idee des Vorschlags noch nicht verstanden. Mit den vorgeschlagenen Hilfstags kann man keine Anzeige beim Renderer erzwingen, ein Element kann dadurch nicht wichtiger werden, als es jetzt schon ist. In der umgekehrten Richtung gibt es dem Mapper allerdings die Moeglichkeit, Elemente fuer hohe oder niedrige Detail-Auswertungen als nachrangig zu kennzeichnen, da sie auf diesem Detaillevel durch ein anderes Element hinreichend repraesentiert werden. Klar - man kann die Regeln des Renderers anpassen und das da eben nicht mehr machen; aber für JEDE Berücksichtigung solcher Tags wird es früher oder später jemanden geben, der sie ausnutzt, um die Standardkarte den eigenen Wünschen entsprechend umzugestalten, und eben nicht selbst zu rendern. Die Missbrauchsmoeglichkeiten sind da sehr beschraenkt: 1. Ein Mapper kennzeichnet etwas als main, was von anderen eher als minor gekennzeichnet werden wuerde - Das Element wird bei niedrigen Zoom-Stufen nicht ausgeblendet - Die Karte sieht genauso aus wie heute ohne solche Zusatztags. Die Lage hat sich also durch den Missbrauch nicht verschlechtert. 2. Ein Mapper kennzeichnet was als minor, was von anderen eher als main gekennzeichnet werden wuerde - Das Element wird bei niedrigen Zoom-Stufen eventuell von einigen Renderen nicht mehr angezeigt (bei vielen Typen wuerde ein minor heute keinen Sinn machen und von einem Renderer deshalb auch nicht beruecksichtigt werden.) - Ein andere Mapper wird das Element auf der Karte vermissen und das Tagging entsprechen korregieren. Das ist genauso, wie Mapper auch heute bei den Strassenkategorien unterschiedlicher Meinung sein koennen, davon geht die OSM-Karte nicht unter. Auf die Kennzeichnung abstract gehe ich hier nicht weiter ein, da es bislang keine derartigen Elemente gibt, das waere also eher was fuer die Zukunft, wenn sich entsprechender Bedarf ergibt. Hier zeigt sich eben auch (mal wieder), dass das Konzept von der OSM-Standardkarte als in erster Linie Proof-of-Konzept und Mapper-Hilfe nicht ganz wasserdicht ist: Die hier sinnvolle Demonstration zusätzlicher Möglichkeiten widerspricht eigentlich dem Ansatz, Hilfe für Mapper und Einstiegspunkt für das Finden vieler Fehler zu sein, wäre aber ein Glanzpunkt, was die Konzept-Implementierung angeht. Dem will ich nicht widersprechen, vorallem deshalb, weil ich nicht verstanden habe, was du damit sagen willst ;-) Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 28.05.2011 16:38, schrieb Torsten Leistikow: Peter Wendorff schrieb am 28.05.2011 09:50: Es ist nur ein Hilfsmittel, das stimmt, aber solange die Renderer auf strikten Regeln arbeiten müssen, wird es Leute geben, die den Weg zu Oma auf der Deutschlandkarte sehen müssen, und deshalb jede noch so kleine Straße auf dem Weg als besonders wichtig einstufen. So ganz hast du die Idee des Vorschlags noch nicht verstanden. Mit den vorgeschlagenen Hilfstags kann man keine Anzeige beim Renderer erzwingen, ein Element kann dadurch nicht wichtiger werden, als es jetzt schon ist. In der umgekehrten Richtung gibt es dem Mapper allerdings die Moeglichkeit, Elemente fuer hohe oder niedrige Detail-Auswertungen als nachrangig zu kennzeichnen, da sie auf diesem Detaillevel durch ein anderes Element hinreichend repraesentiert werden. Ich hab den Vorschlag sehr wohl verstanden. Aber wenn ich nicht wichtiger taggen kann, dann tagge ich eben alle konkurrierenden Objekte als minder wichtig, um mein Ziel zu erreichen. Wo Leute die Sandgrube auf dem Golfplatz als Strand taggen, weil das Rendering die schönere Farbe zeigt, wird auch das früher oder später passieren. Wie? Mapnik zeigt die Nachbarstraße an und nicht die Straße, in der ich wohne? dann tagge ich die Nachbarstraße eben als weniger wichtig. Klar - man kann die Regeln des Renderers anpassen und das da eben nicht mehr machen; aber für JEDE Berücksichtigung solcher Tags wird es früher oder später jemanden geben, der sie ausnutzt, um die Standardkarte den eigenen Wünschen entsprechend umzugestalten, und eben nicht selbst zu rendern. Die Missbrauchsmoeglichkeiten sind da sehr beschraenkt: 1. Ein Mapper kennzeichnet etwas als main, was von anderen eher als minor gekennzeichnet werden wuerde - Das Element wird bei niedrigen Zoom-Stufen nicht ausgeblendet - Die Karte sieht genauso aus wie heute ohne solche Zusatztags. Die Lage hat sich also durch den Missbrauch nicht verschlechtert. Falsch: Heute wird irgendwas ausgeblendet, dann wird bevorzugt etwas anderes ausgeblendet. Klar: man kann dadurch nicht MEHR anzeigen, aber ANDERES. Richtig ist zwar, dass sich die Lage nicht verschlechtert hat, verbessern wird sich dadurch aber auch nichts. 2. Ein Mapper kennzeichnet was als minor, was von anderen eher als main gekennzeichnet werden wuerde - Das Element wird bei niedrigen Zoom-Stufen eventuell von einigen Renderen nicht mehr angezeigt (bei vielen Typen wuerde ein minor heute keinen Sinn machen und von einem Renderer deshalb auch nicht beruecksichtigt werden.) - Ein andere Mapper wird das Element auf der Karte vermissen und das Tagging entsprechen korregieren. Das ist genauso, wie Mapper auch heute bei den Strassenkategorien unterschiedlicher Meinung sein koennen, davon geht die OSM-Karte nicht unter. Aber warum gibst du hier dem Mapper die Möglichkeit, bewusst zu entscheiden, dass etwas nicht gerendert werden soll? Wenn jemand ein solches Element heute löscht, ist das Vandalismus und als solcher in OSM geächtet. Wenn jemand nur dranpappt, dass das irrelevant ist, dann ist die Wirkung für einige, potenziell die wegweisenden Renderings die gleiche, aber du kannst es kaum noch als Vandalismus darstellen. Gewonnen ist damit aber nichts. Hier zeigt sich eben auch (mal wieder), dass das Konzept von der OSM-Standardkarte als in erster Linie Proof-of-Konzept und Mapper-Hilfe nicht ganz wasserdicht ist: Die hier sinnvolle Demonstration zusätzlicher Möglichkeiten widerspricht eigentlich dem Ansatz, Hilfe für Mapper und Einstiegspunkt für das Finden vieler Fehler zu sein, wäre aber ein Glanzpunkt, was die Konzept-Implementierung angeht. Dem will ich nicht widersprechen, vorallem deshalb, weil ich nicht verstanden habe, was du damit sagen willst ;-) Die Mapnik-Karte wird von einigen OSM-Aktivisten (mich eingeschlossen) nicht in erster Linie als gute Karte angesehen. Es geht nicht darum, dass die Standard-Stile auf osm.org die best-aussehenden Karten darstellen; es geht vielmehr darum, sichtbar zu machen, was mit OSM alles möglich ist. Ein neuer Nutzer kommt auf die Webseite und sieht: boah, da ist sogar der Fußgängerweg nebenan eingezeichnet - den hab ich sonst noch auf keiner Karte gesehen!. Spannend in dem Zusammenhang gerade auch die Radfahrer- und ÖPNV-Karten - obwohl die nicht auf der Startseite zu sehen sind. Auch die sind aus kartographischen Gesichtspunkten beurteilt keine herausragenden Werke; aber sie zeigen, was möglich ist. Andererseits nutzen Mapper wie wir die Karten, um festzustellen, wo noch POIs fehlen oder wo Fehler zu beheben sind. Wenn aber die technischen Möglichkeiten von Mapnik dahingehend genutzt (und insofern demonstriert) würden, dass Linienbündel zusammengefasst werden, dann gehen möglicherweise da wieder visuelle Informationen verloren, und ich kann die Frage, ob es sich jetzt um ein Eisenbahngleis oder eine mehrspurige Strecke handelt, möglicherweise nur noch schlecht beantworten. Gruß Peter
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Peter Wendorff schrieb am 28.05.2011 19:17: Aber wenn ich nicht wichtiger taggen kann, dann tagge ich eben alle konkurrierenden Objekte als minder wichtig, um mein Ziel zu erreichen. Das klappt deshalb nicht, weil ein Renderer ja gar nicht pauschal alles mit minor markiertes unterdruecken wuerde, es kommt dabei ja immer noch zusaetzlich auf den Typ des Objektes an. Ausserdem wuerde damit ein Objekt ja auch nicht komplett aus der gerenderten Karte verschwinden, sondern nur auf Zoom-Stufen, wo es in der Anzeige sowieso mit einem anderen Objekt konkurrieren wuerde, d.h. mit guter Wahrscheinlichkeit sowieso verdeckt waere. Auch jetzt ist es so, dass ein Renderer ab einer bestimmten Zoom-Stufe entscheidet, dass ein Objekt zu Gunsten der Uebersicht nicht mehr angezeigt wird. Durch das Detail-Mapping haben wir nun aber immer haeufiger den Fall, dass der Renderer allein aufgrund des Typs der Objekte nicht ausreichend auswaehlen kann, was er weg lassen sollte (es gibt einfach zu viele gleichrangige Objekte). Ist es da nicht sinnvoller, wem man als Mapper dem Renderer einen Tipp geben kann, was er bei der Anzeige im Zweifelsfall unterdruecken koennte, als dass das zufaellig passiert? Wie? Mapnik zeigt die Nachbarstraße an und nicht die Straße, in der ich wohne? dann tagge ich die Nachbarstraße eben als weniger wichtig. Wenn man ein Objekt (eine Strasse) in der Anzeige bevorzugen moechte, dann hat man auch heute schon die Moeglichkeit, an der Klassifizierung rumzuspielen. Die Mapnik-Karte wird von einigen OSM-Aktivisten (mich eingeschlossen) nicht in erster Linie als gute Karte angesehen. Es geht nicht darum, dass die Standard-Stile auf osm.org die best-aussehenden Karten darstellen; es geht vielmehr darum, sichtbar zu machen, was mit OSM alles möglich ist. Mir geht es ja auch nicht darum, dass unbedingt die Mapnik-Karten besser aussehen soll, das Problem betrifft naemlich auch alle anderen automatisch erzeugten Karten. Wenn jemand also das Ziel hat, eine optisch moeglichst schoene Karte zu erzeugen (im Gegensatz zu deinem Anspruch an die Standardkarte), dann verbauen wir ihm dafuer jegliche Moeglichkeit. Wenn wir den Mappern keine Moeglichkeit geben, in gewissen Grenzen die Kartenansicht mit zu beeinflussen, dann neigen die Mapper dazu, zu diesem Zweck die Daten zu verfaelschen (Mappen fuer den Renderer, haeufigster Fall ist da sicherlich das Layer-Tag bei Flaechen). Das Problem ist bei einem Hilfstag ausgeschlossen, wenn es per Definition fuer die Bedeutung des Elementes irrelevant ist. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Hallo Markus. Inwieweit das ein Thema für ein Treffen von ein paar Stunden oder Tagen sein kann, weiß ich nicht, denn das ist 'ne ganz schön große Kiste, die du da als Thema hinstellst. Nichtsdestotrotz sind die Fragen aber, denke ich, ziemlich richtig. Auf der einen Seite sollten die Daten sauber sein, auf der anderen Seite fordert das für Renderer immer komplexere Gebilde. Auf der einen Seite sollen die Daten handhabbar bleiben, auf der anderen Seite ist es schön, genau das Detail zu finden, das ich wirklich grade brauche. Ich denke, eigentlich fehlt trotz vieler Bemühungen immer noch ein Zwischenschritt in der Pipeline, die das OSM-Universum bildet: (a) Wir haben Mapper, (b) wir haben Daten, die wir Anwendern geben können, (d) es existieren Anwendungen wie Renderer/Karten, Router, Kunstanwendungen, Suchmaschinen und so weiter. c hab ich bewusst ausgelassen - da fehlt irgendwie noch was: Eine gut zu verwendende Verarbeitungsschicht, die man Anwendungsentwicklern an die Hand geben kann, ohne dass die erst monatelange Einarbeitungszeit brauchen. Osmosis gehört in diese Kategorie und ist zweifelsohne ein extrem nützliches Tool. Es gibt allerdings auch für osmosis diverse Anwendungen, die immer wieder vorkommen und nützlich wären: - Wie generiere ich aus einem planet oder Gebietsextrakt einen Routinggraphen? Ich bräuchte eine halbwegs passende osmosis-Pipeline und vermutlich ein SQL-Script zur Datenbank-Nachbearbeitung, um einen einfachen Graphen zu erzeugen - das Speziellere Erzeugen für bestimmte Anwendungen, die Bildung von Contraction-Hierarchies oder sonstwas meine ich hier nicht. - Ich hätte gerne ein generalisiertes Eisenbahn-Netz (ja, das wäre genau das collapsing von parallelen Strecken - aber genau darum geht es mir ja: Wieso soll sowas von jedem Renderer extra unterstützt werden?) - Analog zur Generalisierung von Flächen (Häuser zu landuse=residential zusammenfassen und so weiter) Im Grunde gibt es zwei Ansätze, die man da fahren kann: Man kann weiter so taggen, dass die Renderer, die bereits existieren, damit ohne Änderungen umgehen können - und damit die Datenbank entsprechend begrenzen, oder man setzt eben bei den Renderern selbst oder zwischen Renderern und Datenbank an. Ich würde letzteres bevorzugen. Gruß Peter Am 27.05.2011 09:19, schrieb Markus: Ich möchte gern mal über quo vadis sprechen... Einerseits lässt unsere Datenbank beliebige Detailliertheit zu (Mikromapping, Einzelgeleise, Vorhausgärten, Parkplätze, Bäume, etc) Andererseits brauchen wir kartografisch sinnvolle Generalisierung, und routentechnische Berechnungseffizienz. Einerseits gibt es das Credo: wir arbeiten nicht für den Renderer, andererseits geschieht genau dies permanent, denn der Benutzer beurteilt Qualität anhand dessen was er sieht. Zunehmend werden komplexe (und auch nicht so komplexe) Zusammenhänge in Relationen abgebildet, die sowohl vom Benutzer als auch vom Renderer nur schwer zu handhaben sind. Fehler werden dadurch drastisch zunehmen. Zunehmend geht die Nutzung von Punkten und Flächen und Namen wirr durcheinander. Vor allem für neue Benutzer (es werden immer mehr :-) ) scheint es m.E dringend erforderlich, ihnen für sie nachvollziehbare Empfehlungen incl. erklärender Begründung an die Hand zu geben. Dabei müssen wir darauf achten, dass wir die Freiheit (die Intelligenz der Masse) bewahren - denn sie ist eine unserer grössten Ressourcen und Qualitäten. Ich könnte mir gut vorstellen, dass wir uns dazu mal treffen und gemeinsam Lösungen suchen: Daten-Spezialisten, Kartografen, Routing-Spezialisten, Generalisten... Wäre das nicht ein Thema für ein nächstes Treffen im Linux-Haus? Gruss, Markus ___ 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] Konzept für Daten, Karte und Renderer
Hallo, Am Freitag 27 Mai 2011 10:52:51 schrieb Peter Wendorff: Hallo Markus. Inwieweit das ein Thema für ein Treffen von ein paar Stunden oder Tagen sein kann, weiß ich nicht, denn das ist 'ne ganz schön große Kiste, die du da als Thema hinstellst. Nichtsdestotrotz sind die Fragen aber, denke ich, ziemlich richtig. Auf der einen Seite sollten die Daten sauber sein, auf der anderen Seite fordert das für Renderer immer komplexere Gebilde. Auf der einen Seite sollen die Daten handhabbar bleiben, auf der anderen Seite ist es schön, genau das Detail zu finden, das ich wirklich grade brauche. Ich denke, eigentlich fehlt trotz vieler Bemühungen immer noch ein Zwischenschritt in der Pipeline, die das OSM-Universum bildet: (a) Wir haben Mapper, (b) wir haben Daten, die wir Anwendern geben können, (d) es existieren Anwendungen wie Renderer/Karten, Router, Kunstanwendungen, Suchmaschinen und so weiter. c hab ich bewusst ausgelassen - da fehlt irgendwie noch was: Eine gut zu verwendende Verarbeitungsschicht, die man Anwendungsentwicklern an die Hand geben kann, ohne dass die erst monatelange Einarbeitungszeit brauchen. Osmosis gehört in diese Kategorie und ist zweifelsohne ein extrem nützliches Tool. Es gibt allerdings auch für osmosis diverse Anwendungen, die immer wieder vorkommen und nützlich wären: - Wie generiere ich aus einem planet oder Gebietsextrakt einen Routinggraphen? Ich bräuchte eine halbwegs passende osmosis-Pipeline und vermutlich ein SQL-Script zur Datenbank-Nachbearbeitung, um einen einfachen Graphen zu erzeugen - das Speziellere Erzeugen für bestimmte Anwendungen, die Bildung von Contraction-Hierarchies oder sonstwas meine ich hier nicht. - Ich hätte gerne ein generalisiertes Eisenbahn-Netz (ja, das wäre genau das collapsing von parallelen Strecken - aber genau darum geht es mir ja: Wieso soll sowas von jedem Renderer extra unterstützt werden?) - Analog zur Generalisierung von Flächen (Häuser zu landuse=residential zusammenfassen und so weiter) Im Grunde gibt es zwei Ansätze, die man da fahren kann: Man kann weiter so taggen, dass die Renderer, die bereits existieren, damit ohne Änderungen umgehen können - und damit die Datenbank entsprechend begrenzen, oder man setzt eben bei den Renderern selbst oder zwischen Renderern und Datenbank an. Ich würde letzteres bevorzugen. ich glaube nicht, dass es möglich ist, ein Tool zu schreiben, dass den ständig in Bewegung befindlichen OSM-Way-of-tagging bändigen, verwalten oder aktuell auswerten kann. Dafür sind wir zu dynamisch, und das ist letzen Endes auch gut so, auch wenn einem die eine oder andere Tendenz gegen den Strich geht. Ein solches Tool würde zwangsläufig immer hinterher hinken und niemanden so richtig glücklich machen. Auch die heutigen Tools wie osmosis, osm2postgresql etc. haben (subjektive) Schwachstellen, die dem einen oder anderen Wünche übrig lassen. Für den Standardfall (mal eben) sind sie Klasse, und manche Funktionen geradezu unverzichtbar, aber manchmal muss man eben selbst zur 132-Tasten-Maus greifen. Was wir aus meiner Sicht brauchen, ist endlich eine benutzbare X-Api, mit der es möglich ist, im Vorfeld zu filtern, was man aus der DB braucht. Für eine weltweite Karte aller Eisenbahnverbindungen muss man zur Zeit das Planetfile laden, obwohl man nicht mal 1% davon braucht. Mehrgleisige Strecken mit einer Relation zusammen zu fassen sollte nicht das Problem darstellen. Wer eine Anwendung auf freie Inhalte aufsetzen will, muss neben vielen Vorteilen wie Aktualität und Kostenlosigkeit eben auch ein paar Nachteile wie Nachverarbeitung in Kauf nehmen. Wenn er das nicht will, soll er seine Daten kaufen - bei anderen Anbietern oder bei jemandem, der ihm unsere Daten aufbereitet. Hier ständig ein Protestgeheul für die eigene Anwendung zu starten, nervt auf Dauer etwas (womit ich nicht meinen Vorposter meine). Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Hallo Peter, 'ne ganz schön große Kiste Ich denke, vielleicht ist die Zeit reif für ein paar Gedanken wie wir da etwas mehr Ordnung reinkriegen. Klar geht das nicht in ein paar Tagen - aber ein Anfang wäre damit gemacht. Zwischenschritt in der Pipeline, die das OSM-Universum bildet: Ja, das klingt nach einem seehr guten Plan! Eine noch zu lösende Aufgabe wird es sein, den Prozess so offen zu gestalten, dass es jederzeit möglich bleibt, die Core-DB (bzw. deren Spiegel) auch am Standard-Prozess vorbei beliebig zu nutzen. Ein Standard-Prozess kann aber gefühlt 80..98% aller Aufgaben abdecken. Ich könnte mir das so vorstellen: Mapper E-Verarbeitungsschicht DB A-Verarbeitungsschicht Anwendung Die Daten des Mappers (1) werden von einem intelligenten Editor entgegengenommen und vorverarbeitet und in die Eingangs-Verarbeitungsschicht gespeichert (2). In der Eingangsverarbeitung werden die Daten der verschiedenen Editoren standardisiert aufbereitet und in die Core-DB geschrieben (3). Aus der DB werden in der Ausgangsverarbeitung verschiedene Schichten (standardisierte Views) generiert(4), auf die die Anwendungen zugreifen (5). Eine dieser Views ist ein Spiegel der Daten von 3. Auch die anderen Views kann man beliebig spiegeln, um schnellen Zugriff zu gewährleisten. In der Ein- und Ausgangsvearbeitung gibt es dann: Ansätze: - weiter so taggen, dass die Renderer, die bereits existieren, damit ohne Änderungen umgehen können und damit die Datenbank entsprechend begrenzen, - oder man setzt eben bei den Renderern selbst - oder zwischen Renderern und Datenbank an. Ich würde letzteres bevorzugen. Ich auch. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 27.05.2011 10:52, schrieb Peter Wendorff: c hab ich bewusst ausgelassen - da fehlt irgendwie noch was: Eine gut zu verwendende Verarbeitungsschicht, die man Anwendungsentwicklern an die Hand geben kann, ohne dass die erst monatelange Einarbeitungszeit brauchen. Osmosis gehört in diese Kategorie und ist zweifelsohne ein extrem nützliches Tool. Es gibt allerdings auch für osmosis diverse Anwendungen, die immer wieder vorkommen und nützlich wären: - Wie generiere ich aus einem planet oder Gebietsextrakt einen Routinggraphen? Ich bräuchte eine halbwegs passende osmosis-Pipeline und vermutlich ein SQL-Script zur Datenbank-Nachbearbeitung, um einen einfachen Graphen zu erzeugen - das Speziellere Erzeugen für bestimmte Anwendungen, die Bildung von Contraction-Hierarchies oder sonstwas meine ich hier nicht. - Ich hätte gerne ein generalisiertes Eisenbahn-Netz (ja, das wäre genau das collapsing von parallelen Strecken - aber genau darum geht es mir ja: Wieso soll sowas von jedem Renderer extra unterstützt werden?) - Analog zur Generalisierung von Flächen (Häuser zu landuse=residential zusammenfassen und so weiter) Im Grunde gibt es zwei Ansätze, die man da fahren kann: Man kann weiter so taggen, dass die Renderer, die bereits existieren, damit ohne Änderungen umgehen können - und damit die Datenbank entsprechend begrenzen, oder man setzt eben bei den Renderern selbst oder zwischen Renderern und Datenbank an. Eine Lösung könnte auch eine layerorientierte Ausrichtung sein: landuse-Layer (entspricht Flächennutzungsplan) Cover-Layer(beschreibt die vorgefundene Bodenbedeckung) Traffic-way-Layer(beschreibt nur die Verkehrsverbindungen ohne auf verkehrsrechtliche Details einzugehen) Routing-Layer (beschreibt fahrspurdetailiert die Verkehrswege) Building-Layer usw.. Wobei die Layer nicht in der Datenbank auftauchen sollten sondern in den Editoren durch entsprechende Filter erzeugt werden. Bestimmte nodes dürfen dabei nicht layerübergreifend verwendet werden. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 27.05.2011 11:47, schrieb Wolfgang: Hallo, [...] ich glaube nicht, dass es möglich ist, ein Tool zu schreiben, dass den ständig in Bewegung befindlichen OSM-Way-of-tagging bändigen, verwalten oder aktuell auswerten kann. Dafür sind wir zu dynamisch, und das ist letzen Endes auch gut so, auch wenn einem die eine oder andere Tendenz gegen den Strich geht. Ein solches Tool würde zwangsläufig immer hinterher hinken und niemanden so richtig glücklich machen. Dass das Tool eher zurückhinken würde, ist erstmal klar - aber das Problem haben wir momentan auch, verstärkt und verteilt über verschiedene Renderer. Wenn die Entwickler der Render-Engines nicht noch diesen Zwischenschritt aufwändig immer wieder anpassen müssten, könnten Kapazitäten für ein Gemeinsames Tool, das eben diese Aufbereitung vornehmen kann, frei werden. Klar - wenn dann doch jeder sein eigenes Süppchen kocht und Updates lieber lokal in Mapnik oder sonstwo einpflegt, ist nichts gewonnen. Auch die heutigen Tools wie osmosis, osm2postgresql etc. haben (subjektive) Schwachstellen, die dem einen oder anderen Wünche übrig lassen. Für den Standardfall (mal eben) sind sie Klasse, und manche Funktionen geradezu unverzichtbar, aber manchmal muss man eben selbst zur 132-Tasten-Maus greifen. Das ist richtig - aber gerade bei osmosis gibt es doch mittlerweile einige (wenige) Beispiele für Module, die angepasst auf bestimmte Vorgänge sind: Datenbank-schreiben in verschiedenen Formaten z.B. Was wir aus meiner Sicht brauchen, ist endlich eine benutzbare X-Api, mit der es möglich ist, im Vorfeld zu filtern, was man aus der DB braucht. Für eine weltweite Karte aller Eisenbahnverbindungen muss man zur Zeit das Planetfile laden, obwohl man nicht mal 1% davon braucht. Da stimm ich dir voll zu - und sicherlich ist auch (J)XAPI ein Puzzleteil auf dem Vorverarbeitungs-Layer. Mehrgleisige Strecken mit einer Relation zusammen zu fassen sollte nicht das Problem darstellen. Also wenn ich sehe, wie oft Buslinien zerreißen - ich befürchte, das wird bei Bahnstrecken auch nicht viel besser sein (abgesehen davon, dass sie bisher möglicherweise seltener angefasst werden). Das aber führt dazu, dass auch hier wieder Fehlertoleranz verlangt ist - wieder ein schwieriges Thema. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 27.05.2011 12:20, schrieb Markus: Hallo Peter, 'ne ganz schön große Kiste Ich denke, vielleicht ist die Zeit reif für ein paar Gedanken wie wir da etwas mehr Ordnung reinkriegen. Klar geht das nicht in ein paar Tagen - aber ein Anfang wäre damit gemacht. Zwischenschritt in der Pipeline, die das OSM-Universum bildet: Ja, das klingt nach einem seehr guten Plan! Eine noch zu lösende Aufgabe wird es sein, den Prozess so offen zu gestalten, dass es jederzeit möglich bleibt, die Core-DB (bzw. deren Spiegel) auch am Standard-Prozess vorbei beliebig zu nutzen. Ein Standard-Prozess kann aber gefühlt 80..98% aller Aufgaben abdecken. Ich könnte mir das so vorstellen: Mapper E-Verarbeitungsschicht DB A-Verarbeitungsschicht Anwendung Da hast du mich falsch verstanden! Ich bin für Mapper DB Verarbeitungsschicht Anwendung Je nach Kapazität auf den Servern kann man zusätzlich noch Mapper DB Verarbeitungsschicht aufbereiteteDB Anwendung einführen, um die Verwendbarkeit noch einfacher zu machen. Ich halte allerdings die Verwendung von Osmosis nicht für zu viel verlangt; nur reinkommen ist erstmal relativ schwierig. Die Daten des Mappers (1) werden von einem intelligenten Editor entgegengenommen und vorverarbeitet und in die Eingangs-Verarbeitungsschicht gespeichert (2). so intelligent kann die Schicht nicht sein, dass dadurch keine Informationen verloren gehen. Außerdem ist einiges in dem Bereich nicht sinnvollerweise bei jedem Upload durchzuführen. In der Eingangsverarbeitung werden die Daten der verschiedenen Editoren standardisiert aufbereitet und in die Core-DB geschrieben (3). Insofern würde ich diesen Schritt weglassen Aus der DB werden in der Ausgangsverarbeitung verschiedene Schichten (standardisierte Views) generiert(4), ...diesen allerdings hereinnehmen; wobei der eben auch auf Seite der Anwendung oder Anwendungsprogrammierung laufen kann - als Bibliothek oder Hilfsprogramm, das einfach nur aufgerufen werden muss. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 27.05.2011 13:47, schrieb Garry: Am 27.05.2011 10:52, schrieb Peter Wendorff: c hab ich bewusst ausgelassen - da fehlt irgendwie noch was: Eine gut zu verwendende Verarbeitungsschicht, die man Anwendungsentwicklern an die Hand geben kann, ohne dass die erst monatelange Einarbeitungszeit brauchen. Osmosis gehört in diese Kategorie und ist zweifelsohne ein extrem nützliches Tool. Es gibt allerdings auch für osmosis diverse Anwendungen, die immer wieder vorkommen und nützlich wären: - Wie generiere ich aus einem planet oder Gebietsextrakt einen Routinggraphen? Ich bräuchte eine halbwegs passende osmosis-Pipeline und vermutlich ein SQL-Script zur Datenbank-Nachbearbeitung, um einen einfachen Graphen zu erzeugen - das Speziellere Erzeugen für bestimmte Anwendungen, die Bildung von Contraction-Hierarchies oder sonstwas meine ich hier nicht. - Ich hätte gerne ein generalisiertes Eisenbahn-Netz (ja, das wäre genau das collapsing von parallelen Strecken - aber genau darum geht es mir ja: Wieso soll sowas von jedem Renderer extra unterstützt werden?) - Analog zur Generalisierung von Flächen (Häuser zu landuse=residential zusammenfassen und so weiter) Im Grunde gibt es zwei Ansätze, die man da fahren kann: Man kann weiter so taggen, dass die Renderer, die bereits existieren, damit ohne Änderungen umgehen können - und damit die Datenbank entsprechend begrenzen, oder man setzt eben bei den Renderern selbst oder zwischen Renderern und Datenbank an. Eine Lösung könnte auch eine layerorientierte Ausrichtung sein: landuse-Layer (entspricht Flächennutzungsplan) Cover-Layer(beschreibt die vorgefundene Bodenbedeckung) Traffic-way-Layer(beschreibt nur die Verkehrsverbindungen ohne auf verkehrsrechtliche Details einzugehen) Routing-Layer (beschreibt fahrspurdetailiert die Verkehrswege) Building-Layer usw.. Wobei die Layer nicht in der Datenbank auftauchen sollten sondern in den Editoren durch entsprechende Filter erzeugt werden. Bestimmte nodes dürfen dabei nicht layerübergreifend verwendet werden. Die Idee gabs schon mehrfach. Probleme dabei: 1) Wer definiert die Layer? Einerseits müssen die wegen der Evolution des Taggingschemas irgendwann geändert werden, andererseits müssen sie konstant bleiben, damit die Anwendungen nicht in die Falle tappen 2) Welche layer bietet man an? Routing-Layer: Mit oder ohne Fußwegen? was ist mit Rollstuhl-Routing-Eigenschaften? Adressgenau, oder nur die Fahrwege? Nodes nicht layerübergreifend verwendbar? Bei welchen Layern und warum? Ich befürchte, Gegenbeispiele gibt's da immer - es sei denn, man trennte die layer komplett voneinander, was dann aber schnell zu inkonsistenzen führt. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 27.05.2011 14:16, schrieb Peter Wendorff: Am 27.05.2011 13:47, schrieb Garry: Am 27.05.2011 10:52, schrieb Peter Wendorff: c hab ich bewusst ausgelassen - da fehlt irgendwie noch was: Eine gut zu verwendende Verarbeitungsschicht, die man Anwendungsentwicklern an die Hand geben kann, ohne dass die erst monatelange Einarbeitungszeit brauchen. Osmosis gehört in diese Kategorie und ist zweifelsohne ein extrem nützliches Tool. Es gibt allerdings auch für osmosis diverse Anwendungen, die immer wieder vorkommen und nützlich wären: - Wie generiere ich aus einem planet oder Gebietsextrakt einen Routinggraphen? Ich bräuchte eine halbwegs passende osmosis-Pipeline und vermutlich ein SQL-Script zur Datenbank-Nachbearbeitung, um einen einfachen Graphen zu erzeugen - das Speziellere Erzeugen für bestimmte Anwendungen, die Bildung von Contraction-Hierarchies oder sonstwas meine ich hier nicht. - Ich hätte gerne ein generalisiertes Eisenbahn-Netz (ja, das wäre genau das collapsing von parallelen Strecken - aber genau darum geht es mir ja: Wieso soll sowas von jedem Renderer extra unterstützt werden?) - Analog zur Generalisierung von Flächen (Häuser zu landuse=residential zusammenfassen und so weiter) Im Grunde gibt es zwei Ansätze, die man da fahren kann: Man kann weiter so taggen, dass die Renderer, die bereits existieren, damit ohne Änderungen umgehen können - und damit die Datenbank entsprechend begrenzen, oder man setzt eben bei den Renderern selbst oder zwischen Renderern und Datenbank an. Eine Lösung könnte auch eine layerorientierte Ausrichtung sein: landuse-Layer (entspricht Flächennutzungsplan) Cover-Layer(beschreibt die vorgefundene Bodenbedeckung) Traffic-way-Layer(beschreibt nur die Verkehrsverbindungen ohne auf verkehrsrechtliche Details einzugehen) Routing-Layer (beschreibt fahrspurdetailiert die Verkehrswege) Building-Layer usw.. Wobei die Layer nicht in der Datenbank auftauchen sollten sondern in den Editoren durch entsprechende Filter erzeugt werden. Bestimmte nodes dürfen dabei nicht layerübergreifend verwendet werden. Die Idee gabs schon mehrfach. Ich weiss.. Probleme dabei: 1) Wer definiert die Layer? Einerseits müssen die wegen der Evolution des Taggingschemas irgendwann geändert werden, andererseits müssen sie konstant bleiben, damit die Anwendungen nicht in die Falle tappen Eine Layerdarstellung in den Editoren ändert zunächst einmal nichts am Tagging-Schema. Mittelfristig soll aber bewirkt werden dass eine saubere Trennung zwischen Bodenbedeckung, landuse(Flächennutzungsplan?), Verkehrswege etc. einzug hält. 2) Welche layer bietet man an? Routing-Layer: Mit oder ohne Fußwegen? was ist mit Rollstuhl-Routing-Eigenschaften? Adressgenau, oder nur die Fahrwege? Im Routing-Layer sollte alles angezeigt werden was routing-relevant ist, gegebenfalls vom user einzelne Elemente ausblendbar die er gerade nicht benötigt, in dem Fall aber mit einer Verriegelung/Warnung wenn sich eine Änderung auf die ausgeblendeten Elemtente auswirken würde(So wie jetzt schon in Josm wenn man etwas ändern möchte was nicht vollständig geladen ist). Nodes nicht layerübergreifend verwendbar? Bei welchen Layern und warum? Ich befürchte, Gegenbeispiele gibt's da immer - es sei denn, man trennte die layer komplett voneinander, was dann aber schnell zu inkonsistenzen führt. Z.B. sollten Verkehrswege keine gemeinsamen nodes mit landuse / Bodenbedeckung haben. Meist stammen die Daten aus unterschiedlichen Quellen mit unterschiedlicher Genauigkeit. Bei gemeinsamen nodes würden eine Positionsänderungen im einen Layer (aus welchen Gründen auch immer) die Daten im anderen Layer beeinflussen und unter Umständen hochgenaue Daten verschlechtern. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 27.05.2011 09:19, schrieb Markus: Ich möchte gern mal über quo vadis sprechen... Ei, dann hätte das eben bei den Gleisen getippte besser hierher gepasst: Ctrl-C, Ctrl-V: Am 27.05.2011 17:13, schrieb Torsten Leistikow: Frederik Ramm schrieb am 26.05.2011 22:35: man muss das halt beim Rendern in den Griff kriegen. Solche Aussagen ohne konkrete Vorschlaege (oder auch nur Vorstellungen) ueber das Wie finde ich immer besonders hilfreich. Such mal im Wiki nach dem Stichwort Linienbündel Am 26.05.2011 22:35, schrieb Frederik Ramm: und es wirkte etwas seltsam, dass ein einzelner Way, der eine Trasse symbolisierte, sich an einem Bahnhof ploetzlich auffaecherte zu lauter Gleisen und dann hinter dem Bahnhof wieder zu einer Trasse zusammenlief - ziemlich unlogisch, aber ich habe immer angenommen, dass das halt ein voruebergehenden Zustand ist, bis irgendwann mal alle Gleise vollstaendig erfasst sind. Nicht unlogisch, sondenr normal. Das wird auch so gemacht auf Karten, auf denen die Zweigleisigkeit ggü. Eingleisigkeit durch 'nen Querstrich mehr dargestellt wird (bspw. TK50) oder auch nicht (Stadtplan KA 1:20.000). Auch da fächert sich ein Bahnhof durchaus auf in passenden Maßstäben. Aber nicht unbedingt zu voller Gleiszahl, sondern ca. der Hälfte. So war der K'her Hbf auch vorm gleistreuen Mapping. Im Gegensatz zu TK50 und K'her Stadtplan aber mit nach Osten korrekt raus geführten DREI Strecken. Die bei den amtlichen gezeigten Fusionen lassen Eisenbahnfans die Nackenhaare aufstellen ... ;-) Damals schon konnte man beobachten, dass das Auffaechern der Gleise auf den hohen Zoomstufen zwar gut war, auf mittleren Zoomstufen aber haessliche schwarze Flecken im Bahnhofsareal erzeugte. Bei Osmarender habe ich immerhin das Symbol ab einem bestimmten Maßstab gewechselt (wie auch bei Radwegen etc.) Aber vom Optimum ist das natürlich noch weit entfernt... Das ist eine Herausforderung, der man beim Rendern Herr werden kann und muss. Eventuell *kann* man dem Renderer irgendwie helfen, indem man eine Gruppe von Gleisen zu einer Bahntrassen-Relation zusammenfasst und dann neue Funktionalitaeten im Renderer einbaut, die in der Lage sind, solche gruppierten linienfoermigen Objekte geeignet zu vereinfachen. Man muss aber dabei auch den Fall abfangen, dass eine solche Relation fehlen koennte. Deswegen vielleicht eher ein Prozess, der versucht, automagisch das passende zusammenzuwürfeln und nur dort, wo was unpassendes rauskommt, Hinweise geben, was zusammengehört und was nicht ... Das Problem stellt sich ja auch beim Thema separat gemappte Rad- und Gehwege, Straße neben Fluss, aber auch bei Haus neben (mit dem Zoom wachsender) Straße, Sackgasse, die knapp vor Straße endet, ... Da wird man fuer das Standard-Rendering mindestens am osm2pgsql, wenn nicht sogar auch am Mapnik herumdrehen muessen. Das wird nicht leicht, aber danach haben wir eine Karte, die auf allen Zoomleveln besser aussieht als vorher. Ich fürchte, wir müssen langfristig Mapnik, Osmarender Co. ganz wegschmeißen, dann das sind alles keinerlei kartographische Programme, sondern einfachste Umetikettierer, die Null Möglichkeit zur Koordinatenveränderung haben (außer dass sie gelegentlich Kurven durch die Stützpunkte legen statt Geraden, auch nicht immer so doll... aber auch da bleiben die Stützpunktkoordinaten unverändert). Am deutlichsten wird es bei Osmarender, den's auch in einer (lahmen) XSLT-Variante gibt ... Problem ist auch das Ausgabeformat SVG, das in seinen Darstellungsmöglichkeiten limitiert ist, daran scheitert in Osmarender das Rendern einseitiger Radwege. Für alle genannten Probleme müssen aber Koordinaten gerechnet werden für - die Mittellinie (ob nun mit real existentem Objekt wie Tram, ähm, vorm gleistreuen Mapping, oder nur virtuell als Mitte zwischen zwei Fahrbahnen) - alle parallelen maßstabsabhängig (!) auf die Mitte abgestimmten Wege wie Gleise, Fahrbahnen, Radwege - alle Objekte wie Häuser, Bäume, POIs, Sackgassenenden, ... die ggfs. zur Seite geschoben werden müssen - ... Das ist vermutlich zu komplex, um es jedesmal zu machen, sprich: solche Geometrien muss man wohl zwischenspeichern und eine automatische Aktualisierung bei Veränderung der Basisgeometrien organisieren. Etc. Und man muss verstärkt gewisse Sachen wegwerfen und vereinfachen müssenin passenden Zooms wie jetzt schon einige Wegklassen peu a peu in Mapnik In der Zwischenzeit - solang eben die Renderer nicht gut genug sind - muessen wir Rueckschritte hinnehmen. Das ist an vielen anderen Fronten auch so (z.B. einzelne Haeuser, die man auf kleineren Zoomleveln eigentlich lieber als grosse bebaute Flaeche anzeigen will). Aber jetzt das Mapping-Rad zurueckdrehen, beim Mapping zu stagnieren, bloss weil der Renderer damit nicht Schritt halten kann, das waere kontraproduktiv. Erst wenn genug Leidensdruck durch massenhaft Details aufgebaut ist, wird sich jemand dran setzen, obige Liste abzuarbeiten ;-) Gruß Mueck
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 27.05.2011 14:07, schrieb Peter Wendorff: Am 27.05.2011 12:20, schrieb Markus: Ich könnte mir das so vorstellen: Mapper E-Verarbeitungsschicht DB ... Da hast du mich falsch verstanden! Ich bin für Mapper DB ... Die Daten des Mappers (1) werden von einem intelligenten Editor entgegengenommen und vorverarbeitet und in die Eingangs-Verarbeitungsschicht gespeichert (2). so intelligent kann die Schicht nicht sein, dass dadurch keine Informationen verloren gehen. Außerdem ist einiges in dem Bereich nicht sinnvollerweise bei jedem Upload durchzuführen. Ich wäre auch vorsichtig, allzu viel in die E-Schicht zu packen. Eins jedoch sollten Editoren -- oder wenn die es nicht machen -- die Eingangschicht der DB machen: Splits und Vereinigungen erkennen und eine saubere Historie auch für diese erzeugen. Das ist nicht nur DER Knackpunkt der Relizenzierung (ohne saubere Historie auch bei Splits und Vereinigungen ist die rechtlich angreifbar), sondern auch ganz generell lästig, wenn man die Entstehungsgeschichte eines Objekts verfolgen möchte, wann und von wem und warum bspw. Tag X drangehängt wurde an die Y-Straße ... Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 27.05.2011 09:19, schrieb Markus: Andererseits brauchen wir kartografisch sinnvolle Generalisierung, und routentechnische Berechnungseffizienz. Beides fängt m.E. mit einem gemeinsamen Schritt an: Zusammenfassen, was zusammen gehört, s.a. Ctrl-C+Ctrl-V-Mail ;-) Linienbündel etc.: Sowohl beim Rendern ( Radweg/Fahrbahn sollen sich nicht überdecken), als auch beim Generalisieren (Straße mit/ohne Radweg) als auch beim Routen (Rafahrer über Fahrbahn oder Radweg) braucht man die Zusammenhänge paralleler Strukturen. Einige Teilaufgaben brauchen paar mehr (Verdrängung Straße contra Fluss), die andere nicht brauchen (oder? Hmmm... nicht zu weit rechts fahren, sonst *platsch* ;-) ), aber der geometrische Ansatz ist derselbe. Das geht alles in Richtung GIS als Zwischenschicht. Oder sowas in der Art. Jedenfalls etwas, das Koordinaten nicht nur umbildet von geographisch/WGS84 in Karten-x/y, sondern richtig analysiert und verändert: Was ist parallel zueinander? Was stößt in einem Winkel darauf? Was endet kurz davor? Und all das darf sich nicht von unsauberem Mapping beeinflussen lassen wie unterschiedlich dichte und verteilte Stützpunkte bei parallelen Fahrbahnen, Unterbrechungen durch Brücken (die tw. versetzt zueinander sind, wenn was in spitzem Winkel gekreuzt wird etc. Oder beim parallelen Radweg fehlt die Brücke ...), ... Und muss dennoch erkennen, ob ein eine Weile paralleler Radweg doch irgendwo abschwenkt ... Und dann: Was gehört davon zusammen, was nicht? Was für Aufgabe A (Verdrängung), B (Rendern), C (Routen), D (...), ...? Und wie speichert man diese Zusammengehörigkeiten ab? Wie hält man die aktuell, wenn jemand die Basisgeonetrie ändert? Und wie steuert man die, wenn die Automagik falsch zusammenstöpselt? Oder nur manuell, aber was, wenn die fehlt? Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Heiko Jacobs schrieb am 27.05.2011 19:32: man muss das halt beim Rendern in den Griff kriegen. Such mal im Wiki nach dem Stichwort Linienbündel Auch das erfordert weitere Information, das kann ein Renderer einfach nicht von sich aus leisten. Die schlechten Erfahrungen mit den Multipolygonen lassen mich ausserdem daran zweifeln, dass solche Konstrukte das Richtige fuer die Masse der Gelegenheitsmapper ist. Was haltet ihr von folgendem Schema fuer Hilfstags aehnlich den Tags speziell fuer Osmarender, d.h. sie sollen nicht das Objekt selber beschreiben sondern eine Hilfestuetze zur Auswertung/Darstellung bieten. - detail_level=minor Ein Objekt, dass nur auf den groessten Zoomstufen angezeigt werden sollte. Auf groeberen Karten kann es bei Bedarf weggelassen werden, da es durch andere Objekte (mit detail_level=main oder detail_level=abstract) ausreichend repraesentiert wird. - detail_level=main Ein Objekt, dass auf allen Zoomstufen angezeigt werden sollte. - detail_level=abstract Ein Objekt, dass nur auf den kleinsten Zoomstufen angezeigt werden sollte. Auf genaueren Karten kann es bei Bedarf weggelassen werden, da es durch andere Objekte (mit detail_level=minor) ersetzt wird. Mit diesem Schema koennte man z.B. eine Strasse als main definieren und die separat erfassten Rad- und Fusswege als minor. Jeder Renderer koennte mit diesen Informationen dann ohne grossen Aufwand selbst entscheiden, ab welcher Zommstufe der Begleitweg dargestellt wird, und ab welchen Zoomstufen es sinnvoller ist, nur die eigentliche Strasse darzustellen. Ein Mapper haette mit diesem Schema die Moeglichkeit, Elemente, die ihm persoenlich unnoetig detailliert erscheinen, als untergeordnet zu markieren oder sogar durch abstraktere Elemente zu ersetzen, ohne dass er dafuer die eigentlichen Tags der Elemente in der Datenbank veraendern muesste. Es geht also keine Information verloren, und ein Mapper, der meint in seinem Revier etwas aufraeumen zu muessen, kollidiert nicht mit einem Detail-Mapper. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 27.05.2011 20:02, schrieb Heiko Jacobs: Und dann: Was gehört davon zusammen, was nicht? Was für Aufgabe A (Verdrängung), B (Rendern), ... wobei da ja noch stark der Maßstab reinspielt und die Zeichenregeln des Renderers. In z18 kann man noch fast alles unverändert zeichnen. Wann die Objekte zusammenstoßen und Variationen an den Koordinaten benötigen, ist beim renderer mit dicken Linien früher der Fall als bei dem mit den dünnen ... Das macht das mit dem zwischenspeichern von Hilfsgeometrien nicht einfacher ... Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Von einer solchen Abstufung halte ich nichts. Schließlich soll der Renderer (und der Programmierer dahinter) entschieden wann er was darstellt. Von daher ist es sinnvoller das Objekt besser zu beschreiben Im Falle vom Fußweg/Radweg/Straße bspw. könnte man kennzeichnen, dass der Radweg und der Fußweg zur Straße gehören und nicht einen eigenständigen Weg bilden. Dann kann der Renderer bspw. alle nicht eigenständigen Wege ausblenden. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Henning Scholland schrieb am 27.05.2011 20:28: Von einer solchen Abstufung halte ich nichts. Schließlich soll der Renderer (und der Programmierer dahinter) entschieden wann er was darstellt. Die Entscheidung liegt ja auch weiterhin bei dem Renderer. Er ist ja nicht gezwungen die Hilfstags auszuwerten, und wenn er es tut, dann kann er das ja auch fuer verschiedene Elemente unterschiedlich handhaben. Eine Karte fuer Radfahrer koennte so z.B. Radwege immer darstellen wollen, eine Karte fuer Autofahrer wuerde sich in diesem Falle anders entscheiden, und bei Gleisen wuerde es beiden reichen, nur eins von mehreren parallel darzustellen. Das Tag ist ja keine verbindliche Vorgabe fuer die Renderer, sondern es ist nur ein Hilfmittel, um den Auswerteprogrammen das Weglassen von Objekten zu erleichtern. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
