Re: [Talk-de] Garminkarte jetzt mit maxspeed
Hallo, Frederik Ramm schrieb: Was genau muesste osmcut denn tun, um diese Luecken zu vermeiden? Dann Um die Lücken zu vermeiden muß in die Kacheln, in der ein Weg auftaucht alle nodes hinein, die der Weg benutzt. Das ist zwar manchmal richtig viel (daher meine gelegentlichen Riesenkacheln) aber nur den ersten Punkt in der Nachbarkachel zu nehmen reicht nicht. Mein Cutter merkt sich für alle Nodes die Zielkachel und die Koordinaten, danach kann er beim Bearbeiten der Ways die Nodes heraussuchen, die er alle braucht und ebenfalls in die richtige Zielkachel kopieren. Die Ways erscheinen immer nur einmal, in der Kacheln in der der erste Node des ways ist. Das große Problem ist im Moment die Behandlung der Relationen, da muß auf jeden Fall was abgeschnitten werden, sonst macht jemand eine Relation ist in der BRD und schon kann ich meinen cutter vergessen. :-) (Wie die Zielkachelnummern ausgerechnet werden steht übrigens auf meiner Wiki-Seite/Diskussionsseite) kann ich das ja mal reparieren. - Aber osmcut teilt ja ganz rigide an einem geometrischen Muster, ist das ueberhaupt noch zeitgemaess, ist der Mechanismus des Splitters nicht viel besser (wenn auch vielleicht noch etwas buggy)? Warum nicht mit festen Kacheln erstmal bleiben, die Elementdichte sollte noch eine Weile ausreichen, und man hat ein festes Raster um Kacheln zusammenzustellen, die Nummern bleiben ja auch immer gleich (zumindest bei mir). -- Viele Gruesse Computerteddy ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkarte jetzt mit maxspeed
Hallo, Christoph Wagner schrieb: Kachelgrenzen, deswegen nehm ich erstmal nicht osmcut. Und das tool, was computerteddy benutzt scheint ja leider nicht veröffentlich zu sein. Ich bin immer noch daran den Programmierer von CutTheOsmPlanet zu überzeugen, das endlich zu veröffentlichen. Wer übrigens hindert Dich daran einfach meine geschnittenen OSM-Kacheln zu verwenden? OK, das Routing funktioniert dann erstmal nicht über die Kachelgrenzen, aber vielleicht findet sich mal jemand dem Steve zu erklären, wie meine Karten aufgebaut sind, damit er das Routing so in mkgmap einbauen kann, das dann auch mit meinen Kacheln funktioniert. -- Viele Gruesse Computerteddy ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Treppenrouting fuer Radfahrer
Am 5. Mai 2009 17:50 schrieb Sven Sommerkamp s_sommerk...@gmx.de: Bei 500m Umweg würde ich niemals die Treppen nehmen und ich denke mehr wird es sehr, sehr selten sein. Innerstädtisch magst Du recht haben, aber wenn man an Flussbrücken ausserorts denkt, kann das schon sehr schnell passieren. z.B. spaltet sich der Radfernweg R3 bei Okriftel wegen einer Treppe in zwei Alternativen auf: http://openstreetmap.org/?lat=50.0522lon=8.4958zoom=14layers=00B0FTF Grüße, jens ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ref tag bei ways erforderlich wenn eine relation existiert?
Werner Hoch schrieb: ich frage mich ob ich an jeden einzelnen Wegabschnitt ein ref= tag anbringen muss obwohl viele Wege ja bereits über eine Relation eine ref= tag haben. Beispiel1: Jeder Weg mit Referenz: http://www.openstreetmap.org/browse/relation/3420 operator = Bodenseekreis ref = K 7735 route = road type = route Beispiel2: Wege ohne Referenz: http://www.openstreetmap.org/browse/relation/10949 operator = Bodenseekreis ref = K 7719 route = road type = route Im Beispiel2 werden die Referenzen auf den Straßen in Mapnik und TAH nicht dargestellt. Momentan ist es wohl besser, die Tags doppelt zu führen, da die Relation mit type=route und route=road von keiner mir bekannten Anwendung ausgewertet wird. Zukünftig ist es natürlich sinnvoller, gemäß Beispiel 2 zu taggen. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] abkickende vorfahrt
Hi, gibt es eine anerkannte Loesung um abknickende vorfahrten zu taggen? Im moment wird das ja mit unserem datenmodell nicht funktionieren das das navi entweder sagt Der abbiegende Vorfahrt nach Rechts folgen oder auch nur einfach die klappe haelt wie mein festeinbau. Im moment probiere ich bei sowas immer aus der abkickenden straße eine Kurve zu modellieren so das quasi visuell die straße eine Kurve beschreibt und in der Kurve eine Straße abbiegt. Das entspricht ja aber desoefteren mal nicht der realitaet ... Eine idee die ich hatte war das mit den turn restriction relation zu verknoten um eine designated direction mit einzufuegen - allerdings waere das sprachlich ja falsch weil keine restriction im engeren Sinne. Ideen? Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkarte jetzt mit maxspeed
On 09-05-06 01:48:53 CEST, Colin Marquardt wrote: Am 5. Mai 2009 23:28 schrieb Christoph Wagner freemaps@googlemail.com: Okay okay, im Moment läuft ein erneuter Versuch. Könnte sein, dass ich die Karten auf dem Server wohl doch nicht einfach so automatisch per ftp überschreiben konnte. Hab sie erstmal von Hand gelöscht und nach ca. ner Stunde sollten sie wieder aktuell da sein. Wenn nicht, müsst ihr bis morgen früh warten. Da guck ich dann wieder rein. Es ist eine Karte dort, aber der Inhalt scheint mir genau wieder der alte Stand zu sein, wenn ich mich nicht selber vertan habe. ja, mit 342128906 bytes länge ist sie exakt genauso lang wie die vom 2009-04-24, und ein herunterladen von ein paar kilobytes bestätigt auch dass sie gleich sind. offenbar ist durch den upload per ftp nur der originale zeitstempel verloren gegangen, aber es handelt sich wieder um die alte version. irgendeine kleinigkeit muss da noch übersehen worden sein... ;-) rj ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkarte jetzt mit maxspeed
On Wed, May 06, 2009 at 08:03:05AM +0200, Carsten Schwede wrote: Um die Lücken zu vermeiden muß in die Kacheln, in der ein Weg auftaucht alle nodes hinein, die der Weg benutzt. Das ist zwar manchmal richtig viel (daher meine gelegentlichen Riesenkacheln) aber nur den ersten Punkt in der Nachbarkachel zu nehmen reicht nicht. Waere es nicht eigentlich ausreichend aus dem letzten punkt in der kachel und dem ersten punkt ausserhalb der kachel einen punkt direkt auf der kachelgrenze zu berechnen und die restlichen Punkten ausserhalb der Kachel aus dem Weg zu entfernen? Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] abkickende vorfahrt
Original-Nachricht Datum: Wed, 6 May 2009 08:28:22 +0200 Von: Florian Lohoff f...@rfc822.org An: talk-de@openstreetmap.org Betreff: [Talk-de] abkickende vorfahrt Hi, gibt es eine anerkannte Loesung um abknickende vorfahrten zu taggen? Eigentlich kenne ich gar keine Moeglichkeit in OSM die Vorfahrt zu taggen. Bei der Auswertung gehe ich davon aus, dass die hoehere Strassenklasse Vorfahrt vor der niedrigeren hat und beruecksichtige das auch beim Taggen, was aber nicht immer konfliktfrei geht. Das wechseln von niedrig auf hoeher ist dann fuer den Router 'teurer' als der Wechseln von hoeher auf niedriger, egal ob abknickend oder nicht. Wenns die Realitaet hergibt, also die Vorfahrststrasse in der Realitaet baulich hervorgehoben ist, versuche ich das auch aehnlich wie von dir beschrieben abzubilden, sonst nicht. Gruesse Hubert -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ref tag bei ways erforderlich wenn eine relation existiert?
Hallo! Stefan Dettenhofer (StefanDausR) schrieb: Werner Hoch schrieb: ich frage mich ob ich an jeden einzelnen Wegabschnitt ein ref= tag anbringen muss obwohl viele Wege ja bereits über eine Relation eine ref= tag haben. Beispiel1: Jeder Weg mit Referenz: http://www.openstreetmap.org/browse/relation/3420 operator = Bodenseekreis ref = K 7735 route = road type = route Momentan ist es wohl besser, die Tags doppelt zu führen, da die Relation mit type=route und route=road von keiner mir bekannten Anwendung ausgewertet wird. Zukünftig ist es natürlich sinnvoller, gemäß Beispiel 2 zu taggen. Auch wenn die Aussage grundsätzlich nicht falsch ist, möchte ich wie immer bei diesem Thema darauf hinweisen, daß vor einer technischen Umsetzung auch noch einige grundsätzliche logische Probleme zu klären und Festlegung zu treffen wären. Z.B. was überhaupt passieren soll, wenn der way keine ref hat, aber er gehört zu einer road-Relation, zu einer bus-Relation und zu zwei hiking-Relationen und alle 4 Relationen haben eine ref. Das mit den Relationen sieht nur auf den ersten Blick einfach aus, ist aber ziemlich knifflig. Stichwort für Informatiker: Mehrfachvererbung. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] abkickende vorfahrt
Florian Lohoff schrieb: Hi, gibt es eine anerkannte Loesung um abknickende vorfahrten zu taggen? Mir nicht bekannt. Im moment wird das ja mit unserem datenmodell nicht funktionieren das das navi entweder sagt Der abbiegende Vorfahrt nach Rechts folgen oder auch nur einfach die klappe haelt wie mein festeinbau. Oder wie bei meinem noch schlimmer: manchmal meint er einen Abbiegehinweis zu geben und manchmal nicht. Da kann man sich überhaupt nicht mehr drauf verlassen. Ich fürchte, daß läßt sich algorithmisch nicht in den Griff bekommen ... Im moment probiere ich bei sowas immer aus der abkickenden straße eine Kurve zu modellieren so das quasi visuell die straße eine Kurve beschreibt und in der Kurve eine Straße abbiegt. Das entspricht ja aber desoefteren mal nicht der realitaet ... Die Straße sollte ja auf der Karte schon eher der geometrischen Realität folgen und weniger der Vorfahrtsregelung ;-) Eine idee die ich hatte war das mit den turn restriction relation zu verknoten um eine designated direction mit einzufuegen - allerdings waere das sprachlich ja falsch weil keine restriction im engeren Sinne. Ist zwar ähnlich, aber halt keine restriction. Spontane Ideen: Für einfach Fälle (wo die Vorfahrt der höchsten Straßenklasse folgt): Node mit: traffic_sign=right_of_way Für schwierige Fälle: Eine Relation (ähnlich wie turn_restrictions) mit to, via und from und type=right_of_way Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Treppenrouting fuer Radfahrer
Morgen Martin! Das geht vielleicht hier unten im Thread etwas unter. Wenn der Vorschlag ausgereift ist, könntest Du ihn ggf. als eigenen Thread beginnen. Martin Koppenhoefer schrieb: 1. 2 Spuren für Kinderwägen (oder Fahrräder) 2. 1 Rille (aus meist Stahlprofil) für Fahrräder 3. parallele Transportbänder für Gepäck (selten, aber gibt's z.B. in Tübingen am Hauptbahnhof). Es gibt auch eine (etwas breitere) Beton- oder Steinspur am Rand, wo das Rad-Hochschieben IMHO noch bequemer ist als mit einer Stahlrille. Gesehen am Bahnhof Ratingen Ost in der Unterführung am Busbahnhof: http://www.openstreetmap.org/?mlat=51.295548mlon=6.863969zoom=14 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ref tag bei ways erforderlich wenn eine relation existiert?
Hallo Nop, Nop schrieb: Hallo! Stefan Dettenhofer (StefanDausR) schrieb: Werner Hoch schrieb: ich frage mich ob ich an jeden einzelnen Wegabschnitt ein ref= tag anbringen muss obwohl viele Wege ja bereits über eine Relation eine ref= tag haben. Beispiel1: Jeder Weg mit Referenz: http://www.openstreetmap.org/browse/relation/3420 operator = Bodenseekreis ref = K 7735 route = road type = route Momentan ist es wohl besser, die Tags doppelt zu führen, da die Relation mit type=route und route=road von keiner mir bekannten Anwendung ausgewertet wird. Zukünftig ist es natürlich sinnvoller, gemäß Beispiel 2 zu taggen. Auch wenn die Aussage grundsätzlich nicht falsch ist, möchte ich wie immer bei diesem Thema darauf hinweisen, daß vor einer technischen Umsetzung auch noch einige grundsätzliche logische Probleme zu klären und Festlegung zu treffen wären. Z.B. was überhaupt passieren soll, wenn der way keine ref hat, aber er gehört zu einer road-Relation, zu einer bus-Relation und zu zwei hiking-Relationen und alle 4 Relationen haben eine ref. Das mit den Relationen sieht nur auf den ersten Blick einfach aus, ist aber ziemlich knifflig. Stichwort für Informatiker: Mehrfachvererbung. eigentlich ist es doch ganz einfach (oder sehe ich da was falsch): 1) Es werden erst einmal nur die Relationen gerendert bzw. ausgewertet, also nicht mehr auf der Ebene von ways gearbeitet sondern eine Ebenen höher. 2) Dann ist das mit der Vererbung auch kein Problem, denn die Tags in der Relation stellen den Defaultwert dar, der durch einen speziellen am way überschrieben werden kann. 3) Zuletzt werden noch alle ways, die keiner road-Relation angehören, klassisch rerendert. Um bei Deinem Beispiel zu bleiben: - Mit Hilfe der road-Relation und vererbtem ref-Tag (ggf. auch name-Tag) plus aller way ohne road-Relation wird die normale Straßenkarte erzeugt. - Mit Hilfe der bus-Relation und vererbtem (anderem) ref-Tag werden die Buslinien darüber gezeichnet - Mit Hilfe der hiking-Relation und vererbtem (anderem) ref-Tag (und weiteren vererbten Tags) werden die Wanderwege generiert. Aber das ist doch jetzt im Prinzip auch schon nicht anders, oder? Gruß, Stefan P.S.: So können auch die Superrelationen behandelt werden: Erst alle Superrelationen eines typs, dann alle Relationen dieses typs, die keinen Superrelation angehören und zum Schluss alle ways, die keiner Relation angehören. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] abkickende vorfahrt
Original-Nachricht Datum: Wed, 06 May 2009 09:18:01 +0200 Von: Ulf Lamping ulf.lamp...@googlemail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] abkickende vorfahrt Für einfach Fälle (wo die Vorfahrt der höchsten Straßenklasse folgt): Node mit: traffic_sign=right_of_way Mein Loesungsansatz waere, die zwei Schilder fuer die beiden Richtungen an der Vorfahrtsstrasse zu erfassen und in eine relation mit der Strecke dazwischen zu geben (siehe auch mein Schilderthema oben). Vollstaendig beschrieben ist die Situation, wenn man auch noch die 'Vorfahrt achten'-Schilder der anderen Strasse(n) reinnimmt. Die Auswertung waere zwar nicht trivial, aber eindeutig loesbar. Gruesse Hubert -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkarte jetzt mit maxspeed
Hallo, Florian Lohoff schrieb: Waere es nicht eigentlich ausreichend aus dem letzten punkt in der kachel und dem ersten punkt ausserhalb der kachel einen punkt direkt auf der kachelgrenze zu berechnen und die restlichen Punkten ausserhalb der Kachel aus dem Weg zu entfernen? Leider reicht das nicht, zumindest für Polygone, es kann dann wieder zu Fehlern kommen, wenn die Punkte so verteilt sind: *+ * ''' * ' * *+'** ' ' Die durch die ' angedeutete Kachel wird gerechnet. Die + bezeichnen die Nodes, die die ersten außerhalb der Kachel sind. Wenn man hier jetzt entweder die Kreuuzung des Polygons mit der Kachegrenze oder auch die ersten außenliegenden Punkte betrachtet, dann gibt das Endergebnis ein falsches Polygon bei dem die Ecke abgeschnitten ist. Ich denke auch, daß diese Berechnung richtig viel Zeit in Anspruch nimmt. -- Viele Gruesse Computerteddy ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] abkickende vorfahrt
Florian Lohoff schrieb: Im moment wird das ja mit unserem datenmodell nicht funktionieren das das navi entweder sagt Der abbiegende Vorfahrt nach Rechts folgen oder auch nur einfach die klappe haelt wie mein festeinbau. Ich denke dass man das ohne spezieller turn_restriction o.ä. nur von der höheren Straßenklasse ableiten kann und ggf. bei gleicher Straßenklasse auswertet, ob sich der ref-Tag bzw. der Name ändert. Bei meinem Navi ist das auch oft so, dass es sagt: in 300m geradeaus fahren, obwohl nur links eine Straße der selben Klasse abzweigt. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] abkickende vorfahrt
Hallo. Am Mittwoch 06 Mai 2009 09:39:08 schrieb Stefan Dettenhofer (StefanDausR): Ich denke dass man das ohne spezieller turn_restriction o.ä. nur von der höheren Straßenklasse ableiten kann und ggf. bei gleicher Straßenklasse auswertet, ob sich der ref-Tag bzw. der Name ändert. Bei meinem Navi ist das auch oft so, dass es sagt: in 300m geradeaus fahren, obwohl nur links eine Straße der selben Klasse abzweigt. Es wird oft genug ohne eine besondere Angabe der Vorfahrtsregelung nicht möglich sein, die Situation algorithmisch zu erkennen. Beispiel: http://www.openstreetmap.org/?lat=49.005005lon=9.502024zoom=18 Die Bundesstraße zweigt ab, in einem Winkel 90°, grade aus geht nur eine Landesstraße. Eigentlich spricht da alles für eine abknickende Vorfahrtstraße. Wie man hier sieht... http://maps.google.de/?ll=49.004951,9.501194z=18t=k ...ist das aber nicht so. Gruß, Bernd -- Am Ende sind alle Probleme der Wirtschaft Personalprobleme. - Alfred Herrhausen (dt. Bankier) signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ref tag bei ways erforderlich wenn eine relation existiert?
Hi! Stefan Dettenhofer (StefanDausR) schrieb: eigentlich ist es doch ganz einfach (oder sehe ich da was falsch): Ja. :-) Du machst einige Annahmen, für die es noch weder eine Einigung noch eine dokumentierte Festlegung gibt. 1) Es werden erst einmal nur die Relationen gerendert bzw. ausgewertet, also nicht mehr auf der Ebene von ways gearbeitet sondern eine Ebenen höher. 2) Dann ist das mit der Vererbung auch kein Problem, denn die Tags in der Relation stellen den Defaultwert dar, der durch einen speziellen am way überschrieben werden kann. 3) Zuletzt werden noch alle ways, die keiner road-Relation angehören, klassisch rerendert. Funktioniert nur bei einer einzigen Relation, nicht mehr bei mehreren. Um bei Deinem Beispiel zu bleiben: - Mit Hilfe der road-Relation und vererbtem ref-Tag (ggf. auch name-Tag) plus aller way ohne road-Relation wird die normale Straßenkarte erzeugt. - Mit Hilfe der bus-Relation und vererbtem (anderem) ref-Tag werden die Buslinien darüber gezeichnet - Mit Hilfe der hiking-Relation und vererbtem (anderem) ref-Tag (und weiteren vererbten Tags) werden die Wanderwege generiert. Es gibt derzeit keine definierte Unterscheidung von Relationen, es gibt nur einen kurzen Kommentar im Wiki daß _alle_ Tags weitervererbt werden sollen. Es gibt keine Festlegung über die Art- und Weise welche oder wie diese Relationen ausgewertet werden sollen und auch keine definierte Reihenfolge. Das Ergebnis wäre nach heutigem Stand der Definition absolut zufällig. Deine Lösung nimmt an, daß Relationen gezielt unterschieden werden können, daß es extra Layers für unterschiedliche Themen gibt und Du gehst nur auf die speziellen Relationen in meinem Beispiel ein. Die Software könnte mangels Festlegungen und Regeln die Relationen nicht unterscheiden, die sind von der derzeitigen Definition her alle gleich. Und ich kann jederzeit eine Relation mit neuem Typ eintragen und wieder alles durcheinanderbringen. Allein für Wanderrouten gibt es z.B. 3 Typen und 2 weitere in Diskussion. Wie gesagt: Der Fall mit einer Relation sieht einfach aus. Für Fälle mit mehreren, konkret angegebenen Relationen kann ein Mensch noch eine Lösung austüfteln, die aber evtl. für unterschiedliche Karten unterschiedlich aussieht. Aber davon, daß wir es so gut beschrieben haben, daß es in allen Renderern das gleiche Ergebnis liefert und daß ein Mapper irgendeinen Plan hat, was seine Einträge bedeuten werden, sind wir noch sehr weit entfernt. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] abkickende vorfahrt
Bernd Wurst schrieb: Hallo. Am Mittwoch 06 Mai 2009 09:39:08 schrieb Stefan Dettenhofer (StefanDausR): Ich denke dass man das ohne spezieller turn_restriction o.ä. nur von der höheren Straßenklasse ableiten kann und ggf. bei gleicher Straßenklasse auswertet, ob sich der ref-Tag bzw. der Name ändert. Bei meinem Navi ist das auch oft so, dass es sagt: in 300m geradeaus fahren, obwohl nur links eine Straße der selben Klasse abzweigt. Es wird oft genug ohne eine besondere Angabe der Vorfahrtsregelung nicht möglich sein, die Situation algorithmisch zu erkennen. Beispiel: http://www.openstreetmap.org/?lat=49.005005lon=9.502024zoom=18 Die Bundesstraße zweigt ab, in einem Winkel 90°, grade aus geht nur eine Landesstraße. Eigentlich spricht da alles für eine abknickende Vorfahrtstraße. Wie man hier sieht... http://maps.google.de/?ll=49.004951,9.501194z=18t=k ...ist das aber nicht so. Gruß, Bernd Ja das wollte ich ja sagen: 1) Auswertung nach Straßenklasse - Normalfall 2) Spezielle relation analog der turn_restriction - Sonderfall Der Sonderfall kann dann natürlich auch eine Vorfahrtsregel sein, die geradeaus weist. Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] abkickende vorfahrt
wir haben doch dieses maechtige werkzeug namens relationen. ich kenn mich zwar nicht wirklich damit aus aber waere folgendes nicht relativ einfach machbar: eine abknickende vorfahrtstraße gibt's eigentlich nur an einer kreuzung oder einmuendung mit drei oder mehr ways, wobei exakt zwei davon die vorfahrtstraße bilden. da sollte es doch ein einfaches zu sein, eine relation vom type priority oder so zu erstellen, die diese beiden ways enthaelt. optional kann man ja auch noch den verbindungsnode und die entsprechenden schilder mit reinnehmen. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] abkickende vorfahrt
Original-Nachricht Datum: Wed, 6 May 2009 09:46:41 +0200 Von: Bernd Wurst be...@bwurst.org An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] abkickende vorfahrt Es wird oft genug ohne eine besondere Angabe der Vorfahrtsregelung nicht möglich sein, die Situation algorithmisch zu erkennen. Stimmt natuerlich, darum hatte ich oben geschrieben, dass das nicht konfliktfrei geht. Selbst wenn die Vorfahrt ein herausgehobenes Kriterium bei der Klassifizierung waere, bin ich schon ueber Situationen gestolpert, bei denen die Vorfahrt so verflochten ist, dass man in eine Kreisabhaengigkeit kommt, die nicht loesbar ist. Solange man nichts anderes hat, ist die Klasse noch das beste Kriterium. Die refs sind noch problematischer. Landes-, Kreis und Gemeindestrassen gehen deutlich oefter schlecht nachvollziehbar ineinander ueber als Bundesstrassen mit den anderen Klassen. Gruesse Hubert -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ref tag bei ways erforderlich wenn eine relation existiert?
Hi! Bernd Wurst schrieb: Die Mehrfachvererbung wird aber nur dann zum Problem, wenn man keine mehreren Werte haben kann. Da es in der Praxis durchaus passiert, dass eine Straße gleichzeitig zwei ref- Nummern trägt, ist das Problem also dadurch zu lösen, dass mehrere Werte einfach okay sind. Busrouten und Straßen sollten natürlich anhand des Taggings unterschieden werden, eine Straße sollte nicht durch Mehrfachvererbung plötzlich B 123 und Stadtbus 53 parallel als ref erhalten. Genau darum geht es: Wie willst Du das verhindern? Und zwar so allgmein formuliert, daß es in jedem Renderer zuverlässig umsetzbar ist? Jetzt hast schon in dem einfachen Beispiel Relationen, von denen Du mehrfache Werte zulassen würdest und andere, von denen Du keine oder nur einfache Vererbung haben willst - und keine definierte Regel, wie man das unterscheiden könnte und auch keine Möglchkeit ein die beiden oder auch eine andere-Ref zu erzeugen. Nehmen wir noch eine neue, unbekannte Relation hinzu (ich darf ja jederzeit neue Typen eintragen oder den Way weiteren Relationen zuordnen), und das Chaos ist komplett. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkarte jetzt mit maxspeed
Am 6. Mai 2009 08:28 schrieb Robert Joop 5313501608656...@rainbow.in-berlin.de: On 09-05-06 01:48:53 CEST, Colin Marquardt wrote: Am 5. Mai 2009 23:28 schrieb Christoph Wagner freemaps@googlemail.com: Okay okay, im Moment läuft ein erneuter Versuch. Könnte sein, dass ich die Karten auf dem Server wohl doch nicht einfach so automatisch per ftp überschreiben konnte. Hab sie erstmal von Hand gelöscht und nach ca. ner Stunde sollten sie wieder aktuell da sein. Wenn nicht, müsst ihr bis morgen früh warten. Da guck ich dann wieder rein. Es ist eine Karte dort, aber der Inhalt scheint mir genau wieder der alte Stand zu sein, wenn ich mich nicht selber vertan habe. ja, mit 342128906 bytes länge ist sie exakt genauso lang wie die vom 2009-04-24, und ein herunterladen von ein paar kilobytes bestätigt auch dass sie gleich sind. offenbar ist durch den upload per ftp nur der originale zeitstempel verloren gegangen, aber es handelt sich wieder um die alte version. irgendeine kleinigkeit muss da noch übersehen worden sein... ;-) Tatsächlich! Schon wieder eine Kleinigkeit übersehen! Es ist unglaublich wieviel man eigentlich falsch machen kann bei so nem blöden Shellskript. Schaut bitte jetzt nochmal, ob sich das Problem erledigt hat. Jetzt hab ich den Fehler aber wirklich gefunden... Nochmals sorry... Grüße Christoph ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] abkickende vorfahrt
On Wed, May 06, 2009 at 09:39:08AM +0200, Stefan Dettenhofer (StefanDausR) wrote: Ich denke dass man das ohne spezieller turn_restriction o.ä. nur von der höheren Straßenklasse ableiten kann und ggf. bei gleicher Straßenklasse auswertet, ob sich der ref-Tag bzw. der Name ändert. Bei meinem Navi ist das auch oft so, dass es sagt: in 300m geradeaus fahren, obwohl nur links eine Straße der selben Klasse abzweigt. Ich habe hier mehrere Faelle wo das alles die gleiche Klasse ist - Selbst der Name aendert sich an der Stelle - Die abknickende Vorfahrt existiert da meiner Meinung nach um dem typischen Verkehrsfluss Rechnung zu tragen. Aber selbst wenn Klasse, Name und Ref gleich bleibt die Straße aber nach rechts abknickt erwarte ich vom Navi das es mir sagt Der Bundesstraße nach rechts folgen - Denn es mag durchaus Situationen geben - gerade Innerorts - wo fuer den Ortsunkundigen bei Dunkelheit nicht ersichtlich ist das die Land/Bundes/Kreisstraße abknickt. Hingegen wenn der Verkehrsfluss durch eine abknickende Vorfahrt in eine Richtung gelenkt wird, kann das Navi die Klappe halten. D.h. ein explizites taggen einer abknickenden Vorfahrt ist noetig. Da es sich um from/to/via geschichten handelt ist es ein identisches problem wie die turn restrictions. Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ref tag bei ways erforderlich wenn eine relation existiert?
Hallo Nop, Nop schrieb: (...) Ja. :-) Du machst einige Annahmen, für die es noch weder eine Einigung noch eine dokumentierte Festlegung gibt. (...) Du hast natürlich recht, dass das momentan so noch nicht läuft (daher hatte ich ja weiter oberen geschrieben, dass man derzeit die ref-tags besser auch noch an die ways schreibt. Wir diskutieren hier aber doch eher über die zukünftige Entwicklung! Aber auch nach momentanem Stand ist es doch so (egal ob beschrieben oder nicht): Eine Relation mit route=road und type=route wird gar nicht ausgewertet, stellt aber eine logische Zusammenfassung einer Straße dar, die aus vielen ways besteht (mit unterschiedlichen maxspeed=..., bridge=... etc.), aber die selbe ref und highway-typ hat. Also hier mein verbesserter *Vorschlag*, wie man das lösen könnte: Relation: operator = Bodenseekreis ref = K 7735 route = road type = route highway = secondary Member 1: cycleway = lane name = Meistershofener Straße Member 2: junction = roundabout oneway = yes ... Es wird auf Relationsebene gerendert, wenn dort auch der highway-typ angegeben ist. Die ways selber dürfen dann keine highway-Tag mehr enthalten und die tags werden vererbt. Ways ohne road/highway-Relation werden normal behandelt. Es läuft doch jetzt bei der Bus- und Wanderrouten genauso: Man benutzt doch für die Darstellung der Route nur die Geometrie der Wege und die Tags, die einem interessieren, der Rest wird aus der Relation genommen. Ich denke, dass langfristig ein Umdenken erfolgen muss, was die Bedeutung der Grundtypen angeht: früher gab es: node - segment - way jetzt gibt es: node - way - relation ich sehe das eigentlich so, dass ein way eher einem segment entspricht, das aus mehreren geordneten Stützpunkten (nodes) besteht und mehrere ways zu einer geordneten relation zusammengefasst werden. Bei den Multipolygonen ist das ja auch schon so. Je mehr Attribute erfasst werden (maxspeed=, ...) um so zerstückelter und kürzer werden die einzelnen ways, so dass es durchaus Sinn macht, diese Teile wieder logisch zusammenzufassen. Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] abkickende vorfahrt
Florian Lohoff schrieb: Hi, gibt es eine anerkannte Loesung um abknickende vorfahrten zu taggen? Im moment wird das ja mit unserem datenmodell nicht funktionieren das das navi entweder sagt Der abbiegende Vorfahrt nach Rechts folgen oder auch nur einfach die klappe haelt wie mein festeinbau. Bitte? Bei einer um 90° abknickenden VOrfahrt sagt mein TomTom oft genug rechts abbiegen. Und damit hat er sogar voll recht: Ich muss blinken und das Lenkrad drehen. Wo ist das Problem? Bilde die Straßen doch erstmal so ab, wie sie sind. Navis sind Schall und Rauch. Grüße Philipp ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ref tag bei ways erforderlich wenn eine relation existiert?
Nop wrote: Jetzt hast schon in dem einfachen Beispiel Relationen, von denen Du mehrfache Werte zulassen würdest und andere, von denen Du keine oder nur einfache Vererbung haben willst - und keine definierte Regel, wie man das unterscheiden könnte und auch keine Möglchkeit ein die beiden oder auch eine andere-Ref zu erzeugen. Nehmen wir noch eine neue, unbekannte Relation hinzu (ich darf ja jederzeit neue Typen eintragen oder den Way weiteren Relationen zuordnen), und das Chaos ist komplett. Relativiert sich dieses Problem nicht dadurch, dass es doch eigentlich nur genau einen Relationstyp (route=road) gibt, der genau dafür geschaffen wurde vererbbare Eigenschaften zusammenzufassen. Die anderen Relationen (z.b. bus) definieren doch andere Objekte, die den Weg nur nutzen. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] abkickende vorfahrt
Florian Lohoff schrieb: gibt es eine anerkannte Loesung um abknickende vorfahrten zu taggen? Hi, momentan sehe ich den Sinn noch nicht. Das Navi soll doch den berechneten Weg anzeigen, die Vorfahrtsregeln zu beachten sehe ich als Aufgabe des Fahrers an. ;-) Aber wenn man unbedingt will könnte man es mit einer Relation analog zur type=restriction abbilden (type=english-word-for-vorfahrt). Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ref tag bei ways erforderlich wenn eine relation existiert?
Hallo. Am Mittwoch 06 Mai 2009 09:55:24 schrieb Nop: Genau darum geht es: Wie willst Du das verhindern? Und zwar so allgmein formuliert, daß es in jedem Renderer zuverlässig umsetzbar ist? In dem man dem Renderer sagt, welcher Relation-Typ welches Tag vererbt. Dass es prinzipiell sinnvoll ist, möglichst viele Tags zu vererben ist ja das eine, aber praktisch würde ich jetzt so vorgehen: * highway-kategrie sollte beim way verbleiben. Z.B. nicht alle Landesstraßen sind secondary und irgendwie wäre das ganze sehr fehleranfällig wenn man versuchen würde, die highway-Kategorie von oben herab durch eine Relation zu dirigieren. * name sollte in den für andere Zwecke (Busroute, Wanderweg) genutzten Relationen den Namen der Relation beschreiben und nicht vererbt werden. Bei einem speziellen Realtion-Typ, der nur eine stark unterteilte, lange Straße zusammenhalten soll (keine ahnung ob es solche Relationen gibt), sollte der Name vererbt werden. Ein Name an einem Straßenstück wird als alternativer Name benutzt (z.B. Brückennamen) * ref wird von Straßen-Relationen vererbt, von anderen Relationen nicht. Mehrfachvererbung erzeugt mehrfache Werte. Alles andere habe ich entweder hier vergessen oder interessiert den Renderer nicht. Jeder Renderer den ich bisher kenne arbeitet nach einem Whitelist-Verfahren. Nimmt was er kennt und ignoriert den Rest. Ob jetzt irgendwo im Wiki steht, dass alles vererbt werden muss oder nicht, ist eigentlich egal. Wenn es den Renderer gar nicht interessiert, interessiert ihn auch nicht ob und wie es vererbt wird. Jetzt hast schon in dem einfachen Beispiel Relationen, von denen Du mehrfache Werte zulassen würdest und andere, von denen Du keine oder nur einfache Vererbung haben willst - und keine definierte Regel, wie man das unterscheiden könnte Doch. Ich kenn mich mit den benutzten Relation-Typen nicht aus, aber AFAIK gibt es nur einen Typen (road?), der für eine Zusammenfassung z.B. einer Bundesstraße steht. Bei diesem Typen vererbt man ref, bei allen anderen nicht. Es muss ja keineswegs eine Regel existieren, die alle Renderer gleich umsetzen können. Rendert ein Renderer keine Ref-Angaben, lässt er's halt weg. Machst du einen Renderer für Busrouten, interessiert dich vermutlich die ref der Buslinie mehr als die Ref der Straßenverwaltung. und auch keine Möglchkeit ein die beiden oder auch eine andere-Ref zu erzeugen. ? Nur weil in den OSM-Daten keine echten Arrays möglich sind, muss man doch nicht den Kopf in den Sand stecken. Ein Renderer darf meinetwegen gerne in seinem Programmcode mit den Daten arbeiten und dabei seine Datentypen frei benutzen. Ansonsten nimmt man halt das ;-Konstrukt und hängt die Werte mit ; aneinander. Nehmen wir noch eine neue, unbekannte Relation hinzu (ich darf ja jederzeit neue Typen eintragen oder den Way weiteren Relationen zuordnen), und das Chaos ist komplett. Nein, denn wenn ich eine neue highway-Kategorie erfinde, die ich viel toller finde als alle anderen, dann gibt es ebenfalls kein Chaos, weil einfach die Renderer meine Straße ignorieren. Warum machst du's dir immer so schwer? Es gibt momentan einen Regelsatz in jedem Renderer, welche Angaben wie interpretiert werden. Das funktioniert überall so. Unbekannte Daten erzeugen keine Ergebnisse und auch kein Chaos. Warum sollte das jetzt plötzlich anders werden? Gruß, Bernd -- »Niemand hat die Absicht, eine Mauer zu errichten« - Walter Ulbricht (SED), 1961 »Es hat niemand vor, einen Überwachunsstaat in Deutschland zu errichten« - Wolfgang Bosbach (CDU), 2007 signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkarte jetzt mit maxspeed
Hallo, Florian Lohoff schrieb: falsches Polygon bei dem die Ecke abgeschnitten ist. Das sogar im endeffekt offen ist. Ich hatte das schliessen des polygons nicht vorgesehen sondern nur das abschneiden ... nein, durch die Datenstruktur ist das automatisch geschlossen, was da rauskommt. Lieber da die zeit investieren als die karte unnoetig zu verkleinern ;) Und CPUs werden schneller - in 18 Monaten duerfen wir doppelt so viele cycles verballern ;) Das ist zwar richtig, aber anhand der letzten 18 Monate gesehen haben wir dann auch eine Weltkarte die 10x so groß ist wie heute. :-) (Also doch den optimal schnellsten Weg entwickeln) -- Viele Gruesse Computerteddy ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] abkickende vorfahrt
On Wed, May 06, 2009 at 10:35:27AM +0200, Philipp wrote: Bitte? Mercedes Benz - W211 - Command APS sagt bei abknickenden Vorfahrten (Experimente am Wochenende) nichts - d.h. geht davon aus das ich selbsttaetig der abknickenden Vorfahrt folge. Bei einer um 90° abknickenden VOrfahrt sagt mein TomTom oft genug rechts abbiegen. Und damit hat er sogar voll recht: Ich muss blinken und das Lenkrad drehen. Wo ist das Problem? Bilde die Straßen doch erstmal so ab, wie sie sind. Navis sind Schall und Rauch. Das mache ich ja - Ich habe meine statistischen 192km^2 (oder wieviel war es aktuell) auch bald fertig. Nur finde ich erweiterte information und eine erweiterte Sprachausgabe des navis das mich auf die abkickende Vorfahrt vorbereitet gut. Genau wie das Mercedes Navi mich auch vor dem Essener Hauptbahnhof beim abbiegen auf existierende Einfahrtsbeschraenkungen (Taxis, Busse etc) hinweist. Und ich behaupte das der Mensch verwirrt ist wenn er auf eine abknickende Vorfahrt zufaehrt und das Navi nichts sagt - Abbiegen oder geradeaus? Es ist eben nicht alles so definiert ... In der Fahrschule ist nichts sagen auch der Vorfahrt folgen - was aber ohne die zusaetzinformation von den Navis nicht zu machen ist. Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] abkickende vorfahrt
Florian Lohoff schrieb: On Wed, May 06, 2009 at 10:35:27AM +0200, Philipp wrote: Bitte? Mercedes Benz - W211 - Command APS sagt bei abknickenden Vorfahrten (Experimente am Wochenende) nichts - d.h. geht davon aus das ich selbsttaetig der abknickenden Vorfahrt folge. Aber genau hier liegt ja das Problem: Egal, wie wir beim abbilden die Realität verziehen: Irgendein Navi wird nicht damit klar kommen. Also lieber die Realität mappen. Die Realtität fürs Navi verziehen muss das Export-Plugin. Grüße Philipp ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] barrier=bollard
Moin, ist es absehbar dass barrier=bollard in Mapnik irgendwann mal gerendert wird? Ist in meiner Gegend nicht unwesentlich da viele Wohnstraßen irgendwo in der Mitte nen Poller haben und man mit dem Auto nicht durchfahren kann. Viele Grüße /Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] abkickende vorfahrt
On Wed, May 06, 2009 at 11:24:22AM +0200, Philipp wrote: Subject: Re: [Talk-de] abkickende vorfahrt Florian Lohoff schrieb: On Wed, May 06, 2009 at 10:35:27AM +0200, Philipp wrote: Bitte? Mercedes Benz - W211 - Command APS sagt bei abknickenden Vorfahrten (Experimente am Wochenende) nichts - d.h. geht davon aus das ich selbsttaetig der abknickenden Vorfahrt folge. Aber genau hier liegt ja das Problem: Egal, wie wir beim abbilden die Realität verziehen: Irgendein Navi wird nicht damit klar kommen. Also lieber die Realität mappen. Die Realtität fürs Navi verziehen muss das Export-Plugin. Es ging ja eben nicht um verziehen sondern es ging drum die realitaet zu erfassen das ein Navi die moeglichkeit hat richtige und konsistente anweisungen zu geben. Im moment wird das Navi immer von abbiegen sprechen was IMHO zu viel gequatsche ist. Wenn es das wissen um die abknickende vorfahrt hat kann es so der Fahrer moechte: a) darauf hinweisen das der vorfahrt zu folgen ist Folgen sie der abknickenden Vorfahrt nach Rechts b) Stumpf abbiegeanweisungen geben: Biegen sie in 50m rechts ab c) Einfach die klappe halten was imho der groesste Komfort ist. Ohne diese erfassten abknickenden Vorfahrten bleibt nur b). Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] abkickende vorfahrt
Florian Lohoff schrieb: Es ging ja eben nicht um verziehen sondern es ging drum die realitaet zu erfassen das ein Navi die moeglichkeit hat richtige und konsistente anweisungen zu geben. Im moment wird das Navi immer von abbiegen sprechen was IMHO zu viel gequatsche ist. Wenn es das wissen um die abknickende vorfahrt hat kann es so der Fahrer moechte: a) darauf hinweisen das der vorfahrt zu folgen ist Folgen sie der abknickenden Vorfahrt nach Rechts b) Stumpf abbiegeanweisungen geben: Biegen sie in 50m rechts ab c) Einfach die klappe halten was imho der groesste Komfort ist. Ohne diese erfassten abknickenden Vorfahrten bleibt nur b). Es gibt auch noch die Möglichkeit, dass wenn man bei einer nach rechts abknickenden Vorfahrt geradeaus fährt, vom Navi gewarnt wird, dass man hier aufpassen muss! Da gibt es mehrere sehr gefährliche Stellen. Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Geschlossener Kanal nicht gerendert
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo Leute, unter http://www.openstreetmap.org/?lat=51.670369lon=12.268838zoom=18layers=B000FTFTT ist ein Kanal zu sehen, der 2 kleine Inseln begrenzt. Er wird allerdings nur in Osmarender gerendert, nicht in Mapnik. Weiß wer, warum? Gruß, Markus -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoBbDMACgkQFATAbpKdc6pm5ACgwwdfQDUKWWMZVpirj+ahchwt Si8AoNtDVlvjRAYBreIhevi1ThMPz4/q =Trzu -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] barrier=bollard
Am 06.05.2009 11:31, Stephan Elsner: Moin, ist es absehbar dass barrier=bollard in Mapnik irgendwann mal gerendert wird? Ist in meiner Gegend nicht unwesentlich da viele Wohnstraßen irgendwo in der Mitte nen Poller haben und man mit dem Auto nicht durchfahren kann. Viele Grüße /Stephan Hast du schon ein entsprechendes Ticket erstellt? Ansonsten kann dir die Frage nur der Mapnik-Style-Maintainer beantworten, sofern er den Bedarf schon kennt. Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] barrier=bollard
Stephan Elsner schrieb: ist es absehbar dass barrier=bollard in Mapnik irgendwann mal gerendert wird? Einfach 'nen Trac-Eintrag machen. Die Mapnik Karte ist halt generell so konzipiert, dass sie weniger überfrachtet ist wie die t...@h Karte. Ist in meiner Gegend nicht unwesentlich da viele Wohnstraßen irgendwo in der Mitte nen Poller haben und man mit dem Auto nicht durchfahren kann. Ok, das ist noch ein großes Fragezeichen: Poller und Routing. Fakt ist wohl, dass weder ORS noch mkgmap Node-Infos für das Routing auswerten. Wenn man also einen Poller einträgt bedeutet das für die Router erstmal überhaupt nix und meiner Meinung nach zu Recht. Beispiel: Kreuzung einer breiten mit einer schmalen Straße. Mitten drauf ein Poller, so dass man auf der breiten Strasse mit dem Auto dran vorbei kommt, auf der schmalen Straße jedoch nicht. Woher soll der Router das wissen ? Also: Wenn der Poller routing-relevant sein soll, dann muss man ein kleines Wegstück mit motorcar=no markieren Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] abkickende vorfahrt
Florian Lohoff schrieb: Es ging ja eben nicht um verziehen sondern es ging drum die realitaet zu erfassen das ein Navi die moeglichkeit hat richtige und konsistente anweisungen zu geben. Aus deiner 1. Mail: Im moment probiere ich bei sowas immer aus der abkickenden straße eine Kurve zu modellieren so das quasi visuell die straße eine Kurve beschreibt und in der Kurve eine Straße abbiegt. Das entspricht ja aber desoefteren mal nicht der realitaet ... mit besten Grüßen Philipp P.s.: Es reicht, wenn deine Antwort an die ML geht, du brauchst sie mir nicht jedesmal extra persönlich zuzuschicken. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Stellenausschreibung: Digitale Wanderwegverwaltung
Der Verband Deutscher Gebirgs- und Wandervereine e.V. hat eine auf 19 Monate befristete Halbtagsstelle eines Projektreferenzten in Kassel zu besetzen. Projekttitel ist Digitale Wanderwegsverwaltung. Die Beschreibung liest sich, als ob die das machen wollen, was wir eh schon die ganze Zeit tun: Von Ehrenamtlichen/Freiwilligen GPS-Tracks nehmen lassen und daraus Karten erstellen. http://www.wanderjugend.de/ Stellenausschreibung_Projekt_Digitale_Wanderwegeverwaltung.pdf -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] bug plot
hi, dem wiki ist die datei für thumbnails zu groß, aber... hier kann man schön die verteilung der verschiedenen bugs über deutschland sehen: http://wiki.openstreetmap.org/images/4/4f/Bugplot0509.png bitte herunterladen und bildbetrachter nutzen! ciao gerhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] abkickende vorfahrt
On Wed, May 06, 2009 at 01:02:01PM +0200, Philipp wrote: Florian Lohoff schrieb: Es ging ja eben nicht um verziehen sondern es ging drum die realitaet zu erfassen das ein Navi die moeglichkeit hat richtige und konsistente anweisungen zu geben. Aus deiner 1. Mail: Im moment probiere ich bei sowas immer aus der abkickenden straße eine Kurve zu modellieren so das quasi visuell die straße eine Kurve beschreibt und in der Kurve eine Straße abbiegt. Das entspricht ja aber desoefteren mal nicht der realitaet ... Und aus dem restmail ging sicherlich hervor das ich eine schoenere loesung aka turn_restriction suchte weil ich obiges fuer suboptimal halte. Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stellenausschreibung: Digitale Wanderwegverwaltung
Johann H. Addicks schrieb: Der Verband Deutscher Gebirgs- und Wandervereine e.V. hat eine auf 19 Monate befristete Halbtagsstelle eines Projektreferenzten in Kassel zu besetzen. Projekttitel ist Digitale Wanderwegsverwaltung. Die Beschreibung liest sich, als ob die das machen wollen, was wir eh schon die ganze Zeit tun: Von Ehrenamtlichen/Freiwilligen GPS-Tracks nehmen lassen und daraus Karten erstellen. http://www.wanderjugend.de/ Stellenausschreibung_Projekt_Digitale_Wanderwegeverwaltung.pdf Drauf bewerben und OSM nutzen ;-) Oder noch besser anrufen und ihm OSM schmackhaft machen... Grüße Philipp ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM sehr träge
Martin Koppenhoefer schrieb: Am 5. Mai 2009 01:49 schrieb Stephan Wolff s.wo...@web.de: Zum Einzeichnen der Wälder und Seeufer kann ich auch die verminderten Geschwindigkeit ertragen. ja, leider ist das WMS-Plugin noch ein bisschen buggy, ist aber schon besser geworden ;-) Es ist halt durchaus auch für Straßen nicht unwichtig, ich habe es jedenfalls praktisch immer an, weil man so Proportionen und Straßenverläufe z.T. doch besser erkennen kann als aus den reinen GPS-Tracks. Davon träume ich nachts ;-). Nördlich von Hamburg sind die Yahoo- und Landsatbilder so grob, dass man einen Straßenverlauf allenfalls an der unterschiedlichen Färbung auf beiden Seiten erkennen kann. Seen sind sichtbar, mittlere Flüsse teilweise und für das Zeichnen von Wäldern muss man schon etwas Ortskenntnis und einige GPS-Punkte mitbringen. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] bug plot
Gary68 schrieb: http://wiki.openstreetmap.org/images/4/4f/Bugplot0509.png bitte herunterladen und bildbetrachter nutzen! FF kann das auch in Originalgröße anzeigen. Die Crossing-Errors sind vorwiegend Kreuzungen Fluss mit Straße oder? Seit ich hier das layer=-1 von einigen Flüssen / Bächen weggemacht habe, meckt KeepRight auch wieder -1 möchte ich eigentlich nicht, da sonst der Fluss schon mal gerne vom Wald überdeckt wird, und 100 neue Brücken einzumalen, pu... ;-) Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neuer WMS-Dienst mit dem Josm-WMS-Plugin // Nachtrag // Nachtrag 2
Martin Koppenhoefer schrieb: Ich würde mir im Job sowas jedenfalls nicht erlauben. sind vielleicht easter-eggs? Laut meinen Gesprächen auf der FOSSGIS und internen Informationen darf es solche Easter-Eggs in amtlichen Daten nicht geben. Außerdem würden Sie ja somit gegen eine Absprache mit uns verstoßen, was ich Ihnen aber auf keinen Fall unterstellen möchte. Ich werde sie mal auf den Fehler aufmerksam machen, obwohl das wohl technisch tiefgreifender ist (Mapserver falsch konfiguiert). ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] bug plot
Hallo, Gary68 schrieb: http://wiki.openstreetmap.org/images/4/4f/Bugplot0509.png Danke, sieht nett aus. MMh, mich wundert, dass in vielen leeren Städten gar keine OSBs sind. Wissen die Leute da nichts über OpenStreetMap oder kann man Fehler nur dort melden, wo auch schon irgendwelche Straßen vorhanden sind? Vielleicht haben sie auch nur einfach keine Luste, Fehler zu melden :-) Grüße Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] bug plot
-1 möchte ich eigentlich nicht, da sonst der Fluss schon mal gerne vom Wald überdeckt wird Wo passiert das denn noch? Dieser Fehler sollte eigentlich inzwischen in allen Renderern behoben sein; wenn es trotzdem noch vorkommt, leg bitte einen Bugreport auf http://trac.openstreetmap.org/newticket an. Grüße, Marc -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] osm2pgsql Konfiguration der Tag-Länge
Astrid wrote: Hallo, ich habe mit osm2pgsql Daten in eine Postgis Datenbank überführt. Das funktioniert auch ohne weiteres. Jetzt möchte ich aber spezielle Tags importieren. Dafür kann ich in der Datei default.style die Tags angeben, die ich in der Datenbank haben möchte. Das Problem ist, dass Tags mit einer Länge über 23 Zeichen nicht eingelesen werden können. Hier erscheint immer ein Syntaxfehler, weil der Tag nach dem 23sten Zeichen gesplittet wird. Weiß jemand, wo ich die erlaubte Länge für die Tags ändern kann? Hallo Astrid, die Werte sind nicht frei konfigurierbar, dafuer muss der Quelltext der Datei output-pgsql.c angepasst werden. Mich wundert aber auch dass die Feldgroesse so knapp bemessen ist. Ich hab die output-pgsql.c mal angepasst, einen Patch fuer die aktuelle SVN-Version findest du im Anhang. Sag bescheid wenn du Probleme mit dem Kompilieren hast. Fuer welches System brauchst du es denn, event. koennte ich dir dann eine fertige kompilierte Version zuschicken. Gruss Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geschlossener Kanal nicht gerendert
Am 06.05.2009 um 12:53 schrieb Markus Nentwig: unter http://www.openstreetmap.org/?lat=51.670369lon=12.268838zoom=18layers=B000FTFTT ist ein Kanal zu sehen, der 2 kleine Inseln begrenzt. Er wird allerdings nur in Osmarender gerendert, nicht in Mapnik. Weiß wer, warum? Vielleicht, weil der Weg geschlossen ist und deshalb als Fläche interpretiert und damit ignoriert wird? Versuch mal, den Weg aufzuspalten. Stefan -- Stefan Bethke s...@lassitu.de Fon +49 151 14070811 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] osm2pgsql Konfiguration der Tag-Länge
Christian Koerner wrote:
Ich hab die output-pgsql.c mal angepasst, einen Patch fuer die aktuelle
SVN-Version findest du im Anhang.
Mist, Anhang vergessen, neuer Versuch :)
Index: output-pgsql.c
===
--- output-pgsql.c (revision 14931)
+++ output-pgsql.c (working copy)
@@ -134,10 +134,10 @@
{
lineno++;
-char osmtype[24];
-char tag[24];
-char datatype[24];
-char flags[128];
+char osmtype[9];
+char tag[119];
+char datatype[32];
+char flags[32];
int i;
char *str;
@@ -145,7 +145,7 @@
if( str )
*str = '\0';
-int fields = sscanf( buffer, %23s %23s %23s %127s, osmtype, tag, datatype, flags );
+int fields = sscanf( buffer, %8s %118s %31s %31s, osmtype, tag, datatype, flags );
if( fields = 0 ) /* Blank line */
continue;
if( fields 3 )
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stellenausschreibung: Digitale Wanderwegverwaltung
Hallo Johann, Spannende Aufgabe! Der Verband Deutscher Gebirgs- und Wandervereine e.V. hat eine auf 19 Monate befristete Halbtagsstelle eines Projektreferenten in Kassel zu besetzen. Projekttitel ist Digitale Wanderwegsverwaltung. http://www.wanderjugend.de/ Stellenausschreibung_Projekt_Digitale_Wanderwegeverwaltung.pdf Da könnte ein ganzer Verband mit mit OSM verbunden werden. Vom Aufbau der Technik, über die Organisation eines Katasters, bis zur Schulung der Ehrenamtlichen vor Ort. Für 600.000 Mitglieder... und 200.000 km Wanderwege... Wäre schön, wenn sich ein erfahrener OSMer der Sache annehmen würde. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Treppenrouting fuer Radfahrer
Martin Koppenhoefer schrieb: Am 5. Mai 2009 15:10 schrieb Rotbarsch r...@gmx-topmail.de: In diesem Zusammenhang könnte vielleicht auch eine Treppe mit Schiebehilfe anders gewichtet werden als eine ohne... Sehr guter Punkt. Mind. 3 keys kommen mir für Treppen in den Sinn, die wir unbedingt haben sollten (gibts da teilweise vielleicht schon was?): 1. 2 Spuren für Kinderwägen (oder Fahrräder) 2. 1 Rille (aus meist Stahlprofil) für Fahrräder 3. parallele Transportbänder für Gepäck (selten, aber gibt's z.B. in Tübingen am Hauptbahnhof). Wie angedeutet sollten das zusätzliche Keys sein, die man zusätzlich zu highway=steps an einen Treppenway setzt, und falls das Area+Way-modell sich durchsetzt wäre bei breiten Treppen ein eigener Way für die Rillen sinnvoll. Siehe: http://wiki.openstreetmap.org/wiki/Proposed_features/Steps_features Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] bug plot
straßen und tracks stellen die masse. ca 11.500 kommen aus dem c6, welcher folgendes prüft: k=check v=waterway:river k=check v=waterway:riverbank k=check v=waterway:canal k=check v=waterway:stream k=check v=waterway:drain k=against v=highway:motorway k=against v=highway:motorway_link k=against v=highway:trunk k=against v=highway:trunk_link k=against v=highway:primary k=against v=highway:primary_link k=against v=highway:secondary k=against v=highway:secondary_link k=against v=highway:tertiary k=against v=highway:unclassified k=against v=highway:road k=against v=highway:residential k=against v=junction:roundabout ciao gerhard On Wed, 2009-05-06 at 13:44 +0200, Chris-Hein Lunkhusen wrote: Gary68 schrieb: http://wiki.openstreetmap.org/images/4/4f/Bugplot0509.png bitte herunterladen und bildbetrachter nutzen! FF kann das auch in Originalgröße anzeigen. Die Crossing-Errors sind vorwiegend Kreuzungen Fluss mit Straße oder? Seit ich hier das layer=-1 von einigen Flüssen / Bächen weggemacht habe, meckt KeepRight auch wieder -1 möchte ich eigentlich nicht, da sonst der Fluss schon mal gerne vom Wald überdeckt wird, und 100 neue Brücken einzumalen, pu... ;-) Chris ___ 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] Stellenausschreibung: Digitale Wanderwegverwaltung
Markus schrieb: Wäre schön, wenn sich ein erfahrener OSMer der Sache annehmen würde. Wie ich solche Geschichten kenne (ADFC Co.) möchten die lieber ihr eigenes Kartenmaterial haben. Leider leider. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stellenausschreibung: Digitale Wanderwegverwaltung
Am 6. Mai 2009 15:19 schrieb Tobias Wendorff tobias.wendo...@uni-dortmund.de: Markus schrieb: Wäre schön, wenn sich ein erfahrener OSMer der Sache annehmen würde. Wie ich solche Geschichten kenne (ADFC Co.) möchten die lieber ihr eigenes Kartenmaterial haben. Leider leider. noch. Einerseits. Und andererseits ist kein Verband wie der andere, d.h. eine Chance besteht immer. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Treppenrouting fuer Radfahrer
Am 6. Mai 2009 14:41 schrieb Sebastian Hohmann m...@s-hohmann.de: Siehe: http://wiki.openstreetmap.org/wiki/Proposed_features/Steps_features ja, sorry für meinen (fast) überflüssigen Post, der Thread hier war halt mal wieder zerstückelt und ich habe den Rest inkl. der Referenz auf diese Proposal-Seite daher erst später gefunden (und dort meine Anmerkungen ergänzt). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geschlossener Kanal nicht gerendert
Am 6. Mai 2009 14:08 schrieb Stefan Bethke s...@lassitu.de: Am 06.05.2009 um 12:53 schrieb Markus Nentwig: unter http://www.openstreetmap.org/?lat=51.670369lon=12.268838zoom=18layers=B000FTFTT ist ein Kanal zu sehen, der 2 kleine Inseln begrenzt. Er wird allerdings nur in Osmarender gerendert, nicht in Mapnik. Weiß wer, warum? Vielleicht, weil der Weg geschlossen ist und deshalb als Fläche interpretiert und damit ignoriert wird? Versuch mal, den Weg aufzuspalten. ... in Rom steht ein Amphittheater, es wird allerdings nur in Osmarender gerendert, weiss jemand, warum? ;-) http://www.openstreetmap.org/?lat=41.890419lon=12.492687zoom=18layers=B000FTF selbst das Anpassen der Wegrichtungen aussen und innen hat leider nichts gebracht. Passendes Ticket könnte z.B. das hier sein: http://trac.openstreetmap.org/ticket/1650 Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] barrier=bollard
Am 6. Mai 2009 12:59 schrieb Chris-Hein Lunkhusen chris66...@gmx.de: Stephan Elsner schrieb: ist es absehbar dass barrier=bollard in Mapnik irgendwann mal gerendert wird? Einfach 'nen Trac-Eintrag machen. Die Mapnik Karte ist halt generell so konzipiert, dass sie weniger überfrachtet ist wie die t...@h Karte. trac-ticket: unbedingt sinnvoll, Überfrachtung ist bei relevanten Informationen kein Argument. Fakt ist wohl, dass weder ORS noch mkgmap Node-Infos für das Routing auswerten. schlecht Wenn man also einen Poller einträgt bedeutet das für die Router erstmal überhaupt nix und meiner Meinung nach zu Recht. Kreuzung einer breiten mit einer schmalen Straße. Mitten drauf ein Poller, so dass man auf der breiten Strasse mit dem Auto dran vorbei kommt, auf der schmalen Straße jedoch nicht. Woher soll der Router das wissen ? falsch gemappt. Der Poller sollte in diesem Fall natürlich auf der schmalen Straße sein und nicht auf der großen oder auf beiden. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] man_made=breakwater von osmarender dargestellt
Martin Koppenhoefer schrieb: Am 6. Mai 2009 02:50 schrieb Stephan Wolff s.wo...@web.de: man_made=breakwater wird von Osmarender seit zwei Wochen als dünne, dunkelgraue Linie im Zoomlevel 15-17 dargestellt. Einige Beispiele sieht man vor Kiel-Schilksee http://www.openstreetmap.org/?lat=54.4275lon=10.1843zoom=15layers=0B00FFF Die dünnen Linien sehen ganz OK aus, aber was sind die dicken? Fährlinien? Sollte man die nicht durchgezogen und viel dünner machen? Es sind Linien der im ÖPNV verkehrenden Personenfähren. Für virtuelle Objekte (Grenzen, Routen, etc.) finde ich unterbrochene Linien gut. Im Gegensatz zu den Wellenbrechern sind es ja keine Barrieren. Aber die Fährlinien sind im Zoomlevel 15 wirklich zu dominant. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] JOSM-Tool für Innenflächen
Moin, ich finde es in JOSM ziemlich mühselig, neue Flächen zu erstellen, für die bereits äußerlich Grenzen bestehen. Sei es eine Lichtung im Wald als Wiese auszuweisen, einen See in einem geschlossenen Wald in die Aussparung einzupassen oder eine landwirtschaftliche Fläche zwischen die umgebenden Wege einzufügen. Wenn mann hier unschöne weiße Ränder vermeiden will muss man sehr genau arbeiten und dies ist mit einem hohen Zeitaufwand verbunden, der noch ansteigt, je feingliedriger die Grenzen sind. Gibt es hier schon ein Tool oder Tricks mit denen man sich das Leben leichter machen kann? Beispielsweise eine äußere Umgrenzung anhand bestehender Wege zu wählen und in diese ein Polygon einpassen zu lassen? Danke Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] man_made=breakwater von osmarender dargestellt
Am 6. Mai 2009 15:58 schrieb Stephan Wolff s.wo...@web.de: Die dünnen Linien sehen ganz OK aus, aber was sind die dicken? Fährlinien? Sollte man die nicht durchgezogen und viel dünner machen? Es sind Linien der im ÖPNV verkehrenden Personenfähren. Für virtuelle Objekte (Grenzen, Routen, etc.) finde ich unterbrochene Linien gut. Im Gegensatz zu den Wellenbrechern sind es ja keine Barrieren. Aber die Fährlinien sind im Zoomlevel 15 wirklich zu dominant. ja, ob durchgezogen oder gestrichelt, gepunktet, gestrichpunktet, etc. ist nicht ganz so wichtig, auf jeden Fall sollte m.E. die Linie dünn sein, d.h. _viel_ dünner. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM-Tool für Innenflächen
On Wed, May 06, 2009 at 04:00:15PM +0200, Falk Zscheile wrote: Moin, ich finde es in JOSM ziemlich mühselig, neue Flächen zu erstellen, für die bereits äußerlich Grenzen bestehen. Sei es eine Lichtung im Wald als Wiese auszuweisen, einen See in einem geschlossenen Wald in die Aussparung einzupassen oder eine landwirtschaftliche Fläche zwischen die umgebenden Wege einzufügen. Wenn mann hier unschöne weiße Ränder vermeiden will muss man sehr genau arbeiten und dies ist mit einem Normalerweise hast du den Wald als Aussengrenze - Dann die paar Punkte fuer die Lichtung setzen und entsprechend da ein landuse auf den way nageln. Dann beide - inner und outer way markieren - und bei den relations auf New clicken. Oben - type=multipolygon eingeben dann Add selected. bei role dann bei dem einen outer bei dem anderen inner eingeben und auf Ok klicken ... Dauert alles in allem 10-15 sekunden je nachdem wie schnelltipperig man unterwegs ist hohen Zeitaufwand verbunden, der noch ansteigt, je feingliedriger die Grenzen sind. Gibt es hier schon ein Tool oder Tricks mit denen man sich das Leben leichter machen kann? Beispielsweise eine äußere Umgrenzung anhand bestehender Wege zu wählen und in diese ein Polygon einpassen zu lassen? Das Thema hat man ja eigentlich nur da wo flaechen/landuses aneinandergrenzen. Da scheiden sich im moment ja noch die Geister ob man die Nodes noch einmal nutzen soll - d.h. sich flaechen die nodes teilen oder man eigene wege ziehen soll. Es hat beides vor und nachteile - Fuer mich ueberwiegen die nachteile weil anschliessend man die beiden Flaechen nur schwer wieder auseinander bekommt. D.h. in der pflege ist das extrem aufwendig - daher ziehe ich die flaechen dicht aneinander und ggfs korrigiere ich da nach dem renderer 2 mal nach oder so ... Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] google-indizierung des wikis mehr
Hallo, ich waerme mal was vier Wochen altes auf: Johann H. Addicks wrote: Seit der Umstellung der URLs vor rund 3(?) Monaten ist das OSM-Wiki aus dem Google-Index gefallen und kommt dort offensichtlich nicht mehr hinein. Grant hat mir damals auf Nachfrage geschrieben, man wuerde nur nachts fuer Google aufmachen, aber heute erfuhr ich, dass es wohl darueber hinaus einen Konfigurationsfehler gab, der Google fast gaenzlich ausgesperrt hat. Der sei nun behoben, und wenn Google sich nicht mittlerweile beleidigt zurückgezogen hat, sollte es bald wieder Suchergebnisse geben. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stellenausschreibung: Digitale Wanderwegverwaltung
Wie ich solche Geschichten kenne (ADFC Co.) möchten die lieber ihr eigenes Kartenmaterial haben. Leider leider. noch. Einerseits. Und andererseits ist kein Verband wie der andere, d.h. eine Chance besteht immer. www.opencaching.de läuft afaik unter deren Regie (Deutsche Wanderjugend), ebenfalls www.geocaching.de Und auf http://maps.geocaching.de/gm/ kann man auch auf OSM-Karten umschalten, auch wenn's (wie üblich) in der Google-API läuft. Will sagen: Opensource-Affinität scheint durchaus gegeben zu sein und OSM ist zumindest einigen Gliederungen dort nicht fremd. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM-Tool für Innenflächen
Florian Lohoff schrieb: Es hat beides vor und nachteile - Fuer mich ueberwiegen die nachteile weil anschliessend man die beiden Flaechen nur schwer wieder auseinander bekommt. Also siehst Du das Problem eher in der Editierbarkeit? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM-Tool für Innenflächen
On Wed, May 06, 2009 at 04:46:19PM +0200, Tobias Wendorff wrote: Subject: Re: [Talk-de] JOSM-Tool für Innenflächen Florian Lohoff schrieb: Es hat beides vor und nachteile - Fuer mich ueberwiegen die nachteile weil anschliessend man die beiden Flaechen nur schwer wieder auseinander bekommt. Also siehst Du das Problem eher in der Editierbarkeit? Es gibt da mehrere aspekte - Das eine problem ist die editierbarkeit - Ein Beispiel ist z.b. neue nodes einfuegen durch die virtual nodes geht nicht weil immer nur ein way dann gezogen wird - d.h. die ways verfeinern ist ein ding der unmoeglichkeit. Dazu kommt ein visualisierungs/validierungsproblem da meistens dann auch ways/highway mit in die node reusage gezogen werden - das endet dann meistens in der totalkatastrophe weil stichstraßen dann teilweise nur noch mit dem landuse verbunden sind aber nicht mit der eigentlichen straße - Leider ist das ueberhaupt nicht zu erkennen da Straße und landuse ja denselben geometrischen pfad haben. Dazu kommt ja der weitere aspekt das die landuse ways massiv mehr nodes bekommen durch die parallelnutzung mit highway - da bei jedem stich ein node (der zwar schon existiert) in den landuse way eingefuegt wird der eigentlich nur eine bewandnis im highway hat. Ich habe mir das mit der reusage auch in anderen staetden schonmal mit dem JOSM angesehen und da habe ich teilweise nodes die an 4 Highways und 4 landuses haengen. Wenn man da was aendern moechte (Kreuzung auf mehrspuring umarbeiten) ist man erstmal 10 minuten nach dem unglue am nacharbeiten um die richtigen ways wieder zusammenzufuegen - Sehr unschoen. Waere das wirklich 5 unabhaengige nodes muesste man nur die 4 landuse nodes einfach mal nen bischen zur seite schieben und koennte die kreuzung umarbeiten Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] barrier=bollard
Martin Koppenhoefer schrieb: falsch gemappt. Der Poller sollte in diesem Fall natürlich auf der schmalen Straße sein und nicht auf der großen oder auf beiden. Ok, das Beispiel war blöd. Also simpler: Poller auf mittelbreiter Straße, so dass man mit 'nem Smart durchkommt, mit einem Mercedes aber nicht. Der Poller an sich stellt also m.E. keine Zugangsbeschränkung dar. Der Mapper sollte im Einzelfall entscheiden und wenn er meint dass da keine Auto durchgeroutet werden soll, ein Wegstückchen mit motorcar=no taggen. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkarte jetzt mit maxspeed
Moin, ich weiss zwar nicht wieder der Splitter genau vorgeht, aber wenn ich mir von dem ein paar Tiles aus der Europakarte schneiden lasse, dann habe ich da eigentlich auch keine Luecken zwischen. Die Schnittgrenzen protokolliert Splitter dabei ja in einer Datei, so dass man auch zu einem spaeteren Zeitpunkt sich genau die gleichen Kacheln wieder rausschneiden lassen kann. Ich hatte auch mal versucht, mit einer entsprechenden Datei die Kacheleinteilung von Computerteddy mit Splitter nachzuvollziehen, aber irgendwie wollte das nicht so richtig. Zum Einen liegt das daran, das Splitter nur Schnittgrenzen mit den Koordinaten 360° geteilt durch zwei hoch irgendwas unterstuetzt, so dass man nicht genau auf ganze Grad kommen kann. Zum anderen wollte es aber auch mit entsprechenden gerundeten Grenzen irgendwie nicht so wie gewuenscht, so dass ich den Versuch abgebrochen habe und fuer meine Karten jetzt ein von Splitter vorgegebenes, festes Raster verwende. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] barrier=bollard
Chris-Hein Lunkhusen schrieb: Martin Koppenhoefer schrieb: falsch gemappt. Der Poller sollte in diesem Fall natürlich auf der schmalen Straße sein und nicht auf der großen oder auf beiden. Ok, das Beispiel war blöd. Also simpler: Poller auf mittelbreiter Straße, so dass man mit 'nem Smart durchkommt, mit einem Mercedes aber nicht. Der Poller an sich stellt also m.E. keine Zugangsbeschränkung dar. Der Mapper sollte im Einzelfall entscheiden und wenn er meint dass da keine Auto durchgeroutet werden soll, ein Wegstückchen mit motorcar=no taggen. Warum dann nicht an den Poller motorcar=no? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkarte jetzt mit maxspeed
Carsten Schwede schrieb: Wer übrigens hindert Dich daran einfach meine geschnittenen OSM-Kacheln zu verwenden? OK, das Routing funktioniert dann erstmal nicht über die Kachelgrenzen, aber vielleicht findet sich mal jemand dem Steve zu erklären, wie meine Karten aufgebaut sind, damit er das Routing so in mkgmap einbauen kann, das dann auch mit meinen Kacheln funktioniert. Das Routing ist z.Z. sicherlich das Hauptargument, deshalb bin ich auch von diesem Ansatz abgekommen. Ansonsten spricht noch dagegen, dass es deine Kacheln nur einmal die Woche gibt. Bei Geofabrik bekommt man haeufiger frische Daten, um sich daraus seine Garmin-Karten selber zu bauen. Wenn man da jetzt noch eine Grossraum-Deutschland-Karte bekaeme, so dass man sich dass nicht immer erst aus Kompletteuropa ausschneiden muss... Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] barrier=bollard
Ok, das Beispiel war blöd. Also simpler: Poller auf mittelbreiter Straße, so dass man mit 'nem Smart durchkommt, mit einem Mercedes aber nicht. Der Poller an sich stellt also m.E. keine Zugangsbeschränkung dar. Der Mapper sollte im Einzelfall entscheiden und wenn er meint dass da keine Auto durchgeroutet werden soll, ein Wegstückchen mit motorcar=no taggen. Wenn, dann aber andersrum. Das Wiki legt folgende Berechtigungen als Default fest: access=no foot=yes bicycle=yes. Ich finde das sehr vernünftig, denn die Beispiele, die du anführst, sind doch eher seltene Ausnahmefälle. Grüße, Marc signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Regionale Mapping-Berichte in der Presse
Hier zwei weitere Zeitungsberichte über lokale/regionale Mapping-Aktionen und Mapper: Leipziger Volkszeitung vom 2.5.2009 http://www.geocache-leipzig.de/gclefor/viewtopic.php?f=16t=1036start=0 Hobby: Straßen vermessen Der Portitzer Kurt Gilbert erstellt via GPS Stadtplan von Leipzig / Kostenlos im Internet abrufbar Lippische Landes-Zeitung 01.05.2009 http://www.lz-online.de/lokales/bad_salzuflen/2923836_Unterwegs_nur_mit_Hilfe_von_oben.html?em_index_page=1 Unterwegs nur mit Hilfe von oben Technik-Fans vermessen die Region mittels Satelliten-Signalen und setzen markante Wegpunkte VON DANIEL HOBEIN Bad Salzuflen. Wenn Frank Jäger und Hendrik Alvermann für eine Radtour das Haus verlassen, dann immer mit GPS-Satelliten-Gerät. Jedoch nicht, um den Weg zu finden, sondern um die Strecke elektronisch zu markieren. Die Technikfans machen bei einem Projekt mit, um Straßen und Plätze neu zu kartographieren. Auf Empfang: Frank Jäger, Florian Lohoff, Nils Heuermann und Hendrik Alvermann (von links) suchen neue Ziele, die sie mittels GPS kartografieren können.Foto: HOBEIN Würzburg hat mittlerweile Vollzug gemeldet: Radio Gong 29.04.09 - 15:58 Uhr Würzburg: Straßen der Stadt in Online-Atlas erfasst http://www.radiogong.com/index.php?id=426singelid=5314 Es folgen wohl demnächst auch Halzig und Leiple, äh Halle und Leipzig oder auch HalLEipzig - am besten zusammen in einem Ritt und nicht in Konkurrenz zueinander: http://wiki.openstreetmap.org/index.php/Leipzig-stat http://wiki.openstreetmap.org/wiki/Halle_a_d_Saale-stat Aber erst einmal steht für die HalLEipziger und alle anderen Interessierten, z.B. aus Dresden, die Mapping-Party in Grimma am 9. Mai an, die hoffentlich auch noch kräftig die Blätter rascheln läßt: http://wiki.openstreetmap.org/wiki/Leipzig/Stammtisch#Mapping-Party_Grimma http://lists.openstreetmap.de/pipermail/halleipzig/2009-May/thread.html Grüße Roman -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Treppenrouting fuer Radfahrer
Am Mittwoch, 6. Mai 2009 08:28:57 schrieb talk-de-requ...@openstreetmap.org: Bei 500m Umweg w?rde ich niemals die Treppen nehmen und ich denke mehr wird es sehr, sehr selten sein. Innerst?dtisch magst Du recht haben, aber wenn man an Flussbr?cken ausserorts denkt, kann das schon sehr schnell passieren. z.B. spaltet sich der Radfernweg R3 bei Okriftel wegen einer Treppe in zwei Alternativen auf: http://openstreetmap.org/?lat=50.0522lon=8.4958zoom=14layers=00B0FTF Gr??e, jens Ich hätte also auch westlich des Mains fahren können. Das hätte ich getan. Jedenfalls mit bepacktem Rad oder Liegerad, Velomobil oder Fahrrad mit Anhänger. Vielleicht hätte ich es mit dem Rennrad anders gewählt, aber ich kann da keinen großen Umweg entdecken (Wir sehen, man könnte das Routing jetzt noch von dem Typ des Rades abhängig machen). Wohlgemerkt, ich bestreite nicht den Sinn eines Tags für Treppen. Aber ob da ne Schiebespur oder Moos auf den Treppen ist, das ist mir dann schon egal. Und jetzt hab ich auch noch ein Beispiel. http://www.informationfreeway.org/?lat=53.52734948168949lon=9.974351791391188zoom=17layers=BF000F Es gibt unter den Bahngleisen einen Tunnel für Radfarer und Fußgänger. Die Treppen in diesen Tunnel haben auch einen Fahrradrille, aber diese verläuft so sehr an der Seite das ich ein bepacktes Rad sehr schräg halten muß um sie zu benutzen. Kann man in der Praxis echt vergessen! Und nun? Vielleicht auch noch die Lage der Rille taggen? Routingmechanismen auch noch die Lage der Rille auswerten lassen? Wir können alles beliebig verkomplizieren, am Ende wird bei der Fülle der Optionen den Überblick verloren hab, wenn der die Software es nicht sowieso schon hat. Wir müssen simplyfizieren. Nicht wenn man nichts mehr hinzufügen kann, ist etwas gut. Sondern, wenn man nichts mehr entfernen kann, ohne das das Ganze zu sehr leidet. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stellenausschreibung: Digitale Wanderwegverwaltung
Hallo Tobias, Wie ich solche Geschichten kenne (ADFC Co.) möchten die lieberihr eigenes Kartenmaterial haben. Leider leider. Ich hatte eben ein anregendes Gespräch mit Herrn Neumeyer, stv.GF des Verband Deutscher Gebirgs- und Wandervereine e.V. Sie wollen OSM auf jeden Fall als Wahlvariante anbieten (DOP, Topo, OSM) Über die Möglichkeiten von OSM und OL etc. sind sie noch nicht informiert, bis jetzt arbeiten nur einzelne Arbeitsgruppen mit Geocaching und so. Sie sind interessiert an fundierter Information für ihre Verbandsfunktionäre und die regionalen Vereinsvorstände. Wenn also jemand aus Kassel... Sie würden sich freuen, wenn ein OSMer sich auf die Stelle bewirbt. Die Ausschreibung läuft bis zum 20.5. Gruss, Markus PS: Wir hatten hier in Nürnberg einen angeregten Infoabend mit dem ADFC. Man ist beeindruckt von der Qualität von OSM, und vor allem von der Aktualität und dem Mitmach-Spass-Faktor. Gerade letzterer ist für Vereine ein Lebenselixier. Viele haben an dem Abend die OSM-Karte auf ihr Garmin geladen. Und einige kamen sogar zum OSM-Stammtisch. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkarte jetzt mit maxspeed
Hallo, Torsten Leistikow schrieb: Das Routing ist z.Z. sicherlich das Hauptargument, deshalb bin ich auch von diesem Ansatz abgekommen. Naja, funktioniert ja noch etwas holprig, daher ist das bei mir eben kein Argument. Zum Probieren reicht es ja meist aus, was ernsthaftes würde ich noch nicht mit dem Routing machen wollen. Ansonsten spricht noch dagegen, dass es deine Kacheln nur einmal die Woche gibt. Bei Geofabrik bekommt man haeufiger frische Daten, um sich daraus seine Garmin-Karten selber zu bauen. Das ist richtig. Wenn ich Christophs Karte sehe, kommt da momentan aber auch nicht mehr als einmal die Woche. Eine tägliche Karte ist bei mir eben leider nicht machbar, das dauert da dann doch zu lange zum Rechnen. Es rechnet zwar nicht 24 Stunden, aber da sind eben leider noch ein paar händische Tätigkeiten drin, die noch nicht automatisierbar sind, bzw. die ich noch nicht automatisiert habe. (Das könnte ich aber wirklich endlich mal machen, gute Idee) Wenn man da jetzt noch eine Grossraum-Deutschland-Karte bekaeme, so dass man sich dass nicht immer erst aus Kompletteuropa ausschneiden muss... Ich denke, die Europakarte scheitert an der Schneideart, wie splitter.jar schneidet. Da braucht man wohl zuviel Hauptspeicher, oder was fehlt da eigentlich genau? -- Viele Grüße Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] barrier=bollard
Am 6. Mai 2009 17:33 schrieb Marc Schütz schue...@gmx.net: Ok, das Beispiel war blöd. Also simpler: Poller auf mittelbreiter Straße, so dass man mit 'nem Smart durchkommt, mit einem Mercedes aber nicht. Der Poller an sich stellt also m.E. keine Zugangsbeschränkung dar. Der Mapper sollte im Einzelfall entscheiden und wenn er meint dass da keine Auto durchgeroutet werden soll, ein Wegstückchen mit motorcar=no taggen. warum ist es eigentlich ein so großes Problem, beim Routing Nodes auch zu berücksichtigen? Zumindest die, die Teil eines Weges sind? Wenn, dann aber andersrum. Das Wiki legt folgende Berechtigungen als Default fest: access=no foot=yes bicycle=yes. Ich finde das sehr vernünftig, denn die Beispiele, die du anführst, sind doch eher seltene Ausnahmefälle. ja, und sollten dementsprechend zusätzlich mit Breitenbeschränkung versehen werden. I. d.R. wird man aber in diesen Fällen sowieso zusätzlich ein Schild antreffen, dass die Durchfahrt für Kfz verbietet, sonst bräuchte es ja auch keinen Poller, bzw. ist z.B. das Befahren von Gehwegen sowieso verboten. Das Schild braucht man alleine schon wegen der Motorräder... Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Regionale Mapping-Berichte in der Presse
Hallo Roman, hier [1] finden diese Meldungen die beste Archivierung. Gruß Jan :-) [1]http://wiki.openstreetmap.org/wiki/WikiProject_Germany/DeutschePresse Grabolle schrieb: Hier zwei weitere Zeitungsberichte über lokale/regionale Mapping-Aktionen und Mapper: Leipziger Volkszeitung vom 2.5.2009 http://www.geocache-leipzig.de/gclefor/viewtopic.php?f=16t=1036start=0 Hobby: Straßen vermessen Der Portitzer Kurt Gilbert erstellt via GPS Stadtplan von Leipzig / Kostenlos im Internet abrufbar Lippische Landes-Zeitung 01.05.2009 http://www.lz-online.de/lokales/bad_salzuflen/2923836_Unterwegs_nur_mit_Hilfe_von_oben.html?em_index_page=1 Unterwegs nur mit Hilfe von oben Technik-Fans vermessen die Region mittels Satelliten-Signalen und setzen markante Wegpunkte VON DANIEL HOBEIN Bad Salzuflen. Wenn Frank Jäger und Hendrik Alvermann für eine Radtour das Haus verlassen, dann immer mit GPS-Satelliten-Gerät. Jedoch nicht, um den Weg zu finden, sondern um die Strecke elektronisch zu markieren. Die Technikfans machen bei einem Projekt mit, um Straßen und Plätze neu zu kartographieren. Auf Empfang: Frank Jäger, Florian Lohoff, Nils Heuermann und Hendrik Alvermann (von links) suchen neue Ziele, die sie mittels GPS kartografieren können.Foto: HOBEIN Würzburg hat mittlerweile Vollzug gemeldet: Radio Gong 29.04.09 - 15:58 Uhr Würzburg: Straßen der Stadt in Online-Atlas erfasst http://www.radiogong.com/index.php?id=426singelid=5314 Es folgen wohl demnächst auch Halzig und Leiple, äh Halle und Leipzig oder auch HalLEipzig - am besten zusammen in einem Ritt und nicht in Konkurrenz zueinander: http://wiki.openstreetmap.org/index.php/Leipzig-stat http://wiki.openstreetmap.org/wiki/Halle_a_d_Saale-stat Aber erst einmal steht für die HalLEipziger und alle anderen Interessierten, z.B. aus Dresden, die Mapping-Party in Grimma am 9. Mai an, die hoffentlich auch noch kräftig die Blätter rascheln läßt: http://wiki.openstreetmap.org/wiki/Leipzig/Stammtisch#Mapping-Party_Grimma http://lists.openstreetmap.de/pipermail/halleipzig/2009-May/thread.html Grüße Roman ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] abkickende vorfahrt
Am Mittwoch 06 Mai 2009 schrieb Florian Lohoff: D.h. ein explizites taggen einer abknickenden Vorfahrt ist noetig. Da es sich um from/to/via geschichten handelt ist es ein identisches problem wie die turn restrictions. nein, nicht ganz! bei der vorfahrtstrasse ist die fahrrichtung egal. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] abkickende vorfahrt
Am Mittwoch 06 Mai 2009 schrieb Chris-Hein Lunkhusen: Florian Lohoff schrieb: gibt es eine anerkannte Loesung um abknickende vorfahrten zu taggen? Hi, momentan sehe ich den Sinn noch nicht. Das Navi soll doch den berechneten Weg anzeigen, die Vorfahrtsregeln zu beachten sehe ich als Aufgabe des Fahrers an. ;-) manche leute wuerden jetzt sagen, die information ist in der realitaet vorhanden, also sollte man sie auch abbilden ;-) die anwendungen kommen dann schon; fuer's routing waere sowas z.B. recht nuetzlich... ich hatte ja bereits einen vorschlag gemacht, waer das nix? ausformulieren muss das dann halt jemand, der sich mit relations auskennt. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkarte jetzt mit maxspeed
Carsten Schwede schrieb: Wenn man da jetzt noch eine Grossraum-Deutschland-Karte bekaeme, so dass man sich dass nicht immer erst aus Kompletteuropa ausschneiden muss... Ich denke, die Europakarte scheitert an der Schneideart, wie splitter.jar schneidet. Da braucht man wohl zuviel Hauptspeicher, oder was fehlt da eigentlich genau? Ich habe eigentlich keine Probleme, mir mit Splitter aus der Geofabrik-Europa-Datei meine Kacheln auszuschneiden (Windof Vista 64 mit 8GB Ram). Ich bin allerdings lediglich an Deutschland und umzu interessiert, so dass das Runterladen von komplett Europa (3h bei meinem langsamen DSL Anschluss) und das Ausschneiden vom Grossraumdeutschland (etwa 1,5h) fuer mich einiges an uennoetigen Aufwand bedeutet. Und da ich genau an einer Ecke wohne, wo vier deiner Kacheln aneinander grenzen, ist das Routing ueber die Kachelgrenzen hinweg fuer mich schon sehr wichtig. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] barrier=bollard
Ok, das ist noch ein großes Fragezeichen: Poller und Routing. Fakt ist wohl, dass weder ORS noch mkgmap Node-Infos für das Routing auswerten. Wenn man also einen Poller einträgt bedeutet das für die Router erstmal überhaupt nix und meiner Meinung nach zu Recht. Es ist in den allermeisten Fällen ganz einfach, wenn man mit relation:restriction (http://wiki.openstreetmap.org/wiki/Relation:restriction) arbeitet. So sollten das dann auch die Router einfach auswerten können. Zum Beispiel wird mit der AllInOne-Garminkarte an diesem Poller hier http://www.openstreetmap.org/browse/node/311097363 richtig geroutet, seit ich dort mit einer solchen relation eingetragen habe, dass man dort wie ausgeschildert von der Gerwigstraße nur nach links auf die Martkplatz-Straße abbiegen darf, und nicht nach rechts, wo Poller stehen. Vorher wurde man dort auch drübergeschickt. Grüße ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] abkickende vorfahrt
Guenther Meyer wrote: da sollte es doch ein einfaches zu sein, eine relation vom type priority oder so zu erstellen, die diese beiden ways enthaelt. optional kann man ja auch noch den verbindungsnode und die entsprechenden schilder mit reinnehmen. Es gibt allerdings verzogene Kreuzungen, z.B. so was: | | * | -* | | Spontan würde ich sagen, dass man dort via-Ways braucht, oder? Damit wäre man in einer Situation, dass man ähnlich wie bei turn restrictions vorgehen kann, aber from und to wegen Symmetrie nicht unterscheiden braucht. Allerdings gibts auch noch Vorrangregelungen, so was hier: http://de.wikipedia.org/wiki/Datei:Zeichen_308.svg Die bräuchten eine from-to-Unterscheidung, und eigentlich sind sie vom Konzept her das gleiche, oder? Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] abkickende vorfahrt
On Wed, May 06, 2009 at 06:11:02PM +0200, Guenther Meyer wrote: Subject: Re: [Talk-de] abkickende vorfahrt Am Mittwoch 06 Mai 2009 schrieb Florian Lohoff: D.h. ein explizites taggen einer abknickenden Vorfahrt ist noetig. Da es sich um from/to/via geschichten handelt ist es ein identisches problem wie die turn restrictions. nein, nicht ganz! bei der vorfahrtstrasse ist die fahrrichtung egal. lassen wir also from/to weg und nur via ;) Im prinzip aber das verbinden von 1-n wegen und mehreren nodes. Oder solte man das dann zerlegen in mehrere wege? D.h. wenn in der Kurve mehrere Straßen abgehen und das nicht auf dem selben Punkt. Dann muesste man ja die vorfahrt durchmodellieren ueber mehrere wege. Brauch man dann da via? Oder reicht eine collection of ways? Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] abkickende vorfahrt
On Wed, May 06, 2009 at 06:37:18PM +0200, Tobias Knerr wrote: Guenther Meyer wrote: da sollte es doch ein einfaches zu sein, eine relation vom type priority oder so zu erstellen, die diese beiden ways enthaelt. optional kann man ja auch noch den verbindungsnode und die entsprechenden schilder mit reinnehmen. Es gibt allerdings verzogene Kreuzungen, z.B. so was: | | * | -* | | Spontan würde ich sagen, dass man dort via-Ways braucht, oder? Damit wäre man in einer Situation, dass man ähnlich wie bei turn restrictions vorgehen kann, aber from und to wegen Symmetrie nicht unterscheiden braucht. Allerdings gibts auch noch Vorrangregelungen, so was hier: http://de.wikipedia.org/wiki/Datei:Zeichen_308.svg Die bräuchten eine from-to-Unterscheidung, und eigentlich sind sie vom Konzept her das gleiche, oder? Hmmm - Wofuer wuerdest du das modellieren wollen? Ich denke das das schon was anderes ist - da ja kein abknicken also kreuzung mit einer anderen default fahrtrichtung als geradeaus. Hier bleibt ja die fahrtrichtung und weg ja unangetastet nur das ich ggfs auf entgegenkommenden verkehr warten muss. Mappen wir dann auch die verkehrsberuhigung durch inseln an den seiten? Die stellen das selbe ja quasi physisch her ;) Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkarte jetzt mit maxspeed
Hallo, Torsten Leistikow schrieb: Ich bin allerdings lediglich an Deutschland und umzu interessiert, so dass das Runterladen von komplett Europa (3h bei meinem langsamen DSL Anschluss) und das Ausschneiden vom Grossraumdeutschland (etwa 1,5h) fuer mich einiges an uennoetigen Aufwand bedeutet. Naja, gehts halt momentan eben nicht würde ich sagen. Ich gehe davon aus, dass das Routing bei meinen Kacheln nur noch eine Frage der Zeit ist, und wie gut ich das Steve erkläre. Und da ich genau an einer Ecke wohne, wo vier deiner Kacheln aneinander grenzen, ist das Routing ueber die Kachelgrenzen hinweg fuer mich schon sehr wichtig. Zieh doch einfach in die Mitte einer Kachel. ;-D -- Viele Grüße Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] abkickende vorfahrt
Florian Lohoff schrieb: Allerdings gibts auch noch Vorrangregelungen, so was hier: http://de.wikipedia.org/wiki/Datei:Zeichen_308.svg Die bräuchten eine from-to-Unterscheidung, und eigentlich sind sie vom Konzept her das gleiche, oder? Hmmm - Wofuer wuerdest du das modellieren wollen? Von der falschen Seite in so eine Stelle einzufahren kann schon mal aufhalten, wie ja auch die Nutzung einer Kreuzung auf einer der nicht bevorzugten Straßen. Deshalb würde ich andere Routen bevorzugen, wenn sie ansonsten ziemlich gleichwertig sind. Ich denke das das schon was anderes ist - da ja kein abknicken also kreuzung mit einer anderen default fahrtrichtung als geradeaus. Aus meiner Sicht ist eine Vorfahrtregelung zunächst mal eine Vergabe von Prioritäten an verschiedene Verkehrsströme für den Zugang zu einem gemeinsam genutzten Bereich. Das trifft hier wie dort zu. Mappen wir dann auch die verkehrsberuhigung durch inseln an den seiten? Die stellen das selbe ja quasi physisch her ;) Die verschiedenen traffic_calming-Varianten mappen wir, ja. Aber ohne Vorrangregelung brauchts da ja keine komplizierten Konstrukte für. Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ref tag bei ways erforderlich wenn eine relation existiert?
Hi! Norbert Hoffmann schrieb: Relativiert sich dieses Problem nicht dadurch, dass es doch eigentlich nur genau einen Relationstyp (route=road) gibt, der genau dafür geschaffen wurde vererbbare Eigenschaften zusammenzufassen. Die anderen Relationen (z.b. bus) definieren doch andere Objekte, die den Weg nur nutzen. Wo findest Du eine solche Festlegung? bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ref tag bei ways erforderlich wenn eine relation existiert?
Hi! Bernd Wurst schrieb: Dass es prinzipiell sinnvoll ist, möglichst viele Tags zu vererben ist ja das eine, aber praktisch würde ich jetzt so vorgehen: [...] Das wäre z.B. der Beginn eines sinnvollen Regelsatzes. Jetzt müßte man den nur noch im Wiki niederlegen, wo auch andere eine Chance haben ihn zu finden und zu erweitern. Nein, denn wenn ich eine neue highway-Kategorie erfinde, die ich viel toller finde als alle anderen, dann gibt es ebenfalls kein Chaos, weil einfach die Renderer meine Straße ignorieren. Warum machst du's dir immer so schwer? Weils nicht so einfach ist. Wenn ich was neues einbaue, das nirgendwo erscheint - egal. Aber wenn Du sagst: Ref findet sich ab sofort nicht mehr am way, sondern ggf. in einer road-Relation, dann _müssen_ alle Renderer das nachziehen, denn Du hast die Datenquelle für etwas Bestehendes geändert. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ref tag bei ways erforderlich wenn eine relation existiert?
Stefan Dettenhofer (StefanDausR) schrieb: Hallo Nop, Nop schrieb: (...) Ja. :-) Du machst einige Annahmen, für die es noch weder eine Einigung noch eine dokumentierte Festlegung gibt. (...) Du hast natürlich recht, dass das momentan so noch nicht läuft (daher hatte ich ja weiter oberen geschrieben, dass man derzeit die ref-tags besser auch noch an die ways schreibt. Wir diskutieren hier aber doch eher über die zukünftige Entwicklung! Aber auch nach momentanem Stand ist es doch so (egal ob beschrieben oder nicht): Eine Relation mit route=road und type=route wird gar nicht ausgewertet, stellt aber eine logische Zusammenfassung einer Straße dar, die aus vielen ways besteht (mit unterschiedlichen maxspeed=..., bridge=... etc.), aber die selbe ref und highway-typ hat. Also hier mein verbesserter *Vorschlag*, wie man das lösen könnte: Relation: operator = Bodenseekreis ref = K 7735 route = road type = route highway = secondary Member 1: cycleway = lane name = Meistershofener Straße Member 2: junction = roundabout oneway = yes ... Es wird auf Relationsebene gerendert, wenn dort auch der highway-typ angegeben ist. Die ways selber dürfen dann keine highway-Tag mehr enthalten und die tags werden vererbt. Ways ohne road/highway-Relation werden normal behandelt. Es läuft doch jetzt bei der Bus- und Wanderrouten genauso: Man benutzt doch für die Darstellung der Route nur die Geometrie der Wege und die Tags, die einem interessieren, der Rest wird aus der Relation genommen. Versteh mich richtig: Ich bin nicht gegen Neuerungen. Ich bin aber für vernünftig definierte Neuerungen anstatt Chaos durch überstürzte Benutzung undefinierter Mechanismen. Nochmal mein Mantra: Es ist nicht so einfach, wie es aussieht. Wir brauchen genaue Regeln, was wie vererbt werden kann. Sauber im Wiki aufgeschrieben. Wenn nicht irgendwo klar definiert ist, daß ein highway-Typ vererbt werden kann, dann verschwinden die Ways aus Deinem Besipiel komplett aus der Karte. Gefällt mir aber gar nicht, denn das zwingt jeden Editor und Renderer solche Abhängigkeiten zu prüfen. Wenn Du Dir nur den Way ansiehst und nichts von der Relation weißt, erscheint er Dir kaputt und schon bist Du als guter Mapper am verschlimmbessern. Wenn ich Dein Beispiel oben nehme und füge die Wege noch in einer Wanderroute hinzu, dann würde der Roundabout nach aktuellem Stand des Wikis den Namen der Wanderroute erben, weil er selber keinen hat. Kaum das was wir haben wollen, oder? ich sehe das eigentlich so, dass ein way eher einem segment entspricht, das aus mehreren geordneten Stützpunkten (nodes) besteht und mehrere ways zu einer geordneten relation zusammengefasst werden. Bei den Multipolygonen ist das ja auch schon so. Bei den Multipolygonen gibt es auch schon einige seltsame Artefakte und fehlende Lichtungen auf der Karte, die auf unpassendem Gebrauch bzw. nicht Berücksichtigung undokumentierter Abhängigkeiten entstehen. Da haben wir das Problem bereits, es hat halt nur keinen groß interessiert, solange nur Waldlichtungen und Inseln vermurkst werden. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkarte jetzt mit maxspeed
Carsten Schwede schrieb: Ich denke, die Europakarte scheitert an der Schneideart, wie splitter.jar schneidet. Da braucht man wohl zuviel Hauptspeicher, oder was fehlt da eigentlich genau? Das Problem ist, dass man splitter nur die Anzahl der max-nodes in einer Kachel bekannt geben kann. Das Ergebnis sieht aber nicht so doll aus. Wenn man Europa da reintut kommen eben Kacheln zwischen 5 und 30 MiB Dateigröße raus. Das ist an sich nicht so wild, da ja immerhin die max-nodes Grenze eingehalten wird. Allerdings weiß der splitter ja vorher noch nicht, welche nodes überhaupt ausgewertet werden und welche nicht. So kann es vorkommen, dass manche Kacheln während des bauens mit mkgmap zu viele nodes in der Zielkachel haben, obwohl sie vielleicht von der Dateigröße her kleiner sind als andere die problemlos durchlaufen. Korrekterweise müsste der splitter demzufolge das stylefile berücksichtigen. Man kann jetzt natürlich denken, dass es ja schlau wäre die maxnodes einfach sehr weit runter zu setzen, damit die Wahrscheinlichkeit gering ist, dass zu viele Punkte in einer Zielkachel landen. Leider handelt man sich dadurch 2 weitere Probleme ein. Die Anzahl der Kacheln insgesamt nimmt natürlich zu. Leider hat das Garmin eine Beschränkung, was die Gesamtzahl der Kacheln in einer Karte angeht (ich glaube sie liegt bei 256 Kacheln). Des weiteren werden einige Wege und Relation, die zu lang sind und über mehrere Kacheln gehen, weggehaun oder sind nicht routingfähig. Die Anzahl der eingebüßten ways (vor allem Grenzen und so) nimmt natürlich zu, wenn die Kacheln kleiner werden. Meine momentane Taktik: einen Durchlauf mit splitter.jar mit relativ vielen max-nodes zur Erzeugung einer Ausgangs areas.list. Anschließend versuchen mit mkgmap und meinem Style alle Kacheln zu bauen. Die jenigen Kacheln, die immernoch zu groß sind (zielkachel hat zu viele nodes) teile ich einfach, indem ich die areas.list anpasse (aus einer Kachel mach 2). Das mach ich so lange, bis alle Kacheln durchlaufen. Die areas.list bei der es funktioniert veröffentliche ich dann. So weit der Plan. Leider dauert so ein Durchlauf von splitter und mkgmap ne halbe Ewigkeit und so probier ich schon seit 2 Tagen die richtige areas.list zu finden, aber ich komme dem Ziel immer näher. Grüße soweit Christoph signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkarte jetzt mit maxspeed
Carsten Schwede computerte...@gmx.de wrote: Naja, funktioniert ja noch etwas holprig, daher ist das bei mir eben kein Argument. Zum Probieren reicht es ja meist aus, was ernsthaftes würde ich noch nicht mit dem Routing machen wollen. Nach dem release often Prinzip, das bei Open Source ja bekanntlich recht gut funktioniert wird sich das Routing schneller zu einem brauchbaren Stand hinentwickeln, wenn man es möglichst vielen Leuten zum spielen gibt! Oft sind es ja auch Fehler in der Datenerfassung, die die Mappergemeinde sehr wohl korrigieren kann. Ein Beispiel sind die vielen Straßenbegleitenden Radwege, die ich inzwischen mit oneway=yes getaggt habe um korrektes Fahrradrouting zu erreichen. Was derzeit ganz klar gegen Deine Karten spricht ist das kaputte Routing an den Kachelgrenzen. ich wohne nun mal quasi auf dem 49. Breitengrad bzw. ich radle jedesmal drüber wenn ich mich in Richtung Innenstadt begebe. Sven -- In my opinion MS is a lot better at making money than it is at making good operating systems (Linus Torvalds, August 1997) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Kleine rechtliche Frage: Verwendung des Logo + Kartendarstellung
Hallo, wir starten gerade im Kreis Schwäbisch Hall eine OpenStreetMap Stammtisch und ich habe eine Miniseite (wirklich sehr rudimentär) als Infoplattform für Termine gebastelt. Darauf habe ich das OSM-Logo und einen Kartenausschnitt der Stadt Schwäbisch Hall eingebaut. http://osm-sha.ingmars-bastelecke.net/ Beim Logo will ich noch vermerken, dass es das OpenStreetMap-Logo ist. Bei der Karte habe ich einen Vermerk zur CreativeCommons. Ist das so OK, wie ich das Material eingebaut habe oder gibt es da rechtlich noch etwas zu beachten? -- MfG, Ingmar Rieger o...@ingmars-bastelecke.net ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ref tag bei ways erforderlich wenn eine relation existiert?
Nop schrieb: Versteh mich richtig: Ich bin nicht gegen Neuerungen. Ich bin aber für vernünftig definierte Neuerungen anstatt Chaos durch überstürzte Benutzung undefinierter Mechanismen. Nochmal mein Mantra: Es ist nicht so einfach, wie es aussieht. Wir brauchen genaue Regeln, was wie vererbt werden kann. Sauber im Wiki aufgeschrieben. Das ist schon klar, dass es definiert und aufgeschrieben werden sollte, bevor es eingeführt wird, aber wir sind doch momentan erst im brainstorming-Status. Wir überlegen doch erst, was wie funktionieren könnte. Wenn nicht irgendwo klar definiert ist, daß ein highway-Typ vererbt werden kann, dann verschwinden die Ways aus Deinem Besipiel komplett aus der Karte. Gefällt mir aber gar nicht, denn das zwingt jeden Editor und Renderer solche Abhängigkeiten zu prüfen. Wenn Du Dir nur den Way ansiehst und nichts von der Relation weißt, erscheint er Dir kaputt und schon bist Du als guter Mapper am verschlimmbessern. Das ist ein generelles Problem von OSM, das jeder alles machen darf. Sobald es aber gute Werkzeuge gibt (JOSM-Unterstützung), setzen sich aber Neuerungen schon durch. Wenn ich Dein Beispiel oben nehme und füge die Wege noch in einer Wanderroute hinzu, dann würde der Roundabout nach aktuellem Stand des Wikis den Namen der Wanderroute erben, weil er selber keinen hat. Kaum das was wir haben wollen, oder? Nein, es muss schon klar definiert sein, was von welcher Relation vererbt wird.. Für name müsste man sich das gut überlegen, denn z.B. bei einer Wohnstraße, die aus mehreren Stichstraßen besteht, würde ein Vererben Sinn machen, bei einer Landstraße eher nicht, da diese verschiedene Namen oder auch teilw. keine tragen kann. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] barrier=bollard
Sebastian Hohmann schrieb: Der Mapper sollte im Einzelfall entscheiden und wenn er meint dass da keine Auto durchgeroutet werden soll, ein Wegstückchen mit motorcar=no taggen. Warum dann nicht an den Poller motorcar=no? Weil die Router aus mir auch nicht bekannten Gründen access-Tags an Nodes nicht auswerten. Vermutlich weil die intern mit Graphen arbeiten und die Nodes lediglich Verbindungen zwischen Kanten sind. http://de.wikipedia.org/wiki/A*-Algorithmus Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkarte jetzt mit maxspeed
Hallo. Am Mittwoch 06 Mai 2009 18:05:51 schrieb Carsten Schwede: Naja, funktioniert ja noch etwas holprig, daher ist das bei mir eben kein Argument. Zum Probieren reicht es ja meist aus, was ernsthaftes würde ich noch nicht mit dem Routing machen wollen. Ich würde dann mal behaupten, du hast es noch nie richtig probiert oder hast als Alternative ein sowieso voll betriebsbereites Navi mit proprietären Daten. Ich habe ein Garmin mit ausschließlich OSM-Karte und das Routing funktioniert prächtig, hab mich schon mehrmals größere Strecken damit routen lassen. Ich bin nicht verwöhnt von den Zusatz-Gimmicks von anderen Navis, von daher bin ich vielleicht schneller zufrieden. Eine Karte ohne Routing-Feature würde ich mir nicht installieren, schließlich ist das irgendwie der Witz an dem Gerät, dass es navigieren kann. Gruß, Bernd -- Alle wollen zurück zur Natur - aber keiner zu Fuß. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkarte jetzt mit maxspeed
Hallo. Am Mittwoch 06 Mai 2009 21:52:07 schrieb Carsten Schwede: Ich habe ein Garmin mit ausschließlich OSM-Karte und das Routing funktioniert Welches denn? eTrex Legend HCx prächtig, hab mich schon mehrmals größere Strecken damit routen lassen. Ich Ich habe durchaus schon mehrere größere Routen ausprobiert. Und? War das Zielgebiet nicht gemapped oder war am Routing an sich was kaputt? bin nicht verwöhnt von den Zusatz-Gimmicks von anderen Navis, von daher bin ich vielleicht schneller zufrieden. Das Navi, was ich habe kann man wirklich nicht als mit Zusatzgimmicks versehen bezeichnen. (i3) :) Eine Karte ohne Routing-Feature würde ich mir nicht installieren, schließlich ist das irgendwie der Witz an dem Gerät, dass es navigieren kann. Ja ich schon, da ich in erster Linie mein Navi als Fahrradcomputer verwende (hier ein Venture Hcx) und zum Tracks aufzeichnen. Und auch wenn offenbar viele da auch routen wollen, will ich das nicht. Ja, so verwende ich meins auch die meiste Zeit, aber ich will auch nicht die Karte wechseln müssen wenn ich es dann im Auto nutzen will. Und auch mit dem Fahrrad ist es schon elegant, wenn man sich zu nem POI routen lassen kann. Gruß, Bernd -- Auf frischer Tat ertappt: Dunkelheit bei Einbruch verhaftet signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stellenausschreibung: Digitale Wanderwegverwaltung
Martin Koppenhoefer schrieb: Am 6. Mai 2009 15:19 schrieb Tobias Wendorff tobias.wendo...@uni-dortmund.de: Markus schrieb: Wäre schön, wenn sich ein erfahrener OSMer der Sache annehmen würde. Wie ich solche Geschichten kenne (ADFC Co.) möchten die lieber ihr eigenes Kartenmaterial haben. Leider leider. noch. Einerseits. Und andererseits ist kein Verband wie der andere, d.h. eine Chance besteht immer. Ich versuche mich gerade an die Naturfreunde heranzuschmeißen, die haben keinen Direktzugriff auf Kartenmaterial. Wenn ich da mal weiterkomme, melde ich mich. In der bundesweiten Vereinspostille im Juni erscheint eine Notiz über unsere jüngst durchgeführte Mapping-Aktion. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Private Wander/Rad Routen in OSM
Hallo an alle, ich habe eine ganze Weile gesucht aber keine Informationen gefunden ob oder ob es nicht eine gute Idee is private nicht markierte (Rad-) Routen in OSM abzulegen. Mein use-case ist der folgende: Ich wohne in einer Gegend mit sehr wenigen ausgeschilderten Radwegen. Es gibt ein paar, kurze, Radwege und viele Straßen mit sehr wenig Verkehr. Ich kenne mitlerweile einige gute Touren und würde gerne folgendes machen: - Die Touren als Relationen mit JOSM erstellen (aus bestehenden Stücken zusammensetzen) und mir auf einer Karte ansehen können - Sie mir als GPX Dateien wieder zurückholen und auf meinem GPS speichern - Andere Biker auf diese Touren hinweisen (mit Links, die ich auf meinem Blog abspeichere) Dies geht mehr oder weniger einfach, wenn ich die Touren in die OSM Datenbank hochlade. Ich habe ein paar Kommentare gelesen, dass OSM nicht für solche privaten, nicht verifizierbaren, inoffizielle und nicht markierten Touren herhalten soll. Ich stimmer mit dieser Sicht nicht ganz überein, und würde gerne Eure Meinung hören. Mein Argument ist, dass die die Kriterien - private - nicht verifizierbar - inoffiziell - nicht markiert niemals absolut und dauerhaft sind. Was ich aber denke is, dass sie besondere Tags haben sollten und so vom standart Renderer nicht angezegit werden. (Dies sollte aber möglich sein) Ich persöhnlich denke, dass wir solche Informationen in OSM haben sollten. Andere Fälle könnten sein: - Elephantenpfade im Urwald (sehr nützlich für Wanderer) - Meine persöhnliche querfeldein Tour auf diesen tollen Berg, ganz ohne Weg Neugierig auf jeden Kommentar, Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Private Wander/Rad Routen in OSM
Nutze doch einfach bikemap.net /runmap.net etc. Die unterstützen auch OSM-Karten, du bekommst Höhenprofile und eine Art Community gibts auch. Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Private Wander/Rad Routen in OSM
Hi, Carsten Behring schrieb: - Elephantenpfade im Urwald (sehr nützlich für Wanderer) - Meine persöhnliche querfeldein Tour auf diesen tollen Berg, ganz ohne Weg Neugierig auf jeden Kommentar, ich weiß das nicht genau, würde aber glauben, dass du GPX-Dateien mit Openlayers und co direkt in einer Karte anzeigen lassen kannst. Damit kannst du auch deine Querfeldein-Touren leicht im Blog anzeigen. Grüße Philipp ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
