Re: [Talk-de] grade5 tracks nicht mehr in z16 ansicht?
wobei ich feststelle, dass im Gegensatz zu den Beispieltracks meine anderen Tracks nur noch als Weiße Flächen auf hellgrauem Grund erscheinen: http://informationfreeway.org/?lat=48.99602671126077lon=8.27852014461402zoom=16layers=B000F000F Kann man herausbekommen (und gegebenenfalls fixen) warum denen die gestrichelten Linien fehlen? Das passiert imo, wenn ein tracktype nicht richtig gesetzt ist, z.b. grade 1 Bei mir scheint es noch nicht 100% zu funktionieren, manche tracks werden bereits mit dem neuem Patch gerendert, manche nicht, versteh ich nicht ganz. Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] grade5 tracks nicht mehr in z16 ansicht?
Gernot Hillier schrieb: Hi! John07 schrieb: Kann man herausbekommen (und gegebenenfalls fixen) warum denen die gestrichelten Linien fehlen? Das passiert imo, wenn ein tracktype nicht richtig gesetzt ist, z.b. grade 1 Bei mir scheint es noch nicht 100% zu funktionieren, manche tracks werden bereits mit dem neuem Patch gerendert, manche nicht, versteh ich nicht ganz. Osmarender? Wenn ja, dann liegt das vielleicht an der verteilten Natur von Osmarender. Mancher, der das [EMAIL PROTECTED] unterstützt, aktualisiert wohl regelmäßig die Renderregeln, andere nicht. Es gibt wohl ab und an Major-Updates, die dafür sorgen, dass alte Renderer nicht mehr unterstützt werden, aber für die Feinheiten dazwischen macht man das wohl nicht. Ja, Osmarender. Deine Theorie klingt plausibel :-) Es erklärt auch, warum die neue Darstellung schon mal da war und nach erneutem Rendern wieder weg. Immerhin weiß ich jetzt bescheid, dass es nicht an mir liegt. Dann bleibt mir wohl nichts anderes übrig als abzuwarten. Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] grade5 tracks nicht mehr in z16 ansicht?
Moin, G - so sieht der Modellflugplatz aber mit Sicherheit nicht aus den Du mit dort hin mappen wolltest! ;-) jaja, Du sollst Deinen Modellflugplatz schon noch bekommen. Aber erst wenn die Fähre wieder fährt :) . Cheers, ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] grade5 tracks nicht mehr in z16 ansicht?
Moin, Das passiert imo, wenn ein tracktype nicht richtig gesetzt ist, z.b. grade 1 das güldene Hasenhürn des Monats geht an mich. tracktype=1 statt tracktype=grade1. Keine Ahnung was ich mir da gestern bei gedacht habe. Beste Grüße, ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] grade5 tracks nicht mehr in z16 ansicht?
On Sat, 26 Jan 2008 16:07:12 +0100 Christoph Eckert [EMAIL PROTECTED] wrote: Hi, Ich als Radfahrer finde es OK, dass Grade1 fast wie serive aussieht. Ich könnte mir aber vorstellen, dass Inlineskater sich wünschen würden, auf der Karte einen deutlichen Unterschied zu sehen. Vielleicht könnte man grade1 so behandeln wie die tracks bisher auch und von dort aus Abstufungen durchführen. Kann osmarender eigentlich mit SVG-Transparenzen umgehen? Vielleicht könnte man ja auf diese Weise eine Abstufung erreichen. Also moment mal, was soll denn jetzt ein track mit grade1 sein? Also wenn das asphaltierte Wege sein sollen (paved), die sich von den service-Wegen nur durch den Hauptverwendungszweck unterscheiden, dann sehe ich da gerade nicht den Grund warum sich das so beim Rendern unterscheiden sollte. Immerhin sind das auch die Wege, auf denen mir die meisten Inlineskater begegnen. MfG Andreas Kemnade ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] grade5 tracks nicht mehr in z16 ansicht?
Hi! John07 schrieb: Kann man herausbekommen (und gegebenenfalls fixen) warum denen die gestrichelten Linien fehlen? Das passiert imo, wenn ein tracktype nicht richtig gesetzt ist, z.b. grade 1 Bei mir scheint es noch nicht 100% zu funktionieren, manche tracks werden bereits mit dem neuem Patch gerendert, manche nicht, versteh ich nicht ganz. Osmarender? Wenn ja, dann liegt das vielleicht an der verteilten Natur von Osmarender. Mancher, der das [EMAIL PROTECTED] unterstützt, aktualisiert wohl regelmäßig die Renderregeln, andere nicht. Es gibt wohl ab und an Major-Updates, die dafür sorgen, dass alte Renderer nicht mehr unterstützt werden, aber für die Feinheiten dazwischen macht man das wohl nicht. Ich bin hier in der Gegend auch schier verzweifelt, weil bei mehreren hintereinanderliegenden Brücken die Brückeneigenschaft manchmal gerendert wurde und manchmal nicht. Habe alles mögliche probiert, um den herauszufinden, warum, bis ich es eines Tages aufgegeben habe. Und siehe da, eine Woche später waren plötzlich alle Brücken da. Ich vermute also, dass einfach irgendwer noch einen veralteten Stand des Renderers laufen hatte... -- Gernot ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] grade5 tracks nicht mehr in z16 ansicht?
Moin, du bist nicht allein, siehe Statistik zu tracktype http://etricceline.de/osm/germany/de_stats_tracktype.htm mag sein, aber ich bin schon so lange dabei dass mir solche Schnitzer eigentlich nicht passieren sollten. Gruß Dank, ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] grade5 tracks nicht mehr in z16 ansicht?
Hallo, du bist nicht allein, siehe Statistik zu tracktype http://etricceline.de/osm/germany/de_stats_tracktype.htm Gruß Thomas Christoph Eckert schrieb: Moin, Das passiert imo, wenn ein tracktype nicht richtig gesetzt ist, z.b. grade 1 das güldene Hasenhürn des Monats geht an mich. tracktype=1 statt tracktype=grade1. Keine Ahnung was ich mir da gestern bei gedacht habe. Beste Grüße, ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Reisezeiten (was: Potlach! *kotz*)
Hallo, on Saturday, 26 January 2008 10:39:05 +0100, Frederik Ramm [EMAIL PROTECTED] writes: Und es bleibt natürlich noch die Sache mit den Attributen, mit denen man auf eine Reisezeit schliessen kann. Da muss man faktisch bei Null anfangen, weil man das 'highway'- Attribut dafür nicht ernsthaft verwenden kann. Das ist Quatsch. Triff eine gute Abschaetzung anhand des highway-Attributes, und die Fehler in Deiner Berechnung werden garantiert geringer sein als die externen Einfluesse bei der tatsaechlichen Durchfuehrung der Fahrt (lies: Verkehr und Verkehrshindernisse). Jupp, auch die GDF-Daten der beiden Grossen lassen von der Functional Road Class nicht direkt auf Geschwindigkeiten bzw. Reisezeiten ableiten, da die FRC nur etwas die Wichtigkeit der Strasse im Gesamtnetz aussagt. Wo also kaum Autobahnen sind, wird auch eine eigentlich untergeordnete Strasse fuer eine Verbindung wichtig. Nur zusammen mit anderen Attributen (Form-of-Way, innerorts vs. ausserorts, Kurvigkeit, Anzahl Kreuzungen etc.) bekommt man gute Kanten-Reisezeiten. Wenn Du das auch nur ansatzweise mit einbeziehen wolltest, muesstest Du nicht nur speichern, wo Ampeln sind, sondern auch, wie viele Autos pro Ampelphase rueberkommen und wie viele Autos in Abhaengigkeit von der Tageszeit da stehen und so weiter. Das wird sicher irgendwann mal ein spannendes Projekt - aber *nachdem* wir ansonsten funktionierende Routingsysteme haben, nicht in Version 1.0. Ampeln etc. haben die beiden Grossen bislang auch (noch) nicht (flaechendeckend) drin, so dass alle Router/Navis die auch nicht einbeziehen koennen bzw. man mit alten Strassenkarten nicht verwendbare Ergebnisse bekommen muesste, wenn die denn so dringend notwendig waeren. Da die Navis auch schon vor Jahren (sehr) gute Ergebnisse lieferten ... :-) Viel wichtiger statt der Streit um die Brauchbarkeit der Highway-Tags ist IMHO das flaechendeckende Tagging, ob eine Strasse inner- oder ausserorts ist, egal ob dies ueber Ortsgrenzen, is_in-Builtup-Area- Tags oder per maxspeed=50/30/... passiert (ich versuche bspw. letzteres bei den von mir getaggten Strassen flaechendeckend zu tun). Wenn dann die Kantenzuege der Strasse einigermassen gut den Strassenverlauf, d.h. die Kurvigkeit und damit die tatsaechliche maximale Geschwindigkeit ableiten lassen, kann man eine brauchbare durchschnittliche Kanten-Geschwindigkeit aus all diesen ableiten, die fuer einen guten Durchschnitts-Router voellig ausreicht. Das groesste Problem aber ist leider immer noch, dass ich sehr haeufig nicht verbundene Way-Kreuzungen vorfinde, d.h. wo die Endknoten von zwei oder mehr Ways nicht verbunden sind, sondern nur knapp nebeneinander liegen. Und dies ist fuers Routing nun wirklich problematisch, da damit gerade die Routen im Nahbereich, also beim Start oder Ziel, oft unsinnige Ergebnisse liefern. Hier waere ein maplint- bzw. Josm-Validator-Test wirklich hilfreich, auch wenn ein solcher Test oefters false positives liefern wird, wo Wegenden sehr nahe beieinander liegen, aber eben doch (durch Mauern, Zaeune, unterschiedliche Hoehen) unueberwindbar getrennt sind. Das erinnert mich an die Schule, wo im Physikunterricht irgendeine komplett idealisierte Situation durchgerechnet wurde (punktfoermige Masse ohne Reibung...) und dann jemand stolz mit den vom Taschenrechner gelieferten 5 Stellen nach dem Komma ankommt. Jede praktische Anwendung wird 20% um den berechneten Wert herum schwanken, wozu also die Pseudopraezision? ... ganz zu schweigen von all den aufsummierten Rundungsfehlern, die man so bei einer ungluecklichen Implementierung machen kann :-). Die von einem Router berechnete Gesamtreisezeit wird ueblicherweise nur einige Prozent von der real benoetigten Reisezeit abweichen, solange man keine Staus und andere Stoerungen hat. Will man bessere Werte, d.h eine geringere Abweichung muss man so oder so dynamische Reisezeiten verwenden, d.h. zumindest tageszeitabhaengige Ganglinien, um so die ueblichen Pendlerstroeme mit einzubeziehen ... so wie dies auch (alle? die meisten?) aktuellen Router/Navis machen. Schoenes (Rest-)Wochenende, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] grade5 tracks nicht mehr in z16 ansicht?
Moin, du bist nicht allein, siehe Statistik zu tracktype http://etricceline.de/osm/germany/de_stats_tracktype.htm wenn osmarender über einen Tracktype stolpert, den er nicht kennt, wird der Track scheinbar einfach komplett weiß gemalt. Ich fände es besser, wenn er dann so täte, als wäre gar kein Tracktype gesetzt und den Track wie bisher malte. Schönen Sonntag, ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] highway= vs. reale Eigenschaften
Am Sonntag, 27. Januar 2008 01:28:46 schrieb Gerald.Oppen: Man könnte es ihnen mit JOSM leicht machen: Eingabe des Tracks, Konvertierung in einen Way und Attributierung nach der administrativen Zuordnung die fast überall auf kleinen Schildchen am Strassenrand zu finden ist. Wird kein Highway-Attribut eingetragen so wird dies aufgrund der administrativen Bezeichnung zugeordnet. In der Regel wird man dami maximal 1-2 Stufen daneben liegen - nicht mehr als momentan durch die manuelle Zuordnung aufgrund unterschiedlicher Meinungen. Damit ist die Strasse schon mal in OSM vorhanden und verwendbar. Korrigieren kann sie dann immer noch jemand, die Hauptarbeit ist getan. Garry Man könnte auch noch weiter gehen und primary, secondary und tertiary absichtlich nach der Zuständigkeit vergeben und die Information zur Verkehrswichtigkeit der Straße einfach aus den real existierenden Attributen errechnen: maxspeed=, lanes=, ein tag für mittelstreifen, leitplanken usw... Ampeln gibts ja auch, also sehe Ich keinen Grund, warum ein Mapper sich die Arbeit machen soll, aus dem Bauch heraus (eventuell falsch) zu entscheiden, ob Straße A jetzt wichtiger/schneller/durchsatzstärker ist als Straße B oder umgekehrt. Dann kann der Router mit einer sehr feinen Bewertung arbeiten, um unterschiedliche Bedürfnisse zu erfüllen (Bauer Hannes will für seinen Rübentraktor eine Strecke zur Zuckerfabrik, die möglichst viel Feldweg enthält und wenn es doch eine Bundes/Landes/Kreisstraße sein muß, dann eine mit 2 oder mehr Spuren, damit er nicht 200 genervte Autofahrer hinter sich hat. Geschwindigkeit/Durchsatz ist ihm egal.). Der schöne-Bildchen-Renderer kann ebenfalls diese Daten heranziehen, um in seiner Darstellung darauf hinzuweisen, wie schnell oder durchsatzstark eine Straße ist. WENN ER DAS WILL. (andere wollen andere Dinge darstellen, z.B. aus Fahrradfahrer- oder Rübentraktorfahrersicht) Dann wird halt z.B. die Farbe vom highway-Attribut genommen und die Zeichnungsbreite von der Anzahl der Spuren, maxspeed usw. Mal ehrlich - was die Renderer im Moment machen ist doch pillepalle, sie setzen stur das highway-Attribut in eine starre Darstellung um. Im Prinzip ist das, was Ich vorschlage, für tracks gerade schon umgesetzt worden: dort beinflussen jetzt andere Werte (track_grade) die Darstellung mit, so daß der Renderer ein detailierteres Bild zeichnet. Klasse! Meines Erachtens müssen wir letztlich von der starren Anbetung des Highway-Attributes weg - es kann nur die gröbste Information liefern und eignet sich nicht dazu, eine Aussage über die Wichtigkeit zu treffen. Diese muß das Programm, das die Daten nutzt, auf Grundlage eines Regelwerkes treffen, das die jeweiligen Bedürfnisse des Benutzers berücksichtigt. (Auto, Fahrrad, Hundeschlitten... ;-) ) Und wenn Ich mir das Wachstum der Karte so ansehe, dann bin ich mir sicher, daß es bald eine Menge Mapper geben wird, die sich auf solche Details wie maxspeed, surface, trackgrade, lanes etc. stürzen werden, weil es kaum Wege gibt, die noch neu aufgemessen werden müssen. Dann werden vielleicht endlich auch mal einspurige Einbahnstraßen (z.B. bei baulicher Trennung oder ein Rechtsabbieger, um eine Ampel zu umgehen) nicht genauso fett gerendert wie zwei- oder dreispurige Ebs. oder Straßen, die in beide Richtungen befahrbar sind. :-) So, das wars. Was haltet ihr davon? MfG, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Reisezeiten (was: Potlach! *kotz*)
Hallo, Jupp, auch die GDF-Daten der beiden Grossen lassen von der Functional Road Class nicht direkt auf Geschwindigkeiten bzw. Reisezeiten ableiten, da die FRC nur etwas die Wichtigkeit der Strasse im Gesamtnetz aussagt. Wo also kaum Autobahnen sind, wird auch eine eigentlich untergeordnete Strasse fuer eine Verbindung wichtig. Nur zusammen mit anderen Attributen (Form-of-Way, innerorts vs. ausserorts, Kurvigkeit, Anzahl Kreuzungen etc.) bekommt man gute Kanten-Reisezeiten. Stimmt und deshalb geht mein Vorschlag dahin, ein paar Attribute einzuführen, die im Gegensatz zu 'highway' einigermassen exakt definiert sind und sich mit diesen Punkten beschäftigen. Ich baue keinen Router auf der highway-Info auf, weil ich nicht weiss, was sich der Mapper bei seinem Eintrag gedacht hat. Die statische Reisezeit (ohne Staus, etc.) wird ganz wesentlich von drei Bedingungen beeinflusst: Ausbau, Vorfahrt und Restriktionen wie Geschwindigkeitsbeschränkungen. Kurvigkeit ist eine ganz spezielle Geschichte und geht ja direkt aus dem Verlauf hervor. Im derzeitigen Zustand der Karte findet der Router wichtige Verkehrsbeziehungen nicht, weil sie aus der administrativen Zuordnung nicht hervorgehen. Ein schönes Beispiel ist die Umgehung von Rosenheim (OBB). Die ist derzeit als secondary drin und war schon mal tertiary. Damit ist sie nicht mehr aus dem normalen Hauptstraßengewirr herausgehoben und der Router schickt die Leute auf dem kürzesten Weg durch die Stadt, also mitten durch den Rummel mit vielen Ampeln. Alles was ich will ist, dass der Mapper (und damit auch ich ;)) ein Werkzeug an die Hand bekommt um auf die Straße zu schauen und die in OSM beschreiben: Das ist eine etwas breitere Kreisstraße die in diesem Bereich kreuzungsfrei ausgebaut ist und sehr verkehrswichtig ist. Solange er sich entscheiden muss, ob der jetzt trunk, secondary oder tertiary ist und jeweils wichtige Detailinfo auf der Strecke bleibt, ist das Verfahren suboptimal. Im Fall der Umgehung von Rosenheim bedeutet die derzeitige Einordnung, dass alle Routen die Rosenheim queren nicht die sind, die ein Anwender erwartet, der auf schnellstem Weg weiter will. Kleine Ursache, grosse Wirkung. Konkreter Vorschlag: highway bleibt secondary frc beschreibt die Wichtigkeit und divider beschreibt die kreuzungsfreiheit. Die von einem Router berechnete Gesamtreisezeit wird ueblicherweise nur einige Prozent von der real benoetigten Reisezeit abweichen, solange man keine Staus und andere Stoerungen hat. Will man bessere Werte, d.h eine geringere Abweichung muss man so oder so dynamische Reisezeiten verwenden, d.h. zumindest tageszeitabhaengige Ganglinien, um so die ueblichen Pendlerstroeme mit einzubeziehen ... so wie dies auch (alle? die meisten?) aktuellen Router/Navis machen. Na ja, über die Qualität des dynamischen Routings kann man sich streiten. Da ist wohl auch bei den grossen mehr Schein als Sein. Statistische Verfahren funktionieren so la la und die direkte Ableitung aus den Verkehrsmessgrößen (Induktionsschleifen/'Ufos') ist auch nicht viel besser. Grüsse Hubert -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Schweiz: Chaos am Gotthard und Oberalppass
Mehr zufällig bin ich auf ein ordentliches Chaos beim Gotthard und Oberalppass gestossen: http://www.openstreetmap.org/index.html?mlat=46.62mlon=8.564zoom=12 Die Gotthardstrasse und die angrenzenden Strassen sind teilweise 4x vorhanden und zusätzlich sind die Wege doppelt (mehrere Wege nutzen die gleichen Nodes). Zudem sind einige Nodes mit highway-Tags ausgestattet. Einige Strassen sind offensichtlich durch Umwandlung von GPS-Tracks entstanden, so dass viel zu viele Nodes verwendet wurden die sich teilweise auch noch selbst überlappen (Punktwolken von stehendem Fahrzeug). Ich habe angefangen dort aufzuräumen, aber mangels Ortskenntnis ist das schwierig. Kennt sich jemand dort aus? Insbesondere ist es schwierig herauszufinden, wo die Strassen richtungsgetrennt verlaufen, da die oneway Tags fehlen, aber andererseits die Wege und die GPS-Tracks danach aussehen. Gruss, Andy signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Potlach! *kotz*
Hallo, Das ist Quatsch. Also so hart würde ich das jetzt nicht sagen ;) Triff eine gute Abschaetzung anhand des highway-Attributes, und die Fehler in Deiner Berechnung werden garantiert geringer sein als die externen Einfluesse bei der tatsaechlichen Durchfuehrung der Fahrt (lies: Verkehr und Verkehrshindernisse). B baut auf Informationen auf, die A liefert. Wenn die Beschreibung der Straße schon nicht stimmt, kann man deutlich schlechter abschätzen, was dynamisch passieren kann. Ein Stau auf einer kreuzungsfrei ausgebauten Straße ist anderer Natur als einer auf einer Ampelstrecke. Aber Stau als Grund vorzuschieben, dass eine Reisezeitabschätzung ja gar nicht möglich ist, ist problematisch. Bin nicht mehr so ganz gut informiert, aber die chaotische Natur des Staus hat sich eigentlich ganz gut etabliert. Damit ist ein Stau so gut wie nicht vorhersehbar, aber sehr wohl die Reisezeit ohne Stau. Aber soll man auf die Schätzung der statischen Reisezeit deshalb verzichten? Wenn Du das auch nur ansatzweise mit einbeziehen wolltest, muesstest Du nicht nur speichern, wo Ampeln sind, sondern auch, wie viele Autos pro Ampelphase rueberkommen und wie viele Autos in Abhaengigkeit von der Tageszeit da stehen und so weiter. Das wird sicher irgendwann mal ein spannendes Projekt - aber *nachdem* wir ansonsten funktionierende Routingsysteme haben, nicht in Version 1.0. Das ist jetzt alles nicht unbedingt neu und in vielen Forschungsarbeiten kann man nachlesen, welche Parameter braucht um da eine Abschätzung zu treffen. Man braucht also nicht unbedingt zu warten. Egal wie mans angeht, umso genauer man am Anfang arbeitet, desto besser kommt man später vom Fleck. Das erinnert mich an die Schule, wo im Physikunterricht irgendeine komplett idealisierte Situation durchgerechnet wurde (punktfoermige Masse ohne Reibung...) und dann jemand stolz mit den vom Taschenrechner gelieferten 5 Stellen nach dem Komma ankommt. Jede praktische Anwendung wird 20% um den berechneten Wert herum schwanken, wozu also die Pseudopraezision? Keine Pseudopräzision - nur der Versuch, das sauber zu erfassen, was einfach zu erfassen ist um dass darauf aufzubauen. Eine einbahndurchzogene 30er-Zone soll effektiv von einer Ampelstrecke oder von einer gut funktionierenden Umgehung zu unterscheiden sein. Vorfahrt ist da z.B. ein zentrales Thema. Eine Klassifizierung, die auf den realen Vorfahrtsverlauf Rücksicht nimmt, ist fürs Routing effektiver als die Annahme dass die administrative Einteilung da pauschal zu stimmen hat. Grüsse Hubert -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Reisezeiten (was: Potlach! *kotz*)
Am Sonntag 27 Januar 2008 schrieb qbert biker: Hallo, Jupp, auch die GDF-Daten der beiden Grossen lassen von der Functional Road Class nicht direkt auf Geschwindigkeiten bzw. Reisezeiten ableiten, da die FRC nur etwas die Wichtigkeit der Strasse im Gesamtnetz aussagt. Wo also kaum Autobahnen sind, wird auch eine eigentlich untergeordnete Strasse fuer eine Verbindung wichtig. Nur zusammen mit anderen Attributen (Form-of-Way, innerorts vs. ausserorts, Kurvigkeit, Anzahl Kreuzungen etc.) bekommt man gute Kanten-Reisezeiten. Stimmt und deshalb geht mein Vorschlag dahin, ein paar Attribute einzuführen, die im Gegensatz zu 'highway' einigermassen exakt definiert sind und sich mit diesen Punkten beschäftigen. der sinn und das schoene am highway-tag ist ja eigentlich, mit einem tag eine strasse kategorisieren zu koennen. dass das immer irgendwie schwammig bleiben wird, sist eigentlich klar. auch ein neues definiertes tagging-schema wuerde da warscheinlich bei vielen strassen an seine grenzen stossen, wenn auch die zuordnung wohl genauer werden wuerde. inzwischen werden ja immer wieder irgendwelche zusatztags und attribute verwendet, um die gegebenheiten besser abzubilden. vielleicht waere es da nicht mal so verkehrt, generell etwas von dem ein tag beschreibt alles schema etwas wegzukommen. d.h. es gibt nicht mehr ein highway-tag, sondern ein paket von drei oder vier genau definierten attributen, die die strasse beschreiben, und dies wesentlich genauer koennen. Im Fall der Umgehung von Rosenheim bedeutet die derzeitige Einordnung, dass alle Routen die Rosenheim queren nicht die sind, die ein Anwender erwartet, der auf schnellstem Weg weiter will. Kleine Ursache, grosse Wirkung. Konkreter Vorschlag: highway bleibt secondary frc beschreibt die Wichtigkeit und divider beschreibt die kreuzungsfreiheit. sowas in der richtung... signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Dupe-Nodes
On Sat, Jan 26, 2008 at 02:36:58AM +0100, Andreas Stricker wrote: [Dupe-Nodes] D.h. diese Nodes sind auch nicht Way zugeordnet mit unterschiedlichen layer oder ele-Tags? Gut, daß Du mich daran erinnerst. Es gibt tatsächlich drei Kandidatenpärchen mit unterschiedlichen Layern. Die sollten natürlich nicht zusammengefasst werden, Sonst sehe ich hier kein Problem. Aber um ganz sicher zu gehen: Könntest du die Änderungen zum Peer-Review online stellen? Klar. Die Vorauswahl ist ja bereits online... [1] http://sascha.silbe.org/osm/dupeNodeInfo.lst Geht im Moment bei mir leider nicht (connection refused). ... und auch wieder erreichbar. Du hast leider ausgerechnet die (halbe?) Stunde erwischt, wo der Webserver nach Update fehlerhaft konfiguriert war (benutze einen Server mit, auf dem leider ein Apache läuft). Habe die Datei jetzt um Informationen zu den betroffenen Wegen ergänzt. Nur eine einzige Relation (#2708) enthält Nodes, zu denen Duplikate existieren. Diese Nodes haben jedoch Attribute (highway=minor), so daß sie sowieso nicht angerührt werden. Dateiformat ist (pro Zeile): nodeId lat lon nodeTags wayTags Wobei nodeTags und wayTags jeweils Dictionaries sind mit nodeId bzw. wayId als Key und den Tags als Value. Nicht toll zu lesen, aber für eine kurze Übersicht ausreichend. Enthalten sind alle Dupe-Nodes, nicht nur die Merge-Kandidaten. CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ pgpymPfyZaAla.pgp Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Dupe-Nodes
Sascha Silbe [EMAIL PROTECTED] writes: Nachdem ich jetzt endlich meine Datenbank auf die v5-Ways umgestellt habe, bin ich mal wieder auf die Node-Dubletten aufmerksam geworden. Eine schnelle Analyse hat gezeigt, daß der überwiegende Anteil (im Deutschland-Extrakt) außer created_by und converted_by keine Tags hat und somit sehr einfach zusammengefasst werden könnte. Es gab eine ganz spezifische Potlatch-Version (0.4d IIRC), die Dubletten produziert hat, obwohl keine haetten entstehen sollten. Diese koennte man wohl ziemlich gefahrlos zusammenfassen. Bei den anderen ist es u.U. etwas schwieriger. Cheers Colin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Probleme mit Potlach undqy
Hallo, hättet ihr nicht langsam mal Lust, die Betreffzeile zu ändern? Wieso, ist doch schoen ;-) Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Probleme mit Potlach undqy
Hallo, On Mon, Jan 28, 2008 at 04:18:59AM +0100, Frederik Ramm wrote: Wieso, ist doch schoen ;-) Aeh, sorry, die Mail hatte ich eigentlich verworfen, und irgendwie ist sie doch noch durchgerutscht, daher auch das kaputte subject. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Reisezeiten
Im derzeitigen Zustand der Karte findet der Router wichtige Verkehrsbeziehungen nicht, weil sie aus der administrativen Zuordnung nicht hervorgehen. Ein schönes Beispiel ist die Umgehung von Rosenheim (OBB). Die ist derzeit als secondary drin und war schon mal tertiary. Was ich immer sage: die administrativen Zuordnung wird überbewertet. An Deiner Stelle würde ich die Umgehung eine Stufe höher und die Bundesstraße eine Stufe niedriger zu taggen. Und zwar jetzt sofort. Paul ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Schweiz: Chaos am Gotthard und Oberalppass
Hi, Ich habe angefangen dort aufzuräumen, aber mangels Ortskenntnis ist das schwierig. Kennt sich jemand dort aus? Ich schau heut abend mal rein, sollte auch noch ein paar klärende Urlaubstracks von dort haben. Die sind aber meist mit der via Tremola... -- Ciao, Holger (GUS-KOTAL, GUS#1100) 90-92 Honda CB400 10 Mm | 93-95 Yamaha TDM 850 26 Mm 95-97 KTM 620 LC4 13 Mm | seit 97 BMW R1100GS 69 Mm (Die Renndrecksau!) cu @ http://www.issle.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
