Re: [Talk-de] Wanderkarte wieder online
Hi! Michael Buchberger schrieb: Bei der Berechnung der Kacheln scheint in der höchsten Zoomstufe was schiefgelaufen zu sein. http://topo.geofabrik.de/?zoom=15lat=49.20083lon=8.10313layers=BT Hier ist ein Streifen zu sehen der nicht berechnet wurde. Danke für den Hinweis. Der Update läuft noch. Gelegentlich schlägt ein Teilupload fehl, aber das sollte sich selbst reparieren. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Namen von Relationen
Wäre es dann nicht wünschenswert im JOSM, ganz oben, ein optionales feld note für die allgemeine bezeichnung einzubauen - dann ist die gefahr der falsch zuweisung minimiert. als vorlage könnte die zeile im hochladefenster (changeset) sein. gruß Jan :-) Tobias Knerr schrieb: Martin Koppenhoefer schrieb: 1. sollte man den Namen angeben, auch wenn es eher nur ein Identifier ist? 2. gibt's hierfür ein besseres Tag als name? Nimm note. Dürfte für den Zweck, über den Sinn der Relation zu informieren, passen. Wenn eine Relation kein name-Tag hat, zeigt zumindest JOSM stattdessen auch den Wert des note-Tags in der Relationenliste an. Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map - Kompromissvorschlag
Mario Salvini schrieb: Also gibts keinen Fall wo speedzone und maxspeed gleichzeitig Sinn machen. Das heißt aber dann auch, dass speedzone unnötig ist, und wir alles mit maxspeed abbilden können. (siehe meine Argumentation weiter oben Das ist richtig! Meinen Kompromissvorschlag hatte ich ja nur deshalb erstellt, damit -zumindest übergangsweise- beide Tags parallel laufen können und die alten Programme mit rein numerischen maxspeed-Werten versorgt werden können. Je länger ich mir das überlege, ist es aber wahrscheinlich doch besser, gleich alles nur in maxspeed zu packen. Die nötige Vorverarbeitung für die alten Programme hält sich ja in Grenzen. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] neuer OSB Service
On Sun, May 10, 2009 at 11:20:05PM +0200, Mitja Kleider wrote: Hallo, diese Nachricht ging an talk. Ich möchte nicht nochmal alles übersetzen, deshalb ist der Rest meiner Nachricht auf Englisch. One last thing: my goal was to get better query results and more access to the data. I do not intend to spend a lot of time on developing this service. You are always welcome to send patches, maybe it is also possible to share access to the repository. And in the worst case: forking is easy. Hi, ich habe auf der maxspeed karte angefangen das OSB zeugs neu zu bauen (client/javascript teil) weil ich es schoen faende wenn man das OSB zeugs einfach integrieren koennte in jegliche karte - manchmal wuerde es sinn machen bugs von der OpenCycleMap oder von der Maxspeed map aufzumachen. daher waere es schoen wenn man von den osb kisten einfach einen javascript blob nachladen koennte der dann sich schoen integriert. Das zeugs was auf der maxspeed map laeuft ist noch nicht perfekt, aber anstatt fuer das nachladen einfach nen javacript teil in die dom hinzuzufuegen laedt der mit den OpenLayers sachen via AJAX JSON daten nach ... Realisiert habe ich das derzeit durch einen proxy auf der kiste der die daten einmal von dem code in ein JSON ueberfuehrt ... (Auch weil ich via AJAX aka XMLHttpRequest nicht von beliebigen kisten zeugs laden kann) Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkarte (ComputerTeddy): Konf likt zwischen Grenzen und Straßen
Moin, Harald Kirsch schrieb: ist auf dem Gerät in Teilen nicht mehr zu sehen, und zwar offenbar dort, wo die Grenze mitten auf der Straße verläuft. Ist das bekannt? Ist das ein Problem der Kartendaten oder der Garminkarte? Die Daten sind falsch, da ist auf dem gleichen Weg einmal der Highway und die Grenze getaggt, hier kann mkgmap nur eines auswerten. Bitte also korrigieren. -- Viele Gruesse Computerteddy ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Namen von Relationen
Hallo! Tobias Knerr schrieb: Martin Koppenhoefer schrieb: 1. sollte man den Namen angeben, auch wenn es eher nur ein Identifier ist? 2. gibt's hierfür ein besseres Tag als name? Nimm note. Dürfte für den Zweck, über den Sinn der Relation zu informieren, passen. Euch ist schon klar, daß wir damit anfangen uns hier richtig gut zu verzetteln? Bisher waren die Begriffe Name und Note klar - dachte ich zumindest und habe zumindest nie ein Element gesehen, wo das anders benutzt wurde als ich es auch setzen würde. - Name = Name - Note = interner Hinweis für Mapper, häufig sowas wie fixme oder mit längerem Text Jetzt bekommen wir ein Mischmasch aus: - Name_für_die_Karte - Note_als_Workaround_Name_für_Mapper - Note als Kommentarfeld für alles Während der Editor richtig bemerkt nur zur Eingabe eines Namens einlädt. Wäre es nicht sinnvoller, das Problem an der Wurzel anzupacken? Deshalb nochmal die Frage: Warum erscheint der Name einer Relation auf der Karte? Relationen an sich werden nicht gerendert, der Name muß durch einen zusätzlichen Mechanismus auf die Karte kommen, was in diesem Fall ein Fehler ist. Sollten wir in diesme Fall nicht lieber den Fehler beheben anstatt die Bedeutung von häufig verwendet Tags durcheinanderzuwürfeln? Das klappt jetzt in diesem Fall, aber: - wieviele andere Relationen müßten jetzt auch von name auf note geändert werden? - Wieviele neue Relatioen werden umgeändert müssen? - Was ist mit echten Notes mit Kommentarcharakter und Langtext? Einfach löschen? Oder ein neues Tag Note_note einführen? :-) - Wie lange funktioniert dieses Flickwerk bevor das nächste Problem es eh zu Fall bringt? - Wir taggen nicht für den Renderer? Aber wir verschmieren jetzt die Bedeutung lange benutzter Tags um diesen Effekt einzudämmen? Das ist meiner Meinung nur das erste Problem mit übereifriger Übernahme von Tags von Relationen. Wir sollten uns die Ursache ansehen, nicht an den Symptomen herumfummeln. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map - Kompromissvorschlag
Hallo. Am Sonntag 10 Mai 2009 23:26:34 schrieb Mario Salvini: Nochmal: Sind durch das Zeichen innerhalb geschlossener Ortschaften bestimmte Geschwindigkeiten über 50 km/h zugelassen, so gilt das für Fahrzeuge aller Art !!! [...] konsequenterweise gilt an dieser Stelle aber dann auch keine speedzone=in_town, weil ja schließlich alle Begrenzungen aufgehoben worden sind. Ja, aber grade das ist doch das beste Beispiel, warum hier *BEIDE* Informationen unglaublich wichtig sind. Außerorts wird keiner auf die Idee kommen, bei einem maxspeed=70 noch ein maxspeed:hgv=60 dazu zu schreiben, ohne dass es ein passendes Lkw-bezogenes Schild gibt. D.h. eine 70 im roten Kreis bedeutet (für Lkw) innerorts etwas anderes als außerorts. Je länger ich mir das überlege, desto wichtiger erscheint mir, dass wir den Status innerhalb geschlossener Ortschaft sogar völlig unabhängig von der Geschwindigkeit erfassen (also nicht *speed*zone sondern etwas anderes). Denkt nur an so Dinge wie die Erlaubnis zu hupen oder (auch wenn es da viele Ausnahmen gibt) die Verwendung des Fernlichts. Gruß, Bernd -- Die Dunkelheit ist echt. Das Licht aber scheint nur so. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] neuer OSB Service
Hallo. Am Montag 11 Mai 2009 08:43:02 schrieb Florian Lohoff: manchmal wuerde es sinn machen bugs von der OpenCycleMap oder von der Maxspeed map aufzumachen. Ack. Später macht es sogar am meisten Sinn, wenn man Bugs von der openstreetmap.org-Hauptseite aufmachen kann. Aber das geht halt erst, wenn man den Code vorher getrennt davon stabil am Laufen hat. Gruß, Bernd -- Faulheit ist die Mutter aller Erfindungen. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Namen von Relationen
Hi! Frederik Ramm schrieb: Nop wrote: Die Frage ist eher, warum dieser Name auf der Karte landet. Irgendwie scheint der Mapnik-Style da sehr grosszuegig zu sein. Beim Oesterreich-Import wurden sehr viele Strassen absichtlich ohne Highway-Tag importiert, aber mit Name, und auf der Mapnik-Karte erscheinen dann Strassennamen ohne Strassen ;-) Über diese Importdaten bin ich auch schon gestolpert, dort sitzen die Namen aber direkt auf ungetaggten Ways und die Mapnik-DB-Struktur ist in der Tat anfällig für Einzeltags, die in unerwünschtem Zusammenhang nochmal auf der Karte auftauchen. In unserem Fall wandert aber der Name von einer Relation, die überhaupt nicht direkt gerendert wird, auf Ways. Ich fürchte hier haben wir das erste Problem durch unerwünschte Vererbung von einer Relation. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] FreieTonne - Sektoren und Farben von Leuchtfeuern - wie ermitteln?
Hallo allerseits, Bei unserem freien Seekartenprojekt können wir seit neuestem auch die Sektoren und Farben von Leuchtfeuern eintragen und darstellen. Wir haben fröhlich an diesem Feature gebastelt, und jetzt, wo es funktioniert, frage ich mich, wie die Daten eigentlich erhoben werden können. Bei der Position ist das ja einfach. Man fährt ran, macht auf dem GPS klick, notiert sich Farbe, Kennung usw, und alles ist gut. Besagte Sektoren (Abstrahlwinkel) und Farben der Leuchtfeuer sind aber sehr schwer zu ermitteln. Man müßte einmal rumfahren, und befährt dann auch Sektoren, vor denen der Leuchttum ja warnt. Gefährlich. Die einzig sichere Quelle wäre jetzt nach meiner Kenntnis die Seekarte. Und da wollen wir ja nicht abschreiben. Meine Frage also: Kennt jemand eine lizenzrechtlich zu OSM passende Quelle für diese Angaben? Oder hat jemand eine Idee, wie diese sonst erhoben werden könnten? Diese Frage ist sicherlich auch für die anderen laufenden Seekartenprojekte wichtig. Oder haben die Kollegen da schon eine Idee, die sie mit uns teilen wollen? ;-) Beste Grüße aus Berlin JJ www.FreieTonne.de - Neue Tonnen sind aus Plastik. Sie sparen wirklich überall. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Namen von Relationen
On Mon, 11 May 2009, Nop wrote: Wäre es nicht sinnvoller, das Problem an der Wurzel anzupacken? Deshalb nochmal die Frage: Warum erscheint der Name einer Relation auf der Karte? Weil er ein Objekt beschreibt, das auf der Karte dargestellt wird - nämlich ein Multipolygon. Das ist Sinn und Zweck der Sache und kein Fehler. Wie sonst willst Du Waldgebiete, Teiche und andere Multipolygone mit Namen versehen? Relationen an sich werden nicht gerendert, Wer behauptet so einen Unsinn? Na klar werden Relationen gerendert. Wir rendern Routen, Grenzen, Multipolygone, Abbiegeeinschränkungen, ... der Name muß durch einen zusätzlichen Mechanismus auf die Karte kommen, was in diesem Fall ein Fehler ist. Nein. Sollten wir in diesme Fall nicht lieber den Fehler beheben anstatt die Bedeutung von häufig verwendet Tags durcheinanderzuwürfeln? Das klappt jetzt in diesem Fall, aber: - wieviele andere Relationen müßten jetzt auch von name auf note geändert werden? Name bezeichnet überall in OSM einen Namen eines physischen Objekts. Wenn Du eine Bezeichnung für interne Informationen (eben z.B. Relationen) haben willst, dann sind note, comment u.ä. dafür genau richtig. Aus diesem Grund zeigt JOSM die auch als Bezeichnung für Relationen in der Übersicht an. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] neuer OSB Service
Bernd Wurst schrieb: Hallo. Am Montag 11 Mai 2009 08:43:02 schrieb Florian Lohoff: manchmal wuerde es sinn machen bugs von der OpenCycleMap oder von der Maxspeed map aufzumachen. Ack. Später macht es sogar am meisten Sinn, wenn man Bugs von der openstreetmap.org-Hauptseite aufmachen kann. Aber das geht halt erst, wenn man den Code vorher getrennt davon stabil am Laufen hat. Hier zu hieß es auf der dev-liste (ich glaub es war TomH) auch, dass man (nachdem die API0.6 stabil läuft) das schon machen würde, aber nicht so gerne auf externe Services ausweicht, die noch nicht einmal vollständig OpenSource sind (bezog sich damals halt nur auf das originale OSB). Wenn also euer Service stabil läuft und OpenSource ist und ihr am besten noch den Code beisteuert, sehe ich gute Chancen, dass es zeitnah auf die Hauptseite kommt. Wir müssen bloß dabei aufpassen, dass es für den Anwender weiterhin so extrem einfach bleibt, wie OSB bis jetzt ist. Es wäre schon gut, wenn es eine Seite gibt, die halbwegs zentral alle wichtigen Bugs anzeigt, so dass der Anwender nicht erst den passenden Service für sein Problem suchen muss. Am besten wäre openstreetbugs.org, weil die Seite schon ziemlich bekannt ist, mit ein paar Optionen und Bugreport auf openstreetmap.org mit einem vergleichbaren Interface, wie wir es jetzt haben. Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] All in One bald ganz Europa
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christoph Wagner wrote: Huhu. Also Webspace kann ich etwas anbieten. MfG, Lars Schimmer - -- - - TU Graz, Institut für ComputerGraphik WissensVisualisierung Tel: +43 316 873-5405 E-Mail: l.schim...@cgv.tugraz.at Fax: +43 316 873-5402 PGP-Key-ID: 0x4A9B1723 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoH3y0ACgkQmWhuE0qbFyOr8gCdHPvG+chsK/hKJCdFMMVEjvGN 85IAoJcU4VL2NL+7Qy0T1lTXvDzaUube =efAm -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] FreieTonne - Sektoren und Farben von Leuchtfeuern - wie ermitteln?
Am Montag 11 Mai 2009 schrieb Jan Jesse: Hallo allerseits, Bei unserem freien Seekartenprojekt können wir seit neuestem auch die Sektoren und Farben von Leuchtfeuern eintragen und darstellen. Wir haben fröhlich an diesem Feature gebastelt, und jetzt, wo es funktioniert, frage ich mich, wie die Daten eigentlich erhoben werden können. Bei der Position ist das ja einfach. Man fährt ran, macht auf dem GPS klick, notiert sich Farbe, Kennung usw, und alles ist gut. Besagte Sektoren (Abstrahlwinkel) und Farben der Leuchtfeuer sind aber sehr schwer zu ermitteln. Man müßte einmal rumfahren, und befährt dann auch Sektoren, vor denen der Leuchttum ja warnt. Gefährlich. Oder hat jemand eine Idee, wie diese sonst erhoben werden könnten? ich kenn mich ja jetzt nicht so wirklich in der materie aus, aber wuerde es nicht reichen, bis an den rand des erlaubten sektors ranzufahren, also da wo die farbe wechselt? das duerfte doch noch nicht im gefahrenbereich sein... ansonsten rumfliegen mit nem modellhubschrauber, quadrocopter... ;-) signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Diskussionen dokumentieren
Hi, im Prinzip habe ich dieses Anliegen schon seit mindestens einem halbem Jahr, manchmal mehr, manchmal weniger. In letzter Zeit gab es ja öfters mal sehr lange (Tagging-)Diskussionen, aktuelles Beispiel ist die Maxspeed-Map oder zuvor die Diskussion über Ausfahrten. Mangels Zeit und Interesse verfolge ich diese Diskussionen meist höchstens am Anfang über ~5 Beiträge. Dennoch wäre ich sehr am Ergebnis der Diskussion, auch wenn es keine Lösung des Problems gab, interessiert. Bei kürzeren Diskussionen kann man später bei Interesse mal schnell nachlesen und sie lassen sich meist recht leicht mit einer Suchmaschine finden, da der Titel auf die Beiträge passt.. Bei langen Diskussionen bleibt das Ergebnis aber oft ohne weiteren Nutzen für den Rest, der die Diskussion nicht verfolgt hat. Ich möchte daher bitten solche langen Diskussionen im Wiki mit einem passenden Titel zu dokumentieren. Einfach einen Link mit dem Anfangsbeitrag aus dem Archiv an den Anfang der Seite und danach eine kurze Zusammenfassung der Diskussion mit Ergebnis. So können andere sich schnell informieren und doppelte Diskussionen bleiben meist erspart. Wenn man dann noch den Link hier in die Diskussion schreibt ergänzen sicher andere auch noch kurz Etwas. Natürlich soll dann nicht im Wiki weiterdiskutiert werden :-) Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkarte (ComputerTeddy): Konf likt zwischen Grenzen und Straßen
Carsten Schwede schrieb: ist auf dem Gerät in Teilen nicht mehr zu sehen, und zwar offenbar dort, wo die Grenze mitten auf der Straße verläuft. Ist das bekannt? Ist das ein Problem der Kartendaten oder der Garminkarte? Die Daten sind falsch, da ist auf dem gleichen Weg einmal der Highway und die Grenze getaggt, hier kann mkgmap nur eines auswerten. Bitte also korrigieren. Hmmm, seit wann ist das verboten? Naja, ist einer der Gründe warum ich in meiner Karte komplett auf Grenzlinien verzichte. ;-) Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] neuer OSB Service
Hallo. Am Montag 11 Mai 2009 10:10:24 schrieb Jonas Krückel: Hier zu hieß es auf der dev-liste (ich glaub es war TomH) auch, dass man (nachdem die API0.6 stabil läuft) das schon machen würde, aber nicht so gerne auf externe Services ausweicht, die noch nicht einmal vollständig OpenSource sind (bezog sich damals halt nur auf das originale OSB). Wenn also euer Service stabil läuft und OpenSource ist und ihr am besten noch den Code beisteuert, sehe ich gute Chancen, dass es zeitnah auf die Hauptseite kommt. So ist der Masterplan. ;-) Allerdings wäre eine frühe Integration für keinen sinnvoll, lieber gut erreichbar und erstmal separat einen Last-Test machen. Prinzipiell ist bei der neuen Variante ja aber sowohl der Code frei als auch die Datenbank täglich aktuell verfügbar. Einer Integration steht also nichts im Wege, es muss nur jemand machen (der es für stabil genug hält). Wir müssen bloß dabei aufpassen, dass es für den Anwender weiterhin so extrem einfach bleibt, wie OSB bis jetzt ist. Es wäre schon gut, wenn es eine Seite gibt, die halbwegs zentral alle wichtigen Bugs anzeigt, so dass der Anwender nicht erst den passenden Service für sein Problem suchen muss. Am besten wäre openstreetbugs.org, weil die Seite schon ziemlich bekannt ist, mit ein paar Optionen und Bugreport auf openstreetmap.org mit einem vergleichbaren Interface, wie wir es jetzt haben. Ich bin gegen irgend eine externe Domain. Eigentlich bin ich sogar gegen eine externe Website an sich. Ich finde das Bugreport-Feature muss man so eingliedern wie den Edit- oder den Export-Tab oben. Einfach als Feature der Hauptseite. Wo sich dann letzten endes die API dafür befindet, ist was anderes. Ich würde dafür spontan bugs.openstreetmap.org benutzen. Aber für den reinen Anwender sollte die Adresse egal sein, bedienbar sollte alles über die normale Website von OSM sein. Gruß, Bernd -- Wer nicht zweifelt muss verrückt sein - Sir Peter Ustinov signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] route=flight
Am Samstag, 9. Mai 2009 13:00:02 schrieb talk-de-requ...@openstreetmap.org: Hi, Auch ich bin der Ansicht, dass persoenliche Daten nicht zu OSM gehoeren. Da bin ich froh das sich diese Erkenntnis als Konsens wohl langsam etabliert. Ich will ja nicht schon wieder das Beispiel mit dem Goldfischglas.. Ist jedoch eine automatische Filterung der Sache dienlich. Wird nicht evtl. zu wenig oder zuviel gefiltert? Gru? Werner -Urspr?ngliche Nachricht- Von: talk-de-boun...@openstreetmap.org [mailto:talk-de-boun...@openstreetmap.org] Im Auftrag von Frederik Ramm Gesendet: Samstag, 9. Mai 2009 04:34 An: Openstreetmap allgemeines in Deutsch Betreff: Re: [Talk-de] route=flight Hi, Carsten Behring wrote: Gibt es eigentlich derartige Erfahrungen in Wikipedia ? Einer Art fon Behandlugn von unn?tzem Wissen. Was passiert wenn ich in Wikipedia einen Artikel reinstelle der in allen Einzelheiten den Inhalt meines Kellers beschreibt ? Irgendwie unn?tz, aber doch wahr. Ich denke, die Community ignoriert es einfach. Nein, die Community wird es loeschen, weil es nicht den Relevanzkriterien entspricht. Diese sollten wir mal aufstellen! Sonst drehen wir uns im Kreis. Die Wikipedia sieht sich nicht als ein Wiki, sondern als eine Enzyklopaedie, und schmeisst rigoros raus, was nicht enzyklopaedisch ist. Was auch dort, glaube ich sinnvoll ist. ?bertragen auf OSM heisst dies aber, dass das Problem auch auf Editor und Renderer Seite gel?st werden muss, und nicht durch Auschluss von Inhalten (in Grenzen). Ich sehe durchaus, dass wir auf Editor-/Rendererseite mehr und besser filtern muessen (Stichwort altes Rom). Trotzdem gehoeren persoenliche Daten m.E. nicht in OSM, wir hatten gerade eben erst die Diskussion um meine persoenlichen Fahrradroutenempfehlungen. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49?00'09 E008?23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] neuer OSB Service
Bernd Wurst schrieb: Hallo. Am Montag 11 Mai 2009 10:10:24 schrieb Jonas Krückel: Wir müssen bloß dabei aufpassen, dass es für den Anwender weiterhin so extrem einfach bleibt, wie OSB bis jetzt ist. Es wäre schon gut, wenn es eine Seite gibt, die halbwegs zentral alle wichtigen Bugs anzeigt, so dass der Anwender nicht erst den passenden Service für sein Problem suchen muss. Am besten wäre openstreetbugs.org, weil die Seite schon ziemlich bekannt ist, mit ein paar Optionen und Bugreport auf openstreetmap.org mit einem vergleichbaren Interface, wie wir es jetzt haben. Ich bin gegen irgend eine externe Domain. Eigentlich bin ich sogar gegen eine externe Website an sich. Ich finde das Bugreport-Feature muss man so eingliedern wie den Edit- oder den Export-Tab oben. Einfach als Feature der Hauptseite. Wo sich dann letzten endes die API dafür befindet, ist was anderes. Ich würde dafür spontan bugs.openstreetmap.org benutzen. Ja, stimmt das ist besser. Ich hatte eine Mail vorher falsch verstanden, ich hatte es so interpretiert, dass es extra Bugs für Maxspeed Map etc. geben soll. Aber da war ja nur von einer Integration des Services die Rede. Daher braucht man dann auch keine Seite, die alle Bugs darstellt, da es ja keine Unterscheidung zwischen den Bugs gibt und eh immer alle dargestellt werden. Schaun wir einfach mal, wie sich das ganze die nächsten Wochen entwickelt und dann kann man ja mal bei TomH anfragen. Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkarte (ComputerTeddy): Konf likt zwischen Grenzen und Straßen
Hallo. Am Montag 11 Mai 2009 11:22:51 schrieb Chris-Hein Lunkhusen: Hmmm, seit wann ist das verboten? Verboten gibt es bei OSM nicht. Aber da in den meisten Fällen ein OSM-Objekt auch ein physisches Objekt beschreibt, ist es halt etwas unüblich, dass eine Objekt zwei Eigenschaften hat (ist eine Straße und ist eine Grenze). Es geht ja nicht um zwei Ways über die selben Nodes sondern um einen way, der highway=* und boundary=* parallel dran hat. Die andere Sichtweise ist natürlich, dass man sagt die Straße *ist* die Grenze. Das ist nicht wirklich falsch und eigentlich auch nachvollziehbar. Nur macht es die Auswertung grundsätzlich schwieriger in dem Sinne, dass man nicht mehr einfach abbilden kann von einem OSM-Objekt auf ein Objekt im Ziel- Datenformat. Man muss Objekte im Zweifel duplizieren und das ist in den meisten Konverter-Ketten bisher nicht so vorgesehen. Gruß, Bernd -- An den Scheidewegen des Lebens stehen keine Wegweiser - Charly Chaplin (engl. Filmkomiker) signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Diskussionen dokumentieren
Moin, 2009/5/11 Jonas Krückel o...@jonas-krueckel.de Ich möchte daher bitten solche langen Diskussionen im Wiki mit einem passenden Titel zu dokumentieren. Einfach einen Link mit dem Anfangsbeitrag aus dem Archiv an den Anfang der Seite und danach eine kurze Zusammenfassung der Diskussion mit Ergebnis. So können andere sich schnell informieren und doppelte Diskussionen bleiben meist erspart. Wenn man dann noch den Link hier in die Diskussion schreibt ergänzen sicher andere auch noch kurz Etwas. +1 von mir. Gerade in letzter Zeit verfolge ich die langen Diskusionen nur sporadisch, da wäre eine kurze 2-3 Sätze Zusammenfassung oder ein Tipp in welchem der mails eine Lösung gefunden wurde wirklich hilfreich. Gruß Jörg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Diskussionen dokumentieren
Hallo, Jonas Krückel wrote: Dennoch wäre ich sehr am Ergebnis der Diskussion, auch wenn es keine Lösung des Problems gab, interessiert. Es ist oft schwer, ein Ergebnis neutral festzuhalten, so dass alle Diskussionsteilnehmer einverstanden sind. Das ist ganz schoen Arbeit, und es besteht die Gefahr, die Du ja schon vorausgesehenhast: Natürlich soll dann nicht im Wiki weiterdiskutiert werden :-) Und in einem so schnell wachsenden und dynamischen Projekt wie OSM kommt erschwerend hinzu, dass etwas, dem heute alle Mailinglistenteilnehmer zustimmen, schon in 1-2 Monaten keine Autoritaet mehr hat - warum sollten sich die bis dahin hinzugekommen mehreren Hundert Mapper an das halten, was irgendwelche Diskutanten lange vor ihrer Zeit auf der Liste beschlossen haben? Was uns heute noch technisch nicht machbar oder unsinnig erscheint, kann morgen durch neue Technologien, und sei es beispielsweise nur vernuenftiges Layering in einem Editor, schon wieder in Frage gestellt werden... Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Namen von Relationen
1. sollte man den Namen angeben, auch wenn es eher nur ein Identifier ist? 2. gibt's hierfür ein besseres Tag als name? Nimm note. Dürfte für den Zweck, über den Sinn der Relation zu informieren, passen. Euch ist schon klar, daß wir damit anfangen uns hier richtig gut zu verzetteln? Bisher waren die Begriffe Name und Note klar - dachte ich zumindest und habe zumindest nie ein Element gesehen, wo das anders benutzt wurde als ich es auch setzen würde. - Name = Name - Note = interner Hinweis für Mapper, häufig sowas wie fixme oder mit längerem Text Jetzt bekommen wir ein Mischmasch aus: - Name_für_die_Karte - Note_als_Workaround_Name_für_Mapper - Note als Kommentarfeld für alles Während der Editor richtig bemerkt nur zur Eingabe eines Namens einlädt. Wäre es nicht sinnvoller, das Problem an der Wurzel anzupacken? Deshalb nochmal die Frage: Warum erscheint der Name einer Relation auf der Karte? Relationen an sich werden nicht gerendert, der Name muß durch einen zusätzlichen Mechanismus auf die Karte kommen, was in diesem Fall ein Fehler ist. Sollten wir in diesme Fall nicht lieber den Fehler beheben anstatt die Bedeutung von häufig verwendet Tags durcheinanderzuwürfeln? Das klappt jetzt in diesem Fall, aber: - wieviele andere Relationen müßten jetzt auch von name auf note geändert werden? - Wieviele neue Relatioen werden umgeändert müssen? - Was ist mit echten Notes mit Kommentarcharakter und Langtext? Einfach löschen? Oder ein neues Tag Note_note einführen? :-) - Wie lange funktioniert dieses Flickwerk bevor das nächste Problem es eh zu Fall bringt? - Wir taggen nicht für den Renderer? Aber wir verschmieren jetzt die Bedeutung lange benutzter Tags um diesen Effekt einzudämmen? Das ist meiner Meinung nur das erste Problem mit übereifriger Übernahme von Tags von Relationen. Wir sollten uns die Ursache ansehen, nicht an den Symptomen herumfummeln. Du hast glaub ich den aktuellen Fall völlig missverstanden. Das Problem ist nicht, dass der Name der Relation gerendert wird, sondern dass Martin den name-Tag dazu missbraucht hat, dem Objekt einen Bezeichner zu geben, um es in der Relationsliste von JOSM besser auffinden zu können (einen Bezeichner, der _nicht_ der Name des Objekts, sondern eine Beschreibung davon ist). Grüße, Marc -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Frage zu OSM-WMS
Hallo liebe Liste, ich frage mich, ob es möglich ist einen OSM-WMS in der Qualität hinzukriegen, wie die OSM-Daten, welche über Mapnik gerendert werden? Es gibt ja den frei zugänglichen OSM-WMS der Wheregroup: http://osm.wheregroup.com/cgi-bin/mapserv?map=/data/umn/osm/osm_basic.map Die Qualität ist ja auch wirklich nicht schlecht, kommt meiner Meinung nach aber nicht an die typischen OSM-Mapnik-Kacheln heran. Kann man diese Qualität überhaupt mit dem UMN MapServer erreichen? Kann man eigentlich Mapnik nutzen um einen WMS auszuliefern, eher nicht, oder? Danke schon jetzt einmal. Viele Grüße, Kai -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] neuer OSB Service
Hallo. Am Sonntag 10 Mai 2009 23:20:05 schrieb Mitja Kleider: [...] Mir ist klar, dass ein OSM-Bugtracker immer einfach bleiben muss, damit ihn die Leute auch nutzen. Was haltet ihr dennoch von folgender Verkomplizierung: Man sollte Reports eine Gewichtung geben können. Sowas wie * falsch eingetragene / veraltete Daten * Kleinigkeit (Straßenname, POI, ...) * fehlende / unvollständige Straße(n) * Sonstiges So dass man als Bug-Hunter sofort entscheiden kann, ob man das ohne Ortskenntnis bzw. ohne GPS-Daten reparieren kann oder nicht. Mich stört immer mal wieder die Flut an Der Weg geht hier noch weiter- Reports, die einfach niemandem was bringen außer demjenigen selbst. Reports bei denen ein Name falsch ist oder ein POI fehlt, kann man ja ohne Probleme überall reparieren ohne sich auszukennen. Wenn man die dann z.B. per Filter separat anzeigen könnte, wär das super. Was denkt ihr darüber? Gruß, Bernd -- Fachbegriffe der Informatik (#354): Firewall mit absolutem Schutz Kommunikationsverhinderungsmodul (Rainer Kersten und Christoph Weber) signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zu OSM-WMS
Kai Behncke schrieb: ich frage mich, ob es möglich ist einen OSM-WMS in der Qualität hinzukriegen, wie die OSM-Daten, welche über Mapnik gerendert werden? Es gibt ja den frei zugänglichen OSM-WMS der Wheregroup: http://osm.wheregroup.com/cgi-bin/mapserv?map=/data/umn/osm/osm_basic.map Die Qualität ist ja auch wirklich nicht schlecht, kommt meiner Meinung nach aber nicht an die typischen OSM-Mapnik-Kacheln heran. Es gibt auch noch diesen WMS-Dienst (für Deutschland) http://osm.omniscale.de/ aber bitte die Nutzungsbedingungen beachten! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkarte (ComputerTeddy): Konf likt zwischen Grenzen und Straßen
Hi, Bernd Wurst schrieb: Die andere Sichtweise ist natürlich, dass man sagt die Straße *ist* die Grenze. Das ist nicht wirklich falsch und eigentlich auch nachvollziehbar. na das halte ich doch aber für gewagt, eine administrative Grenze ist es eher so, dass die Grenze vielleicht in der Mitte der Straße verläuft, aber nicht die Straße selbst die Grenze ist. -- Viele Gruesse Computerteddy ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] FreieTonne - Sektoren und Farben von Leuchtfeuern - wie ermitteln?
Hallo Jan, On Monday 11 May 2009 09:11:53 Jan Jesse wrote: Meine Frage also: Kennt jemand eine lizenzrechtlich zu OSM passende Quelle für diese Angaben? Oder hat jemand eine Idee, wie diese sonst erhoben werden könnten? Unter http://wiki.openstreetmap.org/wiki/DE:Leuchtfeuer#Links findest du den Abschnitt Leuchtfeuerverzeichnis. Dort sind Listen der weltweiten Leuchtfeuer erfasst. Diese Listen stehen unter einer PD-Lizenz . Vorsicht beim Abschreiben ist trotzdem geboten. Die Daten sind teilweise etwas ungenau. Der erste grüne Sektor des Leuchtfeuers Kiel Friedrichsort endet z.B bei 196° statt den 191,5° der übrigen Verzeichnisse. Grüße Olaf ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] US-Behörde befürchtet GPS-Ausfälle
Warten auf Gallileo... http://golem.mobi/0905/67007.html ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] neuer OSB Service
On Sun, May 10, 2009 at 11:20:05PM +0200, Mitja Kleider wrote: I think it would be nice if the service was using the domain openstreetbugs.org (easy to remember). Currently it is available at http://openstreetbugs.schokokeks.org/ Ach ja - es macht keinen sinn ueberhaupt bugs zu laden in zoomlevel 12. Das verwirrt nur - alle bekommt man eh nicht und die bugs verhindern nur das man seine originaere area findet ... Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] US-Behörde befürchtet GPS-Ausfälle
Zitat von Tobias Wendorff tobias.wendo...@uni-dortmund.de: Warten auf Gallileo... http://golem.mobi/0905/67007.html Glonass wird sicher vorher fertig sein. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Namen von Relationen
Dirk Stöcker schrieb: On Mon, 11 May 2009, Nop wrote: Wäre es nicht sinnvoller, das Problem an der Wurzel anzupacken? Deshalb nochmal die Frage: Warum erscheint der Name einer Relation auf der Karte? Weil er ein Objekt beschreibt, das auf der Karte dargestellt wird - nämlich ein Multipolygon. Das ist Sinn und Zweck der Sache und kein Fehler. Wie sonst willst Du Waldgebiete, Teiche und andere Multipolygone mit Namen versehen? Eine Lösung des Problems könnte darin bestehen, Relationen mit einem weiteren Tag zu versehen, welches die Darstellung in der Karte beeinflusst. Ich denke dabei weniger an Tag wie osmarender:renderName sondern eher an eine generelle Bewertung zwischen allgemeinrelevant und interner Verwaltungsbezeichnung. Sollten wir in diesme Fall nicht lieber den Fehler beheben anstatt die Bedeutung von häufig verwendet Tags durcheinanderzuwürfeln? Das klappt jetzt in diesem Fall, aber: - wieviele andere Relationen müßten jetzt auch von name auf note geändert werden? Name bezeichnet überall in OSM einen Namen eines physischen Objekts. Wenn Du eine Bezeichnung für interne Informationen (eben z.B. Relationen) haben willst, dann sind note, comment u.ä. dafür genau richtig. Aus diesem Grund zeigt JOSM die auch als Bezeichnung für Relationen in der Übersicht an. Ich ärgere mich darüber, dass an der Küstenlinie (oft an unpassenden Stellen) Relationsbezeichnungen wie Schleswig-Holstein (Landmasse), Deutschland (Landmasse) oder Kreis Rendsburg-Eckernförde (Landmasse) stehen. Das sind im Grunde keine physischen Objekte, sondern nur Schnittmengen aus Deutschland und dem Inneren der Küstenlinie. Ich finde es trotzdem sinnvoll, der Relation den Namen Deutschland (Landmasse) zu geben und nicht eine namenlose Relation mit einem Kommentar zu versehen. Man braucht nur eine Möglichkeit, diesen Namen als nicht oder weniger darstellungswürdig zu kennzeichnen. Ich kann mir viele Relationen vorstellen, die in die OSM-Datenbank passen und einen Namen haben, der aber nicht in der üblichen Karte auftauchen sollte: Historische Grenzen (vom der mittelalterlichen Staatsgrenze bis zur im letzten Jahr fusionierten Gemeinde, die noch in verschiedenen amtlichen Verordnungen genannt ist), Außengrenze der Schengen-Staaten, Wasserschutzgebiete, alte Bahntrassen, etc. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] US-Behörde befürchtet GPS-Ausfälle
Weiß einer von Euch wie das dann mit unseren Empfängern aussieht - Firmware-Update oder Mülleimer ?? Gruß Jan :-) Matthias Doell schrieb: Zitat von Tobias Wendorff tobias.wendo...@uni-dortmund.de: Warten auf Gallileo... http://golem.mobi/0905/67007.html Glonass wird sicher vorher fertig sein. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zu OSM-WMS
Hi, Kai Behncke wrote: ich frage mich, ob es möglich ist einen OSM-WMS in der Qualität hinzukriegen, wie die OSM-Daten, welche über Mapnik gerendert werden? Ja, es ist immer eine Frage davon, wieviel Ressourcen man zur Verfuegung hat. Grundsaetzlich ist im Mapnik-Lieferumfang ein Python-Skript namens ogcserver enthalten, mit dem Du einen halbwegs brauchbaren WMS hinbekommst - es gibt regelmaessig Erfolgsberichte auf der Mapnik-Liste. Richtig schnell ist das nicht (eher so fuer die interne Anwendung, nicht auf einem oeffentlichen Server). Wenn man den WMS in einem Kachel-Umfeld betreibt, kann man mit Caching viel rausholen (das beweist ja der bereits gepostede Omnicache-Link). Das Caching hat halt auch da sein Ende, wo Du gerne aus einer Vielzahl von Layern waehlen willst oder gar mit SLDs arbeiten. Es gibt ja den frei zugänglichen OSM-WMS der Wheregroup: http://osm.wheregroup.com/cgi-bin/mapserv?map=/data/umn/osm/osm_basic.map Die Qualität ist ja auch wirklich nicht schlecht, kommt meiner Meinung nach aber nicht an die typischen OSM-Mapnik-Kacheln heran. Das ist in gewisser Weise natuerlich auch immer eine Frage der Gewoehnung ;-) Kann man diese Qualität überhaupt mit dem UMN MapServer erreichen? Ich denke, derzeit fuehrt an Mapnik kein Weg vorbei, aber es gibt durchaus ziemlich schoene Mapserver-OSM-Karten, wie zum Beispiel diese: http://mapserverosm.s3.amazonaws.com/parisosm.html Kann man eigentlich Mapnik nutzen um einen WMS auszuliefern, eher nicht, oder? Wir arbeiten in der Geofabrik an einem Apache-Modul, das Mapnik als WMS bereitstellt und so die Nachteile der oben genannten Python-Bastelloesung (subjektiver Eindruck ;-) ueberwindet. Den WMS bieten wir gegen Bezahlung an. Wenn Du mal auf wms.geofabrik.de schaust und dort ein bisschen reinzoomst, siehst Du, dass wir die detaillierten Zoomstufen schon ganz gut hinbekommen; die groben Zoomstufen muessen wir noch etwas verbessern. (Der WMS ist zugangsbeschraenkt, man braucht einen Key, um ihn in ein GIS zu laden, kostenlose Test-Keys gibts aber auf Anfrage.) Wenn wir das Produkt eingefuehrt haben und der Service laeuft, wird unser Apache-Modul-Code auch in die Mapnik-Codebasis mit einfliessen, derzeit haben wir ihn aber noch nicht veroeffentlicht. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] US-Behörde befürchtet GPS-Ausf älle
Jan Tappenbeck schrieb: Weiß einer von Euch wie das dann mit unseren Empfängern aussieht - Firmware-Update oder Mülleimer ?? Tja, das weiß derzeit noch niemand ... glaubt man der ESA-Website [1], wird Galileo mit GPS und GLONASS kompatibel sein. Andersrum Einige Webrecherchen sprechen jedoch davon, dass es wohl hybride GPS/GLONASS-Empfänger gibt. Viele Hersteller bieten heute bereits Updates für Galileo an, also kann man nur hoffen, dass der jeweilige Hersteller auch Firmwares für GLONAS rausgibt und nicht Gewinn mit neuen Produkten machen will. Referenzen: [1] http://www.esa.int/esaCP/SEMBHN8A9HE_Germany_0.html ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Namen von Relationen
Weil er ein Objekt beschreibt, das auf der Karte dargestellt wird - nämlich ein Multipolygon. Das ist Sinn und Zweck der Sache und kein Fehler. Wie sonst willst Du Waldgebiete, Teiche und andere Multipolygone mit Namen versehen? Eine Lösung des Problems könnte darin bestehen, Relationen mit einem weiteren Tag zu versehen, welches die Darstellung in der Karte beeinflusst. Ich denke dabei weniger an Tag wie osmarender:renderName sondern eher an eine generelle Bewertung zwischen allgemeinrelevant und interner Verwaltungsbezeichnung. Nein. Interne Verwaltungsbezeichnung haben im name-Tag überhaupt nichts verloren. Verwendet einfach (wie gehabt) note oder comment, und das Problem ist erledigt. Ich ärgere mich darüber, dass an der Küstenlinie (oft an unpassenden Stellen) Relationsbezeichnungen wie Schleswig-Holstein (Landmasse), Deutschland (Landmasse) oder Kreis Rendsburg-Eckernförde (Landmasse) stehen. Das sind im Grunde keine physischen Objekte, sondern nur Schnittmengen aus Deutschland und dem Inneren der Küstenlinie. Ich finde es trotzdem sinnvoll, der Relation den Namen Deutschland (Landmasse) zu geben und nicht eine namenlose Relation mit einem Kommentar zu versehen. Man braucht nur eine Möglichkeit, diesen Namen als nicht oder weniger darstellungswürdig zu kennzeichnen. Die hat man schon, nämlich im Stylesheet des Renderers. Abgesehen davon heißt das von der Relation bezeichnete Gebiet bestimmt nicht Schleswig-Holstein (Landmasse), sondern das ist eine Beschreibung und ist daher im name-Tag an der falschen Stelle. Ich kann mir viele Relationen vorstellen, die in die OSM-Datenbank passen und einen Namen haben, der aber nicht in der üblichen Karte auftauchen sollte: Historische Grenzen (vom der mittelalterlichen Staatsgrenze bis zur im letzten Jahr fusionierten Gemeinde, die noch in verschiedenen amtlichen Verordnungen genannt ist), Außengrenze der Schengen-Staaten, Wasserschutzgebiete, alte Bahntrassen, etc. Hier gilt das gleiche wie oben: wenn der Betreiber des Renderers alte Bahntrassen anzeigen lassen will, soll er sie ins Stylesheet eintragen, wenn nicht, soll er sie rauslassen. Man muss halt nur sauber zwischen name, comment und note unterscheiden. Grüße, Marc -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] US-Behörde befürchtet GPS-Ausfälle
Zitat von Jan Tappenbeck o...@tappenbeck.net: Weiß einer von Euch wie das dann mit unseren Empfängern aussieht - Firmware-Update oder Mülleimer ?? Je älter desto wahrscheinlicher nur GPS. Zumindest die aktuelleste Blaupunkt/Denso-Chipgeneration (müsste langsam fertig sein) kann auch Glonass/Gallieo. Da wäre nur ein Firmwareupdate nötig. Aber da Blaupunkt ja nur noch OEM-Produkte entwickelt, betrifft das eher die Autohersteller. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Namen von Relationen
Hi! On Mon, 11 May 2009, Nop wrote: nochmal die Frage: Warum erscheint der Name einer Relation auf der Karte? Weil er ein Objekt beschreibt, das auf der Karte dargestellt wird - nämlich ein Multipolygon. Das ist Sinn und Zweck der Sache und kein Fehler. Wie sonst willst Du Waldgebiete, Teiche und andere Multipolygone mit Namen versehen? Genau das tut er nicht. Eine Relation ist nicht einfach ein Objekt auf der Karte, sondern eine Beziehung zwischen Objekten auf der Karte. Ob und wie sich das auf der Karte auswirkt, ist Sache des Renderers. Ob es überhaupt sinnvoll ist, es auf der Karte darzustellen, ist auch nicht so allgemein zu beantworten. Relationen an sich werden nicht gerendert, Wer behauptet so einen Unsinn? Na klar werden Relationen gerendert. Wir rendern Routen, Grenzen, Multipolygone, Abbiegeeinschränkungen, ... Jeder der sich schion mal mit Rendern gebaut hat. Die Relation sind keine physikalischen Objekte und können daher auch nicht selbst gerendert werden. Sie werden ausgewertet, auf andere Objekte angewandt oder erzeugen neue. Aber eine Relation an und für sich ist unsichtbar. der Name muß durch einen zusätzlichen Mechanismus auf die Karte kommen, was in diesem Fall ein Fehler ist. Nein. Doch. :-) bye Nop -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] US-Behörde befürchtet GPS-Ausfälle
Matthias Doell schrieb: Zitat von Jan Tappenbeck o...@tappenbeck.net: Weiß einer von Euch wie das dann mit unseren Empfängern aussieht - Firmware-Update oder Mülleimer ?? Je älter desto wahrscheinlicher nur GPS. Zumindest die aktuelleste Blaupunkt/Denso-Chipgeneration (müsste langsam fertig sein) kann auch Glonass/Gallieo. Da wäre nur ein Firmwareupdate nötig. Aber da Blaupunkt ja nur noch OEM-Produkte entwickelt, betrifft das eher die Autohersteller. Die Frage ist vielleicht auch, ob Geräte diesmal nicht für Gallieo und GLONASS lizenziert sein müssen. Also: Man darf nur ein Logo draufpacken, wenn man auch bestimmte Messergebnisse einhält. Bei GPS konnte ja jeder x-beliebige Hersteller etwas umsetzen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zu OSM-WMS
Hallo, Frederik Ramm schrieb: Ich denke, derzeit fuehrt an Mapnik kein Weg vorbei, aber es gibt durchaus ziemlich schoene Mapserver-OSM-Karten, wie zum Beispiel diese: http://mapserverosm.s3.amazonaws.com/parisosm.html AFAIK sind dies die Mapfiles: http://code.google.com/p/mapserver-utils/source/browse/trunk/ Grüße Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Namen von Relationen
Du hast glaub ich den aktuellen Fall völlig missverstanden. Das Problem ist nicht, dass der Name der Relation gerendert wird, sondern dass Martin den name-Tag dazu missbraucht hat, dem Objekt einen Bezeichner zu geben, um es in der Relationsliste von JOSM besser auffinden zu können (einen Bezeichner, der _nicht_ der Name des Objekts, sondern eine Beschreibung davon ist). Das sehe ich völlig anders. Das Problem ist, daß Nodes und Ways physikalische Objekte sind, aber Relationen Beziehungen zwischen Objekten. Die Beziehung kann, muß aber nicht ein physikalisches Objekt beschreiben. Wie Stephan mit weiteren Beispielen schon dargestellt hat, liegt das Problem darin, stumpf den Namen einer logischen Beziehung oder Gruppierung mit dem von physikalischen Objekten gleichzusetzen. Dieser Schluß ist ungültig. bye Nop -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkarte (ComputerTeddy): Konf likt zwischen Grenzen und Straßen
Carsten Schwede schrieb: Die andere Sichtweise ist natürlich, dass man sagt die Straße *ist* die Grenze. Das ist nicht wirklich falsch und eigentlich auch nachvollziehbar. na das halte ich doch aber für gewagt, eine administrative Grenze ist es eher so, dass die Grenze vielleicht in der Mitte der Straße verläuft, aber nicht die Straße selbst die Grenze ist. Die Daten sind nicht falsch sondern nur chaotisch. Es ist Aufgabe der Applikationen da sinnvoll zu filtern und die Daten aufzudröseln. Dasselbe Problem besteht auch bei Ways, die gleichzeitig als highway=... railway=tram oder natural=coastline boundary=administrative getaggt sind. Und selbst wenn es als zwei übereinanderliegende ways gemappt wird, nur einer von beiden kann in mkgmap gewinnen. ;-) Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Namen von Relationen
Du hast glaub ich den aktuellen Fall völlig missverstanden. Das Problem ist nicht, dass der Name der Relation gerendert wird, sondern dass Martin den name-Tag dazu missbraucht hat, dem Objekt einen Bezeichner zu geben, um es in der Relationsliste von JOSM besser auffinden zu können (einen Bezeichner, der _nicht_ der Name des Objekts, sondern eine Beschreibung davon ist). Das sehe ich völlig anders. Das Problem ist, daß Nodes und Ways physikalische Objekte sind, aber Relationen Beziehungen zwischen Objekten. Die Beziehung kann, muß aber nicht ein physikalisches Objekt beschreiben. Wie Stephan mit weiteren Beispielen schon dargestellt hat, liegt das Problem darin, stumpf den Namen einer logischen Beziehung oder Gruppierung mit dem von physikalischen Objekten gleichzusetzen. Dieser Schluß ist ungültig. Das ist wieder ein anderes Problem, und da stimme ich dir auch zu. Trotzdem ist das, was Martin gemacht hat, ein Missbrauch des name-Tags. Grüße, Marc -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] US-Behörde befürchtet GPS-Ausfäll e
On Mon, 11 May 2009, Jan Tappenbeck wrote: Weiß einer von Euch wie das dann mit unseren Empfängern aussieht - Firmware-Update oder Mülleimer ?? Galileo ist zumindest im LowCost-Bereich hinreichend zu GPS kompatibel, dass Firmware-Updates reichen könnten. GLONASS nutzt ein anderes Verfahren und Empfänger, welche jetzt kein GLONASS können, werden es auch in Zukunft nicht können. In etwa 5 Jahren will GLONASS mehr Kompatibilität zu GPS erreichen, um kombinierte Empfänger zu vereinfachen. Dass allerdings jemand für LowCost-Empfänger Firmwareupdates anbietet halte ich für sehr unwahrscheinlich. Das lohnt sich einfach nicht. Außerdem sind in den nächsten Jahren viele Veränderungen bei der Satellitennavigation zu beachten, so dass neuere Geräte viel leistungsfähiger sein werden. Genauso unwahrscheinlich ist es aus meiner Sicht übrigens, dass im nächsten Jahr mehr als 10 GPS-Satelliten ausfallen werden (die nominelle GPS-Abdeckung umfasst 21 Satelliten, momentan sind es 31). Der Bericht hat allerdings einen wichtigen Hintergrund: Relativ viele der Satelliten sind älter als 10 Jahre (der älteste 19), so dass die Ausfallwahrscheinlichkeit steigt. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map - Kompromissvorschlag
Bernd Wurst schrieb: Hallo. Am Samstag 09 Mai 2009 10:05:13 schrieb Garry: Ich nehme an Du hast keinen LKW-Führerschein... Da nimmst du falsch an. Da lernt man: verbietet, schneller als mit einer bestimmten Geschwindigkeit zu fahren. Sind durch das Zeichen innerhalb geschlossener Ortschaften bestimmte Geschwindigkeiten über 50 km/h zugelassen, so gilt das für Fahrzeuge aller Art. Außerhalb geschlossener Ortschaften bleiben die für bestimmte Fahrzeugarten geltenden Höchstgeschwindigkeiten (§ 3 Abs. 3 Nr. 2 Buchstaben a und b und § 18 Abs. 5) unberührt, wenn durch das Zeichen eine höhere Geschwindigkeit zugelassen wird. So habe ich das nicht gelernt (oder erinnere mich nicht mehr dran) und ich kann auch in der StVO nichts dazu finden. Aber bevor wir uns unnötig streiten: Gibt es real solche Stellen, an denen eine Straße innerorts auf über 60 freigegeben ist? Ich kenne keine. (Innerorts bedeutet hier nicht Autobahn oder autobahnähnlich ausgebaut.) Gruß, Bernd in Aachen hat der Außenring auch mindestens eine Stelle wo innerorts 70 gilt. -- Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Namen von Relationen
On Mon, 11 May 2009, ekkeh...@gmx.de wrote: Weil er ein Objekt beschreibt, das auf der Karte dargestellt wird - nämlich ein Multipolygon. Das ist Sinn und Zweck der Sache und kein Fehler. Wie sonst willst Du Waldgebiete, Teiche und andere Multipolygone mit Namen versehen? Genau das tut er nicht. Eine Relation ist nicht einfach ein Objekt auf der Karte, sondern eine Beziehung zwischen Objekten auf der Karte. Ob Nein. Du solltest Dir nochmal das Konzept der Abstraktion durch den Kopf gehen lassen. Relationen sind Beziehungen zwischen den OSM-Primärobjekten (Node, Way, Relation). Was eine Relation repräsentiert hängt von der jeweiligen Bedeutung der Relation ab und Multipolygone repäsentieren flächige Kartenobjekte. Andere Relationen Linienobjekte und andere keine kartenrelevanten Objekte. Für Ways und Nodes gilt übrigens das gleiche. Mal repräsentieren sie Kartenobjekte, mal sind es Hilfselemente für übergeordnete Objekte und mal haben sie ganz andere Bedeutungen. Du verwechselst die OSM-API mit den MapFeatures. Das kann nicht gut gehen. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] US-Behörde befürchtet GPS-Ausfälle
Dirk Stöcker schrieb: Dass allerdings jemand für LowCost-Empfänger Firmwareupdates anbietet halte ich für sehr unwahrscheinlich. Das lohnt sich einfach nicht. Außerdem sind in den nächsten Jahren viele Veränderungen bei der Satellitennavigation zu beachten, so dass neuere Geräte viel leistungsfähiger sein werden. Wie gesagt vermute ich auch immer noch einen Kapitalgedanken dahinter. Wieso soll ein Hersteller von LowCost-Empfängern ein Update rausgeben, wenn er gleich eine neue Serie an Receivern herausbringen kann. Wenn alle drei Systeme nahezu gleichzeitig online gehen, dann ist es natürlich schlecht für den Hersteller, weil er (wie bei DVD-+R) alles in einem Gerät anbieten muss, um am Markt anzukommen. Wenn erst GLONASS kommt und 2 Jahre später Galileo, dann kann er mindestens noch 3 verschieden Modelle auf den Markt werfen. Genauso unwahrscheinlich ist es aus meiner Sicht übrigens, dass im nächsten Jahr mehr als 10 GPS-Satelliten ausfallen werden (die nominelle GPS-Abdeckung umfasst 21 Satelliten, momentan sind es 31). Der Bericht hat allerdings einen wichtigen Hintergrund: Relativ viele der Satelliten sind älter als 10 Jahre (der älteste 19), so dass die Ausfallwahrscheinlichkeit steigt. Ich mache mir immer große Sorgen, dass da oben eine Art Kettenreaktion passiert: Ein Satellit kollidiert mit einem anderen, dann fliegen kaputte Teile zum nächsten, beschädigen den etc. etc. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkarte (ComputerTeddy): Konf likt zwischen Grenzen und Straßen
Carsten Schwede schrieb: Moin, Harald Kirsch schrieb: ist auf dem Gerät in Teilen nicht mehr zu sehen, und zwar offenbar dort, wo die Grenze mitten auf der Straße verläuft. Ist das bekannt? Ist das ein Problem der Kartendaten oder der Garminkarte? Die Daten sind falsch, da ist auf dem gleichen Weg einmal der Highway und die Grenze getaggt, hier kann mkgmap nur eines auswerten. Bitte also korrigieren. eine Grenze ist aber doch meistens auch was anderes? Ein Fluß, eine Mauer, eine Straße... Sehe das persönlich jetzt eher als Mangel der Datenverarbeitung wnn ein Way nicht Straße und Grenze sein kann. -- Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Namen von Relationen
Hi! Genau das tut er nicht. Eine Relation ist nicht einfach ein Objekt auf der Karte, sondern eine Beziehung zwischen Objekten auf der Karte. Ob Nein. Du solltest Dir nochmal das Konzept der Abstraktion durch den Kopf gehen lassen. Relationen sind Beziehungen zwischen den OSM-Primärobjekten (Node, Way, Relation). Was eine Relation repräsentiert hängt von der jeweiligen Bedeutung der Relation ab und Multipolygone repäsentieren flächige Kartenobjekte. Andere Relationen Linienobjekte und andere keine kartenrelevanten Objekte. Für Ways und Nodes gilt übrigens das gleiche. Mal repräsentieren sie Kartenobjekte, mal sind es Hilfselemente für übergeordnete Objekte und mal haben sie ganz andere Bedeutungen. Wäre nett wenn Du vielleicht den Ton etwas weniger abfällig halten könntest, als Informatiker habe ich von Abstraktion schon mal gehört. Ich weiß ja auch nicht warum Du Dein Statement mit Nein anfängst, um dann mein Statement aufzugreifen und es sogar noch allgemeiner in meinem Sinne zu formulieren. Aber deshalb schlage ich nicht vor, daß Du Dich mal mit der Semantik der Deutschen Sprache beschäftigen solltest. :-) bye Nop -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] All in One bald ganz Europa
Warum kein Bittorrent wenn man die Daten eh nur alle Woche/zwei/monatlich anbietet ? Lg Flacus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Namen von Relationen
Hallo Nop, ekkeh...@gmx.de schrieb: Das Problem ist, daß Nodes und Ways physikalische Objekte sind, aber Relationen Beziehungen zwischen Objekten. Es kann sein, dass das mal so gedacht war, aber: 1) Es gibt ways, die auch keinen realen Weg darstellen, sondern eine logische Beziehung, nämlich die Hausnummern-Interpolation 2) Ein way ist eine logische Verknüpfung von nodes, eine relation ist eine logische Verknüpfung von nodes, ways und relations. Was ist da der prinzipielle Unterschied? Eigentlich keiner! 3) Es gibt Typen von Relationen, die eine genau definierte grafische Bedeutung haben, nämlich die Multipolygone. Ich denke, das Wichtigste ist, genaue Definitionen und Regeln aufzustellen, was bei welchem Element (node, way, relation+type) wo und wie dargestellt werden soll. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Namen von Relationen
On Mon, 11 May 2009, ekkeh...@gmx.de wrote: Wäre nett wenn Du vielleicht den Ton etwas weniger abfällig halten könntest, als Informatiker habe ich von Abstraktion schon mal gehört. Ich weiß ja auch nicht warum Du Dein Statement mit Nein anfängst, um dann mein Statement aufzugreifen und es sogar noch allgemeiner in meinem Sinne zu formulieren. Aber deshalb schlage ich nicht vor, daß Du Dich mal mit der Semantik der Deutschen Sprache beschäftigen solltest. :-) Wenn Dir die Argumente ausgehen kritisierst Du den Schreibstil? Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] US-Behörde befürchtet GPS-Ausfälle
On Mon, May 11, 2009 at 01:22:13PM +0200, Jan Tappenbeck wrote: Subject: Re: [Talk-de] US-Behörde befürchtet GPS-Ausfälle Weiß einer von Euch wie das dann mit unseren Empfängern aussieht - Firmware-Update oder Mülleimer ?? u-blox 5 soll via Firmware upgrade Galileo koennen. http://www.u-blox.com/products/ublox5/technology/galileo.html Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] US-Behörde befürchtet GPS-Ausfäll e
Florian Lohoff schrieb: u-blox 5 soll via Firmware upgrade Galileo koennen. Die einzige u-blox Endkunden-Hardware, die ich kenne, befindet sich in den aktuellen Microsoft-Empfängern zu deren Map-App. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zu OSM-WMS
Hallo Liste, On May 11, 2009, at 12:01 , Stefan Dettenhofer (StefanDausR) wrote: Es gibt auch noch diesen WMS-Dienst (für Deutschland) http://osm.omniscale.de/ schön den Link hier zu sehen :) Wir haben einen WMS Proxy entwickelt, der die Lücke zwischen herkömmlichen WMS und TileCacheing-Lösungen schließt. Für die Demonstration haben wir intern einen OpenStreetMap WMS auf Mapnik- Basis aufgesetzt. Hier ist die Capabilities-URL http://osm.omniscale.net/proxy/service?service=WMSrequest=GetCapabilities und hier http://omniscale.de/demo sind noch ein paar Infos. aber bitte die Nutzungsbedingungen beachten! Sobald man als Unternehmen etwas Anbietet, kommt man da leider nicht drumrum. Generell ist die private und nicht-kommerzielle Nutzung aber ausdrücklich Erlaubt: http://omniscale.de/nutzungsbedingungen Gruß Oliver -- Oliver Tonnhofer tonnho...@omniscale.de Omniscale - Dominik Helle, Oliver Tonnhofer GbR Industriestr. 1, 26121 Oldenburg Tel: +49(0)441/9392774-2 (Fax: 9) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Namen von Relationen
Am 11. Mai 2009 09:54 schrieb Dirk Stöcker openstreet...@dstoecker.de: On Mon, 11 May 2009, Nop wrote: Wäre es nicht sinnvoller, das Problem an der Wurzel anzupacken? Deshalb nochmal die Frage: Warum erscheint der Name einer Relation auf der Karte? Weil er ein Objekt beschreibt, das auf der Karte dargestellt wird - nämlich ein Multipolygon. Das ist Sinn und Zweck der Sache und kein Fehler. Wie sonst willst Du Waldgebiete, Teiche und andere Multipolygone mit Namen versehen? Indem ich den Namen an den Way hänge? In meinem Fall (Insel im See) kann ich doch sowohl dem See als auch der Insel einen Namen geben: bei einem Namen für das Gesamtkonstrukt halte ich das weniger für gegeben. Insgesamt sehe ich bei Multipolygon-relationen eigentlich keinen Grund (Beispiel), wo man 3 unabhängige Namen (outer, inner, relation) vergeben sollte. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Mappingweekend in der Altmark
Hallo Liste(n), Eine Hotel- und Campingeinrichtung möchte ihre Region gemappt haben. Zitat: Wir sind eine Hotel- und Campingeinrichtung im Raum Altmark zwischen Gardelegen und Salzwedel. Wir sind interessiert, für unserem Bereich verschiedene Rad- und Wanderwegen zu erstellen. Leider fehlt uns dafür das Datenmaterial, da kaum Karten vorliegen und in den letzten Jahren viele Änderungen am Wegenetz vorgenommen wurden. Mein Vorschlag an Sie ist in unserer Einrichtung ein Mapping Weekend zu veranstalten. Wir würden Übernachtung und Verpflegung zu vergünstigten Preisen stellen und Sie so gut wie möglich bei der Organisation unterstützen. Alle Interessenten können sich bei Doodle für einen Termin eintragen. http://www.doodle.com/utpewr96t4fr6ca8 Besonders aufgerufen sind Mapper aus den Regionen Altmark, Lüneburger Heide, Wendland, Prignitz, Havelland und Magdeburger Börde. Gruß Volker -- Volker Grescho ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zu OSM-WMS
On May 11, 2009, at 13:35 , Frederik Ramm wrote: Ja, es ist immer eine Frage davon, wieviel Ressourcen man zur Verfuegung hat. Grundsaetzlich ist im Mapnik-Lieferumfang ein Python-Skript namens ogcserver enthalten, mit dem Du einen halbwegs brauchbaren WMS hinbekommst - es gibt regelmaessig Erfolgsberichte auf der Mapnik- Liste. Bis vor kurzem (0.6.0) konnte der ogcserver allerdings noch nicht mit den .xml Styles umgehen, die für OSM zur Verfügung stehen. Jetzt sollte ein OSM WMS mit den original Styles einfach aufzusetzen sein. Wir haben für http://oms.omniscale.de einen minimalen WMS geschrieben, der direkt auf die Mapnik API zugreift. Davor steht dann unser Proxy, der sich um die richtige WMS Implementierung kümmert und gleichzeitig noch Caching betreibt. Richtig schnell ist das nicht (eher so fuer die interne Anwendung, nicht auf einem oeffentlichen Server). Was allerdings weniger an dem ogcserver selbst liegt. Im kleinen Maßstab hat der Mapnik sehr viele Daten zu verarbeiten. In großen Maßstäben ist der ogcserver/Mapnik recht fix. Man könnte durch aufarbeiten der Daten (Stichwort Generalisierung) noch deutlich mehr an Geschwindigkeit herausholen, aber das ist dann mit Handarbeit verbunden. Beim Einsatz von TileCache oder dem Omniscale Proxy ist die Geschwindigkeit von Mapnik aber letzten Endes unerheblich. Wir arbeiten in der Geofabrik an einem Apache-Modul, das Mapnik als WMS bereitstellt und so die Nachteile der oben genannten Python-Bastelloesung (subjektiver Eindruck ;-) ueberwindet. Das hört sich interessant an. Allerdings Zweifel ich dran, dass ein Apache-Modul, im Gegensatz zum ogcserver mit mod_wsgi/mod_fastcgi, merkbare Geschwindigkeitsvorteile bringt (subjektive Einschätzung :) Gruß Oliver -- Oliver Tonnhofer tonnho...@omniscale.de Omniscale - Dominik Helle, Oliver Tonnhofer GbR Industriestr. 1, 26121 Oldenburg Tel: +49(0)441/9392774-2 (Fax: 9) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Namen von Relationen
Hier gilt das gleiche wie oben: wenn der Betreiber des Renderers alte Bahntrassen anzeigen lassen will, soll er sie ins Stylesheet eintragen, wenn nicht, soll er sie rauslassen. Man muss halt nur sauber zwischen name, comment und note unterscheiden. name kann ich evtl. noch abgrenzen von den beiden anderen, aber wie ist die Abgrenzung von note und comment? Und vor allem: wo ist das dokumentiert? Note wurde bisher allerorten für alle möglichen Hinweise verwendet und keineswegs nur als Identifier für Relationen. Dafür spricht auch, dass JOSM neben name sowohl comment als auch note berücksichtigt. Klar: man kann jetzt damit anfangen und alle zu einer großen Sichtungsaktion des Bestands auffordern. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Diskussionen dokumentieren
Frederik Ramm schrieb: Hallo, Jonas Krückel wrote: Dennoch wäre ich sehr am Ergebnis der Diskussion, auch wenn es keine Lösung des Problems gab, interessiert. Es ist oft schwer, ein Ergebnis neutral festzuhalten, so dass alle Diskussionsteilnehmer einverstanden sind. Daher auch Ergebnis in . Man kann ja auch kurz die verschiedenen Ansichten zusammenfassen. Das ist ganz schoen Arbeit, und es besteht die Gefahr, die Du ja schon vorausgesehenhast: Natürlich soll dann nicht im Wiki weiterdiskutiert werden :-) Und in einem so schnell wachsenden und dynamischen Projekt wie OSM kommt erschwerend hinzu, dass etwas, dem heute alle Mailinglistenteilnehmer zustimmen, schon in 1-2 Monaten keine Autoritaet mehr hat - warum sollten sich die bis dahin hinzugekommen mehreren Hundert Mapper an das halten, was irgendwelche Diskutanten lange vor ihrer Zeit auf der Liste beschlossen haben? Eben, bei OSM gibts kein beschlossen ;-) Was uns heute noch technisch nicht machbar oder unsinnig erscheint, kann morgen durch neue Technologien, und sei es beispielsweise nur vernuenftiges Layering in einem Editor, schon wieder in Frage gestellt werden... Aber man hat dann die alte Diskussion schön zusammengefasst und kann sagen, hey, schaut, damals hatten wir diese technischen Probleme, die nun nicht mehr vorhanden sind und die damals die Argumente begründet haben. Da das nun nicht mehr gegeben ist, sollten wir nochmal neu diskutieren. Wer damals nicht mitdiskutiert hat bzw. sich nicht mehr erinnern kann, kann das ganz einfach nochmal schnell im Wiki nachlesen. Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] US-Behörde befürchtet GPS-Ausfäll e
On Mon, 11 May 2009, Tobias Wendorff wrote: Dirk Stöcker schrieb: Dass allerdings jemand für LowCost-Empfänger Firmwareupdates anbietet halte ich für sehr unwahrscheinlich. Das lohnt sich einfach nicht. Außerdem sind in den nächsten Jahren viele Veränderungen bei der Satellitennavigation zu beachten, so dass neuere Geräte viel leistungsfähiger sein werden. Wie gesagt vermute ich auch immer noch einen Kapitalgedanken dahinter. Wieso soll ein Hersteller von LowCost-Empfängern ein Update rausgeben, wenn er gleich eine neue Serie an Receivern herausbringen kann. Das ist etwas überspitzt. Kompatibel heisst das gleiche Frequenzen und ein prinzipiell ähnliches Verfahren genutzt wird. Die komplette Signalverarbeitung ist vollkommen verschieden. Da die Softwareentwicklung heutzutage die Hauptarbeit ist, aber keiner für Firmwareupdates Geld bezahlen würde, wäre es schon komisch, wenn ein Hersteller Updates für alte Geräte anbietet. Wenn alle drei Systeme nahezu gleichzeitig online gehen, dann ist es natürlich schlecht für den Hersteller, weil er (wie bei DVD-+R) alles in einem Gerät anbieten muss, um am Markt anzukommen. Nur um das mal klarzustellen. GPS und GLONASS sind beide etwa gleich alt. GLONASS ist also schon lange online. Nur war in den 90er Jahren der GLONASS-Wartungszustand miserabel (Geldnot) und deswegen hat sich GPS durchgesetzt. In den letzten Jahren geben die Russen wieder reichlich Geld für GLONASS aus, deswegen ist es jetzt wieder im Gespräch. Im hochpräzisen Bereich ist GPS+GLONASS mittlerweile Standard. Genauso unwahrscheinlich ist es aus meiner Sicht übrigens, dass im nächsten Jahr mehr als 10 GPS-Satelliten ausfallen werden (die nominelle GPS-Abdeckung umfasst 21 Satelliten, momentan sind es 31). Der Bericht hat allerdings einen wichtigen Hintergrund: Relativ viele der Satelliten sind älter als 10 Jahre (der älteste 19), so dass die Ausfallwahrscheinlichkeit steigt. Ich mache mir immer große Sorgen, dass da oben eine Art Kettenreaktion passiert: Ein Satellit kollidiert mit einem anderen, dann fliegen kaputte Teile zum nächsten, beschädigen den etc. etc. Das ist extrem unwahrscheinlich. Kaputt heißt nicht, dass der Satellit kaputt ist, sondern nur, dass die Primärfunktion nicht mehr erfüllt werden kann (z.B. letzte Atomuhr ist kaputtgegangen oder erreicht notwendige Genauigkeiten nicht mehr). Die Satelliten sind deshalb weiterhin steuerbar und werden auf Parkbahnen/Absturzbahnen gelenkt. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] route=flight
Ich habe immer noch eine ambivalente Sicht. Auf der einen Seite hört es sich logisch und richtig an, die OSM Datenbank auf objektives zu beschränken. Auf der anderen Seite, brauchen wir in naher Zukunft wahrscheinlich ehe ein ausgefeiltes Filtersystem auch auf Editor Seite, wenn die Menge an Daten weiter zunimmt und die Speziallfälle wie altes Rom, Elephantenpfade und Flugrouten so stark zunehmen, dass ein vernünftiges Rendern / und Edititieren unmöglich wird. Es könnte gut sein, dass in der Zukunf wir zu einem Punkt kommen, wo eine OSM Standartkarte vielleicht nur noch 10% der vorhandene Daten anzeigt, weil der Rest Spezialfälle sind, die den Großteil der Nutzer in keiner Weise interessiert. Und wenn wird das Filtern ehe brauchen, warum sollten dann die persöhnlichen Route ausgergrenzt werden ? Sie sind dann halt ein sehr spezieller Fall, an dem eventuell nur eine Person interessiert ist. Ich hatt zwar vorgeschlagen nach Wikipedia zu schauen, aber der Vergleich hinkt. Es ist ja kein Problem parallele Wikipedias zu habe, parallele OSM's zu implementieren, die gegenseitig ihre Daten nutzen können sehe ich allerdings als sehr schwierig an. Bei Wikipedias braucht ma nur einfache HTML Links um Inhalte zu verlinken, das Verlinken von OSM Daten zwischen verschiedenen OSM's ist sehr viel schwieriger (also eine Relation R aus OSM 1 benutzt Wege W1, W2 aus OSM 2), wegen der Instabilität der Inhalte (= Splitt / Merge von Wegen) Grüße, Carsten -Original Message- From: talk-de-boun...@openstreetmap.org [mailto:talk-de-boun...@openstreetmap.org] On Behalf Of Sven Sommerkamp Sent: 11 May 2009 11:31 To: talk-de@openstreetmap.org Subject: Re: [Talk-de] route=flight Am Samstag, 9. Mai 2009 13:00:02 schrieb talk-de-requ...@openstreetmap.org: Hi, Auch ich bin der Ansicht, dass persoenliche Daten nicht zu OSM gehoeren. Da bin ich froh das sich diese Erkenntnis als Konsens wohl langsam etabliert. Ich will ja nicht schon wieder das Beispiel mit dem Goldfischglas.. Ist jedoch eine automatische Filterung der Sache dienlich. Wird nicht evtl. zu wenig oder zuviel gefiltert? Gru? Werner -Urspr?ngliche Nachricht- Von: talk-de-boun...@openstreetmap.org [mailto:talk-de-boun...@openstreetmap.org] Im Auftrag von Frederik Ramm Gesendet: Samstag, 9. Mai 2009 04:34 An: Openstreetmap allgemeines in Deutsch Betreff: Re: [Talk-de] route=flight Hi, Carsten Behring wrote: Gibt es eigentlich derartige Erfahrungen in Wikipedia ? Einer Art fon Behandlugn von unn?tzem Wissen. Was passiert wenn ich in Wikipedia einen Artikel reinstelle der in allen Einzelheiten den Inhalt meines Kellers beschreibt ? Irgendwie unn?tz, aber doch wahr. Ich denke, die Community ignoriert es einfach. Nein, die Community wird es loeschen, weil es nicht den Relevanzkriterien entspricht. Diese sollten wir mal aufstellen! Sonst drehen wir uns im Kreis. Die Wikipedia sieht sich nicht als ein Wiki, sondern als eine Enzyklopaedie, und schmeisst rigoros raus, was nicht enzyklopaedisch ist. Was auch dort, glaube ich sinnvoll ist. ?bertragen auf OSM heisst dies aber, dass das Problem auch auf Editor und Renderer Seite gel?st werden muss, und nicht durch Auschluss von Inhalten (in Grenzen). Ich sehe durchaus, dass wir auf Editor-/Rendererseite mehr und besser filtern muessen (Stichwort altes Rom). Trotzdem gehoeren persoenliche Daten m.E. nicht in OSM, wir hatten gerade eben erst die Diskussion um meine persoenlichen Fahrradroutenempfehlungen. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49?00'09 E008?23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] US-Behörde befürchtet GPS-Ausfäll e
Dirk Stöcker schrieb: Das ist etwas überspitzt. Kompatibel heisst das gleiche Frequenzen und ein prinzipiell ähnliches Verfahren genutzt wird. Die komplette Signalverarbeitung ist vollkommen verschieden. Da die Softwareentwicklung heutzutage die Hauptarbeit ist, aber keiner für Firmwareupdates Geld bezahlen würde, wäre es schon komisch, wenn ein Hersteller Updates für alte Geräte anbietet. Klar ist es überspitzt, aber guck' Dir doch mal die Meldungen diesbezüglich in den letzten Jahren an. Stichwort DVD-Brenner oder einfach nur Festplatten, die durch die Firmware in der Kapazität gebremst werden. Vor kurzem gab es auch einen Digitalkamera-Hersteller, bei dem nur der Preis, die Firmware und der Aufkleber modellunterschiedlich waren. Wenn alle drei Systeme nahezu gleichzeitig online gehen, dann ist es natürlich schlecht für den Hersteller, weil er (wie bei DVD-+R) alles in einem Gerät anbieten muss, um am Markt anzukommen. Nur um das mal klarzustellen. GPS und GLONASS sind beide etwa gleich alt. GLONASS ist also schon lange online. Nur war in den 90er Jahren der GLONASS-Wartungszustand miserabel (Geldnot) und deswegen hat sich GPS durchgesetzt. In den letzten Jahren geben die Russen wieder reichlich Geld für GLONASS aus, deswegen ist es jetzt wieder im Gespräch. Im hochpräzisen Bereich ist GPS+GLONASS mittlerweile Standard. Mit online meinte ich für den Endkundenbereich interessant. Aber auch interessant, was die verschiedenen Internet-Quellen zum Thema für eine auseinandergehende Meinung dazu haben. Ich mache mir immer große Sorgen, dass da oben eine Art Kettenreaktion passiert: Ein Satellit kollidiert mit einem anderen, dann fliegen kaputte Teile zum nächsten, beschädigen den etc. etc. Das ist extrem unwahrscheinlich. Kaputt heißt nicht, dass der Satellit kaputt ist, sondern nur, dass die Primärfunktion nicht mehr erfüllt werden kann (z.B. letzte Atomuhr ist kaputtgegangen oder erreicht notwendige Genauigkeiten nicht mehr). Die Satelliten sind deshalb weiterhin steuerbar und werden auf Parkbahnen/Absturzbahnen gelenkt. All diese Fälle würden für unseren Gebrauchszweck kaputt bedeuten. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zu OSM-WMS
Hallo, Oliver Tonnhofer wrote: Beim Einsatz von TileCache oder dem Omniscale Proxy ist die Geschwindigkeit von Mapnik aber letzten Endes unerheblich. Wenn man in einer stark vereinheitlichten (und daher gut cachbaren) Umgebung arbeitet, wie z.B. eben hinter einem OpenLayers mit immer gleicher Projektion und 18 festen Zoomleveln, dann ja. Das hört sich interessant an. Allerdings Zweifel ich dran, dass ein Apache-Modul, im Gegensatz zum ogcserver mit mod_wsgi/mod_fastcgi, merkbare Geschwindigkeitsvorteile bringt (subjektive Einschätzung :) Bei einem Standard-OSM-Stylefile und un-generalisiert mit osm2pgsql importierten Daten werden fuer einen durchschnittlichen WMS-Request 80% der Zeit in der PostGIS, 15% in Mapnik und 5% im Webserver-Drumrum verbraucht. Ob man die 5% jetzt durch Einsatz von C statt Python jetzt drastisch verbessern kann, spielt also tatsaechlich keine Rolle (waren bei uns mehr grundsaetzliche Ueberlegungen) - um wirklich etwas herauszuholen, muss man, wie Du richtig sagst, Handarbeit anlegen, indem man Queries optimiert, Indizes anlegt und Daten geeignet generalisiert. Das aber gilt vermutlich fuer den Mapserver in genau dem gleichen Masse wie fuer Mapnik. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] US-Behörde befürchtet GPS-Ausfälle
On Mon, May 11, 2009 at 03:06:50PM +0200, Tobias Wendorff wrote: Florian Lohoff schrieb: u-blox 5 soll via Firmware upgrade Galileo koennen. Die einzige u-blox Endkunden-Hardware, die ich kenne, befindet sich in den aktuellen Microsoft-Empfängern zu deren Map-App. Der vorgaengerchip - Antharis 4 steckt zum beispiel in dem vielerwaehnten Wintec WBT-201 - Mit dem u-blox5 gibt es heute schon Navilock USB Maeusen http://www.navilock.de/produkte/gruppen/3/Kabel_Empfaenger/60095_NL-402U.html http://www.navilock.de/produkte/gruppen/3/Kabel_Empfaenger/60109_NL-403P.html http://www.navilock.de/produkte/gruppen/3/Kabel_Empfaenger/60096_NL-404P.html Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] All in One bald ganz Europa
FlaBot fla...@googlemail.com wrote: Warum kein Bittorrent wenn man die Daten eh nur alle Woche/zwei/monatlich anbietet ? AFAIK plant Christoph tagesaktuelle Karten. Sven -- The term any key does not refer to a particular key on the keyboard. It simply means to strike any one of the keys on your keyboard or handheld screen. (Compaq FAQ Entry 2859) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Namen von Relationen
name kann ich evtl. noch abgrenzen von den beiden anderen, aber wie ist die Abgrenzung von note und comment? Und vor allem: wo ist das dokumentiert? Note wurde bisher allerorten für alle möglichen Hinweise verwendet und keineswegs nur als Identifier für Relationen. Dafür spricht auch, dass JOSM neben name sowohl comment als auch note berücksichtigt. Klar: man kann jetzt damit anfangen und alle zu einer großen Sichtungsaktion des Bestands auffordern. Am wichtigsten ist, zwischen name und den anderen zu unterscheiden. Nachdem comment hier auf der Liste (oder auf talk) ein paar mal empfohlen wurde, bin ich davon ausgegangen, dass dieses Tag irgendwo genauer definiert wäre. Im Wiki konnte ich jetzt aber auch nix darüber finden. Ich hab die beiden immer so interpretiert: note = beliebige Notiz für andere Mapper, z.B. hier fehlt noch xyz, oder dies ist Absicht, bitte nicht löschen comment = eine Art Beschreibung/Bezeichner des Objekts, z.B. um es in einer Liste leichter identifizieren zu können Grüße, Marc -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] neuer OSB Service
Mitja Kleider mi...@mitjakleider.de wrote: After having some trouble with the precision and number of bugs returned by OpenStreetBugs [1] I contacted the author (Xav). Dem wollte ich auch schon mal eine Email schreiben und hab nirgends eine Kontaktadresse gefunden. Also nun also der Verbesserungsvorschlag an Dich. Es wäre schön, wenn Du noch nen Edit in josm Button wie bei OSM Inspector einbauen könntest! Sven -- C is quirky, flawed, and an enormous success (Dennis M. Ritchie) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zu OSM-WMS
Frederik Ramm frede...@remote.org wrote: Ja, es ist immer eine Frage davon, wieviel Ressourcen man zur Verfuegung hat. Grundsaetzlich ist im Mapnik-Lieferumfang ein Python-Skript namens ogcserver enthalten, mit dem Du einen halbwegs brauchbaren WMS hinbekommst - es gibt regelmaessig Erfolgsberichte auf der Mapnik-Liste. Richtig schnell ist das nicht (eher so fuer die interne Anwendung, nicht auf einem oeffentlichen Server) Hm, nen HOWTO oder sowas gibt es dazu aber auch nicht oder? Sven -- The source code is not comprehensible (found in bug section of man 8 telnetd on Redhat Linux) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zu OSM-WMS
On May 11, 2009, at 15:48 , Frederik Ramm wrote: Oliver Tonnhofer wrote: Beim Einsatz von TileCache oder dem Omniscale Proxy ist die Geschwindigkeit von Mapnik aber letzten Endes unerheblich. Wenn man in einer stark vereinheitlichten (und daher gut cachbaren) Umgebung arbeitet, wie z.B. eben hinter einem OpenLayers mit immer gleicher Projektion und 18 festen Zoomleveln, dann ja. Bei TileCache ja. Beim Omniscale Proxy gibt es keine Einschränkungen was Ausschnitt, Zoomlevel, Projektion etc. anbelangt. Nur wenn man viele unterschiedliche Layer/Styles haben muss, hört es natürlich irgendwann mit der Cachbarkeit auf. - um wirklich etwas herauszuholen, muss man, wie Du richtig sagst, Handarbeit anlegen, indem man Queries optimiert, Indizes anlegt und Daten geeignet generalisiert. Das aber gilt vermutlich fuer den Mapserver in genau dem gleichen Masse wie fuer Mapnik. Für die o...@pgsql Datensätze kann ich das bestätigen. Wir haben hier einen UMN Mapserver aufgesetzt und der braucht in den kleinen Maßstäben, genau wie der Mapnik, eine gefühlte Ewigkeit. -- Oliver Tonnhofer tonnho...@omniscale.de Omniscale - Dominik Helle, Oliver Tonnhofer GbR Industriestr. 1, 26121 Oldenburg Tel: +49(0)441/9392774-2 (Fax: 9) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neues motorroad-Rendering verstaendlich?
Robert rob.foren+...@gmail.com wrote: Am 9. Mai 2009 16:55 schrieb Heiko Jacobs heiko.jac...@gmx.de: Martin Koppenhoefer dieterdre...@gmail.com wrote: hast Du motorroad=yes als gr?nes casing eingebaut? Sieht OK aus. Nur 80 von 100 Punkten ;-) Das war motorroad=no; motorroad=yes (Kraftfahrstra?e) mit blauem casing. Super, genau auf sowas habe ich gewartet, da die Info, ob die Stra?e eine Kraftfahrstra?e ist, eben z.B. f?r Radfahrer elementar wichtig ist. ;-) Hier ist es gut zu sehen (no grenz an yes): http://www.informationfreeway.org/?lat=50.06804568628054lon=8.65291921699zoom=17layers=BF000F Da sehe ich (heute) kein neues rendering mehr, auch ueber meine Beispiele ist mittlerweile fast komplett wieder ein rendering nach alten rules drueber gelaufen. Das ist halt der haken bei t...@h: man weisz nie, wie aktuell die rules @home sind... Aber langfristig wird sich stets das neue durchsetzen :-) In der Tat: Das war des Raetsels Loesung: motorroad=yes bekam eine zusaetzliche motorway-blaue Begleitlinie fuer highway=tertiary/.../trunk, weil fuer unterhalb trunk ist motorroad die erwaehnenswerte Ausnahme und nicht jeder trunk ist wirklich motorroad. motorroad=no bekam eine zusaetzliche secondary-goldene Begleitlinie, weil das fuer trunk erwaehnenswert ist, weil seltener. Fuer primary/.../tertiary/... ist es der nicht erwaehnenswerte Normalfall Fuer unterhalb tertiary duerfte motorroad nicht vorkommen, daher nicht aufgenommen in die Rules... Das dritte Beispiel zeigt in z17 (und bald auch andere) die Faelle bicycle=no fuer motorroad!=yes als dunkelblau angedeutete Durchstreichung Sobald ich dazu komme, werde ich alles fuer weitere Zoomlevel weiterentwickeln und wohl auch die Redering-Kombination motorroad/cycleway ergaenzen. PS: Beim Frankfurter Bsp. sollte man sich einigen, ob trunk oder primary, hin das eine und rueckwaerts das andere... Nun ja... ;-) MfG Heiko Jacobs Z! IRCnet Mueck -- Douglasstr. 30, D-76133 Karlsruhe fon +49 721 24069 fax 2030542 Geo-Bild Ing.b?ro geo-bild-KA.de Internet-Service auch-rein.de Couleurstud. Infos cousin.de VCD, umweltverkehr KA umverka.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] US-Behörde befürchtet GPS-Ausfäll e
On Mon, 11 May 2009, Tobias Wendorff wrote: Nur um das mal klarzustellen. GPS und GLONASS sind beide etwa gleich alt. GLONASS ist also schon lange online. Nur war in den 90er Jahren der GLONASS-Wartungszustand miserabel (Geldnot) und deswegen hat sich GPS durchgesetzt. In den letzten Jahren geben die Russen wieder reichlich Geld für GLONASS aus, deswegen ist es jetzt wieder im Gespräch. Im hochpräzisen Bereich ist GPS+GLONASS mittlerweile Standard. Mit online meinte ich für den Endkundenbereich interessant. Aber auch interessant, was die verschiedenen Internet-Quellen zum Thema für eine auseinandergehende Meinung dazu haben. Ich habe aufgrund meines Berufes den Vorteil, dass ich mit Leuten reden kann, die Bescheid wissen :-) Außerdem kann die damit einhergehende Erfahrung auch nicht schaden. Hinsichtlich GLONASS wird sehr viel Unsinn erzählt. Teilweise aus Marketinggründen, teilweise aus Unwissenheit. Ich mache mir immer große Sorgen, dass da oben eine Art Kettenreaktion passiert: Ein Satellit kollidiert mit einem anderen, dann fliegen kaputte Teile zum nächsten, beschädigen den etc. etc. Das ist extrem unwahrscheinlich. Kaputt heißt nicht, dass der Satellit kaputt ist, sondern nur, dass die Primärfunktion nicht mehr erfüllt werden kann (z.B. letzte Atomuhr ist kaputtgegangen oder erreicht notwendige Genauigkeiten nicht mehr). Die Satelliten sind deshalb weiterhin steuerbar und werden auf Parkbahnen/Absturzbahnen gelenkt. All diese Fälle würden für unseren Gebrauchszweck kaputt bedeuten. Ja. Aber die erwähnte Kettenreaktion ist eben sehr unwahrscheinlich. Das große Problem ist, dass bei GPS eben momentan verhältnismässig viele alte Satelliten oben sind und sollten die wieder Erwarten alle kurz nacheinander ausfallen, dann wird es mit dem Nachschub schwierig. Das sagt der Bericht im wesentlichen aus. In den letzten Jahren haben die Amis 1-2 Satelliten pro Jahr gestartet und die Satellitenzahl auf Maximum hochgefahren, damit die zu erwartenden Ausfälle kompensiert werden können. Aufgrund der langen Satelliten-Lebensdauer sind die Leute etwas faul geworden und das könnte ihnen jetzt auf die Füße fallen. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kleine rechtliche Frage: Verwendung des Logo + Kartendarstellung
Frederik Ramm schrieb: Die Grafik ist doch wohl Content, oder sehe ich das falsch? Wer ganz sicher gehen will, kann Matt Amos fragen, der hat das Logo erfunden. Hast Du gesehen, dass das Logo mittlerweile als Marke in England durch ist? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Namen von Relationen
Marc Schütz schrieb: Eine Lösung des Problems könnte darin bestehen, Relationen mit einem weiteren Tag zu versehen, welches die Darstellung in der Karte beeinflusst. Ich denke dabei weniger an Tag wie osmarender:renderName sondern eher an eine generelle Bewertung zwischen allgemeinrelevant und interner Verwaltungsbezeichnung. Nein. Interne Verwaltungsbezeichnung haben im name-Tag überhaupt nichts verloren. Verwendet einfach (wie gehabt) note oder comment, und das Problem ist erledigt. Interne Verwaltungsbezeichnung war als unwichtiges Ende der Skala gemeint. Es gibt verschiedene, amtliche Bezeichnungen, die aber eher unüblich sind. Wie soll ein note oder comment aussehen? Diese namenlose Relation bezeichnet ein Gebiet, dass amtlich ... heißt? Ich ärgere mich darüber, dass an der Küstenlinie (oft an unpassenden Stellen) Relationsbezeichnungen wie Schleswig-Holstein (Landmasse), Deutschland (Landmasse) oder Kreis Rendsburg-Eckernförde (Landmasse) stehen. [...] Man braucht nur eine Möglichkeit, diesen Namen als nicht oder weniger darstellungswürdig zu kennzeichnen. Die hat man schon, nämlich im Stylesheet des Renderers. Abgesehen davon heißt das von der Relation bezeichnete Gebiet bestimmt nicht Schleswig-Holstein (Landmasse), sondern das ist eine Beschreibung und ist daher im name-Tag an der falschen Stelle. Diese Einteilung der Relationen war ein Kompromiss zwischen den Befürwortern der Land- und der Seegrenzen. Bis auf die überflüssige Darstellung einiger Relationsnamen, finde ich die Einteilung gut. Wie finde ich sonst so eine Relation, wenn sich die logische Bezeichnung irgendwo in name, note oder comment als Text befindet? Ich kann mir viele Relationen vorstellen, die in die OSM-Datenbank passen und einen Namen haben, der aber nicht in der üblichen Karte auftauchen sollte: Historische Grenzen (vom der mittelalterlichen Staatsgrenze bis zur im letzten Jahr fusionierten Gemeinde, die noch in verschiedenen amtlichen Verordnungen genannt ist), Außengrenze der Schengen-Staaten, Wasserschutzgebiete, alte Bahntrassen, etc. Hier gilt das gleiche wie oben: wenn der Betreiber des Renderers alte Bahntrassen anzeigen lassen will, soll er sie ins Stylesheet eintragen, wenn nicht, soll er sie rauslassen. Man muss halt nur sauber zwischen name, comment und note unterscheiden. Viele Bezeichnungen sind als Name auf speziellen Karten sinnvoll. Man kann dann nicht comment und note durchsuchen, um einen Text zu finden, den man als Namen interpretieren kann. Relationen mit dem Namen Schengen Area oder Kleinbahn Kiel-Segeberg sollten nur nicht auf der Standardkarte als Text erscheinen. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] US-Behörde befürchtet GPS-Ausf älle
Am 11. Mai 2009 14:24 schrieb Tobias Wendorff tobias.wendo...@uni-dortmund.de: Ich mache mir immer große Sorgen, dass da oben eine Art Kettenreaktion passiert: Ein Satellit kollidiert mit einem anderen, dann fliegen kaputte Teile zum nächsten, beschädigen den etc. etc. war das ein Scherz? Hast Du eine Ahnung, wie viele Objekte (natürlichen und künstlichen Ursprungs) da oben bereits unterwegs sind? Das spricht natürlich eher für Zusammenstöße aber sicher nicht für eine Kettenreaktion... Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] US-Behörde befürchtet GPS-Ausf älle
Am 11. Mai 2009 12:48 schrieb Tobias Wendorff tobias.wendo...@uni-dortmund.de: Warten auf Gallileo... http://golem.mobi/0905/67007.html Zit: 2008 deckte das GAO auf, dass über die Webangebote von eBay und Craigslist brisante militärische Technik verkauft wird. Mist, wieder zu spät. Hat sich von Euch jemand zufällig mit solchen militärischen Geräten eingedeckt? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Namen von Relationen
Am 11. Mai 2009 16:40 schrieb Stephan Wolff s.wo...@web.de: Interne Verwaltungsbezeichnung war als unwichtiges Ende der Skala gemeint. Es gibt verschiedene, amtliche Bezeichnungen, die aber eher unüblich sind. Wie soll ein note oder comment aussehen? Diese namenlose Relation bezeichnet ein Gebiet, dass amtlich ... heißt? wenn ein Gebiet amtlich xy heisst, wäre das doch ein klarer Fall für das Name-tag. Wie definierst Du denn hier unüblich? Ich kann mir viele Relationen vorstellen, die in die OSM-Datenbank passen und einen Namen haben, der aber nicht in der üblichen Karte auftauchen sollte: Historische Grenzen (vom der mittelalterlichen Staatsgrenze bis zur im letzten Jahr fusionierten Gemeinde, die noch in verschiedenen amtlichen Verordnungen genannt ist), ist hier wirklich ein Name sinnvoll? Außengrenze der Schengen-Staaten dito Wasserschutzgebiete, alte Bahntrassen, etc. hier würde ich einen Namen setzen, zumindest beim Wasserschutzgebiet. Relationen mit dem Namen Schengen Area oder Kleinbahn Kiel-Segeberg sollten nur nicht auf der Standardkarte als Text erscheinen. Problem ist besonders bei Schengen (u.ä.), dass dann womöglich irgendwo im geografischen Mittelpunkt in Z17 ein Label Schengen area auftaucht ;-) In kleinerer Form hat man das ja jetzt schon, s. z.B. hier: http://www.openstreetmap.org/?lat=48.517912lon=9.052269zoom=18layers=B000FTF die Beschriftung Neckar ist ausgerechnet da, wo die Insel ist. Allgemein wäre es schön, die Beschriftungen thematisch getrennt in verschiedenen Typen, Ausrichtungen und Farben zu rendern, so könnte der Fluss hier z.B. etwas größer, blau, und am Flusslauf-way ausgerichtet erscheinen. Mittelgebirge und Wälder, Parks, könnten in braun oder grün gerendert werden, etc. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] US-Behörde befürchtet GPS-Ausf älle
Martin Koppenhoefer schrieb: Mist, wieder zu spät. Hat sich von Euch jemand zufällig mit solchen militärischen Geräten eingedeckt? Einfach nur eine gebrauchte Festplatte bestellen (news.google.de). ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neues motorroad-Rendering verstaendlich?
Am 11. Mai 2009 16:13 schrieb Heiko Jacobs heiko.jac...@gmx.de: Fuer primary/.../tertiary/... ist es der nicht erwaehnenswerte Normalfall Fuer unterhalb tertiary duerfte motorroad nicht vorkommen, daher nicht aufgenommen in die Rules... m.E. kann motoroad für tertiaries auch nicht vorkommen, da sonst mind. Secondary/Primary. Selbst bei Secondaries tue ich mich schwer, diese dort zu belassen sollten sie eine motorroad sein. M.E. motorroad=yes - mind. primary. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkarte (ComputerTeddy): Konflikt z wischen Grenzen und Straßen
Am 11. Mai 2009 14:02 schrieb Chris-Hein Lunkhusen chris66...@gmx.de: Und selbst wenn es als zwei übereinanderliegende ways gemappt wird, nur einer von beiden kann in mkgmap gewinnen. ;-) solange man keine gestrichelten Linien nutzt und die Reihenfolge richtig macht. Ich dachte eigentlich, dass mkgmap mittlerweile mehrere tags gleichzeitig auswerten kann. Für das hier erforderliche hintereinander müsste man wohl ein Preprozessing der Art machen, dass boundaries z.B. zuerst extrahiert / kopiert werden, so dass ggf. manche Objekte dadurch doppelt (einmal als highway, einmal als boundary) erscheinen. Gerade bei den coastlines ist das ja die Realität. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] FreieTonne - Sektoren und Farben von Leuchtfeuern - wie ermitteln?
Am 11. Mai 2009 12:19 schrieb Olaf Hannemann ohannem...@gmx.de: Vorsicht beim Abschreiben ist trotzdem geboten. Die Daten sind teilweise etwas ungenau. Der erste grüne Sektor des Leuchtfeuers Kiel Friedrichsort endet z.B bei 196° statt den 191,5° der übrigen Verzeichnisse. was sind schon 5 Bogengrad. Man sollte nicht überall so penibel sein ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Featurevorschlag Gewichtung für OSB (was: neuer OSB Service)
Bernd Wurst schrieb: Mir ist klar, dass ein OSM-Bugtracker immer einfach bleiben muss, damit ihn die Leute auch nutzen. Was haltet ihr dennoch von folgender Verkomplizierung: Man sollte Reports eine Gewichtung geben können. Sowas wie * falsch eingetragene / veraltete Daten * Kleinigkeit (Straßenname, POI, ...) * fehlende / unvollständige Straße(n) * Sonstiges So dass man als Bug-Hunter sofort entscheiden kann, ob man das ohne Ortskenntnis bzw. ohne GPS-Daten reparieren kann oder nicht. Mich stört immer mal wieder die Flut an Der Weg geht hier noch weiter- Reports, die einfach niemandem was bringen außer demjenigen selbst. Das ist ein Feature, das man - falls es jemand schreibt - erfahrenen Benutzern (sprich: Leuten mit Account) vorbehalten sollte. Für den Erstreporter ist jedes zusätzliche UI-Element potentiell abschreckend. Besonders, wenn noch Faktoren wie unvollständige Lokalisierung hinzu kommen. Auf diese Weise stört ein nicht kategorisierter Bug maximal einen erfahrenen Nutzer ein einziges Mal, der kann ihn dann ja weg-kategorisieren. Bei dieser Einsortierung kann man auch gleich fehlerhafte Reports, Spam etc. filtern, so dass auch in dieser Hinsicht nur eine einmalige Begutachtung stattfinden muss. Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neues motorroad-Rendering verstaendlich?
Am 11. Mai 2009 17:13 schrieb Martin Koppenhoefer dieterdre...@gmail.com: m.E. kann motoroad für tertiaries auch nicht vorkommen, da sonst mind. Secondary/Primary. Selbst bei Secondaries tue ich mich schwer, diese dort zu belassen sollten sie eine motorroad sein. M.E. motorroad=yes - mind. primary. Manchmal gibts kurze Abschnitte einer secondary, z.B. ein kleiner Tunnel, in der Tat seltener andere Straßen, an Flughäfen manchmal aber auch Vorfahrten (unclassified), die als Kraftfahrstraße ausgeführt werden. Grund ist dann da eher das Aussperren bestimmter Fahrzeuge als das schnelle Vorankommen. Da tue ich mich dann schwer die mangels Verbindungscharakter höher zu klassifizieren. ;-) Zugegeben, das kommt (sehr) selten vor. Bob ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Nachrichten vonb Gary68
Hallo alle zusammen, anbei die Nachrichten von Gary68... - bin an der Umstellung (Parallelbetrieb) mit dem neuen Openstreetbugs. - bei checkcross.pl gibt es nun auch einen Link zum MAPCOMPARE TOOL der GEOFABRIK. - bei checkcross.pl gibt es nun eine Spalte mit bugs in der unmittelbaren Nähe. Sowohl vom alten wie auch vom neuen OSB. Kann man auch gut vergleichen. Gestern fehlten z.B. noch einige Bugs beim Neuen... So kann man sehen, ob ein Bug schon gemeldet wurde. - bei meinem PERL Modul habe ich eine Anpassung vorgenommen, dass ausländische Sonderzeichen nun komplett erkannt werden können. Dank an FREDERIK! Total bug count liegt bei 59.100 im Augenblick. Alle bugs als GPX file http://www.gary68.de/osm/qa/gpx/allbugs.gpx ODER ein Extrakt daraus: http://www.gary68.de/osm/qa/gpx/extract.htm ODER als PERMALINK http://www.gary68.de/osm/qa/gpx/extract.php?left=7right=8top=49bottom=48 Relation Check http://wiki.openstreetmap.org/wiki/Relation_Check Mapping Quality http://wiki.openstreetmap.org/wiki/Mapping_Quality MotorwayCheck http://wiki.openstreetmap.org/wiki/MotorwayCheck OSB Reports http://wiki.openstreetmap.org/wiki/OSB_Reports Osmdiff http://wiki.openstreetmap.org/wiki/Osmdiff_reports Relationen Diff http://wiki.openstreetmap.org/wiki/Relation_Diff SomeChecks (Area) http://wiki.openstreetmap.org/wiki/SomeChecks SomeChecks (double nodes in ways) http://wiki.openstreetmap.org/wiki/SomeChecks Roundabout Check http://wiki.openstreetmap.org/wiki/SomeChecks Unmapped Places http://wiki.openstreetmap.org/wiki/Unkartografiert WayCheck http://wiki.openstreetmap.org/wiki/DE:WayCheck Ciao Gerhard Gary68 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] US-Beh?rde bef?rchtet GPS-Ausf?lle
Tobias Wendorff tobias.wendo...@uni-dortmund.de wrote: Warten auf Gallileo... http://golem.mobi/0905/67007.html Jungs, beeilt euch, OSM-Deutschland muss Ende des Jahres fertig sein! ;-) MfG Heiko Jacobs Z! IRCnet Mueck -- Douglasstr. 30, D-76133 Karlsruhe fon +49 721 24069 fax 2030542 Geo-Bild Ing.b?ro geo-bild-KA.de Internet-Service auch-rein.de Couleurstud. Infos cousin.de VCD, umweltverkehr KA umverka.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Garminmaps Comparison Matrix
Hi, erfreulicherweise hat es einige Fortschritte im Bezug auf Garminkarten in letzter Zeit gegeben. Für den normalen Nutzer ist allerdings nicht leicht auf einen Blick die Vor- und Nachteile der Karten herauszufinden und die passende für ihn auszuwählen. Ich schlage daher vor ein Comparison Matrix im Wiki sowohl für routingfähige als auch normale zu erstellen. Ich habe das schon für die online Route Service getan und finde, dass es ganz gut funktioniert: http://wiki.openstreetmap.org/wiki/Routing/OnlineRouters Es gibt schon eine Tabelle hier http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/Download , allerdings bietet die nicht so gut vergleichbare Infos Ich hab leider fast gar keinen Überblick über die verschiedenen Karten im Moment, am besten ist es wohl, wenn jeder seine Karte einträgt. Zumindest die Tabellen hab ich mal hierher kopiert. Falls der Ort nicht passt, kann man die Tabelle später ja immer noch umziehen lassen: http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/Download/Comparison_Matrix Die kleinen Karten für einzelne Länder, die nur mit den Standardeinstellungen von mkgmap durchlaufen, würde ich jetzt erst einmal der Übersicht wegen rauslassen. Wenn das Matrix ein Germany-only wird ist es auch erst einmal nicht schlimm, schließlich gibt es auch meisten Mapper in D. Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] US-Beh?rde bef?rchtet GPS-Ausf?lle
Am 11. Mai 2009 17:57 schrieb Heiko Jacobs heiko.jac...@gmx.de: Jungs, beeilt euch, OSM-Deutschland muss Ende des Jahres fertig sein! ;-) .und dann brauchen wir Papierkarten!! (Weil unsere GPS-Empfänger ja nichts mehr empfangen) ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] US-Beh?rde bef?rchtet GPS-Ausf?lle
Franz Eugen Hagenow schrieb: .und dann brauchen wir Papierkarten!! (Weil unsere GPS-Empfänger ja nichts mehr empfangen) ;-) E-Paper-Karten ... zum Falten :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zu OSM-WMS
Hallo, Kai Behncke wrote: ich frage mich, ob es möglich ist einen OSM-WMS in der Qualität hinzukriegen, wie die OSM-Daten, welche über Mapnik gerendert werden? Zusaetzlich zu allem schon Gesagten gibt es natuerlich noch die Moeglichkeit, sowas wie einen Protokoll-Adapter zwischen WMS und Tiles zu bauen. Sowohl Chris Schmidt (Metacarta/Tilecache) als auch Oliver White (OJW bei OSM) haben schon mal Prototypen vorgestellt, die nach aussen hin WMS sprechen, und die Antworten aus den Standard-Tiles zusammensetzen. Das funktionierte trotz der aufwendigen Bitmap-Rumrechnerei ziemlich flott und gibt einem natuerlich immer die Original-OSM-Ansicht. Nachteil ist halt die u.U. stattfindende Skalierung oder gar Reprojektion auf Bitmap-Ebene, die sich besonders bei Beschriftungen unangenehm auswirkt. Leider sind beide Projekte offenbar in der Versenkung verschwunden, man muesste die Autoren ggf. mal anpingen und nachfragen. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Micro-SD-Angebot bei ALDI-Sued / OSM-Aktion?
On 09-05-07 16:10:23 CEST, Robert Joop wrote: On 09-05-07 15:35:19 CEST, Bernd Wurst wrote: Hallo. Am Donnerstag 07 Mai 2009 11:17:18 schrieb Rotbarsch: Micro-SD á 2.000.000.000 Byte(*) [...] (*) Ich habe die Karten heute getestet: Die versprochenen 2GB passen nicht drauf! 2.000.000.000 Bytes sind 2 GB. 2 GB sind was anderes als 2 GiB. es würde mich wundern, wenn nicht sogar deutlich mehr als die versprochenen 2 GB drauf passen, genau gesagt die gut 7% mehr die 2 GiB größer sind. ich hab auch grad eine 2-GB-SD-karte bekommen. die kernel-meldung beim reinstecken hat mich stutzig gemacht: sd 0:0:0:2: [sdc] 3862528 512-byte hardware sectors (1978 MB) darauf hin hab ich nochmal nachgemessen: % dd if=/dev/sdc of=/dev/null bs=1k 1931264+0 records in 1931264+0 records out 1977614336 bytes (2.0 GB) copied, 215.571 s, 9.2 MB/s es sind tatsächlich weniger als 2 GB, es fehlen gut 1,1%! asche auf mein haupt, ich ziehe meine vorigen einwürfe zurück. aber ist ja echter beschiss! was kommt als nächstes, haben bald auch RAM-riegel kein ganzzahliges vielfaches von 2 hoch n bytes mehr...?! (marke ist SanDisk, also nicht irgendein noname-produkt...) rj ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Featurevorschlag Gewichtung für OSB
Am 11.05.2009 17:42, Tobias Knerr: Bernd Wurst schrieb: Mir ist klar, dass ein OSM-Bugtracker immer einfach bleiben muss, damit ihn die Leute auch nutzen. Was haltet ihr dennoch von folgender Verkomplizierung: Man sollte Reports eine Gewichtung geben können. Sowas wie * falsch eingetragene / veraltete Daten * Kleinigkeit (Straßenname, POI, ...) * fehlende / unvollständige Straße(n) * Sonstiges So dass man als Bug-Hunter sofort entscheiden kann, ob man das ohne Ortskenntnis bzw. ohne GPS-Daten reparieren kann oder nicht. Mich stört immer mal wieder die Flut an Der Weg geht hier noch weiter- Reports, die einfach niemandem was bringen außer demjenigen selbst. Das ist ein Feature, das man - falls es jemand schreibt - erfahrenen Benutzern (sprich: Leuten mit Account) vorbehalten sollte. Für den Erstreporter ist jedes zusätzliche UI-Element potentiell abschreckend. Besonders, wenn noch Faktoren wie unvollständige Lokalisierung hinzu kommen. Es gibt keine Leute mit Account bei OSB, da das Login von OSM bisher noch nicht von externen Anwendungen verwendet werden kann. Ich sehe keinen Verkomplizierung des Formulars durch ein zusätzliches Dropdown mit einem sinnvollen Standardwert wie Allgemeiner Fehler. Ich vermisse eine derartige Funktion auch. Leider muss dafür aber die OSB-Datenbank angepasst werden. Ist Xav dafür offen, Mitja? Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Micro-SD-Angebot bei ALDI-Sued / OSM-Aktion?
Robert Joop schrieb: was kommt als nächstes, haben bald auch RAM-riegel kein ganzzahliges vielfaches von 2 hoch n bytes mehr...?! http://de.wikipedia.org/wiki/KiB#SI-Pr.C3.A4fixe_zur_Basis_10 man mebibyte (MiB) man megabyte (MB) Grüße Philipp ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Straße verschwunden
Hallo, ich habe ein wenig in Kaisersesch getaggt, als mein Potlach einen Verbindungsfehler anzeigte. Daraufhin habe ich erneut auf Edit geklickt um den Kartenausschnitt neu in den Editor zu laden. Allerings musste ich feststellen, dass die Straße, die ich zuletzt angeklickt hatte verschwunden ist, und stattdessen nur die Nodes übriggeblieben sind. Dummerweise ist die Straße nicht aufgetrennt worden und ziemlich lang, sonst hätte ich sie kurz manuell nachgetragen. Ein Drücken von u zeigt die Straße leider auch nicht an. Hat jemand eine Idee wie ich das wieder reparieren kann? Beste Grüße, Simon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straße verschwunden
achja, der Kartenausschnitt ist: http://www.openstreetmap.org/?lat=50.22008lon=7.14611zoom=16layers=B000FTF Beste Grüße, Simon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Micro-SD-Angebot bei ALDI-Sued / OSM-Aktion?
Hallo. Am Montag 11 Mai 2009 19:52:00 schrieb Philipp: http://de.wikipedia.org/wiki/KiB#SI-Pr.C3.A4fixe_zur_Basis_10 man mebibyte (MiB) man megabyte (MB) In dem Fall ist das aber berechtigt: | 1977614336 bytes (2.0 GB) copied, 215.571 s, 9.2 MB/s In einzelnen Bytes ausgedrückt, sollte eigentlich eine 2 ganz vorne stehen, oder? Gruß, Bernd -- Only one book has been printed in more copies than The Bible... ...the IKEA catalogue - Song Facts of Life by Lazyboy signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straße verschwunden
Simon Kokolakis schrieb: ich habe ein wenig in Kaisersesch getaggt, als mein Potlach einen Verbindungsfehler anzeigte. Daraufhin habe ich erneut auf Edit geklickt um den Kartenausschnitt neu in den Editor zu laden. Allerings musste ich feststellen, dass die Straße, die ich zuletzt angeklickt hatte verschwunden ist, und stattdessen nur die Nodes übriggeblieben sind. Dummerweise ist die Straße nicht aufgetrennt worden und ziemlich lang, sonst hätte ich sie kurz manuell nachgetragen. Ein Drücken von u zeigt die Straße leider auch nicht an. Hat jemand eine Idee wie ich das wieder reparieren kann? Das nicht, aber ich habe auch das Gefühl das in Potlach der Wurm drin ist. Immer dann, wenn ich Knoten in eine vorhandene Straße durch Fang mit einer neuen Straße einfüge lande ich in einer Schleife das die Verbindung zum OSM-Server getrennt sei. Die Änderungen sin dann auch weg. Als Workaround füge jetzt immer erst den Knoten ein, dann lege ich die neue Straße drauf. Wahrscheinlich wäre es besser, sich endlich mal mit JOSM zu beschäftigen... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Featurevorschlag Gewichtung für OSB
Claudius schrieb: Am 11.05.2009 17:42, Tobias Knerr: Bernd Wurst schrieb: Was haltet ihr dennoch von folgender Verkomplizierung: Man sollte Reports eine Gewichtung geben können. Das ist ein Feature, das man - falls es jemand schreibt - erfahrenen Benutzern (sprich: Leuten mit Account) vorbehalten sollte. Für den Erstreporter ist jedes zusätzliche UI-Element potentiell abschreckend. Besonders, wenn noch Faktoren wie unvollständige Lokalisierung hinzu kommen. Es gibt keine Leute mit Account bei OSB, da das Login von OSM bisher noch nicht von externen Anwendungen verwendet werden kann. Ich meinte selbstverständlich einen Account bei OSM, und ich sehe bisher kein fundamentales Problem darin (außer: Arbeitsaufwand), hier eine Schnittstelle zu schaffen. Alternativ kann man auch andere Kriterien als die Anmeldung wählen, beispielsweise die erweiterten Funktionen in Editorfunktionalität packen, wenn man von der Annahme ausgeht, das die Schnittmenge zwischen den Experten-Feature-Nutzern und denen, die OSB über Editoren (bzw. Editor-Plugins) ansprechen, groß genug ist. Ich sehe keinen Verkomplizierung des Formulars durch ein zusätzliches Dropdown mit einem sinnvollen Standardwert wie Allgemeiner Fehler. Nun, ich schon. Jede zusätzliche GUI-Komponente ist eine Verkomplizierung. Selbst wenn ich sie nie anfasse, muss ich doch erst mal hinschauen, ob es mich interessieren sollte. Außerdem ist das bestimmt nicht der letzte Featurewunsch, und da ist es doch keine schlechte Idee, schon mal über eine Ausgleichsmöglichkeit zwischen den Anforderungen der Power-User und denen, die eine unkomplizierte Fehlermeldestelle brauchen, nachzudenken? Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] barrier=bollard
Hast du schon ein entsprechendes Ticket erstellt? Ansonsten kann dir die Frage nur der Mapnik-Style-Maintainer beantworten, sofern er den Bedarf schon kennt. Jetzt ja, wußte vorher nicht wie es geht. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] neuer OSB Service
Hallo. Am Montag, 11. Mai 2009 schrieb Florian Lohoff: ich habe auf der maxspeed karte angefangen das OSB zeugs neu zu bauen (client/javascript teil) weil ich es schoen faende wenn man das OSB zeugs einfach integrieren koennte in jegliche karte - manchmal wuerde es sinn machen bugs von der OpenCycleMap oder von der Maxspeed map aufzumachen. Das wäre wirklich praktisch. Die CycleMap habe ich zwar zur Auswahl, aber jede beliebige Karte zu unterstützen geht natürlich nicht. Die API lässt sich momentan auch von anderen Seiten aus nutzen, leider nur mit Proxy, weil es sonst wie ein XSS-Versuch aussieht (das klang bei dir auch schon an). Wenn du den Client-Teil übernehmen willst, würde ich mich sehr freuen. Das Javascript habe ich (fast) nicht angefasst, der Code stammt von Xavier und Christoph. Ich persönlich lasse da auch lieber die Finger von. Wenn es eine andere API erfordert, sollte es auch kein Problem sein beide Möglichkeiten übergangsweise gleichzeitig anzubieten. Versionsnummern habe ich schonmal vorsorglich eingeführt. Mitja ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] FreieTonne - Sektoren und Farben von Leuchtfeuern - wie ermitteln?
HalloMartin; On Monday 11 May 2009 17:31:19 Martin Koppenhoefer wrote: Am 11. Mai 2009 12:19 schrieb Olaf Hannemann ohannem...@gmx.de: Vorsicht beim Abschreiben ist trotzdem geboten. Die Daten sind teilweise etwas ungenau. Der erste grüne Sektor des Leuchtfeuers Kiel Friedrichsort endet z.B bei 196° statt den 191,5° der übrigen Verzeichnisse. was sind schon 5 Bogengrad. Man sollte nicht überall so penibel sein ;-) Naja, wenn 50 cm weiter die Enten gründeln kann das schon eine ganze Menge sein. ;-) Aber hast ja recht. Solange ich im richtigen Sektor fahre ist es eigentlich egal wo ich mich gerade genau befinde. Gruß Olaf ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
