Re: [Talk-de] Kein Micromapping mit landuse
Moin, Wolfgang schrieb: Hallo, Am Donnerstag 26 Mai 2011 19:37:32 schrieb fly: Am 25.05.2011 19:52, schrieb Stephan Wolff: Andere sehen einen Sinn in der Aufteilung von Wohn- und Industriegebiet. Niemand hat etwas dagegen, dass du die Nutzungsart der Grundstücke beschreibst. Aber verwende dazu einen anderen Key als landuse. Der Key ist schon vergeben. +1 auf talk@ gabe es eine Diskussion über private (Vor-)Gärten. Das Ergenis war: landuse=residential als große Fläche erhalten und residential=garden bzw. garden=residential zu verwenden. Gleiches kann ich mir gut für andere landuses vorstellen oder doch gleich landcover verwenden. ...und ich hatte schon gehofft, dieser Blödsinn hätte ein Ende. Was ist Blödsinn daran, physikalischen Zustand (was sehe ich) und Nutzung zu unterscheiden? Dann werden alle Städte gleichmäßig grün, denn auch vor Büros und Fabriken gibt es Gärten. Das wars dann mit der Unterscheidung der Nutzungsarten. Wenn Du Dir Stephans und flys zitierte Bereiche bitte noch einmal durchliest, dann wird Du sehen, dass es dann allein Sache des Renderers wäre, welche Daten bzw. Darstellung (physikalisch oder Nutzung) er malen möchte. Du musst Dir dann halt den richtigen für deinen Zweck aussuchen. Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kein Micromapping mit landuse
Hallo, Am Freitag 27 Mai 2011 08:02:11 schrieb Georg Feddern: Moin, Wenn Du Dir Stephans und flys zitierte Bereiche bitte noch einmal durchliest, dann wird Du sehen, dass es dann allein Sache des Renderers wäre, welche Daten bzw. Darstellung (physikalisch oder Nutzung) er malen möchte. Du musst Dir dann halt den richtigen für deinen Zweck aussuchen. Dann kann ich nur hoffen, dass die Gärten auch wirlich einzeln erfasst werden, so wie man sie sieht. Hier hat die Unsitte um sich gegriffen, ganze Straßenzüge zu Gärten umzudefinieren. Gartengebiet mit Häusern. Das gilt dann unabhängig von der Nutzung, und damit praktisch flächendeckend. Welcher Industriebetrieb, der auf sich hält, hat nicht ein paar Bäume vor der Tür und auf dem Hof. Der Informationswert sinkt damit auf den Nullpunkt. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Konzept für Daten, Karte und Renderer
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
Re: [Talk-de] amazon.de-affiliate für OSM?
moin moin, bedeutet das wirklich, dass alles, was von amazon über diesen link eingekauft wird, 5% für osm bringt? das würde bei einigen 1000 aktiven os-nutzern in deutschland doch wohl mehr bringen als die läppischen 25 pfund/quartal in uk, oder? nur müsste man das etwas mehr publik machen. link auf openstreetmap.de? sticky im forum? ich bin auf jeden fall dabei. Gruss Walter - 33,33% aller Statistiken beruhen auf kleinen Datenmengen. -- View this message in context: http://gis.638310.n2.nabble.com/amazon-de-affiliate-fur-OSM-tp6391845p6410083.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amazon.de-affiliate für OSM?
Am 27.05.2011 09:55, schrieb Walter Nordmann: nur müsste man das etwas mehr publik machen. link auf openstreetmap.de? sticky im forum? Am besten auch in die nächsten Wochennotiz Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Wochennotiz Nr. 44
hi marc wäre das was für die nächste auflage? http://gis.638310.n2.nabble.com/amazon-de-affiliate-fur-OSM-tp6391845p6391845.html gruss Walter p.s. es mach immer wieder spass, über den Tellerrand zu blicken, danke - 33,33% aller Statistiken beruhen auf kleinen Datenmengen. -- View this message in context: http://gis.638310.n2.nabble.com/OSM-Wochennotiz-Nr-44-tp6391174p6410215.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnstrecke vs. Gleis
On Wed 2011-05-25 (20:35), Stephan Wolff wrote: Erfassung der Einzelgleise soweit möglich. Erstellen einer Relation für jede zweigleisige Strecke, bei der ein Gleis (z.B. das nördlichere) role=master und das Gegengleis und die Querverbindungen role=slave erhalten. Es gibt Autobahnen, deren Richtungsfahrbahnen deutlich abweichende Verläufe haben. In der Nähe des Altmühltals habe ich so etwas mal gesehen. Für Bahngleise kann gleiches zutreffen (z.B. die S-Bahn-Gleise, die um Bahnbetriebswerke herum geführt werden, Berlin-Grunewald und evtl. -Wannsee). In solchen Fällen kann eine Relation, die auf eine Linie reduziert wird, Verwirrung stiften, wenn andere (von der Linie überlagerte) Details nicht ausgeblendet werden. Anwendungen/Karten, die ein Einzelgleise auswerten, blieben unverändert. Anwendungen/Karten, die Streckendaten nutzen wollen, müssen die Relation auswerten. Linien mit role=master würden als zweigleisige Strecke dargestellt, Linien mit role=slave ignoriert. Der geringe Lagefehler gegenüber der Mittellinie (ca. 3m) wäre oft unerheblich. Das können gut und gern mal mehrere 10 Meter sein. Anfänger-Frage: warum müssen die Gleise unterschiedliche roles haben? Bei public_transport/stop_area geht es anscheinend auch ohne... Gruß, Steffen ___ 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] amazon.de-affiliate für OSM?
Hallo, On 05/27/11 10:04, Henning Scholland wrote: nur müsste man das etwas mehr publik machen. link auf openstreetmap.de? sticky im forum? Am besten auch in die nächsten Wochennotiz Mal langsam mit den jungen Pferden. Amazon ist einer von sehr sehr vielen Online-Einkaufslaeden, und es gibt durchaus Gruende, *nicht* bei Amazon zu kaufen. (Ich will niemand meine Ideologie aufschwatzen, aber ich persoenlich bemuehe mich seit der Wikileaks-Affaere aktiv darum, bei alternativen Anbietern einzukaufen, selbst wenn Amazon oft komfortabler ist.) Ich finde, dass wir fuer ein paar Prozent Provision nicht unbedacht Werbung fuer Amazon auf OpenStreetMap machen sollten (und sowohl sticky im Forum als auch Wochennotiz bedeuten ein prominentes Placement auf einer openstreetmap.org/openstreetmap.de-Domain). Wenn ueberhaupt, dann wuerde ich eine Seite im Wiki anlegen: Unternehmen, die OpenStreetMap eine Provision zahlen, wenn man bei ihnen einkauft, und auf diese Seite verlinken. Eine herausgestellte Nennung von Amazon (Hey, Leute, kauft doch alle bei Amazon, das bringt noch 5% fuer OSM) faende ich nicht in Ordnung. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amazon.de-affiliate für OSM?
Hallo Frederik, (Ich will niemand meine Ideologie aufschwatzen, aber ich persoenlich bemuehe mich seit der Wikileaks-Affaere aktiv darum, bei alternativen Anbietern einzukaufen, selbst wenn Amazon oft komfortabler ist.) Danke! Ich eigentlich auch - scheitere aber manchmal am inneren Schweinehund und kaufe die Brötchen statt beim Bäcker bequemlichkeitshalber beim Supermarkt :-( Gruss, Markus PS: manchmal nutze ich auch G-Maps, weil deren Performanz immer noch besser ist als unsere ___ 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] amazon.de-affiliate für OSM?
Hallo, Am Freitag 27 Mai 2011 11:03:01 schrieb Frederik Ramm: Hallo, On 05/27/11 10:04, Henning Scholland wrote: nur müsste man das etwas mehr publik machen. link auf openstreetmap.de? sticky im forum? Am besten auch in die nächsten Wochennotiz Mal langsam mit den jungen Pferden. Amazon ist einer von sehr sehr vielen Online-Einkaufslaeden, und es gibt durchaus Gruende, *nicht* bei Amazon zu kaufen. (Ich will niemand meine Ideologie aufschwatzen, aber ich persoenlich bemuehe mich seit der Wikileaks-Affaere aktiv darum, bei alternativen Anbietern einzukaufen, selbst wenn Amazon oft komfortabler ist.) Ich finde, dass wir fuer ein paar Prozent Provision nicht unbedacht Werbung fuer Amazon auf OpenStreetMap machen sollten (und sowohl sticky im Forum als auch Wochennotiz bedeuten ein prominentes Placement auf einer openstreetmap.org/openstreetmap.de-Domain). Wenn ueberhaupt, dann wuerde ich eine Seite im Wiki anlegen: Unternehmen, die OpenStreetMap eine Provision zahlen, wenn man bei ihnen einkauft, und auf diese Seite verlinken. Eine herausgestellte Nennung von Amazon (Hey, Leute, kauft doch alle bei Amazon, das bringt noch 5% fuer OSM) faende ich nicht in Ordnung. +1 Hat schon mal jemand bei alternativen Anbietern gefragt (Thalia fällt mir so auf Anhieb ein)? 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] amazon.de-affiliate für OSM?
Mit der Information, dass dies nun möglich ist, zwingt man aber keinen bei Amazon einzukaufen. Die, die aber ohnehin über Amazon Dinge beziehen, würden sich über die Info freuen. Genau dafür ist u.a. die Wochennotiz da. Die Info zurückzuhalten, nur weil man Amazon kritisch gegenüber steht grenzt schon ein wenig an Zensur. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnstrecke vs. Gleis
Am 27.05.2011 10:51, schrieb Steffen Grunewald: Es gibt Autobahnen, deren Richtungsfahrbahnen deutlich abweichende Verläufe haben. In der Nähe des Altmühltals habe ich so etwas mal gesehen. Bekanntestes Beispiel in D dürfe der Albaufstieg der A8 zwischen Stuttgart und Ulm sein, in bergigen Regionen kommt das öfter mal vor. Das können gut und gern mal mehrere 10 Meter sein. Anfänger-Frage: warum müssen die Gleise unterschiedliche roles haben? Bei public_transport/stop_area geht es anscheinend auch ohne... Man möchte damit wohl die Zugehörigkeit von Gleisen zu einer bestimmten Trasse kenntlich machen ohne ein zusätzliches Way-Element für die Trasse einsetzen zu müssen. Unglückliche Lösung die neue Fehlerquellen schafft da hier willkürlich entgegen der Realität ein Gleis als Master definiert wird. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amazon.de-affiliate für OSM?
Hallo Henning, Info zurückzuhalten grenzt schon ein wenig an Zensur. In einer gewissen Weise ja ;-) - aber: In der Werbung zählt die Wiederholfrequenz. Jede Namensnennung wirbt. Unabhängig ob Du den Namen noch attributierst (gut/schlecht). Deshalb sehen Firmen ihren Namen gern auf OSM, auf der Website und in der DB. Wenn wir nun einen Namen bevorzugen (dadurch dass wir ihn nennen, andere aber nicht), ist das eine politische Aktion. Bei politischen Aktionen sollten wir genau überlegen was wir wollen. Gruss, Markus Henning ___ 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] amazon.de-affiliate für OSM?
Hallo, On 05/27/11 12:26, Henning Scholland wrote: Mit der Information, dass dies nun möglich ist, zwingt man aber keinen bei Amazon einzukaufen. Die, die aber ohnehin über Amazon Dinge beziehen, würden sich über die Info freuen. Ich sag ja - Wikiseite mit allen Anbietern, die uns Provision zahlen, und gut is. Posting im Forum uebrigens gibts jetzt auch bei amazon.de Provision mit Link auf Webseite. Aber kein prominentes sticky-Posting, ausser wenn man bereit ist, auf Dauer *jeden*, der uns Provision gibt, an diesem Ort zu listen. Genau dafür ist u.a. die Wochennotiz da. Die Info zurückzuhalten, nur weil man Amazon kritisch gegenüber steht grenzt schon ein wenig an Zensur. Nein, Zensur waere, wenn eine staatliche Instanz der freien Presse vorschreibt, was sie zu sagen hat und was nicht. Wenn Amazon morgen Lollies verschenkt (was viele OSMer mit Kindern sicher interessiert) und die Wochennotiz als Pressemedium sich entschliesst, an dieser Werbeaktion nicht teilzunehmen, dann ist das keine Zensur, es grenzt auch nicht an Zensur, nicht mal schon ein wenig - es ist eine ganz normale redaktionelle Entscheidung. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggen von Einrichtungen im Bau
Am 25.05.2011 17:19, schrieb Torsten Leistikow: Garry schrieb am 25.05.2011 11:19: Gehst Du blindlings zu einem fremden *) Museum, Restaurant etc. ohne Dich zuvor über die aktuellen Öffnungszeiten zu informieren nur weil Du eine Adresse davon hast? *) bei nennenswerter Anreise zu einer bewusst gewählten Einrichtungen Ja, manchmal: Letzten Samstag stand ich nach fast 2h Anfahrt vor dem leider wegen Renovierung geschlossenem Dom in Hildesheim. Das aber nur am Rande. Dann halten wir mal fest: Eine Renovierung taucht nicht unbdingt als construction in OSM auf und kann (muss aber nicht) bedeuten dass eine Einrichtung nicht zugänglich ist. Umgekehrt construction kann bedeuten dass es für die vorgesehene Nutzung für eine bestimmte Zeit nicht nutzbar ist, muss aber nicht... (Beispiel Hochhaus an dem oben noch gebaut wird während unten schon die ersten Läden geöffnet haben). Viel entscheidender ist ja, dass ein solches Taggingschema ja universell fuer alle Einrichtungen gelten soll. Und wenn ich im Notfall zum naechsten Krankenhaus will, dann moechte ich bestimmt nicht vor Ort feststellen, dass meine Karte/mein Router leider ein kleines constrution=yes/ruins=yes oder vergleichbar sinnwiderlegendes uebersehen/nicht gekannt hat. Du lebst realitätsfremd wenn Du Dich in solchen wichtigen Angelegenheiten auf ein so unzuverlässiges Medium verlässt. Egal wie gut das Taggingschema ist - Du hast keinerlei Garantie das die Daten zum Zeitpunkt Deiner Nutzung aktuell sind. Und nur weil z.B. das ursprüngliche Gebäude gerade durch einen Neubau ersetzt wird heisst das ja nicht automatisch dass in unmittelbarer Nähe kein Ersatz zur Verfügung steht. Jetzt möchte ich das Navi sehen dass Dich über solche Umstände hinreichend aufklärt... Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggen von Einrichtungen im Bau
Am 25.05.2011 17:19, schrieb Claudius: Am 25.05.2011 11:12, Garry: Am 24.05.2011 16:23, schrieb malenki:: start_date=$(Datum der voraussichtlichen Fertigstellung) http://wiki.openstreetmap.org/wiki/Key:start_date Das bezieht sich ja dann wohl eher auf den Anfang der Bauarbeiten Bitte klicke auf den Link und lies dort die erste Zeile. Super - schreibe start und meine Ende... Wieder so ein vermeintlich eindeutiger Key dessen Bedeutung in der Beschreibung umgedreht wird.. :-( Gemeint ist der Beginn der Nutzung bspw. als amenity=museum und nicht der Baubeginn. Insofern finde ich es eindeutig. Gemeint - ich finde es keineswegs eindeutig wenn ich unter construction ein start_date finde und die Fertigstellung gemeint ist. Zumal auch noch mal ein Unterschied zwischen Fertigstellung eines Bauwerks und dessen Nutzungsbeginn gibt. Es gibt Brücken die seit mindestens 25 Jahren fertig sind aber noch nie benutzt wurden... Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kein Micromapping mit landuse
Am 25.05.2011 19:52, schrieb Stephan Wolff: Offizielle Gebietsnamen (Industriegebiet Süd, Waldsiedlung) und ihre Grenzen sind Informationen die für die OSM-Datenbank wichtig sind. Diese Informationen kann man NICHT aus den Einzelflächen ableiten. Innerhalb/am Rande eines Industriegebietes kann es grössere Flächen geben die noch landwirtschaftlich genutzt werden bevor sich ein Industriebetrieb ansiedelt. - das Gesamtgebiet hat einen gemeinsamen Namen, aber unterschiedliche Nutzungsarten. Beides sollte aus den OSM-Daten ersichtlich sein... 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 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] amazon.de-affiliate für OSM?
Am 27.05.2011 13:01, schrieb Frederik Ramm: Hallo, On 05/27/11 12:26, Henning Scholland wrote: Mit der Information, dass dies nun möglich ist, zwingt man aber keinen bei Amazon einzukaufen. Die, die aber ohnehin über Amazon Dinge beziehen, würden sich über die Info freuen. Ich sag ja - Wikiseite mit allen Anbietern, die uns Provision zahlen, und gut is. Posting im Forum uebrigens gibts jetzt auch bei amazon.de Provision mit Link auf Webseite. Aber kein prominentes sticky-Posting, ausser wenn man bereit ist, auf Dauer *jeden*, der uns Provision gibt, an diesem Ort zu listen. +1 Bitte nicht noch mehr Werbung. Gibt schon viel zu viel davon im Web ! cu 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 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] Bahnstrecke vs. Gleis
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. Aber jetzt das Mapping-Rad zurueckdrehen, beim Mapping zu stagnieren, bloss weil der Renderer damit nicht Schritt halten kann, das waere kontraproduktiv. Hier hat ja auch keiner verlangt, das Rad zurueck zu drehen. Letztendlich laeuft es aber darauf hinaus, dass wir frueher keine Unterscheidung fuer unterschiedliche Abstarktionsebenen brauchten, unsere Daten waren fuer sowas einfach noch nicht gut genug. Das mit den Daten hat sich inzwischen geaendert, leider ist aber mit der Datengenauigkeit nicht auch die Strukturtiefe mitgewachsen, so dass inzwischen manchmal die Daten um so schlechter nutzbar geworden sind je genauer sie sind. Wie man auch an den anderen z.Z. aktuellen Diskussionen liest, ist das Problem nicht auf die Bahnstrecken beschraenkt und verlangt wohl deshalb auch nach einer grundsaetzlicheren Loesung. Da es sowas bei OSM ja aber prinzipiell nicht gibt, wurschteln wir uns eben weiter mehr schlecht als recht durch. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amazon.de-affiliate für OSM?
Frederik Ramm wrote: Wenn ueberhaupt, dann wuerde ich eine Seite im Wiki anlegen: Unternehmen, die OpenStreetMap eine Provision zahlen, wenn man bei ihnen einkauft, und auf diese Seite verlinken. OK, ein Logo auf der Webseite oder ein Sticky ist doch etwas zuviel des Guten - daher diskussiert man das ja hier, abgesehen davon, dass man das selber ja garnicht einrichten kann. Aber diese ewigen Hinweise der Art: Ich würde da lieber das und das in's Wiki schreiben kann ich nicht mehr lesen. Das kann/sollte der Vorschlagende bitte gefälligst selber machen, wenn er dies als vernünftige Alternative vorschlägt. Ich selber habe heute 5 Stunden lang aktiv gewikit und damit reicht es mir für heute. Gruss Walter - Wenn du den Wald vor lauter Bäumen nicht siehst, fälle die Bäume und du wirst sehen, dass da kein Wald ist. -- View this message in context: http://gis.638310.n2.nabble.com/amazon-de-affiliate-fur-OSM-tp6391845p6411544.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amazon.de-affiliate für OSM?
Nachtrag: die einzige Werbung, die ich auf openstreetmap.de erkennen kann, ist für Strato als Sponsor einiger OSM-Server und ein Buch über openstretmap. Autor: ja wer wohl. - Wenn du den Wald vor lauter Bäumen nicht siehst, fälle die Bäume und du wirst sehen, dass da kein Wald ist. -- View this message in context: http://gis.638310.n2.nabble.com/amazon-de-affiliate-fur-OSM-tp6391845p6411562.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amazon.de-affiliate für OSM?
Hi, Walter Nordmann schrieb: Nachtrag: die einzige Werbung, die ich auf openstreetmap.de erkennen kann, ist für Strato als Sponsor einiger OSM-Server und ein Buch über openstretmap. Autor: ja wer wohl. OMG, auf http://www.openstreetmap.info/ geht es nur um das Buch !!! Also ob das alles mit rechten Dingen zu geht ;) viele gruesse pascal ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amazon.de-affiliate für OSM?
openstreetmap.info ist auch eindeutig nicht die Seite der deutschen OSM-Community ;) Henning Am 27.05.2011 17:57, schrieb Pascal Neis: Hi, Walter Nordmann schrieb: Nachtrag: die einzige Werbung, die ich auf openstreetmap.de erkennen kann, ist für Strato als Sponsor einiger OSM-Server und ein Buch über openstretmap. Autor: ja wer wohl. OMG, auf http://www.openstreetmap.info/ geht es nur um das Buch !!! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amazon.de-affiliate für OSM?
Wenn die Redaktion der Wochennotiz entscheidet, dass das nicht wichtig genug ist, soll sie es halt nicht bringen. Aber der Redaktion zu sagen, dass das da nicht hin soll, weil Amazon böse ist finde ich nicht richtig. Übrigens wurde auch die flattr-Button in der Wochennotiz erwähnt und erklärt. Des weiteren findet sich dort auch ein Twitter-Button. Wenn schon keine Werbung mit Gegenleistung, dann bitte generell keine Werbung. Henning Am 27.05.2011 13:01, schrieb Frederik Ramm: Genau dafür ist u.a. die Wochennotiz da. Die Info zurückzuhalten, nur weil man Amazon kritisch gegenüber steht grenzt schon ein wenig an Zensur. Nein, Zensur waere, wenn eine staatliche Instanz der freien Presse vorschreibt, was sie zu sagen hat und was nicht. Wenn Amazon morgen Lollies verschenkt (was viele OSMer mit Kindern sicher interessiert) und die Wochennotiz als Pressemedium sich entschliesst, an dieser Werbeaktion nicht teilzunehmen, dann ist das keine Zensur, es grenzt auch nicht an Zensur, nicht mal schon ein wenig - es ist eine ganz normale redaktionelle Entscheidung. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Renderer-Zukunft, was: Re: Bahnstrecke vs. Gleis
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üssen in 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 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnstrecke vs. Gleis
Am 27.05.2011 12:26, schrieb Garry: Am 27.05.2011 10:51, schrieb Steffen Grunewald: Es gibt Autobahnen, deren Richtungsfahrbahnen deutlich abweichende Verläufe haben. In der Nähe des Altmühltals habe ich so etwas mal gesehen. Bekanntestes Beispiel in D dürfe der Albaufstieg der A8 zwischen Stuttgart und Ulm sein, in bergigen Regionen kommt das öfter mal vor. Da isses platt wie 'ne Flunder: http://www.openstreetmap.org/?lat=52.7583lon=9.6679zoom=14layers=M Kennt da jemand zufällig den Grund? Unglückliche Lösung die neue Fehlerquellen schafft da hier willkürlich entgegen der Realität ein Gleis als Master definiert wird. +1 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: 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] Bahnstrecke vs. Gleis
Am 25.05.2011 20:49, schrieb Torsten Leistikow: Stephan Wolff schrieb am 25.05.2011 20:35: Erstellen einer Relation für jede zweigleisige Strecke, bei der ein Gleis (z.B. das nördlichere) role=master und das Gegengleis und die Querverbindungen role=slave erhalten. Wesentlich einfacher und praktikabler waere es, wenn man nur die slave-Gleise (oder alternative nur die master-Gleise) mit einem extra Tag kennzeichnen wuerde, die Relation ist eigentlich ueberfluessig. Als reine Renderinformation könnte man auf die Relation verzichten. Ins Datenmodell von OSM passt es nicht, identische Gleise als physikalische Objekte einmal als master und einmal als slave zu bezeichnen. Die Strecke als Verwaltungsobjekt, das mehrere Gleise zusammenfasst, könnte eher die Zusatzinformation aufnehmen, welche der Mitglieder die Lage der Relation repräsentieren sollen. Viele Grüße, Stephan ___ 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] Bahnstrecke vs. Gleis
Stephan Wolff schrieb am 27.05.2011 19:51: Ins Datenmodell von OSM passt es nicht, identische Gleise als physikalische Objekte einmal als master und einmal als slave zu bezeichnen. Die Strecke als Verwaltungsobjekt, das mehrere Gleise zusammenfasst, könnte eher die Zusatzinformation aufnehmen, welche der Mitglieder die Lage der Relation repräsentieren sollen. Dem Datenmodell ist es vollkommen egal, ob die Information als Tag ans Objekt eingetragen wird, oder ob man dafuer eine Relation darueber baut und die Information dann als Rolle der Mitglieder erfasst. Der Informationsgehalt diesbezueglich ist erstmal voellig identisch. Interessant wird die Relation erst, wenn man wissen will, wer genau der Master zu einem bestimmten Slave ist. Bei der von dir vorgeschlagenen, hierachischen Ordnung der eigentlich gleichrangigen Element ist das aber nicht notwendig, da der Master ja auch ohne die Informationen vom Slave funktionieren soll. Wenn man aber meint, dass man diese Information braucht, dann darf jede Relation nur einen einzigen Master haben. = Man braucht unheimlich viele Kleinstrelationen und das ganze System ist praktisch nicht mehr zu warten. 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
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
Re: [Talk-de] amazon.de-affiliate für OSM?
Walter Nordmann schrieb: bedeutet das wirklich, dass alles, was von amazon über diesen link eingekauft wird, 5% für osm bringt? Im Prinzip ja, aber es ist mehr drin: http://uakieree.notlong.com das würde bei einigen 1000 aktiven os-nutzern in deutschland doch wohl mehr bringen als die läppischen 25 pfund/quartal in uk, oder? Das könnte man vermuten. Aber lieber läppische 25£ als nix nur müsste man das etwas mehr publik machen. link auf openstreetmap.de? Das will ich die Tage versuchen, unter Spenden unterzubringen sticky im forum? Falls das nicht schon jemand erledigt, versuche ich das demnächst ebenfalls. Aber /bitte/ keine Mails an jeden Nutzer in .de! ich bin auf jeden fall dabei. Sehr schön :) Gruß malenki ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Evtl. Lösung für zu kleine Schrift bei nicht Lateinischem Alphabet
Hi In neuem Thread da es sonst vielleicht untergeht: In 'Arabische Schriftzeichen arg klein?' vom 16.5. tauchte auf das manche Schriftarten relativ zu unserem Alphabet und Ziffern zu klein sind. Ich dachte ich bastel mal was, klein, banaler Test, unoptimiert: Ein 'neuer' Font (aus dem bestehenden Khmer OS abgeleitet) http://666kb.com/i/btur2tqq8zu78vrft.png Mit absichtlich extremer Verkleinerung der Zeichen A-Za-z0-9. Das grau eingerahmte ist in OpenOffice 'händisch' verkleinert, also nur die Lateinischen auf 8pt statt 12pt. Man sieht das hier der angepasste Font bischen unscharf wird, in OO verkleinert sieht besser aus. Ich hab' da nicht mehr lange dran rumgemacht, ist nur Proof of concept, mal sehen ob es einer brauchen kann. Das ganze ist einfach: von 'sudo apt-get install fontforge' bis zum ersten Ergebnis 20 Minuten, kurz vorm Zubettgehen. Da man fontforge auch scripten kann, die auch eine eigene Mailingliste haben die vielleicht helfen, könnte man zum Rendern der entsprechenden Gebiete leicht mehrere angepasste Fonts erstellen. Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amazon.de-affiliate für OSM?
Frederik Ramm schrieb: On 05/27/11 10:04, Henning Scholland wrote: nur müsste man das etwas mehr publik machen. link auf openstreetmap.de? sticky im forum? Am besten auch in die nächsten Wochennotiz (Ich will niemand meine Ideologie aufschwatzen, aber ich persoenlich bemuehe mich seit der Wikileaks-Affaere aktiv darum, bei alternativen Anbietern einzukaufen, selbst wenn Amazon oft komfortabler ist.) Wenn man wirklich /alle/ Unternehmen meidet, die irgendwann mal Scheiße gebaut haben, kann man sich gleich auf einen Selbstversorgungsbauernhof zurückziehen. (Das ist keine Verteidigung von Amazon) Wer von euch hat infolge der Wikileaks-Ereignisse seine Visa- (und wer wars gleich noch)-Karte zerschnippelt? Wolfskin hat private Webseitenbetreiber wegen Pfotenabdrucken abgemahnt; von Müller (Sachsenmilch) darf man behaupten, dass sie Genmilch verkaufen; Schwalbe hatte auch ein paar Reseller abgemahnt; Schlecker (persönliche Erfahrung) hat absolut miesen Kundenservice bei Reklamationen (eiigentlich nichtexistent); $alle Discounter beuten ihr Personal aus, Jakob Elektronik ersetzt keine spontan durchgebrannten teuren Grafikkarten, Apple ist usw usf. Gibt es eine Liste, die man abonnieren kann? ;) Ich finde, dass wir fuer ein paar Prozent Provision nicht unbedacht Werbung fuer Amazon auf OpenStreetMap machen sollten (und sowohl sticky im Forum als auch Wochennotiz bedeuten ein prominentes Placement auf einer openstreetmap.org/openstreetmap.de-Domain). Totschweigen wäre aber auch nicht schön. Imo. Wenn ueberhaupt, dann wuerde ich eine Seite im Wiki anlegen: Unternehmen, die OpenStreetMap eine Provision zahlen, wenn man bei ihnen einkauft, und auf diese Seite verlinken. So ähnlich gibt es die schon: http://wiki.openstreetmap.org/wiki/Merchandise Eine herausgestellte Nennung von Amazon (Hey, Leute, kauft doch alle bei Amazon, das bringt noch 5% fuer OSM) faende ich nicht in Ordnung. Einen Hinweis: Wenn ihr bei Amazon kaufen wollt: über diesen Link bekommt OSM 5% Provision fände ich persönlich ok. Wer dort nicht kaufen will, tut es nicht. Möglicherweise ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Evtl. Lösung für zu kleine Schrift bei nicht Lateinischem Alphabet
Hi Im Moment sind das aber nur Konsonanten. Die Vokale werden um die Konsonanten herum geschrieben und machen momentan Probleme. Zudem gibt es für alle Konsonanten 2 Schreibweisen. Also so ähnlich wie bei uns die groß/klein Schreibung. Für solche Tests wären also richtige Wörter sinnvoll. lg, Bernhard On 2011-05-27 22:38, Peter wrote: Hi In neuem Thread da es sonst vielleicht untergeht: In 'Arabische Schriftzeichen arg klein?' vom 16.5. tauchte auf das manche Schriftarten relativ zu unserem Alphabet und Ziffern zu klein sind. Ich dachte ich bastel mal was, klein, banaler Test, unoptimiert: Ein 'neuer' Font (aus dem bestehenden Khmer OS abgeleitet) http://666kb.com/i/btur2tqq8zu78vrft.png Mit absichtlich extremer Verkleinerung der Zeichen A-Za-z0-9. Das grau eingerahmte ist in OpenOffice 'händisch' verkleinert, also nur die Lateinischen auf 8pt statt 12pt. Man sieht das hier der angepasste Font bischen unscharf wird, in OO verkleinert sieht besser aus. Ich hab' da nicht mehr lange dran rumgemacht, ist nur Proof of concept, mal sehen ob es einer brauchen kann. Das ganze ist einfach: von 'sudo apt-get install fontforge' bis zum ersten Ergebnis 20 Minuten, kurz vorm Zubettgehen. Da man fontforge auch scripten kann, die auch eine eigene Mailingliste haben die vielleicht helfen, könnte man zum Rendern der entsprechenden Gebiete leicht mehrere angepasste Fonts erstellen. Peter ___ 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] amazon.de-affiliate für OSM?
Frederik Ramm schrieb: ausser wenn man bereit ist, auf Dauer *jeden*, der uns Provision gibt, an diesem Ort zu listen. +1, es dürfte OSM durchaus nützen Wie es die Forenadmins sehen, kann ich aber nicht beurteilen. malenki ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Evtl. Lösung für zu kleine Schrift bei nicht Lateinischem Alphabet
n'Abend Am 27.05.2011 22:47, schrieb Bernhard Zwischenbrugger: Im Moment sind das aber nur Konsonanten. Die Vokale werden um die Konsonanten herum geschrieben und machen momentan Probleme. Zudem gibt es für alle Konsonanten 2 Schreibweisen. Also so ähnlich wie bei uns die groß/klein Schreibung. Für solche Tests wären also richtige Wörter sinnvoll. Für mich sind das nur hübsche Symbole:-) Von chinesischen würde ich vielleicht 3 erkennen, höchstens. Die scheinen auch zu klein, mehr macht blos so'n Quark in Fonts? Tests braucht man ansich nicht (LOL), wenn das mit dem 'Khmer OS' geht dann ist es ok, wird genauso gehen. Es ist derselbe Font, nur die von char(33)=='!' bis char(255) oder so verkleinert. Schick' halt einen Text hierher, ich mach Bild. Kann halt sein das durch das skalieren die a-z etc. zu dünn in den Strichen werden. Oder das es vom Konzept nicht hilft. Peter On 2011-05-27 22:38, Peter wrote: Hi In neuem Thread da es sonst vielleicht untergeht: In 'Arabische Schriftzeichen arg klein?' vom 16.5. tauchte auf das manche Schriftarten relativ zu unserem Alphabet und Ziffern zu klein sind. Ich dachte ich bastel mal was, klein, banaler Test, unoptimiert: Ein 'neuer' Font (aus dem bestehenden Khmer OS abgeleitet) http://666kb.com/i/btur2tqq8zu78vrft.png Mit absichtlich extremer Verkleinerung der Zeichen A-Za-z0-9. Das grau eingerahmte ist in OpenOffice 'händisch' verkleinert, also nur die Lateinischen auf 8pt statt 12pt. Man sieht das hier der angepasste Font bischen unscharf wird, in OO verkleinert sieht besser aus. [...] Tofu schmeckt pappig ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Evtl. Lösung für zu kleine Schrift bei nicht Lateinischem Alphabet
Hi² Am 27.05.2011 22:47, schrieb Bernhard Zwischenbrugger: Im Moment sind das aber nur Konsonanten. Die Vokale werden um die Konsonanten herum geschrieben und machen momentan Probleme. Zudem gibt es für alle Konsonanten 2 Schreibweisen. Also so ähnlich wie bei uns die groß/klein Schreibung. Für solche Tests wären also richtige Wörter sinnvoll. Ich verstehe nun besser. Das Rendering in osm scheint mehr als mies. Bsp: http://www.openstreetmap.org/browse/node/256842008 Im Browser ist der Name schön in der Karte Örks. Hier als Bild falls der Browser des Betrachters es auch nicht packt: http://666kb.com/i/btusu95vydzcmf5pl.png Selbst der kde desktop zeigt den Text besser an (Name taucht in title der osm -html seite auf: also auch in der Fensterleiste) Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amazon.de-affiliate für OSM?
Hi, On Fri, 27 May 2011 17:57:53 +0200 Pascal Neis pascal.n...@gmail.com wrote: OMG, auf http://www.openstreetmap.info/ geht es nur um das Buch !!! Da ist sogar ein amazon-Bestell-Link. Pfui! Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amazon.de-affiliate für OSM?
malenki wrote: So ähnlich gibt es die schon: http://wiki.openstreetmap.org/wiki/Merchandise Danke, dass du dich da so reinkniest ;) genau auf diese Liste bin ich früher mal reingefallen und hab sie daher als uninteressant abgelegt. Das waren von einiger Zeit nur klassische Merchandizing-Produkte, also Sachen, die direkt was mit OSM zu tun hatten (Tasse u.ä.) Das es jetzt Firmen gibt, die das völlig ohne OSM-Bezug machen, war mir echt neu. Gruss Walter p.s. eigentlich ist mir nicht so klar, WARUM die das machen - aber ist mir relativ egal, solange die Kasse stimmt. - Wenn du den Wald vor lauter Bäumen nicht siehst, fälle die Bäume und du wirst sehen, dass da kein Wald ist. -- View this message in context: http://gis.638310.n2.nabble.com/amazon-de-affiliate-fur-OSM-tp6391845p6412677.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kundenparkplatz
Am 24.05.2011 18:15, schrieb Stephan Wolff: Am 24.05.2011 17:06, schrieb Peter: Am 23.05.2011 20:11, schrieb Stephan Wolff: Mir nicht. name=Kunden Rewe ist offensichtlich falsch. Seh' ich nicht das das falsch ist. das mit note/desc. mag ok sein, aber wenn man das nicht in der Karte sieht ist es fast nutzlos. [] OSM ist auch eine Karte, keine Datenhalde. Du hast das Grundprinzip von OSM nicht verstanden. OSM ist eine Datensammlung aus der (unter anderem) verschiedene Karten berechnet werden. Bei Bedarf werden die Regeln zur Kartendarstellung angepasst, nicht die Daten an die erwünschte Darstellung. Ich hab' das schon verstanden. Was 'ne Unterstellung. Nur ist es so wenn 'die hohen Herren' das Werkzeug nicht geeignet bauen (mal harsch daher gesagt:-) dann geht der gemeine Mapper halt hin und macht was daraus was ihm geeignet scheint. So sind die Leute nunmal. Ich habe mal die Parkplätze (nur way) einer Großstadt gesucht: 400 Stück, 20% haben Namen, über den Daumen gepeilt sind die hälfte(!) Kundenparkplätze, an den Namen erkennbar. access=customers haben 2(!) Ergo ist das ganze ein Dokumentationsproblem, oder am Editor (josm bietet weder in access noch in der Vorlage 'Parkplatz' was an) Ich werf' da keinem der tätigen was vor (nur den Meckerern), das sind einfach Kleinigkeiten die vorkommen. Nun warte man bis das Parkplatz proposal erledigt ist, das mit access oder wie auch immer man den Parkplatz an den Laden bindet, dann die Renderer angepasst sind (wird dann name='' oder der zugehörige Laden angezeigt? Besser beides.) Danach kannst du dann hingehen und die geschätzt 5000 name='Laden' löschen:-) Ich werde den einen Kundenparkplatz den ich erfasste dann höchst persönlich korrigieren. Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Arabische Schriftzeichen arg klein?
Am 24.05.2011 18:21, schrieb Claudius: Am 21.05.2011 00:31, Peter: Am 16.05.2011 23:37, schrieb Stephan Knauss: On 16.05.2011 22:13, Peter wrote:' ich nicht, Kann es sein das die arabische Schrift in Mapnik Karten etwas klein ist? ja, ist sie. Nicht nur die. Auch die ganzen asiatischen Schriften. Problem ist der Font. Größere Größe einstellen? Das Problem ist, dass der Font alle Schriftzeiche, also lateinische und andere enthält. Man kann nicht die Schriftgröße nur für Teile des Fonts einstellen. Kommt auf die Umgebung an:-) Ich würd'mir das zutrauen in Java zu können, naja mal dahergesagt, würde einfach den Text zerhacken und lateinisches kleiner rendern. Aber das ist evtl. zu einfach gedacht. Eine Lösung könnte sein den Font anzupassen, dazu gibt's einen neuen Thread. Besonders bei den asiatischen Schriften ist dann noch das Problem, dass die Ziffern eine deutlich andere Größe haben als die restliche Schrift. Wusst' ich nicht. Würde ich einfach mal ignorieren, zumindest hierzuland sind Ziffern selten in Namen. Leetspeak ist auch out. Kommt in Straßen- oder Gebietsnamen aber recht häufig vor. Siehe hier: http://osm.org/go/zY1jvR3U Ah. Wenn man nachdenkt kann das natürlich auch anderswo '5th Avenue' auftauchen. Da macht es nix, kommt aber vor. Ich suche für meine Iran-Karte auch schon seit längerem nach einem schöneren, freien Font. Es scheint aber keine freien, auf die Kartendarstellung optimierte, internationalisierte Fonts zu geben. Und als Programmierer kann man sowas schlecht nachrüsten. Och. Man kann oft schon, kommt auf die Energie an die man einsetzen kann. Geht nicht gibt's nicht kann allerdings eine menge Zeit verbrauchen:-( Die 90/10 Lösung kann erstmal reichen bis man vielleicht ein sowieso besseres Gesamtkonzept hat. Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amazon.de-affiliate für OSM?
Frederik Ramm schrieb: Pascal Neis pascal.n...@gmail.com wrote: OMG, auf http://www.openstreetmap.info/ geht es nur um das Buch !!! Da ist sogar ein amazon-Bestell-Link. Pfui! ...dem der affiliate-Tag fehlt *renn* ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amazon.de-affiliate für OSM?
Walter Nordmann schrieb: malenki wrote: So ähnlich gibt es die schon: http://wiki.openstreetmap.org/wiki/Merchandise Danke, dass du dich da so reinkniest ;) Auf der Seite habe ich nur den Zweizeiler für amazon.de ergänzt. Das Layout im Quelltext ist übrigens interessant. genau auf diese Liste bin ich früher mal reingefallen und hab sie daher als uninteressant abgelegt. Das waren von einiger Zeit nur klassische Merchandizing-Produkte, also Sachen, die direkt was mit OSM zu tun hatten (Tasse u.ä.) Man könnte das Cleanup-Team um Hilfe bitten, diese Seite übersichtlich zu sortieren... Das es jetzt Firmen gibt, die das völlig ohne OSM-Bezug machen, war mir echt neu. Wenn man es einrichtet, geht das schon ;) Der britische Amazon-Link dürfte gegen fünf Jahre alt sein. gn8 malenki ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnstrecke vs. Gleis
Am 27.05.2011 19:28, schrieb Heiko Jacobs: Am 27.05.2011 12:26, schrieb Garry: Am 27.05.2011 10:51, schrieb Steffen Grunewald: Es gibt Autobahnen, deren Richtungsfahrbahnen deutlich abweichende Verläufe haben. In der Nähe des Altmühltals habe ich so etwas mal gesehen. Bekanntestes Beispiel in D dürfe der Albaufstieg der A8 zwischen Stuttgart und Ulm sein, in bergigen Regionen kommt das öfter mal vor. Da isses platt wie 'ne Flunder: http://www.openstreetmap.org/?lat=52.7583lon=9.6679zoom=14layers=M Kennt da jemand zufällig den Grund? Würde auf militärische Gründe tippen, entweder dass mit einer Bombe nicht so leicht beide Fahrbahnen zerstört werden können oder wegen der Tragfähigkeit des Untergrundes.. Vielleicht auch nur dass man später eine zusätzliche Fahrspur einbauen kann ohne mit Natur/Landschaftsschutzgebiten in Konflickt zu geraten. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Evtl. Lösung für zu kleine Schrift bei nicht Lateinischem Alphabet
Hallo Peter, On 27.05.2011 23:07, Peter wrote: Tests braucht man ansich nicht (LOL), wenn das mit dem 'Khmer OS' geht dann ist es ok, wird genauso gehen. Es ist derselbe Font, so einfach ist es leider nicht. liegt an der Art wie Mapnik mit den Zeichen umgeht. Es rendert jedes für sich allein stehend. Leider gehen dadurch all die Zeichen kaputt die Kontext brauchen. Und das passiert bei den Khmer Zeichen häufiger. Lässt sich ohne größeren Eingriff in Mapnik nicht korrigieren. Siehe auch den Link vom letzten Mal. Dort gab es die Diskussion bzw. auch den Link auf das trac von Mapnik. http://lists.berlios.de/pipermail/mapnik-devel/2010-September/001245.html http://trac.mapnik.org/wiki/InternationalText Font anpassen ist bei Fonts die unter GPL stehen zumindest kein Lizenzproblem. Besser dürfte es sein wenn solche Sachen leute machen die sich mit Fonts auskennen. Kerning, Hinting und was es da so alles gibt muss schon passen. Für die meisten Schriften hat das aber in der Regel schon jemand gemacht. Man muss den Font nur finden. Für meine thaimap hatte ich loma verwendet und die fontsize generell etwas erhöht. Damit hat die Karte den Muttersprachlertest bestanden. Hat jemand Details wie man pango in mapnik reinbekommt? Damit soll es gerüchteweise auch mit anderen Schriften funktionieren. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amazon.de-affiliate für OSM?
Am 27. Mai 2011 13:01 schrieb Frederik Ramm frede...@remote.org: Ich sag ja - Wikiseite mit allen Anbietern, die uns Provision zahlen, und gut is. Posting im Forum uebrigens gibts jetzt auch bei amazon.de Provision mit Link auf Webseite. Aber kein prominentes sticky-Posting, +1 Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
