Re: [Talk-de] landuse= layer=-2 ?
Florian Lohoff wrote: wie ist mit layern von landuse zu verfahren? Ich habe hier einen Dass landuse verdeckend gerendert wird, ist ein Bug der aktuellen Renderer. Und da wir nicht für die Renderer taggen, kommt an ein Landuse auch kein Layer-Tag dran. Oder wenn man es ein wenig pragmatischer sieht, taggt man landuse einfach grundsätzlich als layer=-5 :-) cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] ToDo Kenzeichnung (Karl Eichwalder)
Michael Jopen wrote: Ich fände es sinnvoll, das man an der Stelle ein Symbol setzen könnte, z. B. ein Fragezeichen als Bitmap, welches dann wie ein Parkplatzsymbol in den Karten auftaucht. Vielleicht kann sich auch mal jemand die Zeit nehmen und sowas im maplint Layer einbauen. (Mun muss ja bei der Gelegenheit nicht gleich das ganze maplint Zeug aktualisieren...) cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Dorf/Gemeindegrenzen darstellen?
TopSpotter wrote: wie kann ich erreichen, das man ein Gemeindegebiet tagt und diese Fläche sich dann farblich etwas vom Background abhebt? Ich habe das mal mit places=hamlet versucht, Was Du suchst ist landuse=residential/industrial/commercial... cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Nutzung von Luftbildern des Bayrischen L andesamts für Vermessung und Geoinformation in OpenStree tMap
Bernd Wurst wrote: Hallo. Am Dienstag, 10. Juni 2008 schrieb Henry Loenwind: Die verwendung von öffentlich zugänglichen luftbildern als quellen für das erstellen von karten ist keine urheberrechtverletzung. Das glaube ich nicht. Ist es trotzdem nicht. Was ist was nicht? nötigen Nutzungsrechte erworben zu haben, die erhobenen Geodaten unterliegen nicht dem Urheberrecht des Fotografen. Also wäre jeder IMO Nein. Die Daten werden ja seitens OpenStreetMap wieder veröffentlicht. Und eine Veröffentlichung ist auch eine Nutzung. Ob vom Original oder einer Kopie ist dabei egal. Da der Fotograf von Anfang an keine Rechte an den abgebildeten Sachen hat, und die Daten in OSM der abgebildeten Sache zuzuordnen sind und nicht dem Lichtbild... Deiner These nach könnte man einfach eine kleine GmbH gründen, die Daten von irgendwo kopiert und diese dann jemand anderem zur Verfügung stellt, der die Wenn Du es schaffst, Daten von irgendwo zu kopieren, hast Du eine Datenbank angezapft (sonst müsstest Du die Daten erst unter Hinzuziehung von Luftbildern erstellen). Und da greift dann das Datenbankrecht. Mal abgesehen davon, dass Du dann eine Karte kopiert hast und keine Luftbilder... Urteil. In diesem Bereich gibt es vermutlich deutlich mehr Abmahnungen als Urteile. Nicht wirklich. Die Nutzung fremder Luftbilder ist - im Gegensatz zur Nutzung fremder Karten - eine sehr neumodische Sache. Und die quasi [...] s ging mir hier nur drum, auszudrücken, dass in diesem Bereich weder Urteile noch Abmahnungen existeren, und wir in komplett neues Fass aufmachen. Deiner Aussage nach wäre es wirklich kein Problem für das Projekt wenn jemand anonym Google-Luftbilder abmalen würde. Nicht ganz. 2 Probleme: 1) Ein riesiger Image-Schaden 2) ggf. Haftung für Tätigkeiten von ehrenamtlichen Mitarbeitern... 3) Klageeinreichnung in USA oder UK oder ... cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Nutzung von Luftbildern des Bayrischen L andesamts für Vermessung und Geoinformation in OpenStree tMap
Bernd Wurst wrote: Ich rede davon, Satelliten- bzw Luftbilder abzurufen und darauf basierend Karten zu erstellen. Das was wir grade machen. Du sprachst von Kopieren, und wir _kopieren_ ja grade keine Luftbilder. Schade eigentlich, das würde die Rechtslage sehr eindeutig machen :-)) Es ist doch allgemeiner Konsens innerhalb des Projekts, dass man nur solche Luftbilder dafür verwenden darf, die explizit dafür freigegeben wurden. Genau, weil wir die Nutzugsrechte nicht haben. Nicht weil der Fotograf die Urheberrechte an der Form des Flusslaufs der Donau hat. Irgendwoher muss diese Auffassung doch kommen Klar: Better safe than sorry und irgendwie macht das doch auch Sinn. Sicher? Grade mal ein Beispiel: Wenn ich hergehe und mir von Dir die Mona Lisa beschreiben lasse, Du dafür auf einem kommerziellen Bild nachsiehst, wie sie eigentlich aussieht, und ich die Beschreibung dann in die Wikipedia stelle - haben wir dann die Rechte des Fotografen verletzt? Nein. Die des Künstlers? Nein, zu lange tot. (Sein Pech ;) Beispiel 2: Wenn ich hergehe und mir von Dir das Atomium beschreiben lasse, Du dafür auf einem kommerziellen Bild nachsiehst, wie sie eigentlich aussieht, und ich die Beschreibung dann in die Wikipedia stelle - haben wir dann die Rechte des Fotografen verletzt? Nein. Die des Künstlers? Ja. (Ausnahmen möglich) Beispiel 3: Wenn ich hergehe und mir von Dir ein kommerzielles Foto des Atomiums beschreiben lasse, so von wegen aus welchem Winkel, mit welcher Belichtung, welcher Ausschnitt, und ich die Beschreibung dann in die Wikipedia stelle - haben wir dann die Rechte des Fotografen verletzt? Ja! cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Nutzungsrecht von Geodaten
Michael Jopen wrote: doch, das darf man. wohl. Siehe http://de.wikipedia.org/wiki/Wikipedia:Bildrechte#Luftaufnahmen_und_Geb.C3.A4ude Das bringt leider gar nix, da dort nur steht, dass Luftaufnahmen nicht mehr von Vater Staat genemigt werden müssen. Unter Panoramafreiheit können sie aber auf keinen Fall fallen: ==ZITAT== Der Aufnahmestandpunkt muss zudem allgemein ohne Hilfsmittel zugänglich sein. Eine Leiter – auch wenn sie nicht dazu dienen sollte, über ein Hindernis hinwegzublicken – ist demnach genausowenig zulässig wie ein Hubschrauber. ==ZITAT ENDE== cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Nutzungsrecht von Geodaten
Christian Hartnick wrote: Wenn man allerdings jedes einzelne Haus als reines Beiwerk abtut, das zufällig mit auf dem Bild ist, aber nicht den abgebildeten Gegenstand darstellt... Was ist denn dann der abgebildete Gegenstand? Dir Erdoberfläche. Bei Google Earth ist das Gesamtbild ja so riesig, dass jedes einzelne Land nur ein winziges Beiwerk sein könnte. Anders ist es natürlich, wenn man eine Ausschnittsvergrößerung herstellt mit nur einem Haus, dieses neue Werk kann sich nicht rausreden... cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Nutzungsrecht von Geodaten
Stefan Neufeind wrote: meiner persönlichen Ansicht nach (kein juristischer Hintergrund) darf ein Haus was jeder von der Straße auch sehen kann auch jeder fotografieren und die Fotos weitergeben. Das Recht an der Nutzung der Jepp, solange Du beim Fotografieren auf der Straße stehst (keine leiter, kein Hubschrauber - um mal die Beispiele aus Wikipedia zu zitieren). Einen Schutz wie z.B. bei einem abfotografierten Gemälde (unmittelbare Reproduktion des Kunstwerks) kann ich bei einem Haus ehrlich gesagt nicht erkennen. Das Gesetz macht zwischen Häusern und Gemälden keinerlei Unterschied. cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Nutzungsrecht von Geodaten
Arne Bischoff wrote: Jaja, das Werk ist geschützt, spricht Du kannst jetzt nicht die Pläne nehmen und einfach identisch nachbauen. Das Bild davon ist doch aber nicht geschützt, sonst dürfte ja niemand nichts fotografieren, weil ja irgendwelche Rechte dran hängen! Neee, dem ist nicht so. Doch ist so. Lies mal http://de.wikipedia.org/wiki/Wikipedia:Bildrechte durch, danach weißt Du, wie wenige Sachen man eigentlich fotografieren darf. (bzw. bei wievielen Sachen das Foto hinterher ins Familienalbum muss und nicht für andere Sachen genutzt werden kann.) cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Nutzung von Luftbildern des Bayrischen
Johann H. Addicks wrote: Panoramafreiheit von öffentlichen Stadtplänen: An dieser Stelle stellt sich mir immer die Frage, wie die Touristeninformationstafeln an Ortseingängen lizenziert sind. Die dort häufig aushängenden Stadtpläne sind dauerhaft im öffentlichen Raum angebracht und fallen somit, zumindest als Fotografien unter die Panoramafreiheit. Die Panoramafreiheit hebelt dann zumindest künstlerische Schöpfungshöhe der Zeichnung und Bildgestaltung aus, nach meinem Verständnis jedoch nicht den Datenbankschutz auf das mit angeschlagene Straßenverzeichnis. Und wie sieht es mit den Datenbankrechten der Gemeinde aus, die die Straßenschilder aufgestellt hat? Nur mal so für alle zum Nachlesen...: § 87 a Begriffsbestimmungen (1) Datenbank im Sinne dieses Gesetzes ist eine Sammlung von Werken, Daten oder anderen unabhängigen Elementen, die systematisch oder methodisch angeordnet und einzeln mit Hilfe elektronischer Mittel oder auf andere Weise zugänglich sind und deren Beschaffung, Überprüfung oder Darstellung eine nach Art oder Umfang wesentliche Investition erfordert. Eine in ihrem Inhalt nach Art oder Umfang wesentlich geänderte Datenbank gilt als neue Datenbank, sofern die Änderung eine nach Art oder Umfang wesentliche Investition erfordert. (2) Datenbankhersteller im Sinne dieses Gesetzes ist derjenige, der die Investition im Sinne von Absatz 1 vorgenommen hat. § 87 b Rechte des Datenbankherstellers (1) Der Datenbankhersteller hat das ausschließliche Recht, die Datenbank insgesamt oder einen nach Art oder Umfang wesentlichen Teil der Datenbank zu vervielfältigen, zu verbreiten und öffentlich wiederzugeben. [...] cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] speed color-coded GPX tracks
Raphael Studer wrote: Ich will nicht nerven, aber weist du auch, wie das funktioniert und wo man eventuell die Farben veraendern kann? http://josm.openstreetmap.de/browser/trunk/src/org/openstreetmap/josm/gui/layer/GpxLayer.java#L333 Und bevor irgendjemand an der Stelle im Code rumschraubt, wäre es ganz nett, wenn mal jemand den Patch aus Ticket 720 einchecken könnte. Der macht das Track-Pinseln doch um einiges schneller... cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Parkplätze zu supermarkt ... Ban k ... etc.
musarati wrote: hmm naja eher access=private...? also so machs ich jedenfalls... private heißt, dass dort den Eigentümer vorher um Erlaubnis fragen muss. Das passt bei Supermarktparkplätzen eher nicht... cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] JOSM - Strecke markieren
m*sh wrote: -BEGIN PGP SIGNED MESSAGE-Hash: SHA1Andreas Pothe wrote: Christoph Eckert schrieb: man gewöhnt sich an allem, sogaar am Dativ :) . Wenn JOSM mal eingerichtet ist, kann man eigentlich ziemlich gut damit arbeiten. Nicht, wenn JOSM eingerichtet ist, sondern wenn man sich an die sehr spezielle Bedienweise gewöhnt hat. Denn die ist deutlich anders als in allen anderen Anwendungen, selbst die Bedienung von SAP erschließt sich einem schneller. Und das will was heißen.Aua.Kann mir jemand mal auf die Schnelle erklaeren, wie ich in JOSM eineStrecke markiere, so dass ich bei den Properties sehe, ob es sich umeinen Waldweg oder eine Autobahn handelt?Mit dem Select Tool kann ich ja immer nur einen WP auswaehlen, bzw einenrechteckigen Ausschnitt in dem dann meist auch andere WPs landen, dienicht zu der gwuenschten Strecke gehoeren.Es kann ja nicht sein, dass ich mir in JOSM die ID merke und dann imJOSM-File nach der ID suche um die tags zu diesem Weg herauszufi nden.Danke im Voraus und falls es da noch bessere Dokus oder passendereDiskussionsseiten geben sollte duerft ihr mir auch mit einem Linkantworten.Aufhttp://josm.openstreetmap.de/wurde ich nicht fuendig.BTW, gibt es eine schnelle Moeglichkeit, von einem markierten Wegpunktzur naechsten Kreuzung oder zum Ende des Weges oder zum benachbarten WPzu 'laufen'? Probier doch mal auf den Way zu klicken, irgendwo, wo kein Punkt im Weg ist... cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [EMAIL PROTECTED]
Frederik Ramm wrote: - Für jedes tile, das wir haben wollen: - Inkscape aufrufen mit SVG-Datei und gewünschtem Ausschnitt als Parameter Das stimmt nur fuer Zoomlevel 12. Fuer Zoomlevel n mit n12 wird Inksape 2(n-12) mal aufgerufen, und es werden einzelne Zeilen erzeugt, die dann danach mit Bitmap-Operationen zerschnitten werden. (Oder waren es Spalten...) Ja, es sind Zeilen. Dass wir nicht komplett so vorgehen, wie Du sagst, hatte einen Grund, den ich leider vergessen habe. Eventuell hat es mit der Mercator- Projektion zu tun, die ja in der Hoehe nicht konstant ist. Deelkar wird sich sicher noch erinnern ;-) Zum einen die Projektion, jepp. Zum anderen Zum anderen sind 8192x8192 Pixel große Dateien ziemlich unhandlich. Inkscape frisst so schon genug Speicher. Der dritte Punkt ist Optimierung; höhere Zoomstufen werden nur erzeugt, wenn das übergeordnete Tile nicht eh schon leer war. cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Genauigkeit der Luftbilder vom GeoDaten Bayern WMS Server?
Frank Wein wrote: genaue Prüfung der Bilder müsste man wohl mal seinen GPS Empfänger auf die Straße legen und einfach mal ein paar Minuten lang Daten sammeln und dann den Mittelwert mit den Bildern abgleichen... Wenn ich mir meine Tracks so ansehe, dann ist das genau die richtige Methode eine 50 Meter lange Spur zufälliger Daten zu erzeugen, die noch dazu nicht die reale Position als Mitte hat. Letztens auch wieder gehabt: GPS mit JOSM auf dem Notebook verbunden. Frisch eingeschaltet war die Position auf den Meter genau dort wo ich war (im Vergleich zu den vorhanden OSM-Daten, die nicht von mir sind), nach 15 Sekunden fing die Position an zu wandern, und war dann überall innerhalb eines 50m langen Kreissegments, nur ganz selten dort wo sie sein sollte. Losgelaufen und nach wenigen Schritten wieder super-genau. Ich weiß ja nicht wie das bei anderen Geräten ist... cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Landwirtschaftliche Flächen in Deutschla nd
Robert Heel wrote: irgendwie müssen die Tags doch zuerst definiert werden, wenn die in jeder Region anders heißen endet das doch im Chaos ... Was für ein Chaos? Für die Renderer ist es schnurzpiepegal, ob es jetzt 1 Tag für Felder oder 493 Tags für Felder gibt. Wenn jedoch gar kein benutzt wird... cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Interessenten für Mailingliste Kreis T übingen? Kreis Sigmaringen? Neckar-Alb-Kreis?
[EMAIL PROTECTED] wrote: gibt es hier interessenten für eine Mailingliste für den Landkreis Tübingen? Oder sogar für den Kreis Sigmaringen? Oder vielleicht zusammengefasst einen für Neckar-Alb-Kreis? Fang doch erstmal auf Bundeslandebene an, wenn die zu voll wird, kann man immer noch splitten... cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Gute Relations-Erklärung
Bernd Wurst wrote: Weißt du, ob sich das mit dem nachträglichen Zusammenfassen von Wegen (sei's mit oder ohne Relations) mal jemand bzgl. Implementierung im Renderer angeschaut hat? Ja, ich hab mich damit mal beschäftigt. Geht eigentlich ganz gut. Beispiel: http://j-e-b.no-ip.com:8080/p/map.jpg Was mein kleines Script da macht ist im Prinzip einen extra Beschriftung-Layer anzulegen, der aus den zuerst zusammengesetzten und dann in sinnvoll lange Stücke zerschnittenen Straßen besteht. Das zerschneiden eben dazu, dass der Name alle z.B. 500 Meter wiederholt wird. Bei der Gelegenheit erzeugt es auch gleich Nodes für die ref-Tags alle x Meter. Könnte man wie das Bezier-Script in die Osmarender-Kette einbauen. cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] U6 in Berlin reparieren?
Hi, hat jemand zufällig die Daten die U6 in Berlin-Wedding zum reparieren? Die hat anscheinend ein Potlatch-User(*) mal einfach so in der Gegend rumgeschoben. :-( Ich müsste das jetzt eher pi*Daumen machen, wenn sich's nicht vermeiden ließe... *) Disclaimer: Nein, Potlatch ist ganz sicher unschuldig, und der beste Editor überhaupt, der solche Fehler nur zuläßt, wenn man sich richtig anstrengt. cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] ebenentransparenz in josm einstellen
Frank Sautter wrote: da hast du mich nicht verstanden, ich will lediglich, dass ich an den stellen, wo keine vektoren sind, der hintergrund durchscheint (also meine tracklogs und dann yahoo). Hast du auch die aktuelle Version? Wir hatten vor ein paar Wochen mal 'nen Bug, der genau das kaputtgemacht hat... cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] luftseilbahn taggen
Andreas Stricker wrote: Henry Loenwind schrieb: aerialway=cable_car ist schon das richtige Tag für die Luftseilbahn. Jepp, die Luft steckt da schon im Tag. Allerdings frage ich mich, warum es railway=cable_car nicht gibt laut Features-Seite... Das währe dann railway=incline. Also da würde ich zuerst an eine Zahnradbahn denken, und das ist ja wieder was anderes... cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Heide in Osmarender
Raphael Studer wrote: Für Zoo bräuchte es dann natürlich auch noch ein hübsches Logo. All die Flächen anhand ihres grüns zu Unterscheiden dürfte nämlich etwas schwierig werden.. Jepp, Logos sind wichtig. Aber auch mit Logos ist es wichtig, dass die Flächen einen leicht unterschiedlichen Grünton haben, damit man bei nebeneinanderliegenden Flächen unterschiedlichen Typs sehen kann, was wo dazu gehört. Beispiel: Wir haben hier in der Gegend einen Zoo im Wald, wenn der keine andere Farbe bekommt, ist es wirklich nicht offensichtlich, was jetzt Zoo und was Wald ist, da hilft das Logo nix. cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] OT: Meine unlesbaren Postings...
Gerald.Oppen wrote: Da ich jetzt mehrer Mails erhalten habe bzgl. unlesbarer/zerrissener Postings: Du meinst zerrissene Threads, oder? Ich kenne den Mechanismus nicht der sicherstellen soll dass die Mail richtig eigeordnet wird. Vielleicht kann mich diesbezgl. jemand aufklären. Relativ einfach. Ein Mailprogramm setzt beim Antworten einen Header mit der ID der Mail, auf die geantwortet wurde. z.B.: Message-ID: [EMAIL PROTECTED] Date: Sat, 17 May 2008 15:33:52 +0200 From: =?ISO-8859-15?Q?Andr=E9_Reichelt?= [EMAIL PROTECTED] To: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org References: [EMAIL PROTECTED] [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] Subject: Re: [Talk-de] Taggen von aufgegebenen Wegen? Manuell lässt sich das bei einer neuen Mail IMHO bei keinem Mailprogramm nachpflegen... cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] luftseilbahn taggen
Raphael Studer wrote: aerialway=cable_car ist schon das richtige Tag für die Luftseilbahn. Jepp, die Luft steckt da schon im Tag. Allerdings frage ich mich, warum es railway=cable_car nicht gibt laut Features-Seite... cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Layer
Dimitri Junker wrote: ich dann, daß dort ein Straßentunnel war, dummerweise mit layer -1 in einem richtig. Kann man [EMAIL PROTECTED] auch mal beibringen, daß eine Fläche keine ways überdecken sollte. Mmmmh, eher andersrum. Tunnel sollten über alles (außer Icons und Beschriftungen) gerendert werden. Immerhin werden sie ja gestrichelt, was alleine schon Röntgenblick anzeigt. Wenn man sie stur in ihrem Layer rendert, bräuchte man sie auch nicht stricheln. cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Layer
Dimitri Junker wrote: Und was wäre wenn die Straße nicht durch einen Tunnel führt, sondern einfach durch ein Tal und darüber eine Brücke führt? Gibt man dann der unteren Straße layer -1 und der oberen 0, so würde die untere auch nicht gezeichnet. Das wird jetzt auch nicht richtig gerendert, schon ohne Fläche nicht. Allgemein kann ich mir nicht vorstellen, wo eine Fläche einen Weg oder einen einzelnen Node verdecken soll. Eine einfache Lösung wäre, daß Flächen ohne Ich kenne da ein paar Gebäude, die das tun, z.B. das neue Parkhaus der Messe Stuttgart. layer-Angabe wie layer-5 behandelt werden. Für die wenigen Sonderfälle kan man ja dann was anderes setzen. Schadet nicht. cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] JOSM - langsam bei ausgefüllten Polygo nen?
Andreas Jacob wrote: Am Montag, 12. Mai 2008 05:42:13 schrieb Henry Loenwind: Wie gesagt, draw.rawgps.trianglelines ist bei mir mehr als 10 mal schneller als einfache Linien - und ich verstehe es nicht... Mal in's Blaue hinein vermutet. Die Engines von Grafikkarten bzw. die ansteuernden Treiber sind doch alle auf das Arbeiten mit Dreiecken getrimmt. Na, das ist es nicht. Langsam: g.drawLine(old.x, old.y, screen.x, screen.y); Schnell: g.drawLine(old.x+2, old.y+2, screen.x, screen.y); Also in dem Moment, in dem die Linie dort weitergeht, wo die letzte aufgehört hat, ist es schnarchlangsam. Der Name des Settings bezieht sich nur auf die Form, die dabei rauskommt, da ich dann eben 2 versetzte Linien zeichne (um genau zu sein, diese gehen von den Endpunkten der Pfeil-Linien zum nächsten Punkt). cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [EMAIL PROTECTED] rendert uralte Daten?!
Dirk-Lüder Kreie wrote: Karl Eichwalder schrieb: Stichworte: Hochrechnen, wie lang ein tile normalerweise unterwegs ist. Wird diese zeit überschritten, kann das tile neu vergeben Macht er schon, wenn auch nicht dynamisch. Ich verstehe nicht ganz, was das damit zu tun hat, dass ein ZIP auf einem [EMAIL PROTECTED] rechner 2 Wochen lang rumliegt, bevor es hochgeladen wird? Relativ einfaches Verständnisproblem: Während der Server über Renderaufträge genau buchführt, die neu vergibt, wenn ein Client nicht liefert oder den Auftrag zurückgibt, weil es nicht klappt, ist das Hochladen unabhängig von diesen Aufträgen. d.h. Der Server nimmt alle Uploads an und verarbeitet sie. Wenn damit ein Auftrag befriedigt wird, gut. Wenn nicht, auch gut. cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] JOSM und Background Farbe - ev. Bug
Daniel Naber wrote: Kannst du Dir auch mal meinen Patch in http://josm.openstreetmap.de/ticket/741 anschauen? Ist das nicht die bessere Lösung als einfach auf != null zu prüfen? Wahrscheinlich ja, aber auf null prüfen sollte man das Ergebnis einer Methode, die null zurückliefern darf trotzdem noch. cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] JOSM und Background Farbe - ev. Bug
Frederik Ramm wrote: Daniel hat ja ganz darauf verzichtet, getClibBounds aufzurufen, insofern ist er fein raus ;-) commited für 636. Hey, das ist geschummelt :-)) Haust die die 720 auch gleich noch rein? cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [EMAIL PROTECTED] rendert uralte Daten?!
Dirk-Lüder Kreie wrote: Eigentlich kann sowas nur passieren, wenn jemand tilesets gut ablagern lässt, bevor sie hochgeladen werden. Das passiert aber leider sehr einfach. z.B. Rechner runterfahren, 2 Wochen in Urlaub gehen, tah starten. Schwupp, alte Daten im Upload... cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] JOSM - langsam bei ausgefüllten Polygo nen?
Frederik Ramm wrote: Eingebaut, danke. (Der 733 geht so nicht, beim Aufruf von ... Hast Du Dir eigentlich mal #720 (josm.gui.layer.GpxLayer paint) angeschaut? Wäre die Annahme so richtig? Wenn ja, würde ich da nen richtigen Patch draus machen, hat sich in der Gegend ja auch was getan inzwischen. cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] JOSM - langsam bei ausgefüllten Polygo nen?
Frederik Ramm wrote: Ich hab einen Kommentar rein geschrieben. Komme in letzter Zeit nicht so dazu, trac genau zu verfolgen, daher danke fuer den Hinweis. Ich glaub ich werd wahnsinnig. Wenn ich: g.drawLine(old.x, old.y, screen.x, screen.y); zu: g.drawLine(old.x+2, old.y+2, screen.x, screen.y); ändere, dauert das ganze painten nur noch ca 1/15tel der Zeit. Häh??? Was soll das? Irgendjemand eine Ahnung? cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] JOSM - langsam bei ausgefüllten Polygo nen?
Frederik Ramm wrote: dazu, trac genau zu verfolgen, daher danke fuer den Hinweis. Ok, Patch hängt am Ticket. Ich habe zwei Änderungen, die visuelle Auswirkungen haben, konfigurierbar gemacht; Default: AUS. Siehe auch Tickettext. Wie gesagt, draw.rawgps.trianglelines ist bei mir mehr als 10 mal schneller als einfache Linien - und ich verstehe es nicht... cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] offizielle Bezeichnung von Bundesstraß en/ Autobahnen
Frederik Ramm wrote: Es waere auch relativ trivial, einen Renderer (oder Praeprozessor) so zu gestalten, dass er das Leerzeichen je nach Wunsch des Weiterverar- beiters hinzufuegt oder entfernt. Insofern wuerde ich mir da keinen so grossen Kopf drum machen. Gibt es im Wiki eigentlich eine Seite, wo all die Weiterverarbeitungs- und Interpretationsregeln für Renderer mal zusammengetragen werden können? Wäre vielleicht nicht schlecht, dort dann z.B. sowas zu hinterlegen: Within Germany: * ref tags: ** Official form is: 1 or 2 letters, space, numbers (e.g. A 5, St ). Often the tag is missig the space. When rendering as boxes, you may want to use a narrow width space, or none at all. ** tag-boxes may be colored according to the official road sign color code. When starting with A: blue (link:wikipedia), B: light orange, L: pale yellow, K: white, ... nur so als Beispiel... cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Namen von Auf- / Abfahrten / Ueberleitungen
Martin Simon wrote: mir ist vor einiger Zeit mal aufgefallen (OSM erweitert deine Wahrnehmung! ;-)), daß Autobahnauffahrten und Verbindungsstücke immer die Nummer der Autobahn tragen, auf die sie führen (Pfosten am Straßenrand). Gute Beobachtung. Ich wollte das grade mal im Wiki verewigen, als mir aufgefallen ist, dass auf: http://wiki.openstreetmap.org/index.php/Tag:highway%3Dmotorway_link#Examples das komplette Kleeblatt als motorway und nicht motorway_link getaggt wird. Absicht? Fehler? cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Namen von Auf- / Abfahrten / Ueberleitungen
Etric Celine wrote: On Saturday 10 May 2008 14:57:35 Henry Loenwind wrote: Martin Simon wrote: das komplette Kleeblatt als motorway und nicht motorway_link getaggt wird. Absicht? Fehler? War ein Fehler meinerseits. Ansich sollten die Übergänge von einer Autobahn zur anderen wirklich als motorway_link bezeichnet werden. Ich hab das auch mal für die Parallelfahrspur geändert. Ausserdem ist mir aufgefallen (zweites Bild), dass die nach Süden führende Fahrspur der A27 über die komplette Länge des Kleeblatts als bridge=yes getaggt zu sein scheint. cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Bezeichnung von Überlandstraßen in Thüringen - gute Nachricht
Holger Schrader wrote: einmal. Ich habe etwas gegooglet und auf der Internetseite des Thüringer Landesamt für Straßenbau eine Straßennetzkarte als PDF Datei gefunden. Da hab ich jetzt auch mal gegoogelt, und auf den Webseiten des Landesvermessungsamts Baden-Württemberg etwas interessantes gefunden: 1.50 Erstinstanzliches Gericht Gent Datum der Entscheidung: 21.01.2002 Aktenzeichen: A. R. - Nr. 01/836/A Stichwort: Vektorisierung aus topografischen Karten Leitsätze: Die Übernahme geometrischer Daten aus topografischen Karten durch Vektorisierung ist frei möglich. Bei einem reinen Informationsgehalt der zu Grund liegenden geometrischen Daten oder Koordinaten der realen Geometrie sind keine Urheberrechte möglich. [...] Quelle: http://www.lv-bw.de/lvshop2/Produktinfo/wir-ueber-uns/tipps/Datenbankrecht/infobörse.adv.doc Leider ist das Urteil im Original nicht zugänglich, wäre wirklich interessant, ob der erste Absatz wirklich so aus dem Urteil abgelesen werden kann. Die einzige andere Sekundärquelle, die ich gefunden habe, bezieht sich überhaupt nicht auf Vektorisierung sondern nur auf das Datenbankrecht. Und dass die ganze Karte an sich ein geschütztes Datenbankwerk darstellt, ist ja unstrittig - aber das hier könnte den Weg zur Übernahme der nackten Koordinaten ebnen... cu Henry PS: Haben wir hier einen Anwalt da? Macht sich das Landesvermessungsamt Baden-Württemberg diese Rechtsauslegung durch die unangestrittene Veröffentlichung dieses Urteils unter Tipps -Datenbankrecht eventuell so zu eigen, dass man es drauf festnageln kann? (Bitte keine Laienmeinungen, bringt hier nix...) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] NRW Rendern mit Zoomstufe 8 oder höher für Anfänger
Henry Every wrote: Ich würde gerne NRW oder Berlin oder... in der Zoomsufe 8 oder höher rendern. Am liebsten wäre mir ein Output als Postscript Datei, DWF oder HPGL, damit man diese auch vernünftig ausdrucken kann, in einer Größe die mir vorschwebt (DIN A1). Am einfachsten wäre es sicher, sich von [EMAIL PROTECTED] die zoom-12 captionless Tiles und dazu passende lowzoom/caption Tiles rendern zu lassen, und die diese Bitmaps aneinandergeklebt auszudrucken. Wären eben Bitmaps, aber ich denke, bei der Größe mag auch der Drucker das nicht mehr als Vektordaten. Bei Berlin kann ich mir die captionless Tiles aber nicht in A1 vorstellen, das wird zu grob, Berlin hat ja grade mal 6x6 z12-Tiles oder so. Bei [EMAIL PROTECTED] kannst Du in der layers.conf einstellen, was er Dir rendern soll (welche layer und welche Zoomstufen). Am einfachsten such Du Dir die xy-Adressen der Tiles auf http://www.informationfreeway.org raus, (Berlin z.B. x=2198 bis 2202, y=1341 bis 1344) und lässt das per tilesGen.pl xy 2198 1341 etc. rendern. Hat noch jemand 'nen Tip, wie man aus den vielen Bitmaps dann am besten einen Druckjob zusammenbastelt? cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Radwege entlang von Straßen: wie wird korrekt getagged
Heiko Jacobs wrote: Zitat von Toni Erdmann [EMAIL PROTECTED]: Radwegenetze sollen sich auch in OSM widerspiegeln- klar! Aber: für's Auge (Renderer) oder für's Navigieren (Routing-SW)? ... Oder für den Mapper, der mit dem System zurecht kommen muss? Das ist der Haken: Renderer rendern derzeit nicht vernünftig. Nicht nur das. Was soll ein (Auto-)Navi an so Kreuzung machen, wo die Radwege separat gemapt sind, wenn er Abbiegeanweisung geben soll? Woran soll es erkennen, ob es den Radweg mitzählen soll oder nicht? Gleiches Problem mit allem was highway:service getagt ist, lautet die Ansage jetzt zweite rechts abbiegen oder nächste rechts abbiegen, wenn da ein Service kurz vor der Kreuzung ist? Na, ich möchte kein Live-Navi bauen müssen, solange nicht alle Kreuzungen per Relationen definiert sind. cu Henry PS: Kleine Anekdote: Mein Navi meinte einmal zweite rechts abbiegen. Als erstes kam das falsche Ende einer Einbahnstraße. Als zweites noch ein falsches Ende einer Einbahnstraße. Als drittes dann die Straße, in die ich rein musste. Und laut Kartendarstellung kannte das Navi auch beide Einbahnstraßen... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Neuer Highway fuer Radwege
Andreas Jacob wrote: Wenn mich nicht alles täuscht, hatte hier auf der ML mal jemand geäußert, dass er mal eine Tabelle mit den deutschen Verkehrszeichen in's Wiki stellen wollte [1] Wenn jemand rausfindet, wie man die Bilder in Commons entweder direkt verlinkt, oder einen Massen-import/-export macht, mache ich gern mal das Gerüst für die Seite... Ich habe das bisher so gemacht, dass wenn die Straßentypen unterschiedlich waren, dann hat nur die höherwertige Straßenform ein Tag bekommen. Und falls es z.B. 2 Bundesstraßen waren, dann habe ich beim ref einfach beide getrennt durch einen Schrägstrich angegeben. Sauber ist das wahrscheinlich Strichpunkt ist doch eigentlich der richtige Trenner, wenn ein tag mehrer Werte hat. Also ref:B 76;L 2005. cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Neuer Highway fuer Radwege
André Reichelt wrote: http://wiki.openstreetmap.org/index.php/De:Road_Signs (Wie das darüber,nur speziell auf Schilder ausgerichtet) Pages that link to De:Road Signs (List of links) De:Road Signs What links here Page: Namespace: No pages link to De:Road Signs. Na super, und wie soll das jemand finden? cu Henry PS: Aber ein guter Ansatz! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Gute Relations-Erklärung
Frederik Ramm wrote: Im Osmarender-Perl-Code steht dann drin, was genau zu geschehen hat, Warum das in jeden einzelnen Renderer reinstricken? Ein bisserl Preprocessing reicht schon. Ich hab da mal was gebastelt... http://j-e-b.no-ip.com:8080/p/map.jpg Siehe Screenshot. Ist ein Rendering von Kosmos, da ich da die Rules eim einfachsten anpassen kann. Mein kleiner Prepocessor hat in die osm-Datei noch ein paar neue Ways und Nodes eingebastelt. Zuerst hat er alle Straßen (highway:*) anhand des Namens (sofern sie einen haben und sofern highway-Typ halbwegs zusammenpassen, also keine_links oder so, abenfalls keine area:yes oder junkction:*) zusammengebastelt, dann in maximal 500m lange und auch gleichmäßig lange Stücke zerlegt. Danach das gleiche mit den allen highways, die einen ref haben, daraus aber keine Ways, sondern Nodes gebastelt, auch wieder gleichmäßig verteilt und höchstens alle 750m. Danach hab ich noch händisch kleine rote Pfeile an alles drangebastelt, was anders als normal gerendert wird. PS: Die unsichtbaren Straßen-Teile von Seegasse und Mayerstraße sind living_street, da sollte ich die Kosmos-Rules vielleicht noch erweitern... ;) Wer's selber ausprobieren will, ich häng's auch mal an. Ist in Perl geschrieben, benötigt nur Geo::Direction::Distance (http://search.cpan.org/~kokogiko/Geo-Direction-Distance-0.0.1/) als Voraussetzung, und arbeitet als Filter. z.B. perl computeWayCaptions2.pl data.osm result.osm. Bitte das Ergebnis AUF KEINEN FALL hochladen!!! cu Henry PS: Angepasste Kosmosrules hab ich auch noch attached. PPS: Wenn's doch ein hochlädt, alle neuen Elemente werden mit note:FIXME Please delete me if I was uploaded by accident! getaggt. The original MIME headers for this attachment are: Content-Type: text/plain; name=computeWayCaptions2.pl Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename=computeWayCaptions2.pl The original MIME headers for this attachment are: Content-Type: text/xml; name=cways.xml Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=cways.xml ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Gute Relations-Erklärung
Frederik Ramm wrote: zeichne eine grüne Linie 2,2 Pixel breit in 1,3 Pixel Abstand rechts des Ways? Das kommt drauf an, ob einem irgendein gescheites SVG einfaellt, das das erzeugt. Osmarender errechnet grundsaetzlich nur die Mittellinie des Auf so tiefer Ebene wird das schwierig. Das Problem ist vielleicht noch nicht mal so sehr die Linie, sondern die Kreuzungen. Und damit dann auch die Stellen an der der Way unterbrochen ist. Wenn man hier nur den einzelnen Way ansieht hat man Unterbrechungen und Überlappungen. Also muss man zuerst die Wege zusammensetzen, die die gleiche Linie haben sollen. An Kreuzungen mit mehr als 2 Wegen mit der gleichen Linie muss man sich überlegen wie das aussehen soll. Im Zweifelsfall wird die Linie dann in die Kreuzungsmitte gezogen (und verschwindet so unter der Straße). Auf freier Strecke muss man an jedem Node aus dem Winkel der beiden Linien zu den nächsten Nodes eine Richtung für einen Hilfspunkt berechnen, über den die Linie dann parallel zur eigentlich Strasse liegt. An Sackgassenenden berechnet man disen Punkt entweder senkrecht zu Straße, oder in 45° dazu und haut echten Node noch dazu (Pfeilspitze). An Kreuzungen s.o., wobei die Pfeilspitzenmethode hier auch recht gut aussehen würde. Die ganze Winkelberechnung könnte man in einen Prepocessor auslagern, dann ließe sich der einmal geschriebene Code für mehrere Renderer benutzen. 1-2 Stunden Arbeit, würde ich sagen, wenn ich auf meinem Straßennamenpreprocessor aufbaue. cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Neuer Highway f?r Radwege (war: Radwege entlang von Stra?en: wie wird korrekt getagged )
Karl Eichwalder wrote: Einfach die verkehrszeichen hinzupacken: traffic_sign=z240 Da hab ich auch schon drüber nachgedacht. Werd ich wohl auch so machen, wenn ich irgendeine Situation nicht 1:1 auf Standard-Tags abbilden kann. Aber, wäre es nicht sinnvoll, die Info, dass wir uns auf die deutschen Schildernummern beziehen noch mitzuverewigen? Also: traffic_sign:de=z250 -oder- traffic-sign=de:z250 cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Yahoo-WMS-plugin und firefox 3
Hi, das hier: http://wiki.openstreetmap.org/index.php/Java_Applet_Help Das war der Vorgänger von potlatch. cu Henry Christoph Wagner wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Henry Loenwind schrieb: Jochen Topf wrote: Weil man die Yahoo-Bilder laut Lizenzbedingungen von Yahoo nur über die Javascript-API beziehen darf. Und dafür braucht man halt einen Webbrowser oder sonst irgendwas, was für die Yahoo-Javascript-Library wie ein Webbrowser aussieht. Und was ist mit dem alten Java-Applet? Das war ja schon mal genehmigt. Ich hab's mal spaßhalber entkernt, und alles rausgeworfen was mit osm-Daten zu tun hatte (war ja eh noch API 0.4 Zeug), jetzt läuft's als reiner Yahoo-Browser sehr gut. cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de Wer, wie, was, wo? Wenn das tatsächlich ne nette Alternative wäre als einen kompletten Firefox nur für Yahoobilder installiert zu haben, könnte man ja drüber reden. Wär doch auch nicht schlecht, wenn man da gleich was in das JOSM-plugin mit einbaut. Ich weiß jetzt aber nicht, was du überhaupt mit dem Java-Applet meinst. Erklär mal bitte! Grüße Christoph -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIHWUXRg5oWO2lGuMRAj5yAJ9k06t8il5XRqj+J2rO0ZmP2GufDQCfRpWm U8F0kFdV2DWrW35WSYTv/E8= =hU4P -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Public_building wird nicht gerendert?
Hi, auf jeden Fall solltest Du die Info Studentenwohnheim noch irgendwo unterbringen, im Zweifelsfall halt als note. Dann kann man das Teil auch finden und umtaggen, sobald es etwas für Studentenwohnheime gibt. cu Henry Kremsner Rudolf wrote: http://www.informationfreeway.org/?lat=47.829320630188064lon=16.53526429074046zoom=17layers=B000F000F Bei befragter Adresse ist über der Fachhochschule Eisenstadt eigentlichnoch ein Gebäude eingetragen. Dieses wird aber nicht gerendert. vl willsich das mal einer ansehen. Habe besagtes Gebäude mit amenity = public_buildinggetaggt. ist ein Studentenwohnheim und wusste nicht wie ich es sonst taggen soll. lg me ___Talk-de mailing [EMAIL PROTECTED]://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] TOFU in dieser Mailingliste
SK Hallo, Hallo Simon, PL Angesichts der letzten Postings fühle ich mich motiviert, PL - http://de.wikipedia.org/wiki/TOFU SK dem kann ich mich nur anschliessen, und würde Euch zusätzlich bitten SK auch auf Folgendes zu achten: Na solange hier niemand Fido-Style-Quoting verlangt... ;) SK - keine sinnlosen Fullquotes SK - keine Multipart-Mails versenden SK - keinen HTML-Code einbauen SK - keine Anhänge - bitte Zeilenvorschübe in den Mails belassen/einbauen. Ich finde es einfach nur unleserlich wenn ein kompletter Quote-Block mit sonstwie vielen auf einer Zeile landet SK Des weiteren würde ich euch bitten den Betreff des Vorposters nicht zu SK verändern, da viele Leute die Nachrichten nach Thema sortieren. Und vielleicht ein wenig aufpassen, dass man beim Antworten auch wirklich antwortet, d.h. dass das Mailprogramm auch die Referenz-Header richtig setzt (setzen kann). Dann klappt auch die Thread-Anzeige, bei den Leuten, die sie verwenden. SK mit besten Grüßen, SK Simon Kokolakis cu Henry --- Thunderbird 2.0.0.14 (Windows/20080421) * Origin: RoleBox (2:2468/6038.0) SEEN-BY: 2468/6038 6039 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Talk-de Digest, Vol 22, Issue 21
Hi, Du bist übrigens so ein alles-in-einer-Zeile-Sender. Siehe Screenshot. Irgendjemand eine Ahnung, woran das liegt? cu Henry PS: TOFU Absicht, den Einzeiler zerlege ich nicht freiwillig. Martin Koppenhoefer wrote: SK Des weiteren w?rde ich euch bitten den Betreff des Vorposters nicht zu SK ver?ndern, da viele Leute die Nachrichten nach Thema sortieren. Und vielleicht ein wenig aufpassen, dass man beim Antworten auch wirklich antwortet, d.h. dass das Mailprogramm auch die Referenz-Header richtig setzt (setzen kann). Dann klappt auch die Thread-Anzeige, bei den Leuten, die sie verwenden. SK mit besten Gr??en, SK Simon Kokolakisja sorry, habe das gebündelte Zusenden der Nachrichten geradedeaktiviert, daher kommen die Unannehmlichkeiten... Martin___Talk-de mailing [EMAIL PROTECTED]://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de inline: beispiel.png___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] osmarender: Unechte Kreuzungen
Hi, warum pinselt osmarender 2 Straße, die sich optisch im Renderergebnis berühren, aber keinen gemeinsamen Node haben wie eine Kreuzung? Beispiel: http://www.informationfreeway.org/index.php?lat=49.334837743028665lon=8.664168073246309zoom=17layers=B000F000F Die untere von den drei Sackgassen endet laut josm 8,7m vor der Umgehungsstraße (3m Fahrbahn, Lärmschutzwand, 2m Grünstreifen, 2m Wendehammer ... passt). Muss ich jetzt schon ebenengleiche nebeneinanderliegende Wege nur für die Renderer auf unterschiedliche Layer setzen? cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] osmarender: Unechte Kreuzungen
Jochen Topf wrote: On Sat, May 03, 2008 at 02:22:50PM +0200, Henry Loenwind wrote: warum pinselt osmarender 2 Straße, die sich optisch im Renderergebnis berühren, aber keinen gemeinsamen Node haben wie eine Kreuzung? Ein menschlicher Kartograph würde einen solchen Fall erkennen und die Sackgasse etwas kürzer einzeichnen. Für einen automatischen Renderer ist das aber sehr schwierig, alle solche und verwandte Fälle richtig zu handhaben. Mir geht es nicht, darum, dass sich die 2 Straßen überlappen (das ist ok), sondern, dass sie als Kreuzung dargestellt werden, d.h. dass die Randlinien beider Straßen fehlen. IST: #|g|## -+g|## wwg|## -+g|## #|g|## (#=Hintergrund, -+|=Randlinie, g=gelbe Füllung, w=weisse Füllung) SOLL: #|g|## -|g|## w|g|## -|g|## #|g|## KORREKT ABER UNNÖTIG: #|g|## +|g|## ||g|## +|g|## #|g|## ---+#|g|## www|#|g|## ---+#|g|## #|g|## oder Du machst im JOSM die Sackgasse künstlich kürzer. Beides keine optimalen Lösungen... Bringt wenig, für die niedrigste Zoomstufe, in der die Sackgasse noch gerendert wird, müsste ich sie auf 10% ihrer tatsächlichen Länge verkürzen, oder so... Muss ich jetzt schon ebenengleiche nebeneinanderliegende Wege nur für die Renderer auf unterschiedliche Layer setzen? Das auf keinen Fall. Würde auch nichts helfen, dann wäre nur die Sackgasse über der B535. Umgekehrt, die B535 höher. Ich hab sie mal probeweise auf layer:1 gesetzt, vielleicht wird dann ihr Seitenstrich durchgängig gezeichnet, so wie er soll. Das Problem ist wohl, dass der Renderer die Seitenstriche anhand ihrer Position im Renderergebnis weglässt, nicht anhand der Position der originalen ways. cu Henry PS: EBENFALLS BLÖD: #|g| -|g|-+## w|g|w|## -|g|-+## #|g| Diesen Fall (bei zoom = 15) hab ich mit ner Sackgasse, die im spitzen Winkel (real) 30cm vor dem Leimbach endet (modelliert als 4m vor der Bachmitte), grademal 500m weiter nördlich. Hier hab ich übrigens schon per layer die Straße unter den Bach gesetzt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] osmarender: Unechte Kreuzungen
Jochen Topf wrote: On Sat, May 03, 2008 at 04:57:21PM +0200, Henry Loenwind wrote: Das Problem ist wohl, dass der Renderer die Seitenstriche anhand ihrer Position im Renderergebnis weglässt, nicht anhand der Position der originalen ways. Das ist alles nur ein Seiteneffekt davon wie der Renderer diese Seitenstriche macht. Das geht so: Dieses Verfahren benutzen übrigens alle Renderer, die ich kenne. Auch die proprietären arbeiten alle so. Sie haben also alle diesen Fehler in diesem Fall. Wenn jemand eine Idee hat, wie man das besser machen kann, würde mich das interessieren. :-) Einfach ist das nicht. Auf Anhieb fiele mir ein: Zuerst werden alle nicht-Endnodes der ways (highway:*) untersucht. Wird ein node noch von mindestens einem anderen way (higway:*) im gleichen layer benutzt, wird der durchgehende way gesplittet. Effekt: Kreuzungen bestehen nur noch aus Endnodes. (Diesen Schritt kann man sich sparen, wenn man den folgenden davon überzeugt, mit durchgehenden ways an Kreuzungen zurechtzukommen.) Dann werden die Endnodes der ways untersucht; wenn den letzten node entweder keine anderen ways (highway:*) im gleichen layer oder mehr als zwei sharen (d.h. es ist ein Ende oder eine Kreuzung), wird das letzte segment des ways (also das Stück vom vorletzten zum letzten node des ways) herausgelöst. Als erstes werden nun die Reste der ways gerendert, darüber dann die herausgelösten Wegenden. Hierbei muss man darauf achten, wie man die Enden der Striche rendert, die Füllung muss rund überstehen, die Umrandung darf es nicht (außer bei echten Wegenden). Erste Verfeinerung wäre es, zuerst die Enden, dann die Mitten und dann die Kreuzungen zu rendern. Als zweite Verfeinerung kann man, statt das ganze letzten Stück herauszunehmen, einen neuen temporären node in den way einbauen, genau (maximale Straßenbreite)/2+(Breite eines Pixels nach dem Rendern) vom Ende entfernt. Das sollte es dann eigentlich erschlagen... cu Henry PS: Wo wir grade bei Sackgassen sind; warum verpasst osmarender Sackgassenenden, bei denen der node mit einer Fläche geteilt wird so schöne Rundungen, und sonst nicht? (z.B. Robinienweg/Willy-Brandt-Straße) Ok, wozu die Rundung da ist, weiß ich, es wundert mich nur, dass osmarender Straßen nicht von sonstigen ways unterscheidet dafür... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Parkspuren
Hi, prinzipiell gut, ABER erst wenn es einen Standard gibt, wie man richtungsabhängige Tags so gestalten kann, dass Editoren sie auch umdrehen können, ohne die einzelnen Tags zu kennen. Und dann ein Tag an Nodes für Editoren, das sie dazu bringt, diese Nodes immer auf der geraden Linie zwischen den nächsten Nodes der 2 ways mit denmselben name:*, die an ihnen enden zu halten haben. Oder eine Möglichkeit ways zu unterteilen, die nicht gleich einen node mit Position einbaut und den way zerschneidet... Zur Ursprungsfrage: Ich modelliere im Moment Parkstreifen nur, wenn sie eine wesentlich höhere Kapazität haben als normales an-der-Straßenseite-Parken. Und dann als Parkfläche. cu Henry André Reichelt wrote: Am Samstag, den 03.05.2008, 18:55 +0200 schrieb Sven Grüner: Da fände ich generell einen Zusatztag gut, um zu signalisieren, das an einer Straße geparkt werden kann. Da kommen ja oft mehr Stellplätze zusammen als auf manchen dedizierten Parkplätzen. Ob man da an den Weg einfach ein amenity=parking hängen sollte?Ein Zusatztag fände ich auch sinnvoll. Jedoch sollte man das irgendwievon der Straßenseite abhängig machen. Das könnte man ja mit derNode-Richtung realisieren, dass man macht: parking=none/left/right/both (relativ zur Richtung) Rendern könnte man das als Blauen Streifen neben der Straße oder sowas. Was haltet Ihr davon? ___Talk-de mailing [EMAIL PROTECTED]://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Yahoo-WMS-plugin und firefox 3
Jochen Topf wrote: Weil man die Yahoo-Bilder laut Lizenzbedingungen von Yahoo nur über die Javascript-API beziehen darf. Und dafür braucht man halt einen Webbrowser oder sonst irgendwas, was für die Yahoo-Javascript-Library wie ein Webbrowser aussieht. Und was ist mit dem alten Java-Applet? Das war ja schon mal genehmigt. Ich hab's mal spaßhalber entkernt, und alles rausgeworfen was mit osm-Daten zu tun hatte (war ja eh noch API 0.4 Zeug), jetzt läuft's als reiner Yahoo-Browser sehr gut. cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Bushaltestellen
Hi, irgendwie scheinen sich alle Diskussionen dazu recht schnell zu zerlaufen. Und wenn Relationen ins Spiel kommen, wird gleich wieder angefangen, Buslinien zu modellieren. Hier mal ein ganz dummer einfacher Vorschlag für Haltestellenrelationen (Bus/Tram/Bahn/Fähre/...): Eine Haltestelle ist eine Relation mit folgenden Members: * role:from_way (way/mandatory) der way von dem aus der Bus die Haltestelle anfährt * role:from_position (node/mandatory) entweder der node, an dem der Bus den way verlässt, um in die haltestelle einzufahren, oder der node, an der der bus hält, wenn er den way nicht verlässt (muss Tail von from_way sein) * role:from_direction (node/mandatory) ein node des from_way, der die Richtung bestimmt, aus der der Bus kommt. Bevorzugterweise der node, der direkt vor from_position kommt. * role:stop_way (way/optional) der way, auf dem der Bus steht, wenn er an der Haltestelle anhält. Nur wenn der Bus die Strasse verlässt, ansonsten wird from_position benutzt. Darf bei schienengebundenem Verkehr auch auf dem from_way liegen. * role:passenger_area (way or area/optional) da stehen die Passagiere, während sie auf den Bus warten, also Wartehäuschen oder Verkehrsinsel. Darf mehrmals vorkommen. * role:stop_position (node/optional) hier wird das Icon gerendert, bzw. hier steht das Haltestellenschild. Wenn nicht gesetzt, wird from_position benutzt. * role:to_way (way/optional) der way, auf den der Bus beim Verlassen der Haltestelle fährt. Wenn nicht gesetzt, wird from_way benutzt. * role:to_position (node/optional) der node, an dem der Bus auf den to_way einfährt. Wenn nicht gesetzt, wird from_position benutzt. * role:to_direction (node/optional) die Richtung, in die der Bus davon fährt. Ist mandatory, wenn to_way gesetzt ist. Wenn nicht gesetzt, wird die Gegenrichtung von from_direction benutzt. Im einfachsten Fall (Bus hält auf der Straße an einem Schild), kommt man mit 3 Members aus: from_way für die Straße, from_direction für die Richtung und from_position für die Haltestelle. Und man müsste eigentlich noch nicht mal den bus_stop Node neben die Straße setzen, ein Renderer könnte es über die Relation automatisch im perfekten Abstand auf die richtige Seite der Straße setzen. Aber solange die es noch nicht können, baut man eben das vierte Member ein. Im schlimmsten Fall (Bus fährt in eine abseits der Straße gelegene Haltestelle ein und verlässt diese auf eine andere Straße, Passagiere haben eine eigene Warteinsel) benötigt man alle. (z.B. http://www.openstreetmap.org/?lat=49.40815lon=8.69432zoom=17layers=B0TT - leider nicht eingezeichnet) So, einen Verriss bitte ;) cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Bushaltestellen
André Reichelt wrote: Irgendwie finde ich den Vorschlag doch recht kompliziert. Könnte man dasnicht einfacher lösen? Nicht wenn man alle möglichen Haltestellen damit abdecken möchte. Aber bis auf 3 Elemente ist ja alles optional. Im Grundfall brauchst Du: * Den Way zu dem die Haltestelle gehört. Ohne brauchen wir gar nicht erst anfangen, oder? * Die Position der Haltestelle am Way. Klar, irgendwo muss sie ja sein. * Die Richtung für die die Haltestelle ist. Man /könnte/ auch ohne auskommen, aber mit dieser Info können sowohl Renderer als auch Router so viel anfangen, dass ich sie als Pflicht vorgesehen habe. Im einfachsten Fall kann der Renderer damit das Icon automatisch auf die richtige Seite der Straße setzen, wenn er möchte. Wer mehr Infos unterbringen möchte hat noch: * Die Position, wo das Icon hin soll per Hand. * Die Zuordnung von Fahrgastwartebereichen (Wartehäuschen, Routing-Ziel für Fussgänger, Bänke, Fahrkartenautomaten) zu der entsprechenden Haltestelle. Wie diese Teile getaggt werden ist dabei unerherblich, die Relation ordnet sie ja nur einer bestimmten Haltestelle zu. Oder auch mehreren. * Die Position, wo das Verkehrsmittel steht, wenn es an der Haltestelle hält. In den meisten Fällen uninteressant, ausser man möchte komplizierte mehrspurige Haltestellen sauber abbilden. Wenn man abbilden möchte/muss, wie das Verkehrsmittel wieder in den Verkehr einfließt, z.B. wenn die Haltestelle direkt vor einer Kreuzung liegt, kann man das mit den 3 to_* Elementen machen. Normalerweise genauso uninteressant wie die Halteposition, aber eventuell nützlich. Zusammengefasst: Bei einer normalen Bushaltestelle hat man 3 Elemente in der Relation, den Way und 2 Punkte darauf. Wenn man mit dem Renderergebnis nicht zufrieden ist (z.B. weil kein Renderer das Icon neben die Straße setzt), braucht man noch einen Punkt. Wenn man Zubehör einzeichnet kann man das auch direkt zuordnen. cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Bach über(!) Brücke
Hi, ich hab da nen Bach, der per Brücke einen Graben überquert. Osmarender rendert die Brücke nicht, was tun? Einfach ignorieren? Oder soll ich lieber den Graben als tunnel:yes taggen? (Würde das überhaupt gerendert werden?) Mal ganz davon abgesehen, dass in osmarender drain breiter als stream gerendert wird... ;( cu Henry PS: http://www.openstreetmap.org/?lat=49.35259lon=8.65724zoom=17layers=0BTT ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
