[Talk-de] Tracks Anonymisieren
Ich lese immer wieder davon das Leute ihre Tracks anonymisieren wollen... Eigentlich gehen dabei interessante Informationen verloren! Z.B. könnte man aus dem Originaltrack ableiten in welche Richtung eine Straße befahrbahr ist. Ebenso wie schnell man an welcher Stelle maximal fahren kann. Das ist absolut interessant für unsere Karten, ich denke an späteres Routing! Im übrigen kann man aus den Tracks nicht herleiten was jemand wo getan hat und ob er anwesend war oder nicht! Schließlich kann ich jedem das GPS in die Hand drücken, und ich tu es auch! Z.B. kann man bekannten LKW Fahrern das Gerät in die Hand drücken und auf diese Weise Tracks aufzeichnen lassen. Außerdem macht GPS auch manchmal Fehler. Es zeigt eine Bewegung an, obwohl wir stehen, niemand kann letztlich aus den aufgezeichneten Daten etwas herleiten, daher ist Blödsinn sich allzu viel Gedanken drum zu machen. Da gibt es andere Dinge die problematischer sind, wie z.B. die Überwachung unserer (auch dieser!) Kommunikation! Gruß Sven S. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Spinnt der Server?
Ich versuche gerade Daten mit JOSM hoch und runter zu laden. Kommt immer die Fehlermeldung interner Serverfehler 500. Hat jemand ähnliche Probleme? Gruß Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Tracks Anonymisieren
Message: 3 Date: Sun, 18 Nov 2007 03:04:52 +0100 From: Marcus Krause [EMAIL PROTECTED] Subject: Re: [Talk-de] Tracks Anonymisieren To: talk-de@openstreetmap.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=UTF-8; format=flowed Sven Sommerkamp wrote: Ich lese immer wieder davon das Leute ihre Tracks anonymisieren wollen... Eigentlich gehen dabei interessante Informationen verloren! Z.B. k?nnte man aus dem Originaltrack ableiten in welche Richtung eine Stra?e befahrbahr ist. Ebenso wie schnell man an welcher Stelle maximal fahren kann. Dies ist u.a. ein Problem. Angenommen ich fahre beim tracken mit 80 km/h durch die Ortschaft, so m?chte ich nicht dass man dies anhand des Tracks nachvollziehen kann. ;-) Kann man nicht, denn es kann ja auch jemand anderes das GPS benutzt haben. Und GPS Geräte zeichnen auch mal fehlerhaft auf. Es kommt vor das du an der Kreuzung stehst und dein GPS sagt du fährst. Und wenn du mit 80 durch die Ortschaft bretterst machst du auch etwas falsch, oder? Au?erdem ist die gefahrene Geschwindigkeit von etlichen Faktoren abh?ngig, nicht nur von der maximal erlaubten Geschwindigkeit! Denke an: Fahrzeug (LKW, PKW, Mofa, gedrosselte Fahrzeuge), Verkehr (Stau, liegengebliebenes Fahrzeug, Sonntagsfahrer), Witterungsbedingungen (Schnee, Sonne), Fahrbahnzustand (defekte Stra?e, Bauarbeiten an der Stra?e, Gef?lle, Anstieg), Bebauung (Ampel, Bumper), geh?rtes Radioprogramm, etc. ... ;-) Das stimmt! Trotzdem ist diese Information nicht uninteressant! Ein Track sagt nur aus, das diejenige Person an diesem Tag zu dieser Zeit diese Geschwindigkeit gefahren ist - ein klitzekleiner Spezialfall. Nicht einmal das! Das GPS hat sich an diesem Tag dort entlangbewegt, nicht mehr! Drehst Du nur an einem der o.g. Faktoren, bekommst Du was anderes heraus. Damit ist das Ableiten einer maximal erlaubten Geschwindigkeit anhand eines Tracks meines Erachtens v?llig unm?glich. Gru?,... ...Marcus. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Beobachtungen eines Newbies
Message: 4 Date: Sat, 17 Nov 2007 21:28:50 +0100 From: Dimitri Junker [EMAIL PROTECTED] Subject: Re: [Talk-de] Beobachtungen eines Newbies To: Florian Schmitt talk-de@openstreetmap.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 Denn das h?tte zur Folge, dass die Tools (Editoren, Renderer) entweder nicht mehr universell einsetzbar sind oder an x-beliebig viele nationale tag-sets angepasst werden m?ssen, war auch den technischene Aufwand f?r das Rendering erh?hen d?rfte. Man j?nnte siherlich in JOSM ein W?rterbuch einbauen. Man k?nnte dann deutsch eingebn und es w?rde englich zum Server ?bertragen. Von mir aus kann es aber so bleiben. Die Presets sind das mögliche eingebaute Wörterbuch. Scheint bloß noch keiner erkannt zu haben. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Ich muß zugeben, nach einer gewissen Z eit des herumprobierens komme ich langsam mit dem neuen JOSM klar
Ich muß zugeben, nach einer gewissen Zeit des herumprobierens komme ich langsam mit dem neuen JOSM klar! Aber ein paar Dinge sind mir noch nicht ganz klar.. Mit den Relations z.B. kann ich noch nicht wirklich etwas anfangen, zumal mein JOSM da gerne mal abstürzt. Man kann mit den Relations festlegen wo man wie abbiegen kann? Wie funktioniert das alles? Hat da schon mal jemand etwas in Deutsch zu geschrieben? Die englische Erklärung erschließt sich mir nicht wirklich.. Gruß Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Georeferenzierte Bilder
Gibt es auch für Linux ein Tool um mit Hilfe eines Tracks aus Bildern georeferenzierte Bilder zu machen? Also, so das die Koordinaten dann in den Exif Daten des Bildes eingefügt werden? Gruß Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Der aktuelle Datensatz fürs Garmin funkt ioniert nicht bei mir
Ich habe mir den Aktuellen Datensatz fürs Garmin runtergeladen, entpackt und aufs garmin geladen. Leider funktioniert der Satz nicht. Hab wieder die vorherige Karte drauf gepackt. Hab nur ich das Problem? Gruß Sven S. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Talk-de Digest, Vol 16, Issue 123
Am Sonntag, 25. November 2007 15:27:51 schrieb [EMAIL PROTECTED]: Message: 5 Date: Sun, 25 Nov 2007 14:53:15 +0100 From: Guenther Meyer [EMAIL PROTECTED] Subject: Re: [Talk-de] Mal ganz anders To: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 Am Sonntag 25 November 2007 schrieb Frederik Ramm: Hallo, aufgrund der momentanen struktur koennte man den datenbank teil problemlos erstmal zurueckstellen, und ueber ein klares durchgehendes tagging-schema schon viel erreichen. Oh, dann haben wir aneinander vorbeigeredet, ich dachte, Du wolltest grundlegender ansetzen als bloss an den Tags herumzuschrauben. Meiner Ansicht nach muesste, wenn man es richtig machen will, auch das ganze Objektmodell umgestellt werden. wenn man's richtig machen will, ja. aber das liesse sich dann immer noch in einem zweiten schritt machen. Ich wollte an der Tatsache, dass jeder Taggen kann, was er will, gar nicht ruetteln, sondern praktisch einen Layer untendrunter erstmal etwas einfuehren, was Hand und Fuss hat. Genau, das wäre auch meines Erachtens wichtig! Naja, aber wie gesagt, ich hatte das ja eh aufgegeben. Wenn man bloss Tag-Kataloge erstellt, wird es vermutlich noch schwieriger, echten Mehrwert zu demonstrieren. es geht eben nicht nur um einen blossen tag-katalog, der ist nur die basis, die einheitlich vom mapping bis zur endanwendung benutzt werden muss. dazu muessen sowohl die editoren, als auch die renderer und was sonst noch kommt, entsprechend angepasst werden. ein grundkatalog, der alle momentan sinnvollen moeglichkeiten enthaelt, wird ausgearbeitet, ein wildes hinzufuegen von selbst erfundenen tags lassen die editoren nicht zu. gut, als zusatzinfos meinetwegen, aber zumindest sollte jedes element entsprechende tags aus der vorgegebenen auswahl haben. Das wäre auch mal wichtig. Wir brauchen eine einheitlichere Datenstruktur. da man natuerlich unmoeglich alle eventualitaeten beruecksichtigen kann, soll das ganze durchaus erweiterbar sein. Änderungen können diskutiert werden und dann bei Konsens in die Presets einfließen aber eine erweiterung kann nur in den katalog eingefuegt werden, wenn sie komplett ist, d.h. sowohl bezeichnung, tag, renderingregel/icon usw. vorhanden ist. Als Katalog schlage ich die Presets vor. ein fiktives beispiel zur anwendung: ein deutscher mapper zeichnet eine autobahn. aus einer dropdown-liste mit vorgegebenen typen waehlt er den eintrag autobahn aus. ein zweites, beschriftetes eingabefeld erm?glicht ihm die eingabe der Nummer, also z.B. A9. wenn ein englaender dasselbe mit seiner josm-version macht, steht halt motorway in der liste. Und das läßt sich gut mit den Annotation Presets machen! intern wird das ganze immer mit den tags way=highway.motorway und ref=A9 gespeichert. nur bekommt der normale benutzer diese tags nie zu gesicht. aber ein rendere oder eine navi-software wissen ganz genau, was sie mit diesen daten anzufangen haben. dasselbe gilt natuerlich nicht nur fuer strassen, sondern auch fuer alles andere. wie das z.B. fuer POIs aussehen kann, sieht man ansatzweise in gpsdrive bzw. der zugehoerigen icons.xml ich hatte schon ueberlegt, das (zumindest fuer mein poi-schema) selbst zu machen, aber ich habe echt nicht den nerv, mich in jede einzelnen dieser anwendungen einzuarbeiten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Klare highway tagging Regeln fßr befesti gte, Straßen
Hier wurden einige Interessante Ansätze zur Lösung des Problems vorgeschlagen, ich komme jetzt wieder mit den Presets. Ich glaube die wenigsten von euch haben sich bisher damit beschäftigt, aber ich sage das macht Sinn. Denn statt immer wieder endlose Debatten zu führen, wäre es sehr viel effektiver wir würden uns auf Regeln einigen und die in die Presets fließen lassen. Dann gibt es einen einfachen Weg Straße zu taggen und auf einfache angenehme Art und Weise. Anfängern wird der Einstieg sehr erleichtert, denn die Grundmöglichkeiten eine Straße zu taggen werden mit Bild, wenn man will, vorgegeben. Meistens wird dies das gewünschte Ergebnis erzielen, ich denke zu 95%. Wenn nicht ist Handarbeit aber immer möglich. Wir sollten auch überlegen das Ganze nicht zu sehr zu verkomplizieren. Und Änderungen im Tagging nur dann vorzunehmen, wenn sie wirklich Sinn machen. Ein wenig Kontinuität tut dem Projekt auch gut. Wir wollen uns keine überflüssige Arbeit machen sondern vorankommen. Wir sollte auch überlegen ob wir wirklich überall, alles nochmal aufbröseln, wollen, welcher Nutzen ist damit wirklich verbunden? Wichtig ist Durchschaubarkeit und intuitive Kartiermöglichkeiten. Und das wir einen Rahmen schaffen uns zu einigen, diese Einigungen sollten in die Presets fließen, sie könnten den De Mapfeatureskatalog ablösen, bzw eine Möglichkeit sein diesen weniger zu benutzen zu müssen. P.S:Ich suche noch einen Ort wo man diese Presets unterbringen und pflegen kann, jemand ne Idee? Gruß Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] yahoo images
Konnte man nicht die Images auch transparent hinterlegen? So kann man die ja nur schwer gebrauchen. Gruß Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Tomtom Mapshare
Interessant und vielleicht ärgerlich, vor Jahren habe ich mal eine ähnliche Idee wie die Fa. Tomtom mit Mapshare gehabt, und sie glaube ich Jörg Ostertag oder Fritz Ganter als Idee für GPSDrive geschickt. Nun haben die sich das nochmal ausgedacht und patentieren lassen. Na jedenfalls, es wäre doch klasse wenn man die neuen Geräte für unser Projekt nutzen könnte? Ideen dazu? Eigentlich müßte man in mehreren Schritten vorgehen. Erstens wir müßte in der Lage sein Karten aus unsere Daten zu generieren die auf den Tomtoms laufen. Zweitens müßten wir die Schnittstelle der Geräte nutzen und mit dem Datenformat etwas anfangen können. Aber etwas in der Richtung halte ich wie gesagt schon lange für sinnvoll. Wäre ja auch eine Idee so etwas für PDA's zu programmieren..! Gruß Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] JOSM: Restrictions
Da tun sich ja echt abgr?nde auf. ?Softwarefehler, die zu datenverlusten f?hren, sind schlimmer als security-probleme. Jetzt, wo wir erkannt haben, dass das feature potentiell gef?hrlich ist, sind die entwickler gefordert. ?Es gilt das gleiche, wie bei potlatch: wenn sich das problem nicht einfach fixen l?sst, muss es (vor?bergehend) abgeschaltet werden. Es w?re sch?n, wenn die josm-entwickler reife zeigten und verantwortung ?bern?hmen. Da muß ich auch mal kurz meinen Senf zu abgeben! Es wäre schön, wenn der Kritiker Verantwortung übernehmen würde für seine unbedachten Worte! Nur um mich mal auf sein Niveau zu begeben! Ich kann nur ebenso Chrsitoph und Frederick sagen, die Art und Weise wie du deine Kritik äußerst ist nicht korrekt und Ihrer Leistung angemessen! Im übrigen denke ich ist sie auch in der Sache so nicht angemessen! So nun laßt uns die Presets weiterentwickeln, denn sie stellen eine gute Hilfe zum Tagging dar! Für viele Anfänger wirds einfacher einzusteigen und die Profis haben auch etwas davon! Im übrigen kann man auch alles manuell machen und durch vergleichen sieht man ja die Veränderungen die die Presets machen. Also zeige du einmal Verantwortung und sorge dafür das besser wird was du für schlecht hältst Gruß Sven S.! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Wird highway roundabout nicht verwendet?
Ich habe die Saseler Straße und Kriegkamp in Hamburg mit highway roundabout getaggt. In der gerenderten Karte ist aber kein Weg zu sehen, wird highway roundabout nicht verwendet? oder nur nicht gerendert? Nun hab ich da erstmal einen highway tertiary draus gemacht. Gruß Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Hat mit QLandkarte jemand zugriff auf ein GPMAP60CX?
Ich versuche QLandkarte mit einem GPSMAP60CX zu verwenden. Aber ich weiß nicht was ich da als Schnittstelle und so einstellen soll.. Jemand einen Tip? Gruß Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Berliner Stadteil fast komplett gel?scht
Am Samstag, 20. Dezember 2008 18:03:11 schrieb talk-de-requ...@openstreetmap.org: Frederik Ramm wrote: Man kann anhand des t?glichen diff-Files alle ?nderungen ermitteln, die dieser User vorgenommen hat, und kann alle Objekte auf den Stand von vor der ?nderung zur?cksetzen. Ich habe daf?r ein Skript, aber ich kann mich erst heute abend darum k?mmern. Das Skript funktioniert auch nur dort, wo nicht von anderen Benutzern von Hand schon Korrekturen gemacht wurden. Besonders schlimm ist es in so einem Fall, wenn gel?schte Objekte von wohlmeinenden Usern von Hand neu eingezeichnet werden, weil dann n?mlich ein undo per Skript daf?r sorgt, dass ein Weg doppelt vorhanden ist... Per Hand wurde dort m.E. nichts neues eingezeichnet, nur einiges mit der undo-Funktion von Potlatch wieder hergestellt. Falls dort nun was doppelt sein sollte, werde ich mich darum k?mmern, da? es wieder verschwindet. Sehr vieles gab es ja in der Gegend noch nicht. Ich rate dazu, m?glichst erstmal nichts zu unternehmen (bzw. mal den User zu kontaktieren und zu fragen, was da passiert ist). Heute abend analysieren wir mal den Schaden und stellen ggf. die alten Versionen wieder her. Mit dem User habe ich schon Kontakt aufgenommen. Er hatte auf meine Anfrage geschrieben, das es ein versehen gewesen ist und irgendein Prof. gesagt hat sie(?) sollen mit Josm arbeiten, wobei dieser Unfall dann geschehen ist. Danach schrieb ich, das er seinen Prof mal wegen der Reparatur fragen soll, allerdings kam keine Antwort mehr. Gibt es eigentlich einen Grund, warum sich manche Objekte wiederherstellen lassen und manche nicht, auch wenn sie an im gleichen Zug gel?scht worden sind? Gru? Sascha Unfall ist gut, ich unterstelle ihm da ja nichts b?ses, aber man muss doch mindestens eine ganze Stange features markieren (was ja durchaus versehentlich vorkommen kann (wenn man nicht genau weiss, was man da macht), aber danach muss man doch auch noch entfernen oder l?schen dr?cken. Und dann auch noch alles hochladen. M.E. ist die Wahrscheinlichkeit f?r einen echten Unfall in Potlatch gr??er. Martin Und ich muß immer wieder sagen, die Notwendigkeit von Mechanismen gegen solche gewollte oder ungewollten Unfälle besteht in zunehmenden Maße! Es sollte ab einem gewissen Bearbeitungszustand von Objekten nicht mehr so ohne weiteres möglich sein die sofort zu ändern. Das läßt sich sicher programmieren, ich würde mich sehr wundern, wenn es dazu nicht bereits Ansätze gäbe.. Und dafür soll es dann dort einfacher sein, neues in die Karte einzutragen, wo weiße Flecke in der Karte existieren. So erreicht man das einerseits, das genügend Möglichkeiten bestehen, als Neuling anzufangen, aber gleichzeitig werden die Objekte in der Karte geschützt die schon sehr weit entwickelt sind. Ohne das werden wir uns Meiner Meinung nach, immer im Kreis drehen. Und das führt früher oder später dazu, das diejenigen die große Erfahrung und Wissen haben dem Projekt verloren gehen und Gleichzeitig diejenigen die es erst lernen, keine Ansprechpartner mehr finden die ihnen auf den Weg helfen können. Dann stirbt so ein Projekt und die Daten veralten, schon bald kann sie niemand mehr gebrauchen. Das Projekt lebt von Kontinuität und in richtigem Maße Innovaton. Es braucht die Erfahrung von Leuten die sehr fortgeschritten sind und auch neue Interessierte! Es liegt aber im Interesse aller, das nicht mit wenigen Klicks eine weit entwickelte Karte in einigen Bereichen fehlerhaft wird, oder zerstört, gelöscht wird. So wie es auch im Interesse aller liegt das Flecken gefüllte werden und das neue einen Ansatz finden. Dann funktioniert auch der Wikispirit! Gruß Sven S. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreuzung Radwege
Am Mittwoch, 24. Dezember 2008 13:00:01 schrieb talk-de-requ...@openstreetmap.org: On Tue, Dec 23, 2008 at 11:10:10PM +0100, Wolfgang Wienke wrote: Sascha Rogmann schrieb: Beispiel: Radwege am Ring in M?nster. http://www.openstreetmap.org/?lat=51.972437lon=7.633982zoom=18layers =00B0FTF Endlich finde ich mal einen Detail-Radwegmapper. Ich kenne nat?rlich nicht die Kreuzung in M?nster. Mapps Du so auch Radwege, die direkt auf dem B?rgersteig liegen und von diesem nur z.B. durch die Farbe getrennt sind? - Ich w?rde das f?r sinnvoll halten, sehe daf?r aber oft nur ein DAZUGESETZTES cycleway=track oder highway=path mit bicycle=yes. An gr??eren Stra?en, z.B. Durchgangsstra?en, mappe ich auch Radwege, die auf dem B?rgersteig liegen, von diesem aber farblich getrennt sind. Dort sind dann leichte Schlenker zu sehen wenn f?r ein kurzes St?ck (z.B. 80m) der Radweg und der bisher nicht gemappte Fu?weg durch eine Baumreihe getrennt sind. Beispiel: Lublinring in M?nster mit vielen GPS-Traces im JOSM. Ein Baumreihenwechsel ist oben links (links vom WLAN-X). http://www.rogmann.org/osm/josm_lublinring.png (JOSM-Ansicht zur oben angegebenen Beispiel-URL). Gru?, Sascha Rogmann Also, ich weiß, diejenigen die meinen einen straßenbegleitenden Radweg als einen Extraweg anzulegen, meinen es gut! Aber ich denke das es in den meisten Fällen weit über das Ziel hinausschießt! Für den Mapper: Es macht viel extra Arbeit, in der Zeit könnte man die leeren Flächen füllen. Das würde einen größeren Nutzen haben! Und dann ist diese Arbeit durch kaum Nutzen zu rechtfertigen. Für das Kartenbild: In den meisten Fällen wird das Kartenbild nur unübersichtlich. Eine unübersichtliche Karte ist wieder schlecht nutzbar, kommerzielle Ersteller überlegen sich sehr gut, was sie in die Karte bringen und was nicht. Und zwar nicht, weil sie etwas verschweigen wollen oder zusätzlich teuer verkaufen (jedenfalls meistens) Fürs Routing mit Navigeräten: Der Routinganweisungen werden so kompliziert und folgen so schnell aufeinander das man das wiederum schlecht nutzen kann. Es ist günstiger der Radwegführung vor Ort zu folgen und die Routinganweisungen ein wenig simpler zu lassen, das ist in der Praxis hilfreicher. Übrigens geben Garmingeräte bei der Routenberachnung häufig auf, weil wir mit zuvielen Nodes und eben manchmal auch zuvielen Wegen arbeiten.. Das ist schade! Denn genau das wollen wir doch damit machen? Jeder, der vorhat, das so zu mappen, sollte sich das mal praktisch angucken und versuchen dies so zu nutzen. Inzwischen kann man das Routing mit Garmingeräten gut nachvollziehen. Es gab auch einen Workshop zu diesem Thema: http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Workshops/Linienb%C3%BCndel Das soll jetzt nicht bedeuten, das man das Vorhandensein eines Radweges nicht erfassen sollte! Das ist auf jeden Fall sinnvoll! Das läßt sich ja auch durch die vorhandenen tags gut machen. Siehe: http://wiki.openstreetmap.org/wiki/DE:Map_Features#Fahrradwege Übrigens ist das Radwegerouting noch so sehr unausgegoren, das man dort erstmal einen vernünftigen Konsens, besser eine Regelung, finden müßte um das sinnvoll machen zu können. Dazu gibt es auch Ansätze und interssante Gedanken: http://wiki.openstreetmap.org/wiki/DE:Bicycle/concept_routing Noch etwas: Wir versuchen immer die Wirklichkeit so genau wie möglich abzubilden. Das ist zwar löblich, aber am Ende ist wichtiger, das die Daten benutzbar sind und bleiben! Absolute Genauigkeit gibt es nicht! Dafür sind die Methoden und Geräte mit denen wir arbeite zu ungenau. Selbst wenn sie das Optimum erreichen verändern sich die Koordinaten laufend durch Kontinentaldrift. Das heißt sie müssen laufend gepflegt werden sonst veralten sie auch! (sehr langsam, aber immerhin) Radwege und ihre Verläufe haben sowieso eine noch geringere Halbwertzeit als das Straßennetz. Gleichzeitig sind sie häufig nicht benutzbar, z.B. wegen Bauvorhaben etc. Sehr vieles spricht dafür dies also so effizient und schlank wie möglich zu machen! Ebenso wie bei alles übrigen Daten! Dies sollte immer wieder vorher bedacht werden! Gruß Sven S. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM-Geschwindigkeit
Am Donnerstag, 25. Dezember 2008 00:17:17 schrieb talk-de-requ...@openstreetmap.org: Eine etwas vern?nftigere Datenstruktur und in einigen F?llen die Vermeidung von Kopieroperationen w?rde hier Wunder wirken. W?re es dann nicht eine Idee, so etwas wie eine plattformunabh?ngig Dev-Group zu bilden, die sich um solche Probleme (Datenstrukturen, Algorithmen) Gedanken macht? Dann k?nnen Editor-Entwickler sich mehr auf das Frontend (und was sonst noch alles dazu geh?rt) konzentrieren und Leute, die viel von den ben?tigten Datenstrukturen und Algorithmen verstehen, k?nnen sich an der Basis einbringen und einen Dienst f?r jedwede Sprache leisten, ohne gleich einen alternativen Editor entwickeln zu m?ssen oder Java zu lernen. Eher nicht. Das Hauptproblem ist nicht das Design, sondern die Implementierung. Ideen f?r bessere Strukturierung des JOSM-Codes habe ich reichlich (immerhin programmiere ich schon ein paar Jahre), nur die Umsetzung ist alles andere als trivial. Deswegen fangen viele Anf?nger auch lieber von vorn an. Das ist erstmal einfacher. Keiner will sehen, dass wenn ein wenig Zeit vergangen ist, das eigene tolle neue Projekt genau die gleichen Probleme hat, wie das alte. Nur hat sich das alte in der Zwischenzeit weiterentwickelt. In JOSM z.B. hat sich (auch durch meinen Mithilfe :-) dieses Jahr einiges getan. Permanent aufholen ist nicht so leicht wie mancher denkt. Statt st?ndig neuen Editoren w?ren Verbesserungen an JOSM viel hilfreicher. Bis n?mlich der gleiche Funktionsumfang nachprogrammiert ist, kann schon eine sehr lange Zeit vergehen. Meist wird das Projekt vorher einschlafen. Ich pers?nlich f?nde einen Alternativeditor nicht schlecht, da ich mit JOSM ehrlich gesagt, einige Probleme habe. Die Einstiegsh?rde ist mir etwas zu hoch. Hier k?nnte sich wahrscheinlich ein zweites oder drittes Editor-Dev-Team komplett losgel?st von JOSM neue Gedanken machen, die dann nat?rlich auch bei Erfolg in JOSM einflie?en k?nnen. Momentan haben wir 3+1 Editoren (Potlatch, JOSM, Merkaartor und JOSM-NG). Jetzt kommt noch einer dazu. Das sollte eine Weile reichen. Das Potential an Softwareentwicklern ist nicht unendlich und je mehr man sich hier zersplittert, desto schlechter sind die einzelnen Projekte. Andererseits belebt Konkurrenz das Gesch?ft. Der richtige Mittelweg ist nicht so leicht :-) Nur so als Hinweis - Obwohl ich JOSM mitentwickle finde ich 1) ein Java-Editor ist nicht der Weisheit letzter Schlu? 2) die interne Struktur ist (teilweise stark) ?berarbeitungsbed?rftig 3) eine Menge Designentscheidungen sind nicht optimal Nichtsdestotrotz bringe ich JOSM voran statt von vorn anzufangen. Wir haben alle mehr davon. Gebe ich dir recht. Ich rege mich nur immer extrem dar?ber auf, wenn so etwas in einer Mailing List aufkommt, da es, wie Hobby Navigator in seiner Mal schrieb, eine gewisse Frustschwelle gibt, an der ich bereits bei einem Projekt gescheitert bin. Daher bin ich Von Mails sollte man sich nicht abschrecken lassen. Unkonstruktives einfach ignorieren, den Rest zumindest ?berdenken oder beherzigen. Ciao -- http://www.dstoecker.eu/ (PGP key available) Auf Dauer wäre ein Editor, der in ein gut funktionierendes Navi auf OSM Basis integriert ist, sehr wichtig! Das wäre eine Vision und ein Wunsch für die Zukunft von mir. Ich habe festgestellt es gibt noch mehr Leute hier die eine ähnliche Idee bereits hatten! So etwas sollte man entwickeln, denke ich. Effizienter und schneller kann man vor Ort Änderungen wohl nicht erfassen. Ich denke an Tomtom Mapshare als Anregung wie so etwas gehen und funktionieren könnte. Gruß Sven S. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreuzung Radwege
Am Donnerstag, 25. Dezember 2008 16:07:33 schrieb talk-de-requ...@openstreetmap.org: Dimitri Junker schrieb: Hallo, F?r den Mapper: Es macht viel extra Arbeit, in der Zeit k?nnte man die leeren Fl?chen f?llen. F?r das Kartenbild: In den meisten F?llen wird das Kartenbild nur un?bersichtlich. das l??t sich auch kombinieren, wenn ein Bereich zu un?bersichtlich ist weiger ich mich dort zus?tzliches zu mappen. Man sollte sich wenn es 2 M?glichkeiten gibt etwas zu mappen ?berlegen wie ihr Informationsgehalt ist und wie der Aufwand ist. Das h?ufigste Argument f?r einzeln gemappte Fahrradwege ist: der ist baulich getrennt aber was steht da in den Map_Features: ycleway track Ein baulich abgesetzter Radweg (cycle track), z.B. durch einen Bordstein, der meist neben der Fahrbahn verl?uft. Kommt drauf an was man mit baulich getrennt genau meint. Ich verstehe darunter nicht nur einen etwas abgesetzten Radweg mit Bordstein, sondern eine tats?chliche Trennung. Sobald man n?mlich ?ber eine Mauer klettern oder mehrere Meter durch Wiese stapfen muss, kann man nicht mehr so einfach ?berall auf die Stra?e wechseln. Da ergibt es von der Bedeutung her schon Sinn einen extra Weg einzuzeichnen. Ganz genau! Ein Bordsteinradweg ist nicht baulich getrennt! Denn ich kann an fast beliebigen Stellen die Fahrbahn überqueren und z.B. zurück fahren. Das ist der springende Punkt! Wenn der Radweg nur abgesetzt ist, reicht auch das entsprechende Tagging der Stra?e. Das k?nnte dann auch entsprechend gerendert werden, z.B. durch ver?nderte R?nder der Stra?e (fett, farbig, was auch immer). Das ist z.B. bei den ADFC Karten so und funktioniert sehr gut! So w?rde man auch direkt den Unterschied zwischen baulich getrennt und baulich abgesetzt sehen und w?sste ob man hier die Stra?e problemlos ?berqueren kann (sofern es der Verkehr zul?sst nat?rlich). Ansonsten wei? man nie ob man einen Zaun oder nur ein paar Zentimeter Bordstein ?berwinden muss. Sicherlich k?nnte man sowas auch mit Relationen l?sen, die die Beziehung zwischen den einzelnen Wege beschreiben, aber das d?rfte h?chstens f?r wirklich komplexe F?lle notwendig sein. In sehr vielen F?llen d?rfte sich das mit maximal einer Handvoll Tags beschreiben lassen. Ob ein Weg ein paar Meter einen Schlenker macht, d?rfte in der Praxis kaum einen Unterschied machen. Wenn der Schlenker weiter von der Stra?e wegf?hrt, liegt vermutlich sowieso wieder eine bauliche Trennung vor. Liegt der Schlenker an einer gro?en Kreuzung oder sowas (also bedingt durch breitere Stra?e), m?sste eben die Stra?e entsprechend breiter gerendert werden, wenn man solche Details m?chte. So, ist es! Gru? Gruß Sven S. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Talk-de Digest, Vol 29, Issue 269
Am Donnerstag, 25. Dezember 2008 16:07:33 schrieb talk-de-requ...@openstreetmap.org: Hallo, F?r den Mapper: Es macht viel extra Arbeit, in der Zeit k?nnte man die leeren Fl?chen f?llen. F?r das Kartenbild: In den meisten F?llen wird das Kartenbild nur un?bersichtlich. das l??t sich auch kombinieren, wenn ein Bereich zu un?bersichtlich ist weiger ich mich dort zus?tzliches zu mappen. Man sollte sich wenn es 2 M?glichkeiten gibt etwas zu mappen ?berlegen wie ihr Informationsgehalt ist und wie der Aufwand ist. Das h?ufigste Argument f?r einzeln gemappte Fahrradwege ist: der ist baulich getrennt aber was steht da in den Map_Features: ycleway track Ein baulich abgesetzter Radweg (cycle track), z.B. durch einen Bordstein, der meist neben der Fahrbahn verl?uft. Also hat ein parallel neben der Stra?e verlaufender Fahrradweg keinen zus?tzlichen Informationsgehalt zu cycleway=track, vorallem wenn er einfach nach Augenma? eingezeichnet wurde statt ihn wirklich zu mappen. Zus?tzliche Information w?rde man erst erhalten wenn man den genauen Verlauf eintragen w?rde, interessant w?rde dies aber erst wenn zwischen Stra?e und Fahrradweg mehrere Meter Abstand sind. Eine andere Zusatzinfo w?re, wenn man jede Verbindung zwischen Stra?e und Fahrradweg einzeichnen w?rde. Ob dies n?tzlich w?re sei dahingestellt. Aber diese M?he machen sich die wenigsten. Es m??te dann jede Bordsteinabsenkung eingetragen werden, und auch jedes zus?tzliche Hindernis, also z.B. ein zus?tzlicher Gr?nstreifen. Oder auch ob zwischen Fahrradweg und Stra?e ein Parkstreifen ist. Vor allem aber mu? gew?hrleistet werden, da? diese zus?tzlichen Wege mit der Stra?e ?ber Relations o.?. verbunden werden. Sonst sind sie wie schon oft berichtet wurde eher verwirrend f?r Router u.?.. Und das ganze mu? irgendwie so von Josm/Potlach unterst?tzt werden, da? es nicht zu zu vielen Fehlern f?hrt. Die meisten Fehler die ich so in den Daten finde h?ngen mit komplexen Stra?en zusammen. Das in etwa mein ich Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreuzung Radwege
Am Donnerstag, 25. Dezember 2008 20:42:45 schrieb talk-de-requ...@openstreetmap.org: Message: 1 Date: Thu, 25 Dec 2008 18:22:04 +0100 From: Wolfgang Wienke wo_wie...@gmx.net Subject: Re: [Talk-de] Kreuzung Radwege To: johan...@huesing.name, Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Message-ID: 4953c13c.10...@gmx.net Content-Type: text/plain; charset=UTF-8; format=flowed Hallo! Johannes Huesing schrieb: Dimitri Junker o...@dimitri-junker.de [Thu, Dec 25, 2008 at 03:29:52PM CET]: [...] Da sind wir uns einig, nur ich beobachte da anderes, es werden extra Fahrradwege gezeichnet die genau dem entsprechen wof?r cycleway=track gedacht ist. Der gr??te Nachteil dieser Methode ist nun mal, dass ich unterschiedliche Verh?ltnisse auf beiden Seiten der Stra?e nicht abbilden kann, und die sind f?r den Radfahrer sehr wichtig. Doch das könnte man auch mit dem entsprechenden Tagging hinkriegen All das hier geschriebene spricht eigentlich nur daf?r, dass die Mappingregeln in diesem Bereich DRINGEND grundlegend gekl?rt und mehr festglegt werden sollten. Mein Reden! Es ist sehr frustrierend, wenn man sich in diesem Bereich z.B. durch Abfahren der Wege mit GPS M?he gibt und dann h?rt die Wahrheit ist zu kompliziert, k?nnen wir nicht darstellen (ein Radweg-Rendrer m??te es nat?rlich k?nnen) Deswegen habe ich lobend erwähnt das ich schon sehe das sich manche sehr viel Mühe geben! Danke dafür! Das ist das Problem, viele Dinge sind unausgegoren, oder wir sind nicht in der Lage verbindliche Regeln zu finden. Das führt zu Frust, weil man sich mit etwas Mühe gibt und der nächste es ändert, weil er es für falsch hält. Darum brauchen wir verbindlichere Regeln auf die wir uns irgendwie einigen müssen! Ein Konsens reicht nicht! Denn was ist denn Konsens, da werden wir schon Probleme haben das zu spezifizieren . Ob ein Radweg ein Track auf dem B?rgersteig oder eine lane auf der Stra?e ist, ist f?r unsichere, ?ltere Radfahrer sehr entscheidend. cycleway=track und cycleway=lane unterscheiden das. Dann m??te man ehrlicherweise sagen: Eine Radfahrkarte (speziell im st?dtischen Breich) werden wir niemals hinbekommen. Doch das bekommt man trotzdem hin! Und als Radfahrer, der ich bin, wünsch ich mir das auch! Und arbeite daran! -- Mit freundlichen Gruessen Wolfgang Wienke Mit freundlichen Grüßen Sven S. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreuzung Radwege
Sven S. Messenger: sven...@yahoo.de sven1971sommerk...@gizmo5.com Voip: sip: 17472402163 Am Freitag, 26. Dezember 2008 11:41:32 schrieb talk-de-requ...@openstreetmap.org: Hallo! Dimitri Junker schrieb: Ob ein Radweg ein Track auf dem B?rgersteig oder eine lane auf der Stra?e ist, ist f?r unsichere, ?ltere Radfahrer sehr entscheidend. Diese Unterscheidungsm?glichkeit gibt es derzeit aber nur bei der 1-Weg Methode, n?mlich cycleway=lane oder track. Zeichnet man den Fahrradweg einzeln ist er highway=cycleway, da gibt es (noch) keine Unterscheidung. Zeichnet man ihn einzeln dann ist er weder ein cycleway=lane oder cycleway=track Ich kenne hierf?r, dass zu highway=cycleway ZUS?TZLICH cycleway= lane/track hinzugesetzt wird. Du meinst das an einen Radweg zusätzlich noch cycleway=lane, oder track hinzugefügt wird? Wozu? highway=cycleway ist doch ein eigenständiger Radweg? Das bezeichnet das Ganz doch schon hinreichend, cycleway=lane, oder track schließt das eigentlich aus.. -- Mit freundlichen Gruessen Wolfgang Wienke Mit freundlichen Grüßen Sven S. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreuzung Radweg
Sven S. Messenger: sven...@yahoo.de sven1971sommerk...@gizmo5.com Voip: sip: 17472402163 Am Freitag, 26. Dezember 2008 17:04:06 schrieb talk-de-requ...@openstreetmap.org: Hallo, Meiner Erfahrung nach verl?uft ein Radweg, wenn er baulich getrennt ist, meistens entweder nicht immer parallel zur Stra?e (macht Schlenker etc.), oder es gibt an verschiedenen Stellen Querverbindungen zur Stra?e Als baulich getrennt (also cycleway=track) gilt schon ein Bordstein, und da ist der Fahrradweg meist parallel zur Stra?e und weniger als 1m von dieser entfernt. Und Querverbindungen taggen macht nur sinn wenn sie selten sind. Wenn man bei jeder Einfahrt, also etwa alle 20m wechseln kann schaut keiner auf die Karte oder sein Navi um zu sehen wann die n?chste Einfahrt kommt. Baulich gertennt kann also nicht bedeuten, das ein Bordstein das baulich trennt! Denn der Bordstein stellt wohl nicht wirklich ein Hindernis dar, oder? Es ist sehr leicht eine Straße über den Bordstein zu überqueren, ob mit Fahrrad oder zu Fuß. Das vermeidet auch einen ganzen anderen Haufen von Verständnisproblemen. Z.B. wie ist der Name des Weges? Und welche Hausnummer ist dort? Es vermeidet, alles Mögliche doppelt zu machen und spart dadurch ne Menge Arbeit und Daten. Wenn der Radweg auf dem B?rgersteig ist, sehe ich das noch nicht als bauliche Trennung an; Ich auch nicht! So steht es aber im Wiki - wir sind uns also da einig. Wenn das so im Wiki steht, und wir uns einig sind das ein Bordstein keine bauliche Trennung ist, was nach meiner Meinung nicht der Fall ist, dann sollten wir das ändern! Ein Beispiel f?r einen meiner Meinung nach unn?tigen abgesetzten Radweg ist hier in Aachen die Triererstr. S.: http://www.informationfreeway.org/?lat=50.769lon=6.120zoom=17 und http://maps.google.de/maps?oe=UTF- 8hl=deq=ie=UTF8om=1ll=50.769108,6.120047spn=0.001218,0.002355t=hz=1 9 vor allem da die Querverbindungen nicht eingetragen sind. Gru? Dimitri Sven S. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einigkeit bei Linienb?ndeldiskussion (Re: Kreuzung Radweg)
Sven S. Messenger: sven...@yahoo.de sven1971sommerk...@gizmo5.com Voip: sip: 17472402163 Am Sonntag, 28. Dezember 2008 14:22:56 schrieb talk-de-requ...@openstreetmap.org: Hallo, Sag mir nur einen einzigen Vorteil. Irgendetwas das Software nicht automatisch genau so gut erstellen k?nnte. Wenn der Fahrrad und/oder Fu?g?ngerweg parallel in geringem Abstand neben der Stra?e verl?uft kann Software einfach den Stra?en-Weg parallel verschieben und erh?lt einen genau so guten Verlauf wie die meisten handgezeichneten. Denn 1. sind die meisten eh so entstanden, zwar meist per Hand aber eben einfach parallel neben die Stra?e gezeichnet. 2. Wenn sie doch nicht so gezeichnet wurden sondern per GPS aufgenommen wurden ist die Genauigkeit gerade neben einer H?userreihe auf dem B?rgersteig so ungenau, da? wohl jeder Mapper das Zickzack das er da aufgenommen hat wieder gl?ttet, und wie macht er das? Er orientiert sich an der Stra?e - also doch wieder eine Parallelverschiebung - der zus?tzliche Weg hat keinen oder einen sehr geringen Informationsgehalt. Und alles andere (einseitige Fahradwege,..) ist eine Frage der Tags. Redundante Daten sollten m?glichst eliminiert werden. Und die oft genannten Ver?tze an einer Kreuzung sind auch nicht unbedingt so interessant. Ich kann mir nicht vorstellen, da? ich irgendwann 10m vor der Kreuzung per Fahrrad ankomme und verwirrt auf mein Navi schaue um zu sehen, da? der Fahrradweg 2m nach rechts schwenkt. Wo dies sinnvoll ist ist bei Navigation f?r Blinde, aber das ist eine ganz andere Liga, und auch eher nicht f?r Fahrradwege interessant. Hier braucht man Differiential-GPS, mu? jede Laterne, jeden Bordstein, die genaue Position von Ampeln,... mappen, davon sind wir weit entfernt. Und es bringt auch nichts ein bischen in diese Richtung zu gehen, denn entweder ist die Genauigkeit 1m oder sie ist f?r Blinde ohne Mehrwert. Und das ist den Meisten nicht klar. Sonst würden wir gar nicht drüber diskutieren. Selbst wenn Gallileo aktiv ist und eine Alternative darstellt wird die Genauigkeit meistens für solche Dinge immer noch nicht ausreichen. Zusätzlich produzieren wir Fehler, wenn wir Hindernissen ausweichen die sich auf unserem Weg befinden. Nachdem wir zuhause sind und mit den Daten arbeiten haben wir vergessen, wann und wo genau das der Fall war. Meiner Meinung nach haben Karten den Sinn weiter schauen zu k?nnen als man es von der aktuellen Position kann. Aber sp?testens bei der Me?genauigkeit ist Schlu?. Und das d?rfte auf einem B?rgersteig neben mehrst?ckigen H?usern deutlich gr??er sein als die Breite des B?rgersteiges. Ich wei?, das bei Nichtphysikern die Bedeutung des Fehlers einer Messung immer untersch?tz wird. Aber stell Dir einfach vor man w?rde jeden Weg in JOSM als Linie mit deiner Breite von der Me?genauigkeit (etwa 10m im Freien oder mehr neben H?usern) zeichnen, k?nntest Du dann noch Stra?e und Fahrradweg unterscheiden? Das ist der springende Punkt! Schon unsere Meßmethodik ist sehr Fehlerbehaftet, aber Navigtionsgeräte gleichen das gut aus. Darum braucht es keinen Extra Bordsteinradweg. Nur die Tags die an der zugehörigen Straße sind. Außer in wenigen Einzelfällen wo tatsächlich eine bauliche Trennung da ist, wie z.B. eine Mauer(Lärmschutz). Wir zwingen ja auch niemanden Telefonzellen zu mappen, wenn er es nicht will. Jedes zus?tzliche Element in einer Karte macht diese erstmal un?bersichtlicher, ist der Informationsgehalt gro? ist dies OK, hat sie aber keinen Informationsgehalt, wie parallellaufende Linien ist es besser sie weg zu lassen. Deshalb werden ja je nach Zoomstufe Elemente weggelassen. Das geht aber nicht bei parallel verlaufenden gleichwertigen Wegen. Ich m?chte z.B. als Fahrradfahrer einen einzell verlaufenden Fahrradweg auch in einer geringen Zoomstufe sehen, w?hrend ich da auf den neben der Stra?e verzichten kann. In einer sehr hohen Zoomstufe k?nnten Renderer automatisch Fahrradwege zeichnen. Genau! Und in Hamburg haben wir ja sonst auch nichts mehr zu tun (die Sta?en sind drinn) Es gibt hier und da noch Fehler.. Aber außerhalb von Hamburg kann man sehr viel sinnvolles Hinzufügen. Dinge die in unserer Prioritätenliste sehr hoch stehen sollten. OSM ist keine Besch?ftigungstherapie! Und ich bin sicher, da? es auch in Hamburg noch viel zu tuen g?be. Sind z.B. alle Abbiegeverbote drin, alle Geschwindigkeitsbeschr?nkungen, alle Ausnahmeregeln f?r Fahrradfahrer (cycleway=opposite,...) Dimitri Danke Dimitri! Du hast das immer wieder schön veranschaulicht, was ich genau sagen will (wollte)! Ich sehe, das ich nicht völlig falsch liege, und gar nicht allein bin, mit dem was ich denke! Gruß Sven S. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einigkeit bei Linienb?ndeldiskussion (Re:Kreuzung Radweg)
Sven S. Messenger: sven...@yahoo.de sven1971sommerk...@gizmo5.com Voip: sip: 17472402163 Am Montag, 29. Dezember 2008 13:00:01 schrieb talk-de-requ...@openstreetmap.org: Am Sonntag, 28. Dezember 2008 19:24 schrieb Dimitri Junker: Ich kann Deine Argumente alle verstehen. Ich hoffe du verstehst meine auch. Dein Argument scheint zu sein, das es grafisch einfacher zu editieren ist? Ich verstehe Deine W?nsche, sehe aber nicht, da? daf?r ein eigener Weg n?tig ist. das Ergebnis ist, das du den Main-Highway in Tausend St?cke zerteilst Ich denke, dafür gibt es Relationen? Wie gesagt kann man anders l?sen. und ein komplexes Tagging erfinden musst Wenn das vern?nftig von JOSM Co unterst?tzt wird ist mir das egal. Man k?nnte z.B. eine Tastenkombination einf?hren bei der aus einem Highway=residential mit 2 Fahrradwegen automatisch 3 Linien gezeichnet werden, die kann man dann einzeln anklicken und Tags setzen. Dies wird dann in die komplizierten Tags umgesetzt. Wäre eine gute grafische Möglichkeit Genau daran glaube ich nicht. Niemand wird sowas Programmieren, weil es schnell zu Inkonsistenzen f?hren wird. Auch das Datenmodell muss einfach sein. Sonst akzeptieren es die Programmierer nicht, die enstcheiden, ob sie es in den Renderer und Editor aufnehmen. Nein, aber egal wie Fahrradwege (neben einer Stra?e) getaggt werden sollen, sollten B?rgersteige ?hnlich getaggt werden. Denn alle Argumente f?r abgesetzte Fahrradwege gelten genau so f?r diese. Das stimmt nicht. F?r Blinde ist es ein Mehrwert sich das ansehen zu k?nnen wie z.B. eine Kreuzung aufgebaut ist (aha ich muss also erst an der Telefonzelle vorebei ...) Interessant, mal abgesehen von dem unpassenden ansehen frage ich mich wie der Blinde die Telefonzelle erkennt wenn nicht gerade jemand anruft. z.B. indem sie mit dem Blindenstock dagegen sto?en. Ich hab im Zivildienst mit Blinden gearbeitet. Blinde sehen anders, aber man sollte das nicht untersch?tzen. Und gerade Wegpunkte auf dem Gehweg sind sehr Hilfreich f?r Sie: Du solltest mal h?ren wie ein Blinder einen anderen Blinden den Weg beschreibt. Aber das ist eigentlich egal, wir Mappen ja nicht f?r (nur) f?r Blinde ;-) Wie stellt ein GPS eigentlich einem Blinden etwas dar, so das es ihm hilft? Naja es gibt ja die GPS-Me?genauigkeit und dann meine Beobachtungsgenauigkeit und die sagt mir die Telefonzelle ist rechts vom Briefkasten obwohl die beiden 2 m von einander entfernt sind. Eben und das GPS sagt Dir wenig ?ber den Verlauf von Fahrradweg und Stra?e, da hilft nur die Beobachtungsgenauigkeit: Der Fahrradweg verl?uft unmittelbar neben der Stra?e) Aber diese Info kann ich in 1 Byte speichern, da macht es keinen Sinn bei einer langen krummen Stra?e zig Nodes zu erfinden. In einem Byte wirst du das nicht speichern k?nnen. Ich glaube wir sollten unseren Entwurf f?r OSM auch nicht an Bytes und Plattenplatz orientieren sondern am Mapper und (aber erst an zweiter Stelle) am Karten-Nutzer (?blicherweise Software). Naja, es ist wohl wieder die Frage was wir mit den Daten tun wollen.. Die Meisten sehen OSM nicht als Beschäftigungstherapie an, sondern haben einen Gedanken, was man damit anfangen könnte. Sehr viele wollen die Daten für Navis und Gedruckte Karten oder dergleichen nutzen. Und dafür muß man gewisse Dinge konsistent und effizient mappen. Und vielen übrigen Anwendungen käme diese Arbeitsweise ebenso entgegen! F?r mich ist es wesentlich ?bersichtlicher einen Weg auch plastisch auf dem Bildschrim zu haben als mir irgendwas vorzustellen wie okay da kommt jetzt eine Busspur und ein Gr?nstreifen und den Briefkasten muss ich jetzt da hin setzen... Es wurde schon vorgeschlagen den Editor so zu programmieren, das er das graphisch besser darstellt. Gut wenn das Konsens ist, darfst du die h?lfte der Motorways wieder l?schen. Der Gr?nstreifen ist meist breiter als die GPS-Me?genauigkeit. Ja, die Leitplanke zwischen zwei Autobahnspuren auch. Mit dem Argument k?nnten die Autofahrer dann auch sagen wenn die Fahradfahrer 2 Wege bekommen m?chten wir auch 2 haben. Wir h?tten dann f?r jede Spur einen einzelnen Weg - 2 Autospuren, 2 Fahrradspuren und 2 Fu?g?ngerwege statt eines. Ich denke darauf wird es wahrscheinlich auch irgendwann hinaus laufen. F?r gute Navi-Unterst?tzung braucht man sowas ja auch (bitte rechts einordnen). Es gab und gibt meines Wissens ein Tagging welches festlegt wieviele Spuren ein Weg hat. Ist also auch dort nicht nötig Extrawege anzulegen. Sollst Du, mich st?ren ja nur die wo es keinen Mehrwert liefert. Und bisher funktionieren beide Methoden nicht, sei es weil laneabh?ngige Tags fehlen oder weil Relationen o.?. fehlen die die Wege verbinden. Und bevor man sich da was ?berlegt mu? man entscheiden was der Normalfall sein soll, 1 Weg f?r alles oder einer pro Spur. Bei OSM wird IMHO nichts Entschieden, sondern ?berzeugt (Es gibt keine Entscheidung statt
Re: [Talk-de] Einigkeit bei Linienb?ndeldiskussion ( Re:Kreuzung Radweg )
Am Montag, 29. Dezember 2008 19:11:31 schrieb talk-de-requ...@openstreetmap.org: talk-de-requ...@openstreetmap.org: Am Sonntag, 28. Dezember 2008 19:24 schrieb Dimitri Junker: Ich kann Deine Argumente alle verstehen. Ich hoffe du verstehst meine auch. Dein Argument scheint zu sein, das es grafisch einfacher zu editieren ist? Eines meiner Argumente Ein anderes i(mir wichtigeres) ist das es ein bereits vorhandenes Datenmodell ist, und wir daf?r eigentlich nichts neu Erfinden m?ssten. Das müssen wir ja auch nicht großartig bei der anderen Methode. Die Tags gibt es im wesentlichen. Siehe: http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Workshops/Linienb%C3%BCndel Ich verstehe Deine W?nsche, sehe aber nicht, da? daf?r ein eigener Weg n?tig ist. das Ergebnis ist, das du den Main-Highway in Tausend St?cke zerteilst Ich denke, daf?r gibt es Relationen? Ich wei? das es Ans?tze gibt, mit Relationen etwas auf Teilbereichen zu definieren. Aber diese Ans?tze werden von keinem Tool unterst?tzt. Und ich denke das wäre der richtige Weg! Obwohl ich mit Relationen noch so gar nicht klarkomme. Das müßte mir mal jemand vernünftig zeigen. z.B. indem sie mit dem Blindenstock dagegen sto?en. Ich hab im Zivildienst mit Blinden gearbeitet. Blinde sehen anders, aber man sollte das nicht untersch?tzen. Und gerade Wegpunkte auf dem Gehweg sind sehr Hilfreich f?r Sie: Du solltest mal h?ren wie ein Blinder einen anderen Blinden den Weg beschreibt. Aber das ist eigentlich egal, wir Mappen ja nicht f?r (nur) f?r Blinde ;-) Wie stellt ein GPS eigentlich einem Blinden etwas dar, so das es ihm hilft? Mein Zivildienst ist nun ja auch schon ein paar j?hrchen mehr her, aber ich bin mir sicher, das es da eine L?sung gibt. Wei? da jemand mehr? In einem Byte wirst du das nicht speichern k?nnen. Ich glaube wir sollten unseren Entwurf f?r OSM auch nicht an Bytes und Plattenplatz orientieren sondern am Mapper und (aber erst an zweiter Stelle) am Karten-Nutzer (?blicherweise Software). Naja, es ist wohl wieder die Frage was wir mit den Daten tun wollen.. Die Meisten sehen OSM nicht als Besch?ftigungstherapie an, sondern haben einen Gedanken, was man damit anfangen k?nnte. Sehr viele wollen die Daten f?r Navis und Gedruckte Karten oder dergleichen nutzen. Und daf?r mu? man gewisse Dinge konsistent und effizient mappen. Und vielen ?brigen Anwendungen k?me diese Arbeitsweise ebenso entgegen! Ich wei? was jetzt wieder von dir kommt: Dein garmin l?uft ?ber, weil ich einen Radweg an der Neuwiedenthaler Stra?e eingetragen habe und deshalb m?chtest du nicht das ich ihn als extra Weg Eintrage. Aber das ist Mumpitz. Wir k?nnen doch nicht, nur weil einer mit einer Casio-Uhr routen m?chte alle Fu?wege aus OSM l?schen. Der Ansatz bei OSM ist ein anderer: Jede Anwendung muss selbst entscheiden, welche Daten sie braucht. Es geht nicht um Neuwiedenthal und nicht um mein Garmin (Übrigens verwenden sehr viele hier Garmingeräte, du auch, mein ich zu errinnern.. Das ist eine erste Anwendung unserer Daten, die möglich sein sollte, wie auch immer. Sehr viele hier wären sicher traurig wenn es nicht ginge, denn genau das haben sie auch im Sinn damit. Ich dann sicher eingeschlossen)! Jedes Navigationsgerät wird das ziemlich ähnlich machen und dann besonders schnell eine Route errechnen, wenn es eine Karte vorfindet die es ihm leicht macht. Es sollen auch keine Extrawege aus den Daten gelöscht werden die Sinn machen! Was Sinn macht und wofür, darüber diskutieren wir gerade. Auch wollen viele gerne Karten drucken, das steht zwar nicht im Vordergrund für mich. Aber den gedruckten Karten steht es auch gut zu Gesicht, wenn sie übersichtlich und klar wirken. Und für den Renderer ist es gut, wenn die Karten einfach und schnell zu berechnen sind, soweit möglich. Das ist für unsere Qualität wiederum auch von Vorteil, denn wir können das Ergebnis schneller betrachten. Schließlich ändert sich momentan und in Zukunft viel. In Deinem Fall ist es sogar so, da? ich gerne im Navi angezeigt bekommen w?rde, wo ich die Stra?e Queren muss. Versteh ich grad nicht. Ich kann an beliebigen Stellen eine Straße überqueren, außer bei Autobahnen, wenn es Mauer oder dergeleichen gibt. Ich bin auch in der Lage sehr viel schneller und besser zu entscheiden wo ich eine Straße überquere als ein Navi. Denn das hängt ja noch von Gegebenheiten und Präferenzen ab, die ein Navi nicht kennen kann. F?r mich ist es wesentlich ?bersichtlicher einen Weg auch plastisch auf dem Bildschrim zu haben als mir irgendwas vorzustellen wie okay da kommt jetzt eine Busspur und ein Gr?nstreifen und den Briefkasten muss ich jetzt da hin setzen... Es wurde schon vorgeschlagen den Editor so zu programmieren, das er das graphisch besser darstellt. Ja, aber wenn wir die Spur nicht selbst abspeichern, wird es immer Abweichungen zur wirklichkeit geben. Osmarender
Re: [Talk-de] Einigkeit bei Linienb?ndeldiskussion (Re:Kreuzung Radweg)
Sven S. Messenger: sven...@yahoo.de sven1971sommerk...@gizmo5.com Voip: sip: 17472402163 Am Dienstag, 30. Dezember 2008 10:15:23 schrieb talk-de-requ...@openstreetmap.org: Hallo, Sicher, nur diesen einfachen fall gibt es in der realit?t nur selten. Also hier in Aachen besteht dieser einfache Fall fast ausschlie?lich. Das ist aber f?r dich kein problem; denn du hast ja bereits verk?ndet, dass dich die wirkliche kreuzungssituation nicht interessiert. Der genaue Verlauf des Fahrradsweges interessiert mich dann wenn er mehr als sagen wir 10m vom 'normalen' Verlauf abweicht. bordsteinradwege haben zwischen kreuzungen gern verengungsstellen, wechseln den belag Ich habe noch nirgendwo gesehen, da? jemand Breiten eintr?gt, und wenn w?rde ich f?r einen Abschnitt jeweils die engste Stelle und den schlechtesten Belag nehmen. haben verschwenkungen an bushaltestellen Me?genauigkeit haben absperrungen zwischen fahrbahn und radweg Und wie taggst Du die bei separatem Radweg? MAchst Du dann einen Weg fence dazwischen? Wenn Ja OK. haben abweichende oneway-regelungen cycleway=opposite wechseln zwischen z240, z239, und Radfahrer absteigen Und wie tagst Du das? haben von der fahrbahn abweichende abbiegevorschriften. bei denen gibt es bereits ein exept und man sollte meiner Meinung nach noch ein only hinzuf?gen. Zum teil hast du das ja auch schon erkannt, aber zugleich sagst du nun, dass relationen die dinge komplizierter machen. Meine Erfahrung ist, 90% der Radwege verlaufen entweder auf der Fahrbahn oder unmittelbar daneben, und es tr?gt keiner Breiten oder Fahrbahnbelege ein. Diese 90% m?chte ich m?glichst einfach taggen. Alles andere darf dann komplizierter sein. Taggt man grunds?tzlich Fahrradwege,.. als eigene Wege ist alles kompliziert. Genau! lern, mit den endlichen ressourcen auszukommen. Sie reichen nicht, entweder sehen die Karten schlecht aus oder ein Router kann damit nichts anfangen. Genau! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Mappen von verzweigten Wegen
Sven S. Messenger: sven...@yahoo.de sven1971sommerk...@gizmo5.com Voip: sip: 17472402163 Am Dienstag, 30. Dezember 2008 17:28:19 schrieb talk-de-requ...@openstreetmap.org: LiLi, Wie mappe ich einen verzweigten Weg? Zum Beispiel in einem Wohngebiet, wenn die Stra?e pl?tzlich noch einen Abstecher macht, um einige zur?ckgesetzte H?user anzubinden? Oder wenn die Einfahrt in eine Stra?e von einer gr??eren Stra?e aus zwei Teilen (einmal von links, einmal von rechts) besteht? Zu sehen gibt es beides im Ort Herzhausen http://openstreetmap.org/?lat=50.95015lon=8.08453zoom=17layers=0B00TTF mfG, Peter Zunächst fällt mir mal auf das da wahrscheinlich etwas nicht stimmt.. Der Bach dort, heißt Dreisbach. Die Straße heißt, An der Dresibach? Was ist denn richtig? Gruß Sven S. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] right/left
Am Freitag, 2. Januar 2009 15:18:27 schrieb talk-de-requ...@openstreetmap.org: Dimitri Junker schrieb: Oder wenn 2 solcher Stra?en verbunden werden. genau... es gibt da kein System das nicht vor ungewollten Ver?nderungen gesch?tzt ist. (falls doch sagt es bitte) desshalb sollten wir uns immer f?r das einfachste entscheiden Üblicherweise neigen wir dazu, manche Dinge zu verkomplizieren. Das bisherige System mit den Richtungspfeilen ist sehr einfach zu bedienen. Hat man im Editor das Anzeigen der Pfeile eingestellt, dann hat man eine schnelle optische Kontrolle. Ich denke so wie es ist, ist es gut! Gruß Sven S. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] right/left
Sven S. Messenger: sven...@yahoo.de sven1971sommerk...@gizmo5.com Voip: sip: 17472402163 Am Freitag, 2. Januar 2009 16:45:11 schrieb talk-de-requ...@openstreetmap.org: Josias wrote: ich glaube es ist unumstritten, dass wir zeitnah eine M?glichkeit brauchen die eine Seite von der anderen zu unterscheiden, Rechts ist in Pfeilrichtung rechts, ist doch total simpel. wenn wir alles in einen way packen wollen. Ich denke, der obige Anspruch (alles in einen way packen) beschreibt schon das Hauptproblem. ansonsten m?ssen wir wieder mit extra ways arbeiten, aber da sprechen auch wieder viele gegen. Das mag sein. Mittel- bis langfristig werden die extra Ways allerdings die Situation wesentlich transparenter darstellen, als eine Rotte von extra Attributen an nicht weiter vorhersagbarer Stelle. Zumal sich die z.t. komplexen Abbiegebeziehungen an Kreuzungen mit Radweganteil ohne extra-ways auch gar nicht vern?nftig darstellen lassen. Wenn man den komplizierten Abbiegebeziehungen dadurch Rechnung trägt, das man sie als komplizierte Extrawege anlegt, wird derjenige der die Routenanweisungen (oder Karte) deuten soll überfordert. Dann schau ich als Radfahrer nur noch auf Display, statt auf die Straße. Das ist nicht sinnvoll. Ich hab das schon durchprobiert. Radwege haben sehr viele sehr komplizierte Wegebziehungen, gängige Navis sind mit solchen Sachen schnell überfordert und brechen ab (Garmingeräte bspw.) Es w?re besser, den Editoren eine vern?nftige Gruppierung von Wegseqmenten (meinetwegen intern abgebildet als Relation) und die entsprechende Darstellung analog zu einem aktuellen DTP- oder CAD- Programm beizubringen, als immer mehr Spezialtags auszudenken, mit denen sich die Realit?t am Ende doch nicht vern?nftig darstellen l??t und die zudem viel zu schnell verloren gehen k?nnen. anstatt immer nur Argumente zu bringen warum etwas nicht gut ist, sollte man lieber einen Vorschlag bringen wie es besser zu machen ist. Es wurden doch in den vergangenen Tagen gute Ideen zu Tage gefördert. Es wird durchaus nicht nur gegen Argumentiert, was tatsächlich zu einfach wäre. - Jedes Element mit besonderen Eigenschaften wird mit einem eigenen Objekt in der Datenbank verewigt - ?ber eine Group-Relation werden die zueinander geh?renden Objekte geb?ndelt. Ob diese Relation nur eine abstrakte Gruppe oder tats?chlich ein vorhandenes Feature (Bundesstra?e XY) beschreibt, ist erstmal irrelevant. - Damit die ?bersicht beim editieren nicht verloren geht, sollten alle Editoren einen vern?nftigen Group-Support bekommen: Beim betreten einer Gruppe/Relation wird alles andere ausgeblendet, nur noch die einzelnen Elemente sind editierbar. Das Handling mit Relationen müßte wirklich besser werden, ich komm ganz ehrlich nicht damit klar. Ich stelle mir vor das man das vielleicht in die Voreinstellungen integrieren könnte. Würde das Ganze erheblich vereinfachen. - Was die jammernden Autofahrer betrifft, die z.B. extra Ways f?r Radwege ablehnen, weil das die sch?nen Autokarten verunstaltet?: Das ist eine Sache, die sich schnell ?ber die Renderer (und nur dort) l?sen lassen sollte. Dazu muß ich mich als Radfahrer mal melden. Ich jammere über Extrawege die unnötig sind, die Gründe hab ich mehrfach geschildert. Das ist kein Autofahrer--Radfahrer Problem. Und genau, es ließe sich bestimmt einfacher schön rendern, wenn die entsprechende Information als Tags an den Weg gehängt wird. Es gab dazu vielversprechende Ansätze in den letzten Tagen... dass manche diese rechts links Unterscheidung nicht brauchen ist kein Argument, sich keine Gedanken drum zu machen. Meiner Meinung nach werden rechts/links Unterscheidungen durchaus gebraucht, sie als richtungsabh?ngige Extratags statt als eigene Ways zu realisieren ist jedoch IMO fahrl??iger Unsinn und wird unweigerlich zu unn?tigem Datenverlust f?hren. Schon die jetzige Oneway L?sung ist haarstr?ubend. Just my 2?. Bj?rn ?) Begr?ndung des Users, der vor einiger Zeit mal in Braunschweig einige Kilometer stra?enbegleitenden Radweg gel?scht hat. Gruß Sven S. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] right/left
Hallo, Auch Fu?- und Radwege haben baulich definierte ?bergangspunkte. Ich wei? ja nicht wo Du wohnst, aber in der realen Welt gibt es gro?e Stra?en mit Ampeln wo man die Stra?e nur dort ?berqueren soll, aber kleine Stra?en haben keine ?berg?nge, da kann man die Stra?e also ?berall ?berquern. Und wenn mir ein Router sagt ich soll an der T-Kreuzung rechts abbiegen, bis zur n?chsten Kreuzung gehen, dann zur?ck gehen und stelle dann fest, da? das gesuchte Haus fast genau gegen?ber der T-Kreuzung war, das ist das M?ll. Es m??te also auch bei getrennten Wegen entweder jede m?gliche/erlaubte Wechselm?glichkeit als Querweg eingezeichnet werden, oder per Relation gesagt werden, man kann zwischen Spur A und Spur B: -immer -etwa alle 10m -nur an Kreuzungen -nie wechseln Ja, das sind eine Menge Daten. Aber wo ist das Problem? Vom jetzigen OSM Stand haben die Experten vor Jahren ja auch behauptet, da? man sowas niemals als freies Projekt umsetzen k?nne, weil es zu viele Daten seien. Wir haben jetzt in vielen Gebieten einen Stand erreicht wo die Karte schon brauchbar ist. Wir sollten also Mappingregeln finden mit denen man einfach und schnell die fehlenden Infos hinzuf?gen k?nnen, wenn dann jemand sp?ter dies nach detailierter machen will soll er es machen, vorausgesetzt die Daten werden dadurch nicht unbrauchbar, wir brauchen meiner Meinung nach also beides. Wenn ein Autofahrer sieht, da? neben der langen Stra?e die er f?hrt ein Fahrradweg verl?uft, ist es mir lieber er tr?gt ihn per cycleway=track ein, als er zuckt mit den Schultern und man wartet bis mal jemand wirklich per Fahrrad diesen abf?hrt. Die Info ob da ein Fahrradweg ist ist viel wichtiger als die Info ob er 10cm oder 1m neben der Stra?e verl?uft oder auch ob er an der Kreuzung einen Schlenker macht. Letztlich ist meistens nur diese Info von Wichtigkeit und vielleicht noch der Zustand. Ohne eine einfache M?glichkeit z.B. Fahrradwege zu mappen schrecken wir viele Mapper ab die sich eigentlich nicht f?r Fahrradwege interessieren. Eben. Sogar die die Radfahren, wie ich. Ich mappe haupts?chlich zu Fu?, trage dann aber nat?rlich Auto, Fahrrad und Fu?g?ngerinfos ein. Ich werde aber nicht auf der Stra?e laufen um diese zu vermessen, und wenn ich mal per Auto eine Autobahn aufnehme werde ich nicht dauernd auf der linken Fahrbahn fahren um diese als getrennten Weg mappen zu k?nnen. Wenn wir jemals in die Lage versetzt werden sollen, daf?r ein vern?nftiges Routing zu entwerfen, brauchen wir diese Details. Vernünftiges Routing funktioniert nur nach dem weniger ist mehr Prinzip. Ob ich eine Straße überqueren kann um auf der anderen Seite wieder zurück zu fahren oder zu laufen, wird jeder anders beurteilen! Also lassen wir es doch in der Entscheidungskompetenz des Einzelnen. Nochmal. Nat?rlich gibt es F?lle wo Zusatztags nicht ausreichen, oft reichen sie aber oder sind als Zwischenl?sung besser als nichts. Nehmen wir hier die Triererstra?e, dort verl?uft ein Fahrradweg auf dem B?rgersteig absolut parallel zur Fahrbahn, teils durch einen 1m Gr?nstreifen getrennt. Aber etwa alle 10m ist der Gr?nstreifen unterbrachen, wegen Garageneinfahrten o.?. Ein cycleway=track w?rde ein Router so interpretieren, da? man jederzeit wechseln kann, was fast stimmt, der jetzt dort vorhandene abgesetzte Weg ohne Querverbindungen zwischen den Kreuzungen w?rde dagegen so interpretiert, da? man immer zu n?chsten Kreuzung mu? um zu wechseln. Das ist deutlich ungeauer. Dimitri Gruß Sven S. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Track-Anonymisierer gesucht
Patrick Kolesa wrote: Dann wird jede Zeit auf den Ersten des Quartals gesetzt, also bspw. 01.03.2009 00:00 UTC, bei jedem Trackpoint erh?ht sich die Zeit um eine Sekunde. Eine automatische Ermittlung der Geschwindigkeiten auf verschiedenen Strassen oder eine Heuristik, die bestimmt, ob jemand zu Fuss, mit dem Rad oder mit dem Auto unterwegs war, sind damit nicht mehr m?glich. Wie schon gesagt, solche Tracks sollten auf jeden Fall als verf?lscht gekennzeichnet werden, wenn man sie hochl?dt. Pers?nlich bin ich der Ansicht, dass man, wenn man derartige Bedenken hat, lieber ganz auf ein Hochladen der Tracks verzichten sollte. Zwar sind GPS-Daten in unserer Datenbank manchmal hilfreich, aber wenn ich annehmen muss, dass alles, was ich da rausziehe, mit sehr viel Vorsicht zu geniessen ist, weil es u.U. durch zig verschiedene Skripts verfremdet und verwurstet wurde (ja ich weiss, ihr wollt die Koordinaten nicht anpassen, aber wer sagt mir denn, ob irgendjemand nicht beim gpsbabel doch mal irgendwelche witzigen Switches angibt...), dann sinkt der Wert so weit, dass man es auch ganz bleiben lassen kann. Da muß ich dir voll und ganz zustimmen! Ich will den Schutz der Persoenlichkeitssphaere gar nicht kleinreden, das ist ein legitimes Ansinnen, und es ist gut, sich darueber Gedanken zu machen, aber ich finde, man sollte sich am Ende entweder fuer das Hochladen der unverfaelschten Tracks oder fuer das Nicht-Hochladen entscheiden und dazu stehen. Eben! Bye Frederik Gruß Sven S. P.S.: Ich würde noch hinzufügen wollen: Wer sagt denn das du den Track erzeugt hast? Du hast ihn ja nur hochgeladen. Der Informationsgehalt ist viel geringer als viele annehmen. Ich lasse z.B. einen LKW Fahrer mit meinem GPS durch die Gegend fahren. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Anregung für zukünftige Datenimport e und spezielle Fuktionalitäten
Vielleicht wäre es eine Idee, wenn man Daten die man in OSM importieren möchte auf einen speziellen Server oder Serverbereich ablegt und dann in seinem Editor diese Daten als zusätzlichen Layer anzeigen kann. Wenn alles am selben Ort liegt und mitgeladen wird, führt das leicht zu Verwirrung. Und es kommt schnell zu unschönen Effekten in den gerenderten Karten. http://openstreetmap.org/?lat=47.064lon=10.6607zoom=13layers=B000TTF Möglicherweise wird da sogar noch mehr in Mitleidenschaft gezogen.. Kann man mit JOSM mehrere Server abfragen? Wie schwer mag es sein einen OSM Server aufzusetzen? Vielleicht wäre es sinnvoll Basiskartenelemente auf dem Haupt Osm Server zu haben, und speziellere Dinge auf weiteren? Ich habe da z.B. gerade so ein Problem mit einem Wintersportort http://www.informationfreeway.org/?lat=47.03838071240456lon=10.606773624779946zoom=15layers=BF000F den habe ich seinerzeit ziemlich komplett gemappt. Nun versuche ich die Daten eines Importes zu nutzen. Was gar nicht so leicht ist. Gruß Sven S. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Anregung f?r zuk?nftige Datenimporte und spezielle Fuktionalit?ten
Am Dienstag, 13. Januar 2009 16:00:54 schrieb talk-de-requ...@openstreetmap.org: Sven Sommerkamp schrieb: Vielleicht w?re es eine Idee, wenn man Daten die man in OSM importieren m?chte auf einen speziellen Server oder Serverbereich ablegt und dann in seinem Editor diese Daten als zus?tzlichen Layer anzeigen kann. Wenn alles am selben Ort liegt und mitgeladen wird, f?hrt das leicht zu Verwirrung. Und es kommt schnell zu unsch?nen Effekten in den gerenderten Karten. http://openstreetmap.org/?lat=47.064lon=10.6607zoom=13layers=B000TTF M?glicherweise wird da sogar noch mehr in Mitleidenschaft gezogen.. Kann man mit JOSM mehrere Server abfragen? Wie schwer mag es sein einen OSM Server aufzusetzen? Vielleicht w?re es sinnvoll Basiskartenelemente auf dem Haupt Osm Server zu haben, und speziellere Dinge auf weiteren? Hallo, dazu m?sste es aber in JOSM einfach m?glich sein, Objekte zwischen zwei Layern zu transferieren, z.B. wie in AutoCAD. Derzeit geht nur das komplette eindampfen eines h?heren Layers auf den darunterliegenden (iirc). Stimmt. Auch eine Pinsel-Funktion, wie in den Office-Programmen w?re sch?n, um (mehrere) Attribute von einem Element auf's andere zu ?bertragen, gerade bei Import-Projekten. Auch lg roland Gruß Sven S. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Abstraktionsgrad, Erfassen von Spuren etc.
Am Sonntag, 18. Januar 2009 16:52:45 schrieb talk-de-requ...@openstreetmap.org: Hallo, Leute! Hier etwas, was ich schon l?nger loswerden wollte, aus aktuellem Anlass und wegen des regnerischen Sonntags aber nun endlich schreibe: Nach einiger Beobachtung sehe ich jetzt in einigen Aspekten dessen, was und wie inzwischen von engagierten Mappern erfasst, OpenStreetMap in einer gewissen Krise - wobei ich unter Krise, gem?? dem Ursprung dieses Wortes, eine sich versch?rfende problematische Situation verstehe, die zu einer Entscheidung dr?ngt: Da gibt es einerseits - auch in Deutschland - noch viele Gebiete, in denen h?chstens die ?berlandstra?en erfasst, inner?rtliche Stra?en aber kaum zu finden sind [1]. Andererseits ist an bestimmten anderen Stellen, vor allem in St?dten, schon so viel gemappt, dass Mapper sich schon daran gemacht haben, dort jedes einzelne Haus, jede Kneipen und jeden Recycling-Container zu erfassen [2] ... oder jedes Gehege im Zoo [3], jeden Fu?weg auf einem Friedhof [4] oder jedes Becken einer Kl?ranlage [5]. Es ist auch nichts dagegen zu sagen, wenn Mapper sich auf diese Weise (oder auch z.B. durch das Erfassen von Hausnummern) um gr??ere Detailtreue in ihrer Umgebung bem?hen, falls es ihnen nicht m?glich oder zu aufw?ndig ist, sich in noch wesentlich weniger erfassten Gegenden zu bet?tigen. Problematisch wird das Ganze, wenn die Abstraktionsebene des Projektes verlassen wird. Das geschieht z.B., wenn einige bereits damit beginnen, einzelne Spuren einer mehrspurigen Stra?e getrennt zu erfassen (obwohl diese Teil einer Fahrbahn sind und man real zwischen den Spuren durchaus wechseln kann). Ein Beispiel, auf das ich heute gesto?en bin, ist die A 559 bei K?ln [6]. Das Ergebnis des Renderns ist durchaus unbefriedigend, und man kann das hier auch nicht dem Renderer zuschreiben. Das ist sicherlich ein gutes Beispiel dafür das wir in inzwischen vielen Fällen übers Ziel hinausschießen. Und das ist durchaus als problematisch anzusehen, denn inzwischen werden die Daten ja auch verwendet und sollen eine Funktionalität erfüllen. Bei OpenStreetMap gibt es, wie man aus der Entstehung und auch aus der noch (!) ?berwiegenden Praxis erschlie?en kann, folgende Abstraktion: Jeder Weg (ob Stra?e, Rad-, Fu?weg etc.) wird in der Datenbank grunds?tzlich als Polygonzug [7] erfasst, unabh?ngig von der physikalischen Breite des Weges oder der Anzahl seiner Fahrspuren, also nicht als Fl?che. Das ist auch eine gute Wahl, wenn man sie von der Nutzung der Daten her betrachtet: Es geht bei den Wegen um die Verbindung zwischen Orten. So, werden es wohl die Meisten sehen, die die Daten nutzen. F?r das Visualisieren (Rendern) ist z.B. das (bei unseren Datenquellen zudem immer recht ungenaue) Mappen einzelner Spuren eher kontraproduktiv, wie das obige Beispiel [6] zeigt - die zus?tzlichen geokodierten Nodes haben eine Pseudogenauigkeit, deren wahre Ungenauigkeit visuell nun deutlich hervortritt. Das kann man so sehen (tu ich auch). Und selbst wenn der Renderer nun noch die Information bek?me, dass es sich um eine gemeinsame Fahrbahn (und Br?cke) handelt und der Wechsel zwischen den Spuren erlaubt ist, dann ist gegen?ber einem einfachen Polygonzug (way), der mittels zus?tzliche Tags mit der Information ?ber die Zahl der Spuren versehen ist, keinerlei Informationsgewinn zu verzeichnen; es ist nur die Sache f?r die Renderer und die Routingsoftware erschwert. Genau Nun mag mancher erwidern: Wir mappen doch nicht f?r die Renderer und Router. Da ist etwas Wahres dran; es wird aber zu oft als Totschlagargument gebraucht. Es trifft vor allem zu, wenn jemand versucht, Bugs oder auch Unzul?nglichkeiten der Renderer beim Mappen auszugleichen - da ist es besser, richtig zu mappen und die Darstellung dann der jeweiligen Software zu ?berlassen. Richtig mappen hei?t aber nicht, jeden Bordstein und jede Linie zwischen zwei Fahrspuren derselben Fahrbahn in ihrer Lage zu erfassen, sondern den Zweck von OpenStreetMap zu beachten. Der liegt nun mal in einer Karte, zu deren Abstraktionsgrad nun einmal geh?rt, einen Weg (Stra?e) als Verbindung (Polygonzug) zu erfassen und diese Information (wo ist A und B und wie komme ich von A nach B) m?glichst gut darzustellen (sei es als Karte oder per Routingsoftware oder wie auch immer). Und wenn z.B. die Breite oder Zahl der Spuren (einschlie?lich ihrer Abbiegem?glichkeiten) einer Stra?e in diesem Rahmen eine sinnvolle Information sind, dann sollte man sie als Eigenschaften (Tags) der entsprechenden Stra?e zuschreiben. Das ist dann der richtige Abstraktionsgrad - im Gegensatz zur Pseudogenauigkeit von in die Gegend gesetzten Nodes mehrerer Spuren. Ganz deiner Meinung! Um schlie?lich noch ein Beispiel zu erg?nzen: F?r kontraproduktiv halte ich es auch, wenn jeder zu einer Stra?e parallele Radweg als eigener Polygonzug (Way) gemappt wird und man dann eventuell jeden abgesenkten Bordstein, ?ber den man vom Radweg auf die Fahrbahn
[Talk-de] Abstraktionsgrad, Erfassen von Spuren etc.
Am Sonntag, 18. Januar 2009 19:29:07 schrieb talk-de-requ...@openstreetmap.org: Ich halte es durchaus f?r sinnvoll, wenn man auf mittlere Sicht dazu ?ber geht, anstatt einfacher Linien wirklich jede Fahrbahn separat einzuzeichnen. Man sollte sogar noch weiter gehen und s?mtliche Objekte der realt?t entsprechend als Fl?chen erfassen. Au?erdem sollte man davon weg kommen, mit Linien zu arbeiten und auf Kurven ausweichen, da diese weit realistischer sind. Warum glaubst du das? Welcher Vorteil soll damit verbunden sein, den man wirklich gebrauchen kann? Nat?rlich sind wir noch weit davon entfernt. Um so etwas sinnvoll durchzusetzen, ben?tigt man zun?chst einmal hochaufl?sende Luftbilder mit einer Aufl?sung von weniger als 10cm. Auf jeden Fall ist es der falsche Weg, sich an irgendwelchen technischen Grenzen bei der Verwertung fest zu klammern. Denke ich für den Moment nicht! Vielleicht haben wir eines Tages die Möglichkeit. Aber im Moment haben wir weder die Möglichkeit noch den Nutzen. Also macht es nur Arbeit und erzeugt Daten die keiner versteht, gebrauchen kann, und speichern will. Allerdings sollte es immer konvertierungsm?glichkeiten auf die aktuellen Systeme geben. Da allerdings schon seit langem Systeme mit dreidimensionaler Landschaftsdarstellung in Planung sind, sollte man sich an der Zukunft orientieren und nicht an der Gegenwart. Wenn das Material vorhanden ist, wird auch die n?tige Technik folgen. Der Knackpunkt, warum es solche Systeme nicht schon l?ngst gibt, ist die Materialgrenze. Das tollste 3D-Navi hat keinen Zweck, wenn man nicht die 3D-Modelle zur Verf?gung hat. Ich glaube ein 3D Navi bringt sowieso nicht wirklich viel.. Aber das ist meine persönliche Meinung. Ich bin auf jeden Fall schwer daf?r, dass wir versuchen, neue Ma?st?be zu setzen, denn Google und Konsorten schlafen nicht. Wir haben neue Maßstäbe gesetzt indem wir freie Karten produzieren, die man zu Dingen verwenden kann die sonst Unmengen von Geld kosten würden. Und ausgehend davon kann man gucken ob man manche Dinge besser machen kann als Andere. Man sollte sich aber immer vorher über die Konsequenzen klar werden, bevor man sehr entscheidende Dinge ändert. Auch in deren Karten ist abzusehen, dass bald komplette Pl?ne von Paranlagen auftauchen werden. Von Parkanlagen? Na, fein! Man sollte aber nicht mehr aus den Daten ableiten als das, was sie anbieten. Mit der aktuellen GPS-Technik kann man eben nicht den Gehweg centimetergenau abmessen. Die Kombination aus Korrektursignalen, GPS und Gallileo wird uns dahin sicher einen entscheidenden Schritt n?her bringen, aber es gibt eben nichts besseres als gut gemachte Luftbilder. Luftbilder haben ja aber auch wieder einen gewissen Versatz und stimmen nicht. Deshalb sollte man auch unser Schwesterprojekt OAM massiv unterst?tzen. Die Anfertigung von Luftbildern ist mit heutiger Technik nicht mehr schwer. Flugger?te und Drohnen sind billig zu bekommen und handels?bliche Kompaktkameras haben Ausl?sungen von zehn Megapixeln und mehr. Andr? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Objekte gegen Änderungen schützen
Am Mittwoch, 21. Januar 2009 03:10:00 schrieb talk-de-requ...@openstreetmap.org: Hi, Am 21. Januar 2009 00:54 schrieb Detlef Reichl detlef.rei...@gmx.org: implementiert werden sollten. Was dabei raus kommt sieht man bei WikiPedia. Dort mu? derweil auch die kleinste ?nderung an den meisten (alle?) Artikeln von den Admins abgenickt werden. Das t?tet die Motivation vieler Leute. Es tötet auch die Motivation, wenn es keine klare Linie gibt, weil jeder etwas anders für richtig hält. Bitte nur so etwas schreiben, wenn du dir auch sicher bist, danke. (Hint: Es ist nicht der Fall und die gesichteten Versionen, die du m?glicherweise ansprichst, funktionieren anders). Um Verunstaltungen r?ckg?ngig machen zu k?nnen sollte es simple Werkzeuge geben, mit denen man auf eine beliebigen Versionsstand f?r eine Objekt oder einen Bereich zur?ckgehen kann. Der Vorteil von Wikis liegt zum Teil darin, dass das R?ckg?ngigmachen von Vandalismus in der Regel einfacher ist, als die Durchf?hrung desselben. Dies ist derzeit bei OSM leider nicht der Fall. Um genau zu sein wundert es mich immer wieder, dass sich f?r OSM noch niemand ?hnliche fiese Vandalismus-Techniken hat einfallen lassen, wie sie in der WP zur Anwendung kommen. Das denke ich auch. Mit einer gewissen Fehlerhaftigkeit der Daten müssen wir leben. Niemand soll dafür hafbar gemacht werden. Aber es sollte schwerer sein einen Fehler einzufügen oder Daten zu löschen die von den meisten als korrekt angesehen werden. Sonst drehen wir uns im Kreis und kommen nicht voran. Auch denke ich es ist besser langsam fortzuschreiten und wenig Fehler zu haben als schnell und dafür viele. Ich denke, es wäre eine gute Sache, wenn bestimmte Objekte bei jedem Ändern einen Index bekommen. Und ab einem gewissen Punkt müssen sich dann mehrere Leute einig sein dies zu ändern, dann erst wird es vollzogen. Dann bekommen die leeren Bereiche eine magische Anziehungskraft, was wünschenswert wäre. Und Bereiche die schon weit fortgeschritten sind wären besser geschützt, aber immer noch änderbar. Das halte ich für einen guten Kompromiss und einfach handhabbar. Tsch?ss, Tim. Gruß Sven S. -- http://wikipedistik.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Openstreetmap-Daten für Navigationssy steme der Automobilhersteller?
Ich denke schon mal dass es ein Problem ist dass die Automobilhersteller auf eine (Iso...)-Zertifizierung Ihrer Lieferanten bestehen. OSM hat nicht mal ein konsistentes Datenmodell auf das man sich verlassen kann - nicht mal eine Versionierung so dass sich jedes Tag zu jedem beliebigen Zeitpunkt ändern kann. Und die Navihersteller liefern das was der Automobilhersteller von Ihnen verlangt. Also selbst wenn die Naviherrsteller schon eine Umsetzung in der Schublade haben werden diese kaum das Licht der Öffentlichkeit erblicken. Ja, das glaub ich ganz genau auch! Vielleicht sollte man bei der ganzen jetzigen Lizenzdebatte überlegen ob man denn vielleicht bei der Gelegenheit mal etwas in der Richtung, zumindest in einem Fork verändert. Das jetzige OSM sehe ich mehr als eine Experimentalversion. Und es ist in Ordnung ein OSM Experimental zu haben! Das ist nur unattraktiv für Firmen, wie Entwickler von Software für Datenanwendungen, als auch für Anwender. OSM kann noch so tolle Kartendemos machen - ohne einer verlässlichen Datenmodellbeschreibung bleiben es letztenendes nur Demos, auch wenn die Daten 1000mal detailierter und präziser als die kommerziellen Produkte sind. Was wir noch nicht einmal wissen, denn wir bekommen ja nicht die eigentliche Datenbasis von den zwei bekannten Firmen. Sondern die daraus erstellten. Wie kann man also sagen wie gut deren Datenmodel und deren Daten tatsächlich sind? Möglicherweise sind sie sogar besser? Daher _auch_ mein Beitrag: Lizenzumstellung - Warum kein OSM 2.0 mit besserem Datenmodell? Das ist auch immer wieder meine Meinung! Garry Sven ___ 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] Wie erreichen wir einheitliche Tagdefinitionen?
Meine Meinung dazu ist dass man die geplante Lizenzumstellung dazu nutzen sollte ein OSM2.0 zu schaffen. Die Masse wendet OSM wohl in Form von MappnikCo, Garmin-Karten und neuerdings auch den Wiki-Kartenlink an und wird durch die Lizenzumstellung keine Verbesserung, aber eventuell eine grössere Verschlechterung erfahren werden weil plötzlich bereits vorhandene Daten aus Lizenzgründen weg sind. Mit einem neueren, besseren Datenmodell könnte man dafür dann auf mehr Verständniss hoffen. Das finde ich auch! Garry Gruß Sven S. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Josm Java 6
Ich bekomme die neueren Josm Versionen nicht gestartet (Kubuntu 10.04LTS). Das hat mit der Java Einstellung zu tun oder? Eine ältere Version aus dem Repository startet.. Was tun? Gruß Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Josm Java 6
Nein, keine. OpenJDK blinkt zum Starten und erlischt Am Samstag, 13. November 2010, um 13:40:55 schrieb Marco Lechner - FOSSGIS e.V.: gibt es eine Fehlermeldung? Welche? On Sat, 13 Nov 2010 13:34:55 +0100, Sven Sommerkamp s_sommerk...@gmx.de wrote: Ich bekomme die neueren Josm Versionen nicht gestartet (Kubuntu 10.04LTS). Das hat mit der Java Einstellung zu tun oder? Eine ältere Version aus dem Repository startet.. Was tun? Gruß Sven ___ 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] Josm Java 6
D.h. per Konsole ins entsprechende Verzeichnis wechseln und per Befehl Josm starten und gucken was die Konsole ausgibt? Dann sagts Befehl nicht gefunden Am Samstag, 13. November 2010, um 15:50:58 schrieb Carsten Schönert: Hi, hast Du mal per Konsole geschaut was ausgegeben wird? Irgendwas muss ja kommen. cars...@q9550-squeeze64:~$ java -version java version 1.6.0_22 Java(TM) SE Runtime Environment (build 1.6.0_22-b04) Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode) cars...@q9550-squeeze64:~$ java -jar Downloads/josm-latest.jar Repository Root: http://josm.openstreetmap.de/svn Build-Date: 2010-11-09 02:31:31 Last Changed Author: bastiK Revision: 3652 Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b URL: http://josm.openstreetmap.de/svn/trunk Last Changed Date: 2010-11-08 23:29:07 +0100 (Mon, 08 Nov 2010) Last Changed Rev: 3652 Ungültige URL '' im Plugin restart Ungültige URL '' im Plugin restart lade Plugin 'plastic_laf' (Version 2) lade Plugin 'remotecontrol' (Version 22734) RemoteControl::Accepting connections on port 8111 lade Plugin 'undelete' (Version 22365) lade Plugin 'openstreetbugs' (Version 23747) lade Plugin 'PicLayer' (Version 22549) lade Plugin 'tageditor' (Version 21026) lade Plugin 'reverter' (Version 23278) lade Plugin 'validator' (Version 23917) lade Plugin 'terracer' (Version 22169) Silent shortcut conflict: 'tools:Terracer' moved by 'tool:revert' to 'Alt+Umschalt+T'. lade Plugin 'turnrestrictions' (Version 24125) lade Plugin 'measurement' (Version 22547) lade Plugin 'multipoly' (Version 23885) Silent shortcut conflict: 'tools:multipoly' moved by 'tools:mirror' to 'Alt+Umschalt+M'. lade Plugin 'FixAddresses' (Version 24135) lade Plugin 'wmsplugin' (Version 23904) WMSPlugin: initializing remote control RemoteControl: adding command wms (handled by WMSRemoteHandler) lade Plugin 'public_transport' (Version 22148) Silent shortcut conflict: 'menu:Public Transport' moved by 'menu:Presets' to 'Alt+B'. lade Plugin 'ext_tools' (Version 23327) lade Plugin 'buildings_tools' (Version 23804) lade Plugin 'lakewalker' (Version 21706) lade Plugin 'multipoly-convert' (Version 21706) Silent shortcut conflict: 'tools:multipolyconv' moved by 'tools:mirror' to 'A'. lade Plugin 'OpeningHoursEditor' (Version 22850) Am 13.11.2010 13:40, schrieb Marco Lechner - FOSSGIS e.V.: gibt es eine Fehlermeldung? Welche? ___ 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] Josm Java 6
Also die Webstartvariante startet.. Java liegt bei mir am selben Ort. Nachdem ich besagten Befehl benutzt hab, hab ich jene Ausgabe: s...@multikubu:~/Desktop$ java -jar josm-latest.jar Repository Root: http://josm.openstreetmap.de/svn Build-Date: 2010-06-29 01:31:41 Last Changed Author: jttt Revision: 3354 Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b URL: http://josm.openstreetmap.de/svn/trunk Last Changed Date: 2010-06-28 21:31:49 +0200 (Mon, 28 Jun 2010) Last Changed Rev: 3354 icons site: http://josm.openstreetmap.de/plugin-icons.zip Fehler: Das Bild 'importvec.jar/' konnte nicht geladen werden. Das ist ein schwerwiegendes Konfigurationsproblem. Fehler: Das Bild 'restart.jar/' konnte nicht geladen werden. Das ist ein schwerwiegendes Konfigurationsproblem. Fehler: Das Bild 'restart.jar/' konnte nicht geladen werden. Das ist ein schwerwiegendes Konfigurationsproblem. Fehler: Das Bild 'importvec.jar/' konnte nicht geladen werden. Das ist ein schwerwiegendes Konfigurationsproblem. Einstellung proxy.anonymous wird nicht länger benutzt und wurde deshalb entfernt. Einstellung proxy.enable wird nicht länger benutzt und wurde deshalb entfernt. lade Plugin 'remotecontrol' (Version 21706) RemoteControl::Accepting connections on port 8111 lade Plugin 'openstreetbugs' (Version 21706) lade Plugin 'wmsplugin' (Version 18453) lade Plugin 'PicLayer' (Version 21706) lade Plugin 'alignways' (Version 22050) lade Plugin 'routes' (Version 22046) lade Plugin 'buildings_tools' (Version 21846) lade Plugin 'DirectUpload' (Version 21706) Silent shortcut conflict: 'tools:uploadtraces' moved by 'tools:jumpto' to 'Strg+Umschalt+G'. lade Plugin 'lakewalker' (Version 21706) lade Plugin 'AddrInterpolation' (Version 21710) lade Plugin 'photo_geotagging' (Version 21706) lade Plugin 'turnrestrictions' (Version 21706) s...@multikubu:~/Desktop$ s...@multikubu:~/Desktop$ java -jar josm-latest.jar Repository Root: http://josm.openstreetmap.de/svn Build-Date: 2010-06-29 01:31:41 Last Changed Author: jttt Revision: 3354 Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b URL: http://josm.openstreetmap.de/svn/trunk Last Changed Date: 2010-06-28 21:31:49 +0200 (Mon, 28 Jun 2010) Last Changed Rev: 3354 Fehler: Das Bild 'restart.jar/' konnte nicht geladen werden. Das ist ein schwerwiegendes Konfigurationsproblem. Fehler: Das Bild 'importvec.jar/' konnte nicht geladen werden. Das ist ein schwerwiegendes Konfigurationsproblem. lade Plugin 'remotecontrol' (Version 22734) RemoteControl::Accepting connections on port 8111 lade Plugin 'openstreetbugs' (Version 22466) lade Plugin 'wmsplugin' (Version 18453) lade Plugin 'PicLayer' (Version 21706) lade Plugin 'alignways' (Version 23165) lade Plugin 'routes' (Version 22046) lade Plugin 'buildings_tools' (Version 22164) lade Plugin 'DirectUpload' (Version 22017) Silent shortcut conflict: 'tools:uploadtraces' moved by 'tools:jumpto' to 'Strg+Umschalt+G'. lade Plugin 'lakewalker' (Version 21706) lade Plugin 'AddrInterpolation' (Version 21710) lade Plugin 'photo_geotagging' (Version 21706) lade Plugin 'turnrestrictions' (Version 21706) Am Samstag, 13. November 2010, um 16:24:10 schrieb Carsten Schönert: Du kannst ruhig den Output posten :-) weil eine Glaskugel haben wir alle nicht. Dann schau mal folgendes und prüfe welche Version nun bei dir installiert ist. Wo liegt dein Java, erstens liegt es in der Pfadvariable cars...@q9550-squeeze64:~/tilesAtHome$ which java /usr/bin/java Ok, was verbirgt sich dahinter? cars...@q9550-squeeze64:~/tilesAtHome$ ls -la /usr/bin/java lrwxrwxrwx 1 root root 22 14. Sep 14:54 /usr/bin/java - /etc/alternatives/java Aha, ein Symlink, also weiter cars...@q9550-squeeze64:~/tilesAtHome$ ls -la /etc/alternatives/java lrwxrwxrwx 1 root root 36 14. Sep 14:53 /etc/alternatives/java - /usr/lib/jvm/java-6-sun/jre/bin/java Noch ein Symlink, jetzt aber cars...@q9550-squeeze64:~/tilesAtHome$ ls -la /usr/lib/jvm/java-6-sun/jre/bin/java -rwxr-xr-x 1 root root 50810 15. Sep 10:35 /usr/lib/jvm/java-6-sun/jre/bin/java Wenn bei Dir gar nichts zu sehen ist dann musst Du für Deine Distri prüfen ob Dein Java richtig installiert ist, Ich benutze ein Debian Squeeze, bei Ubuntu wird dies möglicher Weise leicht anders sein, Info gibt es wohl im Wiki von Ubuntu cars...@q9550-squeeze64:~/tilesAtHome$ dpkg -l | grep java ii java-common 0.40 Base of all Java packages ii libcommons-codec-java 1.4-2 encoder and decoders such as Base64 and hexadecimal codec ii libgettext-commons-java 0.9.6-2Java classes for internationalization (i18n) ii libjaxp1.3-java 1.3.05-1 Java XML parser and transformer APIs (DOM, SAX, JAXP, TrAX) ii libmetadata-extractor-java 2.3.1+dfsg-2 JPEG metadata extraction framework ii liboauth-signpost-java 1.2.1.1-1 simple OAuth message
Re: [Talk-de] Josm Java 6
So startet meine alte Version aus dem Repository.. Frag mich auch wird das nicht mehr gepflegt? Schade! Sven Am Samstag, 13. November 2010, um 16:26:36 schrieb Florian Gross: Am Samstag 13 November 2010, 16:01:50 glaubte Sven Sommerkamp zu wissen: D.h. per Konsole ins entsprechende Verzeichnis wechseln und per Befehl Josm starten und gucken was die Konsole ausgibt? Dann sagts Befehl nicht gefunden Starte es mal mit java -jar [JOSM-PROGRAMMNAME] also z.B. mit java -jar josm-latest.jar flo ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Navigon POI aus OSM Daten
Am Sonntag, 12. Juni 2011, 15:08:38 schrieb Stephan Knauss: Hallo, in der Wochennotiz stand es ja schon drin: Navigons neue POI Datenbank mit 2.2 Millionen Einträgen basiert auf OSM Daten. http://www.navigon.com/portal/de/uebernavigon/presse/artikel/110609_OSM_ove rmap.html Ich denke wir können stolz sein und es als Auszeichnung auffassen wenn unsere Daten als so hochwertig angesehen werden dass Navigon diese verwendet. Schon, ja! Was mich interessieren würde ist, ob Navigon auch die Anforderungen unserer Lizenz, also CC-BY-SA einhält. Das abgeleitete Werk muss ebenfalls unter dieser Lizenz stehen, ebenso muss zumindest Openstreetmap genannt werden. Und ohne bisher danach gesucht zu haben, denke ich das das wohl nicht passiert ist.. Und ich denke mit solchen schwarzen Schafen muß anders umgegangen werden! Deswegen stellen wir unsere Arbeit, in die wir viel Zeit und Muße stecken unter die entsprechenden Lizenzen. Wenn das nicht geschieht, brauchen wir sie gar nicht. Dann ergeht es vielen die an solchen Projekten mitarbeiten wie dem damaligen Tetris Erfinder.. Welche Firma hat sich doch gleich eine goldene Nase damit verdient..? So.y? Hat jemand ein Navigon Gerät und dieses POI Paket gekauft? Könnte mal über Erfahrungen damit berichtet werden? Viele Grüße, Stephan Schöne Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Antw.: Netter Artikel auf Heise
Stimmt auch was in dem Artikel steht. Das sind für Radfahrer ganz entscheidende Vorteile. Aber was für mich im Moment auch eine starke Anziehungskraft hat, ist die sinnvolle Verknüpfung und prakitsche Anwendbarkeit der Daten, die ich bei meinem Androidhandy wirklich sehr schätzen gelernt habe. Ich würde mir wünschen, das man das so auch in Linux basierten Handys und auf Rechnern noch besser hinbekommt. Das wird wohl allgemein als Systemintegration bezeichnet.. Schöne Grüße Sven - Reply message - Von: Jan Tappenbeck o...@tappenbeck.net An: talk-de@openstreetmap.org Betreff: [Talk-de] Netter Artikel auf Heise Datum: Fr., Jul. 1, 2011 11:16 Am 01.07.2011 10:14, schrieb Jacques Nietsch: http://www.heise.de/ct/artikel/App-ins-Gruene-1260683.html Da kommt OSM ziemlich gut bei weg :-) Jacques Hi ! Das ist ein Auszug aus dem aktuellen Magazin !! Gruß Jan :-) ___ 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] Redundanz?
Würde man statt einem Waldstück jeden einzelnen Baum erfassen? Warum nicht? Vielleicht mit Pilzbewuchs und ohne als Tag? Die Frage ist doch immer wieviel ist ausreichend und macht Sinn? Und ist ist das Konstrukt noch allgemein durchschaubar? Gruß Sven Am Mittwoch, 6. Juli 2011, 11:40:06 schrieb Florian Lohoff: On Wed, Jul 06, 2011 at 10:50:41AM +0200, Andreas Neumann wrote: Moin, bevor ich einen Editwar beginnen, wollte ich nur klären, ob ich da falsch liege... Es geht darum, wenn mehrere Bänke an einem Platz stehen. Ich hab immer einen Node für jede Bank gesetzt. Nun geht ein User in Ilmenau durch und löscht die Bänke. Auf unserem Kirchplatz stehen jeweils Bäumchen mit Bänken, er machte daraus einen Baum mit Bank. Er verweist darauf, dass mehrere Bänke an einem Ort redundant sind und es ausreicht nur eine zu malen. Gibt es da eine Redundanz-Regel, die ich nicht kenne? Aeh? Stehen alle Baeume und Baenke auf exakt derselben Position? Wenn nicht dann muessen sie doch rein logisch schon einzeln gezeichnet werden. Flo -- „Zwanghaftes Arbeiten allein würde die Menschen ebenso verrückt machen wie absolutes Nichtstun. Erst durch die Kombination beider Komponenten wird das Leben erträglich.“ Erich Fromm (1900-80), amerik. Psychoanalytiker dt. Herkunft ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
