Re: [Talk-de] Wald , Gebüsch, Urwald, Hecken u sw.; natural=wood / l anduse =forest
micha ruh schrieb: Als total falsch empfinde ich die gleichzeitige Verwendung beider Tags, da dies eine sinnlose Redundanz darstellt. Das sehe ich in mehrfacher hinsicht anders. Ohne redundanzen könnten wir wahrscheinlich bald einpacken (das ist wie mit der sprache). (Schon mal einen Wald ohne Holz gesehen?) Das sehe ich überhaupt nicht so. wood ist einfach erstmal nur eine grobe näherung. Mittelfristig müssen wir anstelle von wood verfeinerungen verwenden (nadel-, laub-, mischwald etc.) Es wäre auch sinnvoll, schonungen oder kahlstellen durch windbruch zu kennzeichnen. Nach meinem empfinden sind derartige aufforstungsstellen wiederhin forest, auch wenn da momentan nicht viel wächst, aber bei natural würde ich gern etwas wie weihnachtsbäume oder lichtung oder felsen eintragen. Ich finde es auch nicht gut, dass jedes Land eine Seite mit abweichenden 'Local Tagging Schema' erstellt anstatt auf die beiden oben verlinkten Seiten zu verweisen. Ja, nationale besonderheiten sollten in einen eigenen namensraum verlagert werden. - bitte keine Änderungen / Aufräumen (EditWar) in der OSM Datenbank an bestehenden Wäldern bis eine möglichst breit unterstützte Einigung gefunden ist. Das wird sich kaum durchsetzen lassen. Ein recht des erstbearbeiters gibt es im web20 nicht... -- Karl Eichwalder ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Wald , Gebüsch, Urwald, Hecken u sw.; natural=wood / l anduse =forest
Hallo, m.E. ist natural=wood überall da, wo Bäume stehen (egal ob das jetzt ein forstwirtschaftlich genutzter Wald, ein Park, ein Zoo, ein Friedhof, ein Industriegelände, oder sonstwas ist). Das landuse=forst würde dann eben dazu kommen, wenn der Wald forstwirtschaftlich genutzt ist (wobei mir eigentlich keine Anwendung einfällt, wo diese Information wirklich interessant ist). Mit dieser Argumentation wäre dann natural=wood der Standard für Wälder. Viele Grüße Jürgen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Wald, Gebüsch, Urwald, Hecken us w.; natural=wood / landuse=forest
micha ruh schrieb: Hallo Mapper, ich weiss es ist ein viel diskutiertes (heisses) Thema, aber ich muss es ansprechen, da sich momentan ein Karten- und Wiki-EditWar etabliert (hat). Ich finde das landuse=forest / natual=wood Thema auch ein ziemlich lästiges. In meinen Augen liegt die Ursache in der Empfehlung hier in Deutschland alles als natural=wood zu taggen, wogegen die eigentliche Definition bedeutet, dass ein Deutschland ca. 95% der Waldflächen landuse=forest sein müsste, von ein paar wenigen naturbelassenen Wäldern in Naturschutzgebieten abgesehen. (Das ist so ein Thema, wo man als Landbewohner sagt: Typisch Städter - kaum sehen die einen Baum denken sie das wäre alles 100% Natur) Als Mapper steht man dann vor der Gewissensentscheidung auf welche Art man es falsch machen soll. In meinen Augen würde es reichen mal klar zu sagen, dass in Deutschland ein Wald normalerweise immer landuse=forest ist. Und wer bei einem Stück genau weiß, dass es tatsächlich ein naturbelassener Wald ist, der darf auch mit natural=wood taggen. Ich habe in den vergangenen Monaten große Teile der Schwäbischen Alb anhand der Landsat Bilder mit Wäldern versorgt und ich habe mich dabei an die umliegenden Flächen angepaßt, da ich bewußt KEINEN Edit-War heraufbeschwören wollte. Im Regelfall ist das dann landuse=forest gewesen. Inzwischen sind aber einige Wälder auf natural=wood geändert, da speziell die Region um Stuttgart eher ein Anhänger der natural=wood fraktion war. Ich habe keine Lust da alles hin und her zu ändern, auch wenn ich natural=wood für inhaltlich falsch halte. Ich finde aber ziemlich dämlich, wenn Flächen mit natural=wood UND mit landuse=forest getaggt werden. Beides sind Tags die den Landuse anzeigen. Was soll ein Renderer jetzt daraus machen? Er wählt irgendeines der beiden Tags aus - aber das ist doch keine Lösung sondern ein oberfauler Kompromiss. Wenn man hier wirklich was verbessern will, dann wäre es in meinen Augen noch nett Laubwälder, Nadelwälder und Mischwälder zu unterscheiden. Ich orientere mich bei meinem persönlichen OSM Ziel an der gängigen Wander- und Freizeitkarten, und da ist so was üblich. Wir sind in OSM zwar besser was die Kategorisierung der Wege betrifft aber bei den Wäldern kann man mit einer normalen Wanderkarte mehr anfangen. Gruß, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Wald, Gebüsch, Urwald, Hecken us w.; natural=wood / landuse=forest
Ich finde das landuse=forest / natual=wood Thema auch ein ziemlich lästiges. In meinen Augen liegt die Ursache in der Empfehlung hier in Deutschland alles als natural=wood zu taggen, wogegen die eigentliche Definition bedeutet, dass ein Deutschland ca. 95% der Waldflächen landuse=forest sein müsste, von ein paar wenigen naturbelassenen Wäldern in Naturschutzgebieten abgesehen. Mich interessieren naturbelassene Wälder und bewirtschaftete im internationalen Vergleich. Gruß, Stephan. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Wald , Gebüsch, Urwald, Hecken u sw.; natural=wood / l anduse =forest
Thomas Hieber schrieb: Im prinzip hast du recht, aber... In meinen Augen würde es reichen mal klar zu sagen, dass in Deutschland ein Wald normalerweise immer landuse=forest ist. Und wer bei einem Stück genau weiß, dass es tatsächlich ein naturbelassener Wald ist, der darf auch mit natural=wood taggen. beides widerspricht sich nicht. Naturbelassener wald wäre auch mit einem landuse einzutragen, nur halt etwas wie landuse=urwald oder landuse=naturschutzgebiet. Ich habe keine Lust da alles hin und her zu ändern, auch wenn ich natural=wood für inhaltlich falsch halte. Ist nicht falsch, aber nur die halbe miete. Ich finde aber ziemlich dämlich, wenn Flächen mit natural=wood UND mit landuse=forest getaggt werden. Beides sind Tags die den Landuse anzeigen. Was soll ein Renderer jetzt daraus machen? Er wählt irgendeines der beiden Tags aus - aber das ist doch keine Lösung sondern ein oberfauler Kompromiss. Noe, hängt eben davon, was für eine karte du erstellen willst: flächennutzungsplan oder eine karte der naturräume... -- Karl Eichwalder ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Wald , Gebüsch, Urwald, Hecken u sw.; natural=wood / l anduse =forest
Würdet ihr natural=water auch nur für Wildwasser nehmen?!? ;-) M.E. sind natural und landuse zwei orthogonale Konzepte. natural - wie sieht das Gelände aus. landuse - wofür wird das Gelände verwendet. Daher sind die Tags auch nicht redundant. Nur die Beschreibung im Wiki ist halt ein bisschen doof... Jürgen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Waldteile mit Namen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 HI Mailingliste, hab da eine Frage: Und zwar hab ich hier einen Wald (den Seewald um genau zu sein).. Dieser besteht aus kleinen Teilen, die verschiedene Namen tragen (da hängen überall im Wald so Schilder 'rum) Meine Frage wäre jetzt, ob ich den Wald in kleine Stücke aufteilen muss, wenn ich diese Namen in die Karte aufnehmen will oder ob es da nicht vl. ne andere Möglichkeit gibt. Gruß aus Friedrichshafen, martin -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIHCNX1BBJXQc9sfwRAkFhAJ4pfCVW8LrsxTwHPyltGslqHa3PhQCfa0sU hwblmlc7M9NEG4hGiVLxoCI= =lOeD -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] neues Worldfile vom 30.4.08
Hallo Holger, Holger Issle schrieb: Vektorkarte am Mann... nur die Schnitte an den Kachelgrenzen stören doch gewaltig. Gibts da Hoffnung, daß das noch besser wird? Kann man da irgendwie unterstützen? Es gibt Hoffnung, im Moment müssen nur noch ein paar (massive) Bugs aus dem Programm, die verhindern, dass ich das schonmal testweise veröffentlichen kann. Hilfe brauchen wir hier eigentlich nicht, danke. Die meiste Hilfe wäre für mich jetzt ein schneller Internetzugang, vorallem der Upload, 6000er DSL ist halt doch ziemlich schnarchlahm, wenns um dei Upload geht. -- Viele Grüße Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Helgoland überflutet
Hallo, ein ähnliches Problem versuche ich in Thailand zu lösen: http://www.informationfreeway.org/?lat=9.118lon=99.276zoom=12 ich habe schon temporäre Punkte in die Küste eingebaut, so daß eine Bucht in die blauen Quadrate reichte, dann wurde es richtig gerendert, sobald ich die Punkte dann aber wieder löschte sah es wieder aus wie früher. Wie kann man solche Fehler, da gibt es noch viele mehr, beheben? Gruß Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Waldteile mit Namen
Hallo, Meine Frage wäre jetzt, ob ich den Wald in kleine Stücke aufteilen muss, wenn ich diese Namen in die Karte aufnehmen will natural=wood ist doch für nodes und areas. Wenn Du also nur den Namen sehen willst sollte es reichen einen Node mit natural=wood und name=... zu setzen. Die Grenzen sieht man dann natürlich nicht, dafür müßtest Du ihn in einzelne areas aufteilen. Ob die Renderer das dann so machen ist die nächste Frage, habe ich nicht getestet. Gruß Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Bach über (!) Brücke
Am Samstag, den 03.05.2008, 00:20 +0200 schrieb Karl Eichwalder: Wenn das so wichtig ist, dann pinsel einfach etwas wood, farm oder land über den uferbereich. Oder warte, bis das Mapnik-ergenis vorliegt... Ich denke schon, dass man das irgendwie direkt in die Engine einbauen sollte, alles Andere wäre nämlich nur Pfusch. ___ 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
[Talk-de] 2 Anmerkungen zu JOSM und Ubuntu 8.04
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Da ich wie viele andere vielleicht auch Ubuntu benutze und natürlich auch kürzlich die neue Version gezogen habe, hab ich noch 2 Anmerkungen bezüglich JOSM. Ersteinmal finde ich gut, dass es jetzt ein Paket von JOSM in den Repositories gibt, das man über den Paketmanager installieren kann. Leider ist die Version schon wieder ziemlich alt, die es dort gibt und einige Sachen funktionieren noch nicht so, wie beim josm-latest direkt von der OSM-Seite. Da ich aber ziemlich bequem bin, fände ich es toll, wenn man den updatezyklus des paketes an den des josm-latest anpasst oder ist das von Ubuntu abhängig? Ich kenn mich da leider nicht so genau aus. Klärt mich auf. Die nächste Anmerkung habe ich schonmal gemacht und bezieht sich nochmal auf Firefox3 und dem Yahoo WMS plugin. Ich hab schon alles mir mögliche probiert, aber es ließ sich nicht überzeugen zu funktionieren. Gibts diesbezüglich schon Fortschritte? Grüße Christoph -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIHFuTRg5oWO2lGuMRAgj5AJ9BD6kHRHJ7XbWUsKZVoGE54x4HtgCeOhZu H92WLakErVwhxwi0l9mGaxI= =uhwr -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Bach über(!) Brücke
Henry Loenwind [EMAIL PROTECTED] wrote: ich hab da nen Bach, der per Brücke einen Graben überquert. Bei Kanälen gibt es solche Dinge ja häufiger. Das berühmteste sollte das hier sein: http://geggus.net/gmaps/gmaps-osm-fs.html?lat=52.303440474272755lon=8.92613410949707zoom=15maptype=map_mapnik Wie man sieht rendert Mapnik die Brücke halbwegs korrekt. Das rendering von Flüssen ist derzeit IMO noch eine der unschönsten Seiten von Osmarender. Sven -- I'm a bastard, and proud of it (Linus Torvalds, Wednesday Sep 6, 2000) /me is [EMAIL PROTECTED], http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Bach über(!) Brücke
Frank Jäger [EMAIL PROTECTED] wrote: Man bräuchte vielleicht so 3 - 4 Abstufungen der Breite statt nur 2. IMO bräuchte man bei Flüssen einen optionalen Parameter für die Breite, den die Renderer dann berücksichtigen könnten. Gruss Sven -- Osama bin Laden might wish to destroy America, but America is too big for him; he cannot do it. Bush may really do it. (Richard M. Stallman) /me is [EMAIL PROTECTED], http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] 2 Anmerkungen zu JOSM und Ubuntu 8.04
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christoph Wagner wrote: | Ersteinmal finde ich gut, dass es jetzt ein Paket von JOSM in den | Repositories gibt, das man über den Paketmanager installieren kann. | Leider ist die Version schon wieder ziemlich alt, die es dort gibt und | einige Sachen funktionieren noch nicht so, wie beim josm-latest direkt | von der OSM-Seite. | Da ich aber ziemlich bequem bin, fände ich es toll, wenn man den | updatezyklus des paketes an den des josm-latest anpasst oder ist das von | Ubuntu abhängig? Ich kenn mich da leider nicht so genau aus. Klärt mich auf. Was in den offiziellen Ubuntu-Repos landet, hängt von denen ab, es gibt allerdings die möglichkeit eigene Repositories anzulegen, die man dann in apt einbinden kann und deshalb direkt von denen updaten kann. mfg jacko. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIHEmybCPVS12dTK4RArtPAJ0Rxd9Qq9kNqH0ni8+vkn6kJu7K6gCgh4Lx 2Piu5bXAf8f7kza/76OJC8g= =5kgg -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] osmarender: Unechte Kreuzungen
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? 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). Das liegt einfach daran, dass Strassen im Rendering eine gewisse Breite haben, was sich ja nun nicht vermeiden läßt. Und die Breite der B535 in diesem Rendering ist halt größer als der Abstand vom Ende der Sackgasse zur Mitte der B535. Allgemein werden Strassen in Karten breiter eingezeichnet, als sie wirklich sind, weil man sonst nichts mehr erkennen kann. 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. Du hast jetzt die Wahl: Entweder läßt Du es, wie es ist und hoffst darauf, dass der Renderer sowas irgendwann mal kann oder Du machst im JOSM die Sackgasse künstlich kürzer. Beides keine optimalen Lösungen... 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. Jochen -- Jochen Topf [EMAIL PROTECTED] http://www.remote.org/jochen/ +49-721-388298 ___ 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! Ein Workaround für Ubuntu 8.04 ist Firefox 2 zusätzlich zu installieren und diesen für JOSM zu verwenden. Das Paket heißt firefox-2. Danach muss man in .josm/preferences die folgende Zeile ywms.firefox=firefox durch ywms.firefox=firefox-2 ersetzen. Jochen -- Jochen Topf [EMAIL PROTECTED] http://www.remote.org/jochen/ +49-721-388298 ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jochen Topf schrieb: Hi! Ein Workaround für Ubuntu 8.04 ist Firefox 2 zusätzlich zu installieren und diesen für JOSM zu verwenden. Das Paket heißt firefox-2. Danach muss man in .josm/preferences die folgende Zeile ywms.firefox=firefox durch ywms.firefox=firefox-2 ersetzen. Jochen Ja is schon klar. Ich frag mich eigentlich die ganze Zeit, wozu man überhaupt den firefox braucht. Also ich meine mir ist schon klar wie das funktioniert - mir gehts mehr darum, warum josm nicht die Bilder direkt vom Yahooserver ziehen kann. Gibts da wieder lizenzrechtliche Probs oder is es eher der Programmieraufwand, der dem im Wege steht? Grüße Christoph -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIHHP5Rg5oWO2lGuMRAiOKAJ9HWNycnIRX2J3OshMFW8sAh5Ot0ACgg31/ 2vBfT11UOhBnHQgj0csiGmE= =PuUj -END PGP SIGNATURE- ___ 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] Bushaltestellen
ich wundere mich gelegentlich ein bisschen, wie schnell manche hier gut strukturierte Vorschläge abbürsten. Dass überhaupt Relations für Buslinien gebraucht werden, ist (dachte ich zumindest) seit einiger Zeit Konsens, sonst müsste man diese ja wieder über bestehende Wege doppelt drüberzeichnen (von Ausnahmen abgesehen, wo Busse spezielle Busspuren nutzen). Der Vorschlag hörte sich zwar ein bisschen kompliziert an, war aber bei näherem Hinsehen ziemlich einfach und lediglich optional kompliziert, wenn man z.B. eine komplexe Situation mit vielen Haltestellen etc. abzubilden hat. 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? wozu? wenn man den way einzeichnen will, dann als highway=service oder so, und gut is... relation, wozu? nee, nicht highway=service, sondern bestehenden Weg in die Relation einbinden (s.o., und vorausgesetzt, der Bus hält an einer normalen Straße), sonst zeichnet man alles doppelt und im Extremfall hundertfach (bei hundert Buslinien an einer Haltestelle ;-) ) * Die Position der Haltestelle am Way. Klar, irgendwo muss sie ja sein. ein node, entsprechend getaggt. ganz genau * 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. ein weiterer key/value eintrag zu dem haltestellen-node. oder ergibt sich auch aus der route, die die haltestellen verbindet. wie soll sich das auf einer normalen Straße (ein way für beide Richtungen) aus der Richtung ergeben, vor allem, welche Richtung ohne Relation? Jedenfalls sinnvoll, die Richtung anzugeben. Übrigens sind Bushaltestellen selten genau gegenüber, sondern meist versetzt weil platzsparend. Wer mehr Infos unterbringen m?chte hat noch: * Die Position, wo das Icon hin soll per Hand. im normalfall die position des nodes. PER HAND (optional!) * 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. wozu? meinetwegen kann man das zeug alles eintragen, aber wozu eine zuordnung? Diese Dinge gehören meiner Meinung nach auch nicht primär in die Relation, d.h. sie sollten als Nodes eigenständig erfasst oder als weitere Keys / Attribute an den Haltestellennode gepackt werden. Falls eigenständig wäre es wichtig, diese ebenfalls in die Relation zu packen. Eine weiter verschachtelte Lösung wäre hier auch: Relation für die Haltestelle, die alle Features enthält (Bänke, Automaten, Dach, behindertengerecht, Haltepunkt des Fahrzeugs, etc.), diese Relation wiederum Bestandteil der Relation Buslinie, diese Bestandteil der Relation Busverkehr in XY-Stadt, diese Bestandteil der Relation ÖPNV in XY-Stadt) * 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. uninteressant, richtig. ausser man möchte komplizierte ... Warum so schnell dagegen? Muss man sicher auf dem Land für den Bus nicht nutzen / verwenden. Ist ja optional. Aber in einer Großstadt am zentralen Busbahnhof will man sowas definitiv haben (zumindest haben können). Kostet den Rest der Welt ja nichts, wenn es dort nicht genutzt und daher auch nicht verwendet wird. 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. unnoetig. verstehe ich auch nicht ganz, wozu man das braucht. die Busse werden ja nur auf Straßen fahren. Diese Straßen (bzw. Teilabschnitte davon) sind Bestandteil der Relation. Dadurch ergibt sich doch zweifelsfrei, wo der Bus langfährt, oder? 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. fuer mich ist eine haltestelle ein node, wenn noch ein automat oder sowas rumsteht, dann entsprechend mehrere. alles andre halte ich
Re: [Talk-de] Helgoland überflutet
Hallo Dimitri, Am Samstag, 3. Mai 2008 schrieb Dimitri Junker: ein ähnliches Problem versuche ich in Thailand zu lösen: http://www.informationfreeway.org/?lat=9.118lon=99.276zoom=12 ich habe schon temporäre Punkte in die Küste eingebaut, so daß eine Bucht in die blauen Quadrate reichte, dann wurde es richtig gerendert, sobald ich die Punkte dann aber wieder löschte sah es wieder aus wie früher. Wie kann man solche Fehler, da gibt es noch viele mehr, beheben? In Informationfreeway gibt es unten links eine Tastenbelegungs-Hilfe. l soll für Land stehen, s für Sea. Die funktionieren, glaube ich, nur auf Zoom-Level 12, und geben soweit ich mich erinnere (vielleicht korrigiert mich jemand der es besser weiß?) dem Osmarender Hints, wie der Hintergrund von Tiles (ohne Küstenlinie?) zu rendern ist. Ich habe die beiden Tiles mal mit l gekennzeichnet. Mal sehen, ob das wirkt ... Viele Grüße, -- Holger Schoener ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Helgoland überflutet
Hallo, @Frederik: Könntest du mal schauen, was da los ist? Ist notiert, aber gerade sitze ich in London und hacke mit den anderen am API 0.6 ;-) http://wiki.openstreetmap.org/index.php/OSM_Protocol_Version_0.6 Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] API 0.6
Frederik Ramm schrieb: Hallo, @Frederik: Könntest du mal schauen, was da los ist? Ist notiert, aber gerade sitze ich in London und hacke mit den anderen am API 0.6 ;-) http://wiki.openstreetmap.org/index.php/OSM_Protocol_Version_0.6 Wenn Ihr grad über das API 0.6 diskutiert, denkt ihr bitte auch dran, eine Möglichkeit zu schaffen über das API alle Nodes und Wege aus einem Area abzufragen, inclusive der gelöschten? Ich habe in der bisherigen API Doku nichts gefunden, was da passt (oder ich habe nich gut genug gesucht). Ideal wäre eine Abfrage, die alle Objekte liefert, die irgendwann in ihrem Lifecycle einmal in den angegebenen Area waren, sonst können Elemente unauffällige gelöscht werden, indem die Nodes irgendwo in den Pazifik verschoben werden. Gruß, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Parkspuren
Wie sollte man eigentlich seitlich von der Straße liegende Parkspuren taggen? Bei uns hier ist das so, dass rechts von der Fahrbahn auf einer Straßenseite eine erhöhte Spur ist, die zum Parken gedacht ist. Die einzelnen Parkbuchten sind nicht abgetrennt. Danke schonmal. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Bessere Luftaufnahmen
Gibt es denn irgend eine Möglichkeit, an bessere Luftaufnahmen zu kommen, die man dann dazu nutzen kann, min. Flüsse oder wichtige Gebäude sowie Sportplätze ordentlich abzuzeichnen, ohne dass alles von Wolken bedeckt ist? Straßen will ich eh manuell per GPS holen. Danke! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] API 0.6
Thomas Hieber schrieb: Wenn Ihr grad über das API 0.6 diskutiert, denkt ihr bitte auch dran, eine Möglichkeit zu schaffen über das API alle Nodes und Wege aus einem Area abzufragen, inclusive der gelöschten? Ich habe in der bisherigen API Doku nichts gefunden, was da passt (oder ich habe nich gut genug gesucht). Ideal wäre eine Abfrage, die alle Objekte liefert, die irgendwann in ihrem Lifecycle einmal in den angegebenen Area waren, sonst können Elemente unauffällige gelöscht werden, indem die Nodes irgendwo in den Pazifik verschoben werden. Da ja gerade fleißig diskutiert wird Potlatch auf die API umzustellen wird das sowieso nötig sein, da sonst dessen revert-Funktion nicht mehr funktionieren würde. Andererseits könnte das obsolet werden wenn die Changesets kommen. Ich schicke herzliche Grüße an die Themse und wünsche produktives Arbeit. Bin gespannt was ihr so ausknobeln werdet. Grüße, Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Parkspuren
André Reichelt schrieb: Wie sollte man eigentlich seitlich von der Straße liegende Parkspuren taggen? Bei uns hier ist das so, dass rechts von der Fahrbahn auf einer Straßenseite eine erhöhte Spur ist, die zum Parken gedacht ist. Die einzelnen Parkbuchten sind nicht abgetrennt. 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? Grüße, Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] API 0.6
Am Samstag, 3. Mai 2008 18:53:55 schrieb Sven Grüner: Thomas Hieber schrieb: [...] Ich schicke herzliche Grüße an die Themse und wünsche produktives Arbeit. Bin gespannt was ihr so ausknobeln werdet. Schließe mich dem an, und danke allen dort für ihr engagierte Arbeit. :-D Gruß Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Parkspuren
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 irgendwie von der Straßenseite abhängig machen. Das könnte man ja mit der Node-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 list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Bessere Luftaufnahmen
Am Samstag 03 Mai 2008 schrieb André Reichelt: Gibt es denn irgend eine Möglichkeit, an bessere Luftaufnahmen zu kommen, die man dann dazu nutzen kann, min. Flüsse oder wichtige Gebäude sowie Sportplätze ordentlich abzuzeichnen, ohne dass alles von Wolken bedeckt ist? Straßen will ich eh manuell per GPS holen. Also so ganz allgemein gesagt, kommt drauf an :-) 1. Ich vermute yahoo-bilder weisst Du? Die sind in manchen Bereichen brauchbar, andernorts viel zu schlecht. 2. Meistens haben Städte/Gemeinden Luftbilder. Die frei zu bekommen wäre eine politische Entscheidung, entsprechend müsste man rangehen. Ob das in Deutschland für eine politisierung taugt, kann ich nicht einschätzen, es gibt einige Gemeinden in anderen Ländern, die hochqualitative Luftbilder unter Public Domain verfügbar machen. 3. Selber machen? Stichworte wären hierfür Drohnen, Quadrocopter etc. -- Hanno Böck Blog: http://www.hboeck.de/ GPG: 3DBD3B20 Jabber/Mail:[EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] 2 Anmerkungen zu JOSM und Ubuntu 8.04
Am Samstag 03 Mai 2008 schrieb Christoph Wagner: Da ich wie viele andere vielleicht auch Ubuntu benutze und natürlich auch kürzlich die neue Version gezogen habe, hab ich noch 2 Anmerkungen bezüglich JOSM. Ersteinmal finde ich gut, dass es jetzt ein Paket von JOSM in den Repositories gibt, das man über den Paketmanager installieren kann. Leider ist die Version schon wieder ziemlich alt, die es dort gibt und einige Sachen funktionieren noch nicht so, wie beim josm-latest direkt von der OSM-Seite. Da ich aber ziemlich bequem bin, fände ich es toll, wenn man den updatezyklus des paketes an den des josm-latest anpasst oder ist das von Ubuntu abhängig? Ich kenn mich da leider nicht so genau aus. Klärt mich auf. Naja, der Updatezyklus von josm-latest ist fast täglich :-) Bei Ubuntu ist es üblich, neue Features nur mit major-releases einzuführen und dazwischen nur security und wichtige bugfixes einzupflegen. Wobei wir da evtl. auch beim Thema josm + releases wären, ich wär ja dafür, ab und an mal ein josm rauszuhauen, von dem man sagt dass er etwas stabiler als der daily-snapshot ist... (ich spreche im übrigen als Maintainer der Gentoo-Pakete) -- Hanno Böck Blog: http://www.hboeck.de/ GPG: 3DBD3B20 Jabber/Mail:[EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Bessere Luftaufnahmen
Am Samstag, den 03.05.2008, 19:24 +0200 schrieb Hanno Böck: 3. Selber machen? Stichworte wären hierfür Drohnen, Quadrocopter etc. Ich habe einen :) . Aber leider ohne Kamepaundmit max. 30 Metern flughöhe. Aber wenn wer aus der Nähe Crailsheim mit Quadrocopter hier mitliest... ___ 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
On Saturday 03 May 2008 15:51:41 Jochen Topf wrote: Hi! Ein Workaround für Ubuntu 8.04 ist Firefox 2 zusätzlich zu installieren und diesen für JOSM zu verwenden. Das Paket heißt firefox-2. Danach muss man in .josm/preferences die folgende Zeile ywms.firefox=firefox durch ywms.firefox=firefox-2 ersetzen. Jepp, danke, tut wieder. Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Bessere Luftaufnahmen
André Reichelt [EMAIL PROTECTED] wrote: Gibt es denn irgend eine Möglichkeit, an bessere Luftaufnahmen zu kommen, die man dann dazu nutzen kann, min. Flüsse oder wichtige Gebäude sowie Sportplätze ordentlich abzuzeichnen Nun ja, es gibt eine einfache _technische_ Möglichkeit das mit Google Earth zu machen. Google Earth kann selbstgezeichnete Linien und Polygone im inzwischen sogar standardisierten KML Format abspeichern. Dieses wiederum kann man mit Hilfe der osmlib in Eine osm-Datei konvertieren, die josm lesen kann. Ich selbst nutze dieses Verfahren aufgrund der unklaren Rechtslage nur für Gebäudeumrisse und Gewässer, nicht jedoch für Straßen. Leider schweigen sich die Lizenzbedingungen von Google Earth über die Verwendbarkeit von Material, das mit Hilfe der Software erstellt wurde aus. Man muss sich seien Rechtsauffassung zu diesem Thema also wohl oder übel selber zusammenreimen. Ziemlich eindeutig ist für mich die Tatsache, dass Google mir die freie Verwendung selbsterstellter Daten durch die in der Software eingebauten Funktion erlaubt. Schon deshalb, weil die Lizenzbedingungen ja kein explizites Verbot enthalten mit Hilfe der Software erstellte Daten anderweitig zu verwenden. Üblicherweise ist das abspeichern von selbsterzeugten Daten mit Hilfe einer Software ja ganz gewöhnliche Nutzung der selben, von deren Legalität man zunächst mal ausgehen kann. Möchte mir ein Softwarehersteller eine solche Nutzung explizit nicht erlauben, dann muss er das in die Lizenzbedingungen reinschreiben, wenn er die Funktion trotzdem in sein Programm einbaut. Gruss Sven -- and on the third day he rebooted into Linux-1.3.84 (Linus Torvalds, Easter Kernel Release 1996) /me is [EMAIL PROTECTED], http://sven.gegg.us/ on the Web ___ 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
On Sat, May 03, 2008 at 04:17:29PM +0200, Christoph Wagner wrote: Ja is schon klar. Ich frag mich eigentlich die ganze Zeit, wozu man überhaupt den firefox braucht. Also ich meine mir ist schon klar wie das funktioniert - mir gehts mehr darum, warum josm nicht die Bilder direkt vom Yahooserver ziehen kann. Gibts da wieder lizenzrechtliche Probs oder is es eher der Programmieraufwand, der dem im Wege steht? 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. Jochen -- Jochen Topf [EMAIL PROTECTED] http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] osmarender: Unechte Kreuzungen
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: Zuerst zeichnet der Renderer eine schwarze dicke Linie entlang der Strasse und darüber dann eine etwas dünnere farbige Linie. Der Effekt ist dann eine farbige Linien mit einem schwarzen Rand auf beiden Seiten. Genauer: Der Renderer zeichnet zuerst alle schwarzen Linien und dann alle farbigen drüber. Nur dann klappt es nämlich an den Kreuzungen richtig. Daraus ergeben sich in der Regel ganz gut aussehende Karten, aber es gibt jede Menge Fälle, in denen es nicht ganz so rauskommt, wie man gerne möchte. 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. :-) Jochen -- Jochen Topf [EMAIL PROTECTED] http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Zahnarzt taggen
Hallo. Ich bin noch recht neu hier und hab erst heute meinen GPS-Logger (WBT 201) bekommen :) Wie soll ich eine Zahnarztpraxis taggen? Ich hab jetzt vorläufig mal amenity=doctor;dentist genommen. Im Wiki hab ich da nichts zu gefunden. mfg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Bessere Luftaufnahmen
Am Samstag, 3. Mai 2008 20:05:14 schrieb Sven Geggus: [...] Üblicherweise ist das abspeichern von selbsterzeugten Daten mit Hilfe einer Software ja ganz gewöhnliche Nutzung der selben, von deren Legalität man zunächst mal ausgehen kann. Möchte mir ein Softwarehersteller eine solche Nutzung explizit nicht erlauben, dann muss er das in die Lizenzbedingungen reinschreiben, wenn er die Funktion trotzdem in sein Programm einbaut. Die Frage welche mit der schwammigen GoogleEarth Lizenz einhergeht ist ja die Frage nach einem abgeleiteten oder einem eigenständigen Werk. Sollte die kognitive Abstraktion, welche für das Abzeichnen der reinen Orthofots ja durchaus vorhanden sein muss, für die Schöpfungshöhe eines eigenständigen Werkes reichen, sollte die vorhandene Lizenz dem nicht im Wege stehen. Sollte die Schöpfungshöhe jedoch nicht für ein eigenständiges Werk ausreichen, dann werden wieder die Googlelizenzbedingungen wichtig. Leider habe ich bisher im Internet so rein gar nichts zum Thema abgeleitetes Werk (Derived work) und Fotos gefunden. Außer dem Artikel in der englischen Wikipedia[1]. Wobei dort als Beispiel ein Foto zu sehen ist, welches ganz klar aus mehreren Teilen originalen Bildmaterials besteht. Man man man, was bricht mich dieses ganze Urheberrechts- und Lizenzzeugs an. Für mich sind eigentlich alle Erzeugnisse menschlichen Denkens und Handelns auf in Jahrtausenden angesammelten Erfahrungen und Erkentnissen beruhende abgeleitete Werke, und als solche nur unter das Urheberrecht der Allgemeinheit zu stellen. ;-) [1] http://en.wikipedia.org/wiki/Derived_work Gruß Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Bessere Luftaufnahmen
Hallo Stefan Am Samstag, 3. Mai 2008 21:03:10 schrieb Stefan Seifert: Hallo, ich hatte vor einiger Zeit mal beim Landesvermessungsamt Sachsen angefragt, ob wir die Luftbilder des WMS Servers verwenden dürfen. Nach mehrmaligem Schriftwechsel mit Erläuterungen und Vorschlägen zur Kennzeichnung der abgezeichneten Daten erhielt ich leider folgende Antwort: Az.: 34-292/07 Nutzung von Geodatendiensten der oberen Vermessungsbehörde Ihre Nachricht vom 05.03.2008 (Email) Sehr geehrter Herr Seifert, eine Erlaubnis zur Vektorisierung der freien WMS-Deinste der oberen Vermessungsbehörde des Freistaates Sachsen mit dem Ziel, die so gewonnenen Geometrien in das Produkt OpenStreetMap einzupflegen wird nicht erteilt. Zur Begründung: Das Produkt OpenStreetMap unterliegt einer permanenten Veränderung. Die Erteilung einer Erlaubnis zur Vervielfältigung der Daten des Geodatendienstes Und hier sehe ich in meiner laienhaften Rechtsauffassung absolut keine Vervielfältung der Daten. Vervielfältigung wäre in meinen Augen exakt dann gegeben, wenn du das Orthophoto komplett oder in Teilen zur Verfügung stellen würdest. setzt voraus, dass Urheberrechte dauerhaft eindeutig und nachvollziehbar für den Nutzer kenntlich gemacht werden Und hier ist wieder die Frage ob eine Vektorisierung dieser Daten, welches zweifelsohne eine kognitive Abstraktion erfordert, nicht dazu führt, dass kein abgeleitetes, sondern ein eigenständiges Werk entsteht. und die vervielfältigten Geometrien wegen des Vertrauens in eine amtliche Kartengrundlage nicht mehr beliebig verändert werden dürfen. Dies ist in vorliegendem Produkt nicht gegeben. Das finde ich eine sehr abenteuerliche Argumentation. Ersteller der vervielfäligten Geometrien wärest du, und keine Behörde. So lange du das Vektorisieren nicht komplett Algorithmierbar durchziehen kannst, sehe ich da keine Vervielfältigung von amtlichen Werken. Und überhaupt. was bestehen sie denn auf eine Kennzeichnung - ohne dies hätten sie das Problem nicht. *SCNR* Na ja, bin ja mal gespannt. was mir meine Thüringer auf die Anfrage bzgl. des WMS antworten werden. Bisher war der Emailkontakt sehr nett, wenn auch etwas schleppend. Zumindest habe ich die von mir vertretene Ansicht eines eigenständigen Werkes beim Vektorisieren der Orthophotos vorsichtshalber in meine Argumentationsstruktur der Anfrage vorab eingebaut. ;-) Gruß Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Zahnarzt taggen
Moin, Ich bin noch recht neu hier herzhaft willkommen :) . und hab erst heute meinen GPS-Logger (WBT 201) bekommen :) Glückwunsch. Schickes Teil. Wie soll ich eine Zahnarztpraxis taggen? Ich hab jetzt vorläufig mal amenity=doctor;dentist genommen. Im Wiki hab ich da nichts zu gefunden. Momentan gibt es amenity=hospital amenity=pharmacy [...] IMO wird es darauf hinauslaufen dass es irgendwann eine eigene Kategorie health oder so gibt, in den wir dann anfangen die Einträge etwas filigraner zu sortieren: health=hospital health=pharmacy health=dentist health=... Wahrscheinlich wäre es das beste wenn ein paar Leute einfach anfingen das so zu machen. Beste Grüße, ce ___ 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] Software um GPS-Trecks aufzuzeichnen??
Moin, Ich hab das N800, ohne internes GPS, hab mir eine Nokia GPS Maus dazu gekauft, die ich per bluetooth verbinde. Bin mehr als zufrieden damit! die externe Maus ist auch beim N810 empfehlenswert... :) . Gruß, ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Nokia N8xx/N770 Users: Welche Software?
Moin, Navit verwende ich wenn ich jmd. OSM zeige - So sieht OSM als Vektordaten aus - Routing funktioniert auch Schade eigentlich, denn Navit ist ein cooles Stück Software. Leider neigt es auf dem ARM zum abnippeln. Außerdem hat es noch arge Probleme mit dem gpsd zu kommunizieren. Das sind aber IMO Kinderkrankheiten. Allerdings müsste mal jemand mit genug Ahnung von der Materie in den Code schauen. [...] Habe auch schon die Webcam versucht, als Digicam zu missbrauchen um Straßenschilder aufzunehmen, war dann aber, durch die schlechte Qualität bedingt, doch ein Flop. ein zusätzliches Problem ist die Anordnung der Digicam beim n810 Bilder lassen sich damit nur blind machen, da das Display und die Cam auch der gleichen Geräteseite sind. Es gibt da ein Programm das sich gpscam nennt. Kann angeblich Bilder erzeugen in denen die GPS-Position schon in die EXIF-Tags eingebaut ist, was lästiges Nachreferenzieren vermeidet. Dass die Kamera im Gegensatz zum Vorgänger nicht mehr gedreht werden kann ist natürlich ein Verlust. Wenn man sich aber mit dem Rücken zum Straßenschild stellt und dann eine Aufnahme über Kopf macht geht's. Allerdings bin ich mit meiner Diktiergerätemethode schneller. Gruß, ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Bessere Luftaufnahmen
Andreas Jacob [EMAIL PROTECTED] wrote: Man man man, was bricht mich dieses ganze Urheberrechts- und Lizenzzeugs an. Für mich sind eigentlich alle Erzeugnisse menschlichen Denkens und Handelns auf in Jahrtausenden angesammelten Erfahrungen und Erkentnissen beruhende abgeleitete Werke, und als solche nur unter das Urheberrecht der Allgemeinheit zu stellen. ;-) Im Prinzip sehe ich das genauso, aber man hat ja eine gewisse Loyalität gegenüber bestehenden Gesetzen :) Sven -- In the land of the brave and the free, we defend our freedom with the GNU GPL (Richard M. Stallman on www.gnu.org) /me is [EMAIL PROTECTED], http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Bessere Luftaufnahmen
Hallo Andreas, der Kontakt mit dem sächsischen Landesvermessungsamt war ebenfalls nett, aber träge. Die Diskussion lief eigentlich darauf hinaus, wie die Daten zu kennzeichnen sind, um die Herkunft zu zeigen. Der Vorschlag war, den Daten einen Kommentar Hergestellt unter Verwendung der [EMAIL PROTECTED] sachsen mit freundlicher Genehmigung des Landesvermessungsamtes Sachsen anzufügen. Das wäre für mich kein Problem gewesen, aber ich konnte natürlich nicht zusichern, dass der Kommentar nicht entfernt wird und das die entstehende Karte nur nichtkommerziell verwendet wird. Falls Du ein possitives Ergebniss in Thüringen erreichst, melde dich unbedingt mal bei mir, dann könnte ich es noch mal versuchen... Gruß Stefan Andreas Jacob schrieb: Hallo Stefan Am Samstag, 3. Mai 2008 21:03:10 schrieb Stefan Seifert: Hallo, ich hatte vor einiger Zeit mal beim Landesvermessungsamt Sachsen angefragt, ob wir die Luftbilder des WMS Servers verwenden dürfen. Nach mehrmaligem Schriftwechsel mit Erläuterungen und Vorschlägen zur Kennzeichnung der abgezeichneten Daten erhielt ich leider folgende Antwort: Az.: 34-292/07 Nutzung von Geodatendiensten der oberen Vermessungsbehörde Ihre Nachricht vom 05.03.2008 (Email) Sehr geehrter Herr Seifert, eine Erlaubnis zur Vektorisierung der freien WMS-Deinste der oberen Vermessungsbehörde des Freistaates Sachsen mit dem Ziel, die so gewonnenen Geometrien in das Produkt OpenStreetMap einzupflegen wird nicht erteilt. Zur Begründung: Das Produkt OpenStreetMap unterliegt einer permanenten Veränderung. Die Erteilung einer Erlaubnis zur Vervielfältigung der Daten des Geodatendienstes Und hier sehe ich in meiner laienhaften Rechtsauffassung absolut keine Vervielfältung der Daten. Vervielfältigung wäre in meinen Augen exakt dann gegeben, wenn du das Orthophoto komplett oder in Teilen zur Verfügung stellen würdest. setzt voraus, dass Urheberrechte dauerhaft eindeutig und nachvollziehbar für den Nutzer kenntlich gemacht werden Und hier ist wieder die Frage ob eine Vektorisierung dieser Daten, welches zweifelsohne eine kognitive Abstraktion erfordert, nicht dazu führt, dass kein abgeleitetes, sondern ein eigenständiges Werk entsteht. und die vervielfältigten Geometrien wegen des Vertrauens in eine amtliche Kartengrundlage nicht mehr beliebig verändert werden dürfen. Dies ist in vorliegendem Produkt nicht gegeben. Das finde ich eine sehr abenteuerliche Argumentation. Ersteller der vervielfäligten Geometrien wärest du, und keine Behörde. So lange du das Vektorisieren nicht komplett Algorithmierbar durchziehen kannst, sehe ich da keine Vervielfältigung von amtlichen Werken. Und überhaupt. was bestehen sie denn auf eine Kennzeichnung - ohne dies hätten sie das Problem nicht. *SCNR* Na ja, bin ja mal gespannt. was mir meine Thüringer auf die Anfrage bzgl. des WMS antworten werden. Bisher war der Emailkontakt sehr nett, wenn auch etwas schleppend. Zumindest habe ich die von mir vertretene Ansicht eines eigenständigen Werkes beim Vektorisieren der Orthophotos vorsichtshalber in meine Argumentationsstruktur der Anfrage vorab eingebaut. ;-) Gruß Andreas ___ 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] 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] Bessere Luftaufnahmen
Hallo Stefan Am Sonntag, 4. Mai 2008 00:04:58 schrieb Stefan Seifert: Die Diskussion lief eigentlich darauf hinaus, wie die Daten zu kennzeichnen sind, um die Herkunft zu zeigen. Der Vorschlag war, den Daten einen Kommentar Hergestellt unter Verwendung der [EMAIL PROTECTED] sachsen mit freundlicher Genehmigung des Landesvermessungsamtes Sachsen anzufügen. Wobei ich ja der Auffassung bin, dass die [EMAIL PROTECTED] Sachsen bestimmt eine bereits vektorisierte Generalisierung der Orthophotos ist. Das wäre für mich kein Problem gewesen, aber ich konnte natürlich nicht zusichern, dass der Kommentar nicht entfernt wird und das die entstehende Karte nur nichtkommerziell verwendet wird. Das ist leider das von mir schon angesprochene Problem der CC-by-sa, unter der die Daten von osm liegen. Mit non-commercial wären wesentlich mehr Daten bei den Vermessungsämtern zu holen. Obwohl ich, trotzdem ich ein überzeugter Debiannutzer bin, auch eher die BSD Lizenzen bevorzuge, welche weitaus mehr Rechte einräumen. Falls Du ein possitives Ergebniss in Thüringen erreichst, melde dich unbedingt mal bei mir, dann könnte ich es noch mal versuchen... Viel Hoffnung habe ich ja nicht, aber diese stirbt ja bekanntlich zuletzt. ;-) Aber ich geb auf jeden Fall bescheid. Auch wenn sich die Damen und Herren vom Bundesamt in FFM melden. Gruß Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Bessere Luftaufnahmen
Am Samstag, den 03.05.2008, 19:24 +0200 schrieb Hanno Böck: / 3. Selber machen? Stichworte wären hierfür Drohnen, Quadrocopter etc. / Ich habe einen :) . Aber leider ohne Kamepaundmit max. 30 Metern flughöhe. Aber wenn wer aus der Nähe Crailsheim mit Quadrocopter hier mitliest... Was beschränkt Dich auf 30m? Reichweiter der Fernsteurung? Mir fehlt eine geignete Kamera - Flughöhe ansonsten so weit das Auge reicht - 100m dürften hier realistisch sein(ohne GPS-Steuerung). Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Bessere Luftaufnahmen
Am Samstag, 3. Mai 2008 23:50:56 schrieb Sven Geggus: Andreas Jacob [EMAIL PROTECTED] wrote: Man man man, was bricht mich dieses ganze Urheberrechts- und Lizenzzeugs an. Für mich sind eigentlich alle Erzeugnisse menschlichen Denkens und Handelns auf in Jahrtausenden angesammelten Erfahrungen und Erkentnissen beruhende abgeleitete Werke, und als solche nur unter das Urheberrecht der Allgemeinheit zu stellen. ;-) Im Prinzip sehe ich das genauso, aber man hat ja eine gewisse Loyalität gegenüber bestehenden Gesetzen :) Wenn ich mir vorstelle welche Effekte es haben könnte, wenn sämtliches Wissen frei zugänglich wäre, und von jedem genutzt werden könnte, dann muß ich irgendwie sogleich an die 2 aneinandergeketteten Anwälte auf dem Meeresgrund denken. Von denen man ja kolportiert, dass sie ein guter Anfang wären ... ;-) Apropos Anwälte. Auf dem letzten CCC Kongress (24C3) war doch m.E. ein Anwalt mit einem Vortrag bzgl. Opensource Lizenzen dabei. Vielleicht könnte man den ja mal ganz unverbindlich bzgl. des Abzeichnes der Luftbilder befragen, wie der das sieht. Werde mal das ftp Verzeichnis der Videomitschnitte durchfursten, und dieses Vorhaben mal abwägen. Gruß Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Bessere Luftaufnahmen
Andreas Jacob [EMAIL PROTECTED] wrote: Ein anderer Punkt ist das schon so häufig diskutierte Urheberrecht beim Abzeichnen von Luftbildern. Viele Bundesländer bieten ja momentan ihr eigenes WMS mit Orthofotos an. Vielle davon erreichbar über den Deutschlandviewer [1], oder sogar direkt, dann aber meist ein GK Bezugssystem und kein EPSG:4326, wie es momentan das WMS Plugin beherrscht. Das ist bis hierher aber ein rein technisches Problem, dass sich mit Hilfe eines dazwischengeschalteten UMN-Mapservers als WMS-Proxy lösen lässt. Sven -- /* * Wirzenius wrote this portably, Torvalds fucked it up :-) */(taken from /usr/src/linux/lib/vsprintf.c) /me is [EMAIL PROTECTED], http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Nokia N8xx/N770 Users: Welche Software?
Moin, Welche -OpenStreetMap relevante- Software benutzt ihr und wie benutzt ihr sie? ich habe die Kiste noch nicht so lange. Es gibt eine Menge freier Software dafür. Allerdings kann momentan noch keine davon mein GPSr-Gerät ersetzen. = Steuerung, GPS-Ort = Einer der verwirrendsten Punkte auf dem Gerät. Hier kann man sehr komfortabel zwischen dem internen Empfänger und einem Bluetoothgerät umstellen. Es hat allerdings etwas gedauert bis ich verstand dass GPS aktivieren weder den Treiber läd noch gpsd startet. Mir ist nicht ganz klar für was die Checkbox gut sein soll. Auch für was die Option Speicherort gut sein soll erschließt sich mir nicht so ganz. = Karte = Die kommerzielle Applikation, die dem Gerät beiliegt, hatte ich anfangs gleich mal deinstalliert, mittlerweise aber zum Anguggen wieder 'drauf. Cool finde ich die Onscreen-Zoombuttons und dass das Zoomen animiert ist. Was mich ein wenig verblüfft hat war die Tatsache dass in dem Kartenmaterial teilweise Wege enthalten sind die so schlecht sind, dass ich die nichtmal als tracktype=grade5 in unsere Datenbank hauen möchte. Anderswo fehlen dann aber wieder asphaltierte landwirtschaftliche Wege zuhauf. = Navit = Momentan mein absoluter Favorit, weil ich zur Laufzeit sehr einfach über eine XML-Datei steuern kann was ich auf der Karte sehen will und wie es dargestellt werden soll. Außerdem kann Navit schonmal ein wenig nach Straßen suchen und beherrscht brauchbares Routing. Nachteile: * Zur Sprachausgabe kann man momantan wohl nur flite verwenden, das aber nur angelsächsische Phonetik beherrscht. Ist eigentlich kein Navitproblem, sondern ein Plattformproblem. Ich müsste mal schauen was es sonst noch so für Sprachsynthesesoftware gibt, die sich auf dem Gerät zur Mitarbeit überreden ließe. * Momentan neigt Navit noch zu Crashes und (Hauptnachteil) hat auf dem Gerät Probleme mit dem gpsd zu kommunizieren. Navit weiß also häufig nicht wo es gerade ist, obwohl ein GPS-Fix vorliegt. * Wenn eine Applikation GPS-Daten benötigt dann muss sie selbst dafür sorgen dass der Treiber geladen und der gpsd hochgezogen wird (läuft via libgpsmgr). Navit kann das derzeit noch nicht, weshalb man gleichzeitig eine andere GPS-Applikation starten muss um GPS nutzen zu können. = Maemo-Mapper = Ein äußerst cooles Stück Software mit so ziemlich allen Features die man sich so wünschen kann. Vielleicht kommt da später noch eine etwas bessere Bedienung über den Touchscreen dazu. Nachteile entstehen IMO durch die Verwendung vorgerenderter Kartenkacheln: * Will man mehr als ein Stadtviertel mit auf die Reise nehmen, braucht man eine Menge Speicherplatz und zudem Geduld, um sich alles 'runterzuladen was man braucht. Kein Vergleich zu dem Navit'schen Vectordaten, wo ich mir einfach Europa komplett konvertiere und auf das Gerät werfe. * An Kacheln in hohen Zoomwerten braucht man aufgrund des benötigten Speicherplatzes und der nötigen Bandbreite ebenfalls nicht zu denken. Für eine Innenstadt mag es reichen, aber für eine 100km-Radtour taugt es nicht * Maemo-Mapper verwendet eine sqlite3Datenbank (wogegen nichts einzuwenden ist) und stopft dahinein auch die Kartenkacheln (was beim Laden der Kacheln ganz schön Performance kostet). * Karten lassen sich aufgrund der Datenbank nur direkt über das Tablet laden. Ich würde es cool finden wenn ich die Kacheln mit meinem Desktoprechner besorgen und dann auf das Tablet kopieren könnte. Klar, auch da kann man sich sicher was bauen was die sqlite-Datei auf dem Desktop erstellt, aber das ist halt umständlich * Wenn man nicht selbst rendert, muss man sich mit den vorhandenen Renderstilen zufrieden geben. Alles in allem gefällt mir Maemo-Mapper ziemlich gut, aber die Verwendung von Kacheln birgt konzeptuell ein paar Schwachstellen. Allerdings auch Vorteile: Man kann Kacheln der bekannten kommerziellen Map-Webdienste mitnehmen! = Mapper = Ein Maemo-Mapper-Fork mit ein paar ziemlich coolen Features, die das Mappen erleichtern helfen: Große Buttons um POIs zu erstellen und die Möglichkeit, Sprachaufnahmen zu starten. Muss ich noch intensiver testen. Die POIs wandern scheinbar allesamt in eine sqlite-Datei, und einen GPX-Export habe ich noch nicht gefunden. Ich muss mal forschen, ob man die POIs exportieren kann oder ob man per sqlite an die Datenbank 'ranmuss. = NaviPOWM = NaviPOWM ist Navit nicht unähnlich. Eine OSM-Datei wird wie bei Navit in ein binäres Vektorformat gewandelt, so dass man auch größere Gebiete mitnehmen kann. Ich muss allerdings zugeben noch nicht so detailliert 'reingesehen zu haben, da ich hauptsächlich an Patches für Navit gebastelt habe. Kommt noch. = QtGPS = Ein kleines Tool das nur den aktuellen Status des GPS-Empfanges anzeigt (ähnlich wie die Sat-Anzeige an GPSr-Empfängern). Manchmal ganz nützlich wenn man wissen will ob tatsächlich kein Fix vorliegt oder nur Navit gerade nicht will. :) = Gebabbel = Graphisches Frontend für gpsbabel. Ich find's cool dass es (mit
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
