Re: [Talk-de] Parkplätze von Aldi - war 'Garagenh of - wie taggen?'
SLXViper schrieb: Friedhelm Schmidt schrieb: Wo wir schon dabei sind: Wie wäre es wenn man parking mit access = private mit einem grauen P symbol rendern würde. Das sind dann z.b.Parkplätze und Tiefgaragen in Wonanlagen, aber auch Aldis, Lidls und Baumarkts Parkplätze. Das sind dann aber access=permissive. Die sind nicht wirklich privat, aber auch nicht komplett öffentlich. Permissive heißt 'privat, aber Benutzung erlaubt'. Einen Aldi-Parkplatz darfst du strenggenommen nur verwenden wenn du auch bei Aldi einkaufst. D.h. wir brauche ein access='nur für Besucher und Angestellte von xxx'. Ein Router sollte einen dahin führen wenn man das Geschäft als Ziel angegeben hat. Einen Access-Tag dafuer gibt es SIW bis jetzt noch nicht. Könnte man entwender mit einer Relation lösen oder mit Namen+speziellen access tag. Bis jetzt ist garnicht taggen oder access=private die einzige Alternative. Gruß, Grungelborz ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Parkplätze von Aldi - war 'Garagenh of - wie taggen?'
Jörk schrieb: grungelborz schrieb: D.h. wir brauche ein access='nur für Besucher und Angestellte von xxx'. ist das nicht destination? Anlieger frei = ich habe da etwas zu Erledigen... Man muß IMO irgendwie angeben, zu welchem Geschäft der Parkplatz gehört. Daher reicht 'access' alleine nicht aus. Hier http://www.openstreetmap.org/?lat=48.34524lon=12.126389zoom=18layers=B000FTF zum Beispiel weißt du nicht ob du den Parkplatz verwenden darfst wenn du das Seniorenzentrum besuchen willst. Gruß, Grungelborz ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Steigung auf Radkarten
Wolfgang Wienke schrieb: Karl Eichwalder schrieb: Flabot fla...@googlemail.com writes: Und SRTM hilft da auch nicht weiter ?zumindest konnte man so etwa die Steigung der Straße zwischen den 10 Meter Höhenlinien beurteilen oder ? Das ginge wohl. Alternativ könnte man bei stabiler Wetterlage mit einem barometrischem Höhenmesser arbeiten. Ich will doch nur wissen, wie man es einträgt! Ich entnehme es Radkarten oder messe es mit dem Höhenmesser (Neigungsmesser) am eigenen Rad! Unter http://wiki.openstreetmap.org/wiki/Key:incline ist alles erklärt. Neigungsmesser gibts z.B. hier http://globetrotter.de/de/shop/detail.php?mod_nr=fl_35001 Gruß, Grungelborz ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Data Layer on osm.org and landuse areas
Frederik Ramm schrieb: does anyone have a good trick how to select individual roads on the openstreetmap.org data layer when the whole village is covered by a freaking landuse polygon? I can only ever select the polygon ;-( Das Problem wurde irgendwann im Forum diskutiert. Manche lösen das Problem offenbar indem sie die landuse areas einfach loeschen. Ich halte das zwar nicht für gut, aber immerhin kann man die Gebiete später wiederherstellen. Grungelborz ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Tobias Wendorff schrieb: grungelborz schrieb: Mit Abweichung meine ich die Differenz zum Wert aus der topologischen Karte, 1.3m. Die ist 5m. Ausreisser sind bei mir das obere und das untere Drittel des Histograms. Die Begriffe waren nicht aus der Statistik - ich hab das nicht studiert. Worauf es ankommt ist, daß man mit einem simplen Algorithmus und genügend Daten dreimal hintereinander relativ gute Werte erhält. Für mehr Tests habe ich keine Daten. Das kannst Du aber unmöglich als Referenztest für alle GPS-Geräte nehmen. Natürlich kann das Ergebnis mit GPS-Daten von anderen Loggern schlechter werden. Ich habe drei normale GPS-Logger (50-100€) genommen und im Vorbeifahren gemessen. So gut waren die Ausgangsdaten also nicht. Ich hab noch ein bischen gegoogled. Es gibt zu dem Problem einiges in der Wikipedia. Was wir brauchen ist ein robustes Schätzverfahren (http://de.wikipedia.org/wiki/Robuste_Sch%C3%A4tzverfahren) - d.h. ein Verfahren daß auch noch bei Ausreißern gute Werte liefert. Wie robust ein Schätzverfahren ist wird durch den Bruchpunkt (http://de.wikipedia.org/wiki/Bruchpunkt_(Statistik)) beschrieben - der gibt an viel Prozent an Fehlern der Schätzer verträgt. Ich kenne mich mit den Algorithmen zwar nicht aus, vermute aber daß man in unserem Fall einen Schätzer schreiben kann der noch mit 2/3 schlechten Daten vernünftige Werte (10m) liefert - bei ausreichender Datenmenge. Denn die guten Werte konzentrieren sich auf c.a. 20m, die schlechten auf c.a. 100m. Daher sollte ein Schätzer im Histogram den Bereich der guten Daten an der höheren Häufigkeit erkennen können. Ich habe seit einigen Tagen hier ein großes Trimble-Gerät, was ich für die kommenden Monate und Jahre kostenfrei zur wissenschaftlichen Analyse nutzen kann. Ich werde es bald mit einer Antenne fest installieren und kontinuierlich Messdaten ins Web streamen. Da ich die genauen Koordinaten und Höhe dank Vermessungsamt kenne, kann ich die genauen Fehler wiedergeben. Die Höhe schwankte in den letzten 3 Tagen um durchschnittlich 8 Meter hoch/runter. Ausreißer waren bis 17 Meter spürbar. Ich tippe darauf, daß das alpha-getrimmte Mittel mit alpha=1/3 trotzdem einen Fehler unter 5 m hat (http://de.wikipedia.org/wiki/Bruchpunkt_(Statistik)). Die Fehler der einzelnen Messungen sind da nicht relevant. Eine interessante Präsentation zum GPS-Höhenmessen findet sich außerdem unter http://www.intergeo.de/archiv/2005/Drewes.pdf. Grungelborz ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Johannes Huesing schrieb: grungelborz grungelb...@arcor.de [Sat, Feb 21, 2009 at 12:37:41AM CET]: In der ersten Messung meines Experiments unter http://lists.openstreetmap.org/pipermail/talk-de/2008-December/030479.html haben die Messwerte auch eine Streuung von 80 m (Histogram unten). Wenn man dann aber die Ausreisser wegschmeisst und den Rest mittelt kommt man auf eine Abweichung von unter 5m. Streuung scheint bei Dir die Spannweite zu sein, Abweichung scheint bei Dir etwas anderes zu sein, ich komme aber nicht drauf was. Wenn man als Ausreißer alle die ansieht, welche oberhalb von 520 liegen, wäre die Spannweite der verbleibenden gleich 12, die Standardabweichung etwas unter 4, die MAD etwa 4.4, der Interquartilsabstand 6 (die letzten beiden Maßzahlen unabhängig davon, ob man die Ausreißer rauswirft). Mit Abweichung meine ich die Differenz zum Wert aus der topologischen Karte, 1.3m. Die ist 5m. Ausreisser sind bei mir das obere und das untere Drittel des Histograms. Die Begriffe waren nicht aus der Statistik - ich hab das nicht studiert. Worauf es ankommt ist, daß man mit einem simplen Algorithmus und genügend Daten dreimal hintereinander relativ gute Werte erhält. Für mehr Tests habe ich keine Daten. Grungelborz ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Garry schrieb: Du bekommst einen Höhenteppich mit einer Dicke von Grössenordnung 80-160m - ausgehend von einem Messfehler von 30m und und einer nicht bekannten GPS-Höhenkorrektur des jeweils verwendenten Empfängers(knapp50m für Deutschland)... Wenn man konsequent nur bekannte Quellen mit bekanntem Korrekturwert zulässt reduziert sich das natürlich - aber damit entfälltt quasi das Argument automatisch ohne Handarbeit erstellt. In der ersten Messung meines Experiments unter http://lists.openstreetmap.org/pipermail/talk-de/2008-December/030479.html haben die Messwerte auch eine Streuung von 80 m (Histogram unten). Wenn man dann aber die Ausreisser wegschmeisst und den Rest mittelt kommt man auf eine Abweichung von unter 5m. Die Messungen wurden im Fahren gemacht, sind also auch für Wege und nicht nur für einzelne Punkte geeignet. Ich behaupte sobald man 10 gute und bis zu 20 schlechte GPS-Tracks einer Strecke hat kann man die Höhe bis auf 5 m genau schätzen. Tracks ohne Geoid-Korrektur kann man aus dem Höhen-Histogramm erkennen und automatisch korrigieren. Außerdem kann man GPS-Geräte mit falscher Höhenmessung auf der GPS-Geräte-Seite im Wiki markieren und nicht für OSM empfehlen. Das Hauptproblem bei der ganzen Diskussion ist, daß alles theoretisch ist. Mit Höhenwerten in der GPS-Punkte-DB könnte man die Behauptungen überprüfen. Grungelborz ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Dimitri Junker schrieb: ..mit unbekannter Genauigkeit Ich werde mal suchen ob ich irgendwo vernünftige Angaben zu GPS-Fehlern finde. Falls jemand eine Quelle kennt nennt sie mir. http://users.erols.com/dlwilson/gps.htm http://www.kowoma.de/gps/gpsmonitor/gpsmonitor.php Laut beiden Seiten ist der vertikale Fehler nicht so viel schlechter wie der horizontale. Als Faustregel würde ich sagen 50% schlechter. Allerdings scheit des laut der ersten Quelle GPS-Geräte zu geben die immer die Höhe + z.B. 10m ausgeben. Ich hab da auch mal Experimente gemacht: http://www.mail-archive.com/talk-de@openstreetmap.org/msg29339.html Wenn man von einem Ort genügend viele Höhenmesssungen hat sollte man mit statistischen Methoden die richtigen rausfiltern können und so trotz Fehlmessungen und einiger schlechter Geräte gute Werte erhalten. IMO wäre der erste Schritt die Höhe und e.v. noch VDOP+Gerätenamen in die OSM-GPS-Punkte-Datenbank zu laden. Dann sind schon mal die Daten verfügbar und wer will kann was damit basteln. Grungelborz ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Plaedoyer fuer Nick ohne Realnamen
Sven Geggus schrieb: Das heißt Du willst der Öffentlichkeit nicht mitteilen, dass Du bei OSM dabei bist. Nun ja, jeder wie er mag. Mir gehts ja subjektiv immer so, dass Leute die ohne Realnamen posten sehr viel gehaltvollere Mails schreiben müssen um bei mir in der Achtung ähnlich hoch zu liegen wie diejenigen, die Unfug mit Realnamen posten. Akzeptiert. Ich persönlich bewerte eine Mail primär nach dem Inhalt - wenn sie Sinn macht und gut begründet ist ist mir egal wer das geschrieben hat und ob ich den kenne. Ansonsten ist es z.B. bei jeder Bewerbung dem Arbeitgeber möglich meine Mailinglisten/Forums-Artikel zu lesen. Ja und? Schämst Du Dich dafür? Es kann ein Nachteil für mich sein den ich vermeiden kann. OSM ist für mich persönlich zweitrangig sodaß ich dafür diese Nachteile nicht in Kauf nehmen will. IMO ist es ein Unterschied ob das was man schreibt für einen begrenzten Personenkreis ist oder von der ganzen Welt und für immer gelesen werden kann. Im letzteren Fall paßt man lieber ein bißchen auf. Gruß, Grungelborz ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Plaedoyer fuer Nick ohne Realnamen
Simon Kokolakis schrieb: Man muss ja nicht zwangsläufig seinen echten Namen benutzen, sondern von mir aus auch einen erfundenen Realnamen. Für die Leser ist es nicht wichtig ob hinter dem Namen wirklich die exakte Person steckt oder nicht. Hautsache man ist mit dem Namen immer zu identifizieren. Kontrollieren kann das eh niemand. Ich überlegs mir. Irgendwie ist mir ein 'echtes' Pseudonym unsympatisch weil man behauptet jemand anderer zu sein. Beim Nick gibt man offen zu daß man nicht erkannt werden will. Und: Der Grund dafür ist der Google-Index, nicht die anderen Mailinglistenteilnehmer. Gruß, Grungelborz ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] dringende Frage zur Vorgehensweise den LVA-B-Luftbildern
Worin unterscheidest du bei DOPs, bei denen ein Pixel für 2m der Realität steht, welche noch dazu leicht schräg aufgenommen sein können, zwischen den einzelnen highway Typen? Motorway und trunk dürften inzwischen alle erfasst sein. primary und tertiary kann man in aller Regel unterscheiden, secondary liegt dazwischen und kann auch verwendet werden wenn man sich mit den anderen beiden nicht sicher ist. Residential ist auch erkennbar, unclassified wenn der Weg ein bischen besser ausgebaut aussieht. Was nach weniger aussieht wird erstmal ein track. Damit hat man schonmal eine wesentlich brauchbarere Klassifizierung als mit road, auch wenn man 1-2Kategorien daneben liegt und im Einzefall mal doch eine Strasse gesperrt ist. Mehr darf man von den OSM-Daten derzeit sowieso nicht erwarten auch wenn regional schon sehr viel genauere Daten vorliegen - auf dem Navi siehst Du im Routing nicht wo wie genau gearbeitet wurde wenn Du keine Ortskenntnis hast. Ich stimme im wesentlichen zu. tertiary+secondary+unclassified+track sind i.a. besser als road. Aus der Breite kann man in etwa erkennen, ob die Straße zweispurig oder einspuring ist. Im ersten Fall sollte sie IMO mindestens unclassified bekommen. Weiterhin kann man darauf achten, ob die Straßen einen Verbindungscharakter hat. Jeder Ort (mehrere Häuser, kein Bauernhof) ist mindestens über eine öffentlich zugängliche Straße erreichbar. Im allgemeinen ist das die breiteste. IMO sollte diese Straße immer mindestens tertiary sein. Kurze Wege zu Höfen sind eher 'service'. Danach kann man schauen, ob andere Wege existieren, die Orte 'optimal' verbinden - d.h. wenn der Weg nicht da währe müßte man einen _großen_ Umweg machen. Auch solche Wege sollten tertiary/secondary getaggt werden. IMO sollte man mit solchen Heuristiken eine Fehlerquote für _Straßen_ unter 5% bekommen. Viel besser geht nicht wenn man nur Luftbilder hat und sich nicht auskennt. Danach sollte man die residential/industrial Gebiete (landuse) eintragen. Dadurch könnnen Openstreetbugs-Benutzer erkennen wo die Orte sind. Ortskundige können das entstehende Gitter leicht interpretieren und zumindest mal die Orte benennen. (Orte ohne Namen werden ja nicht gerendert, SIW). IMO klappt daß nur wenn die Verbindungsstraßen farblich hervorgehoben sind, was bei tertiary/secondary der Fall ist. Schmale Straßen, die die Kriterien oben nicht erfüllen sollten IMO eher als tracks getaggt werden - nach der Regel daß im Zweifelfall der 'geringwertigere' Tag verwendet wird. Der Schaden für den Benutzer ist dadurch geringer. Wenn ein Router eine Strecke vorschlägt die verboten ist kommt er garnicht an. Tracks die möglicherweise geringwertige tracks sind - grade4+5 sollten IMO garnicht von Luftbildern getaggt werden. Im allgemeinen sind solche tracks nur für den Landwirt interessant, und sie verwirren den normalen Benutzer nur. Wenn man die Tracks für Fahrradfahrer hat reicht das. Außerdem wird es bei solchen tracks zunehmend unwahrscheinlich, daß man einen Ortskundigen findet, der das alles korrigiert. Ich weiß das andere der Meinung sind, alles muß gemappt werden - die Frage ist: wozu? Außerdem sollte man berücksichtigen, daß Wälder, Flüsse und Seen wesentlich sicherer mit Luftbildern getaggt werden können und IMO daher vor den Straßen getaggt werden sollten. Gruß, Grungelborz ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorschlag fürs Höhenmessen: GPS+S tatistik
Hallo, Tobias Wendorff schrieb: GPS-Logger loggen *keine* qualitativ verwertbaren Höhen. Vorallem, weil die ganzen GPS-Logger (also die von verschiedenen Herstellern) meistens auch noch anders loggen. Vielleicht ist es richtig daß man keine vernüftigen Höhendaten bekommt, wenn man Einzelmessung macht. Wenn man aber sehr viele Messungen durchführt und die statistisch miteinander verrechnet sind IMO die Ergebnisse ganz brauchbar. Und für OSM ist es möglich an sehr viele Messungen zu kommen. Ich habe dazu mal ein Experiment gemacht: Ich habe drei Positionen genommen, von denen ich sehr viele GPS-Höhenmessungen hatte - an verschiedene Tagen mit verschiedene Geräten. Diese Messwerte hab ich nach der Höhe sortiert und jeweils das obere und untere Drittel weggeschmissen. Vom Rest hab ich den Mittelwert genommen. Das ist eine grobe Heuristik, um die Fehlmessungen loszuwerden, sollte aber noch besser gehen. Die Ergebnisse: 1) Ort: 11.688145/48.218678 GPS-Höhe: 491.6 (Mittelwert aus 135 Werten, c.a. auf 1m Höhe gemessen) Höhe aus topologischer Karte: 491.9 Differenz: 1.3 (1 m Korrektur) 2) Ort: 11.661333/48.197187 GPS-Höhe: 498.0 (Mittelwert aus 51 Werten, c.a. auf 1m Höhe gemessen) Höhe aus topologischer Karte: 500.0 Differenz: 3m 3) Ort: 11.701727/48.225953 GPS-Höhe: 487.8 (Mittelwert aus 38 Werten, c.a. auf 1m Höhe gemessen) Höhe aus topologischer Karte: 488.7 Differenz: 1.9m Ich habe drei verschiedene GPS-Chips (SIRF, MTK, Antaris) verwendet. Die Messungen wurden alle im Vorbeifahren gemacht. VDOP/HDOP/#Sat wurden ignoriert. Die drei Messwerte sind zwar noch kein Beweis, daß das immer klappt. Aber eine Genauigkeit von 10m sollte mit dem Verfahren kein Problem sein. IMO sind 10m für Wanderer + Radfahrer ausreichend. Das Datum der Messungen hab ich ignoriert (weiß nicht welches Datum die Topologische Karte hat). Gruss, Grungelborz Hier noch das Histogram der ersten Messung (Höhe/#Messungen) - die Einzelwerte waren tatsächlich nicht immer gut: 480 3 481 6 483 1 484 18 485 10 486 29 487 40 488 13 489 27 490 26 491 70 492 39 493 26 494 69 495 52 496 1 498 5 499 9 500 10 501 3 502 1 535 5 536 3 537 10 538 11 539 7 546 11 547 7 548 1 562 8 563 6 564 5 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbilder LVA Bayern - Vertrag unterschrieben
Markus schrieb: Der Vertrag ist unterzeichnet. Das Projekt ist bis 31.3.2009 verlängert. Jetzt liegt es an uns, was wir daraus machen... Jochen Topf kümmert sich um die Erfolgs-Statistik und hat Ideen zu einem Mal-Wettbewerb. Weiß jemand, warum das LVA zuerst ein Pilotprojekt macht und uns die Daten nicht einfach so gibt? IMO wäre das interessant um die Wahrscheinlichkeit zu erhöhen dass wir den Rest von Bayern bekommen. Mögliche Gründe die mir einfallen: 1. Sie wollen prüfen ob OSM sich an den Vertrag hält und z.B. die Luftbilder nicht für andere Zwecke verwendet werden. (Sollte für uns machbar sein - ob die Karte was wird wäre dann egal) 2. Sie wollen prüfen ob das der Öffentlichkeitsarbeit des LVA hilft. D.h. wohlwollende Artikel in Zeitungen, e.v. Werbung für die Luftbilddaten. (Hier brauchen wir präsentable Karten) 3. Sie wollen sehen, ob die OSM Daten für das LVA von Nutzen sind. Z.b. um mögliche Fehler in topologischen Karten zu finden. (IMO nur schwer von uns zu erfüllen) 4. Sie wollten testen, ob die OSM-Karten eine Konkurrenz zu den eigenen Karten werden können. D.h. wir bekommen den Rest von Bayern nur wenn die Oberpfalz richtig schlecht gemappt wird. ;) Gruss, Grungelborz ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ziel des Pilotprojekts
André Reichelt schrieb: FrauSuhrbier schrieb: Da das Pilotprojekt befristet ist, schlage ich vor die Aktivitäten organisiert, gesteuert eventuell über das WIKI anzugehen. Gibt es dazu schon Ideen? Ich denke, wir sollten das Ganze in Planquadrate aufteilen, die man in maximal 30 Minuten bearbeiten kann (geübter Mapper). Man trägt sich beim Start für eines ein und markiert es dann als bearbeitet. Das Ganze sollte dann min. noch von zwei anderen Personen gegengeprüft werden, sodass nichts vergessen wurde. IMO sollte es das Ziel des Pilotprojekts sein, das LVA von OSM zu überzeugen. Dazu braucht man nicht die ganze Oberpfalz zu vektorisieren. Es ist besser wenn man 2-3 wirklich gute und präsentable Orte hat als die gesamte Oberpfalz in uneinheitlicher und mäßiger Qualität. Das Hauptproblem von Luftbilder ist, daß man damit Karten zeichen kann obwohl man von der Gegend überhaupt keine Ahnung hat. Die Qualität der Karten ist dann entsprechend. Ortskundige Mapper haben dann anschließend mehr Arbeit damit, die Fehler zu korrigieren als wenn sie auf einer weißen Fläche anfangen könnten - ich z.B. meide solche Gebiete eher. Bei Wälder+Flüssen kann man zwar nicht viel falsch machen, von Luftbildern abgezeichnete Feldwege sind meiner Erfahrung nach relativ wertlos weil man nichtmal weiß ob man da fahren darf. Bei Gebäuden wird oft willkürlich mit dem vektorisieren angefangen und dann aufgegeben - mit dem Effekt daß irgendwelche Wohnhäuser eingezeichnet sind, Rathaus, Schulen und Kirchen aber fehlen. IMO sollte man sich für das Pilotprojekt einen Ort suchen, den man kennt und versuchen eine interessante und präsentierbare Karte zu basteln. Die Leute die daran mappen sollten sich koordinieren sodaß die Karte einheitlich wird (z.B. ob alle Gebäude oder nur die wichtigen gezeichnet werden). Zur Organisation ist IMO nicht viel Aufwand nötig - nur eine Liste der Orte die als Kandiaten taugen und wo sich Mitstreiter organisieren können. Am Schluß zeigt man die besten Orte dem LVA und hofft daß sie einem den Rest von Bayern (und Deutschland) geben. Ich werden e.v. die Karte von Berching (http://informationfreeway.org/?lat=49.107404606319356lon=11.438880511658873zoom=15layers=BF000F) im Weihnachtsurlaub dafür herrichten - wenns zeitlich geht. Gruß, Grungelborz ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Begriffsfrage life_cycle
Garry schrieb: Bitte einen konkreten Link - was ich beim überfliegen gefunden habe geht auch nur um den Lebenszyklus /Lebensdauer einer Strasse - dass hat nichts mit dem Betriebsstatus einer Strasse zu tun! Nur weil Du eine Erkältung hast ist deswegen Dein Lebenszyklus auch noch nicht abgelaufen... Der aktuelle Vorschlag geht ja auch um 'construction', 'in_use' und 'disused' - das passt zu Lebenszyklus. Ich werde meinen Vorschlag hier nicht weiter verteidigen - ich habe in de der Diskussion nur meine Meinung gesagt die nicht vollkommen unsinning ist. Wenn die Mehrheit einen anderen Begriff will ist das für mich OK. Das Problem war daß in der Diskussion des Proposals kein gut begründeter und e.v. mit Beispielen belegter Gegenvorschlag kam. Darum hat life_cycle irgendwie gewonnen. Gruss, Grungelborz ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Begriffsfrage life_cycle
Garry wrote: Tordanik schrieb: Gegenfrage: Liegt Dir sehr am Begriff life_cycle? :-) ... Garry wrote: Ich bin anfangs noch davon ausgegangen dass lifecycle nur ein mir unbekannter, aber vielleicht doch etablierter Begriff für diesen Zweck ist. Meine Recherchen dafür haben aber nicht den geringsten Hinweis in diese Richtung ergeben sondern meine mittelmässige Englischkenntnisse bestättigt dass dieser Begriff in Richtung Lebensdauer geht.. Der Vorschlag 'life_cycle' (Lebenszyklus) kam von mir als Alternative für den anfänglichen Vorschlag 'status'. IMO bietet er zumindest weniger Verwechslungsgefahr - unter 'status' könnte jemand auch die Straßenqualität verstehen. Ich hab den Begriff aus der Softwaretechnik wo er für das Erzeugen und Löschen von Objekten verwendet wird (life cycle management). Wie gut er für Straßen passt weiß ich ehrlich gesagt nicht, aber eine Google Suche nach 'life cycle road construction' zeigt daß es auch andere gibt die den Begriff so verwenden. Wenn der Begriff nicht selbsterklärend ist muß man halt die Beschreibung in dem 'Map Features' lesen. Gruss, Grungelborz ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie wichtige Gebäude taggen
es gibt Gebäude, die nicht öffentlich sind - aber von öffentlichem Interesse (z.B. Verbraucherzentrale). Wie taggen ??? AFAIK gibt es dafür keinen Tag. Eigentlich gibt auch keinen Tag für öffentliche Gebäude, ausser man sammelt alle Schulen, Rathäuser etc auf. IMO wird das zum Problem wenn man Karten rendern will auf denen alle solchen Gebäude hervorgehoben sind. (Wie z.B. http://leben.ismaning.de/user/eesy.de/ismaning.de/w2leben/dwn/dw_ortsplan.pdf). Im Augenblick wird man da relativ komplizierte und unzuverlässige Render-Regeln brauchen. IMO die beste Lösung wäre den Wert des 'building'-tags zu dem Zweck zu verwenden. Das scheint aber im Augenblick nicht beabsichtigt zu sein. (http://wiki.openstreetmap.org/index.php/Proposed_features/Building). Gruss, Grungelborz ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unclassified vs. Tracks
Christian schrieb: Während ich persönlich Wirtschaftswege gerne als unclassified tagge, scheint der Trend dahin zu gehen sowas als track mit grade1 zu loggen. Das ist das Problem. Weil es IMHO einen himmelweiten Unterschied zwischen Wirtschaftsweg und Feld- oder Waldweg gibt. Ich verwende 'track'+'grade1' statt unclassified wenn ein Weg einspurig ist und für den allgemeinen Autoverkehr nicht gedacht oder verboten ist - d.h. es gibt einen besseren 'unclassified' Weg. Z.b. bei http://informationfreeway.org/?lat=48.225841899987074lon=11.784917586138693zoom=15layers=B000F000F ist der beste Weg für Autos vom BMW Testgelände nach Neufintsing über 'An der Dorfen' + 'Eicherloher Straße'. Der südliche Weg über den 'grade1-track' wird von Autos normalerweise nicht verwendet. In Google ist dieser Weg auch nur als 'track' d.h. dünner gezeichnet. Daher macht 'track+grade1' als zusätzliche Kartegorie durchaus Sinn. Ein 'grade1' und ein 'grade2' track unterscheiden sich IMO nicht so sehr - auf beiden muß man als Autofahrer langsam fahren, sie sind aber ohne Probleme und bei jedem Wetter befahrbar. Gruss, Grungelborz ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Neue Symbole für die Statustabellen
Hallo, auf der Diskussionsseite des Landkreis Münchens hab ich Vorschläge für drei neue Symbole für die Statustabellen: http://wiki.openstreetmap.org/index.php/Talk:Landkreis_M%C3%BCnchen#Weitere_Symbole Gruss, Grungelborz ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Nutzung von Luftbildern des Bayrischen Landesamts für Vermessung und Geoinformation in OpenStr eetMap
Andreas Jacob schrieb: D.h. unvollständig gemappte Gebiete scheinen Mapper eher abzuschrecken. Dazu sollten auch von Luftbildern abgezeichnete Gebiete gehöhren. Gilt IMHO nur so lange, wie es noch große weiße Flecken auf der Karte gibt. Denn das ist ja das Ziel, diese Flecken zu beseitigen. Aber wenn die Aussagen von dir und Bernd wirklich für die Mehrheit der am Projekt mitarbeitenden zutreffen sollte, dann haben wir nach Erreichen der optischen Vollständigkeit ein echtes Problem. Sobald die OSM-Karten für größere Gebiete zuverlässig sind werden die Leute sie auch benutzen - dadurch steigt auch die Zahl der Mapper (soweit sind wir glaub ich noch nicht). IMO wird die Karte langsamer vollständig werden wenn es viele Gebiete gibt, die zwar angefangen sind aber bei weitem noch nicht vollständig. Da fehlt sowohl der Anreiz ein neues Gebiet zu mappen als auch die Karte tatsächlich zu verwenden. Wenn das stimmt wird die Karte am schnellsten fertig wenn jedes Gebiet im ersten Schritt zumindest bis auf Google-Niveau gemappt wird. Danach ist es zumindest halbwegs verwendbar. Ich mappe in solche Gebiete auch nur ungern. Oft sind z.B. von Luftbildern Privatwege oder grade4-tracks abgezeichnet die man beim Abfahren ignoriert (ich mappe mit Kamera, ohne Karte). Weshalb ignorierst du diese Wege? Du kannst doch auch davon ein Foto machen, und bei einem Privatweg dann access=privat/no und/oder highway=service daraus machen. Hofeinfahrten - auch lange - schauen am Boden furchtbar uninteressant aus - da denkt man nicht ans Fotografieren. Ausserdem muss man ja auch weiterkommen. Ich komm so schon auf bis zu 1000 Bilder pro Mapping-Tag. http://informationfreeway.org/?lat=48.18624727026545lon=11.772987123024516zoom=17layers=B000F000F Wie ich an den Fußwegen am Fasanenweg vorbeigefahren bin habe ich keinen Fußweg gesehen, der zur Mövenstraße geht. Eingezeichnet ist aber einer. Um zu verifizieren daß der falsch ist müßte ich da wieder hin (20 km - mag aber nicht). Wenn man dann am Computer sitzt weiß man nicht was man mit diesen Wegen manchen soll. Vernünftig wäre IMO löschen aber das soll man ja nicht. Wieso löschen? Der Weg ist doch da. Und die Information, dass dies jetzt eine private Zufahrt ist, hast du auch gesammelt. Warum willst du ihn dann nicht bearbeiten? Ein gesperrter privater Weg auf einer Karte richtet weniger Schaden an wenn er garnicht da ist als wenn er als öffentlicher Weg gemappt ist. Im ersten Fall nimmt der Anwender halt einen anderen Weg. Im zweiten Fall kommt er nicht an oder muß nach dem Weg fragen. Für den Anwender sind abgezeichnete oder aus GPS-Daten automatisch generierte Wege IMO wertlos. Ja, aber nur für den Anwender, welcher selber nicht am Projekt mitarbeiten möchte, sondern nur die Daten nutzen. Für alle anderen ist ein highway=road doch ein Zeichen, dass es an dieser Stelle noch ein Informationsdefizit gibt, welches man füllen sollte. Wenn man highway=road als gesperrten Weg betrachtet, OK. Andernfalls führt man damit nur Leute in die Irre. Gruss, Grungelborz ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Abgezeichnete Tracks
Johann H. Addicks schrieb: Luftbildern Privatwege oder grade4-tracks abgezeichnet die man beim Abfahren ignoriert (ich mappe mit Kamera, ohne Karte). Wenn man dann am Computer sitzt wei? man nicht was man mit diesen Wegen manchen soll. Vern?nftig w?re IMO l?schen aber das soll man ja nicht. Als Geocacher bin ich auch für solche Wege dankbar. Und ja ich mappe fast ausschließlich tracktype grade=2, und das nicht nur, weil hier im Großraum Frankfurt die Wohnstraßen nahezu 100% bereits erfasst sind. Ein dichtes Netz aus grade5 finde ich nicht verwerflich, auch wenn der durchschnittlicher Auto- oder Radfahrer damit nichts anzufangen weiß. Wer nur zwei- und vierrad-taugliche Wege sehen will der soll sich die Feldwege von einem entsprechenden Renderer ausblenden lassen. Wenn Tracks von Luftbildern abgezeichet werden werden die natürlich ohne tracktype eingetragen, selbst wenn sie grade4 sind - d.h. alle Tracks schauen gleich aus. Man weiß dann nicht welchen Weg man am besten mit dem Fahrrad nimmt und ob man bei Regen da überhaupt weiterkommt. Um das ohne Löschen zu korrigieren muß man alle Tracks abfahren. Ansonsten müßte man im ersten Schritt nur die navigationsrelevanten tracks eintragen und hätte eine nützliche Karte. Grade4-Tracks sind ansonsten natürlich OK, insbesondere wenn sie auch als Grade4 markiert sind. Z.b: http://informationfreeway.org/?lat=48.2273571492482lon=11.849633911232862zoom=14layers=B000F000F Was ist dort denn das konkrete Problem? Nur weil wir uns hier den Luxus gönnen, selbst Rad- und Feldwege in mindestens 7 verschiedene Klassen zu teilen, muss das nicht immer auch voll ausgereizt werden: Wenn ich meine Garmin-Top anschaue, dann gibt es dort gerade mal 3 Klassen, deren Zuordnung aber sehr oft völlig zufällig erscheint. Weg (das üblicherweise gestrichelte Ding in Wald und Flur) kann dann sowohl ein Holzrückweg in tiefem Bruchwaldboden, frei von jeder Befestigung und mit 20cm hohem Dornengestrüpp zwischen den Fahrspuren sein, aber auch eine voll ausgebauter Landwirtschaftsweg für schwere Molkereitankwagen, auf dem es nur geringfügig eng wird, wenn mal der doppelt bereifte Ackerschlepper entgegenkommt. Wobei die automatischen Mapper durchaus bessere Ergebnisse erzielen, wenn sie die lokale Fahrgeschwindigkeit bezogen auf die Fahrzeugart und die Durchschnittsgeschwindigkeit berücksichtigen. Fahrrad und 15km/h sollte z.B. Grade5 ausschließen, 25km/h auch Grade4. Und wenn der Radler plötzlich 50m mit konstant 3-5km/h macht, dann sollte man mal schauen, ob da nicht highway=stairs angebracht wäre... Will sagen: Das Streben nach Perfektion ist nicht verwerflich, aber dort wo wir überhaupt mappen ist es nicht schwer, zumindest an den für Privatleute bezahlbaren 1:50.000-Topos vorbeizuziehen. IMO sollte man schon erkennen können welcher Weg für Autos bzw. Fahrräder geeignet oder der beste ist. Für die Tourplanung sind Karten schließlich da (mein ich). Die 1:50.000-Topo ist in dem Fall deutlich besser. Gruss, Grugelborz ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Nutzung von Luftbildern des Bayrischen Landesamts für Vermessung und Geoinformation in OpenStr eetMap
Bernd Wurst schrieb: Es gibt doch nichts besseres als einen weißen Fleck auf der Karte in was brauchbares zu wandeln. Wenn sich das jetzt darauf reduziert, dass ich nur noch die letzten 100 Meter Feldweg nachtrage und den Rest von road nach track/uncalssified oder sowas umwandle, dann motiviert mich das gar nicht. Unter http://lists.openstreetmap.org/pipermail/talk/2008-May/026284.html gibts eine Statistik die Bernds Meinung untermauert: Zitat: Now, London gets quite dark at some spots... More remarkably, this picture shows that data imports dramatically decrease mapping activity (or so it seems): not only the Netherlands show relatively little activity, also Osnabrück looks quiet (compare for example to the Ruhr area or the area between Brussels and Antwerp). Still, in my opinion, these imported areas are far from complete. D.h. unvollständig gemappte Gebiete scheinen Mapper eher abzuschrecken. Dazu sollten auch von Luftbildern abgezeichnete Gebiete gehöhren. Ich mappe in solche Gebiete auch nur ungern. Oft sind z.B. von Luftbildern Privatwege oder grade4-tracks abgezeichnet die man beim Abfahren ignoriert (ich mappe mit Kamera, ohne Karte). Wenn man dann am Computer sitzt weiß man nicht was man mit diesen Wegen manchen soll. Vernünftig wäre IMO löschen aber das soll man ja nicht. Für den Anwender sind abgezeichnete oder aus GPS-Daten automatisch generierte Wege IMO wertlos. Z.b: http://informationfreeway.org/?lat=48.2273571492482lon=11.849633911232862zoom=14layers=B000F000F Die Tracks um Lausbach wurden wahrscheinlich automatisch mit GPS tracks generiert. Die Frage: Wie komme ich mit dem Auto nach Lausbach. Mit Google kann mans rausfinden. http://informationfreeway.org/?lat=48.236447702757346lon=11.617118626511234zoom=15layers=B000F000F: Hier sind von Luftbildern abgezeichnete Wege in einem militärischen Sperrgebiet. Am Boden verifizieren kann man die nicht. Was tun? Gruß, Grungelborz ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Saubere GPS-Tracks machen
Ralph Aichinger schrieb: Wieviel Aufwand treibt ihr, damit euer GPS immer gute Sicht zum Himmel hat (z.B. Montage am Rucksack oben). Normalerweise nehme ich immer zwei GPS-Logger. Wenn einer Fehler aufzeichnet hat man immer noch den anderen. Beim Fahrrad wird einer am Lenker, der andere am Gepäckträger befestigt. Zu Fuß und im Winter kann man einen in die Mütze und einen in den Handschuh stecken - die besseren Signale bekommt man von dem in der Mütze, mit dem im Handschuh kann man Wegpunkte aufzeichnen. Ist recht unauffällig. Im Sommer kommt halt einer in den Rucksack, den anderen halte ich in der Hand. Unterschiedliche Position auf der Straße (z.B. linker und rechter Gehsteig abwechselnd, oder mitten in der Straße/Rand, wenn Autos kommen). Wenn Luftbilder vorhanden sind ist die Qualität der Tracks IMO nicht so wichtig. Vor dem Einzeichnen der Wege in JOSM überprüfe ich erst, daß die Tracks mit den Luftbildern kosistent sind - d.h. auf den Straßen liegen. E.v. verschiebe ich die Luftbilder dass das so ist. Die Straßen zeichne ich dann nur nach Luftbildern. IMO bekommt man dadurch die Form der Straßen besser hin. Gruss, Grungelborz ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] fortschritt messen, aber wie?
mariner schrieb: Mir gefällt daher die Vorschrittkontrolle, wie sie viel in Deutschland angewendet wird: http://wiki.openstreetmap.org/index.php/Landkreis_M%C3%BCnchen Dieses System, wie es in München praktiziert wird, gefällt mir. Wie kann ich das ganze auf eine Wiki Seite mit schweizer Kontext übernehmen? Unter http://wiki.openstreetmap.org/index.php/Template:Map_status gibt es inzwischen ein Template. Die Diskussion dazu ist bei http://wiki.openstreetmap.org/index.php/Talk:Landkreis_M%C3%BCnchen. Gruss, Grungelborz ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Status-Icons für die Fortschrittstabe llen im Wiki
FYI: Im Wiki unter http://wiki.openstreetmap.org/index.php/Talk:Landkreis_M%C3%BCnchen gibt es eine Diskussion über die Neudefinition der Status-Icons und der Definition neuer Icons. Gruss, Grungelborz ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] opengeodb: Bayern
Das Verfahren ist IMO eine sehr gute Sache. Allerdings glaub ich nicht da? der aktuelle Abgleich wirklich exakt ist - die Gemeinde Ismaning hab ich bis auf ein paar Feldwege systematisch gemappt - laut deiner Statistik fehlen trotzdem noch 15 Stra?en. Von allen anderen Gemeinden kommt auch keine auf nahezu 100%. Ich hoffe mal da? das am Skript liegt - ansonsten ist an der Art wie ich kartographiere was falsch. Hallo Grungelborz, am einfachsten pr?fst du mal nach, was fehlt... danke für die Straßenliste. Ich hab sie mit dem OSM-Daten und meinen Fotos verglichen und den Rest auf kommerziellen Karten gesucht. Ergebnis: - manchmal weicht die Schreibweise im Straßenverzeichnis von den Schildern ab - nicht alle Straßen im Straßenverzeichnis existieren schon - ich vermute die reservieren schon Namen für Neubaugebiete, teilweise sind es Gebiete (Isarauen östlich) und Bauernhöfe (Karlshof) - bei Feldwegen glaub ich nicht daß die alle Namensschilder haben (ich schau nochmal) - OK, ein einige Fehler von mir waren auch drin (bin etwas frustriert) Fazit: - selbst eine vollständige gemappte Gemeinde wird noch Unterschiede zum Straßenverzeichnis haben - wenn man die Differenzen zum Straßenverzeichnis überprüft hat sollte man die Gemeinde als 'fertig' bezeichnen können - natürlich nur bzgl. der Straßennamen Wens interessiert, hier die Details: Schreibweise in Straßenverzeichnis weicht von Schildern ab: Max-Josef-Str. - auf Schild steht: Max-Joseph-Straße (fehlt ausserdem) Walderdorff-Ring - auf Schild steht 'Walderdorffring' (Schild sollte korrekt sein da es eine Person ist) Schlesier Weg - auf Schild steht 'Schlesierweg' Nicht alles im Straßenverzeichnis ist eine Straße: Karlshof: Bauernhof, SIW hat er als Adresse die Freisinger Straße Auch in kommerziellen Karten nicht vorhanden: Forstweg Im Oberfeld Isarauen östlich Kolomansteg (Vermutlich der offizielle Name einer Fahrradbrücke - in den Wegweisern ist die als 'Isarsteg Ismaning' bezeichnet. Karlsbader Weg Klaus-von-Klitzing-Str. Falsche Schreibweise, Fehler von mir: Adolph-Kolping-Str. Bahnhofplatz Münchener Str. Hortenseweg Haushamerstr. Von-Ketteler-Str. Fehlt komplett, Fehler von mir (von den ersten zwei hab ich Fotos, weiss nicht warum die in OSM fehlen): Malteserstr. Emmeramstr. Am Poschinger Weiher(hätte ich zu Unterföhring gezählt bin aber nicht sicher wo die Grenze ist) Fehlende Feldwege (an zwei Feldwegen bin ich vorbeigefahren, habe aber kein Schild gesehen): Am Katzengerbl Schafweidstraßl Nördlicher Speicherseeweg Remisstr. Ansonsten: Speicherseestr. (Liegt IMO komplett in der Nachbargemeinde - ist dort gemappt) Gruss, Grungelborz ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] opengeodb: Bayern
Hallo, auch mit den bayrischen OSM-Daten habe ich nun einmal einen Abgleich mit den Stra?enverzeichnissen gemacht. Die Ergebnisse stehen auf http://wiki.openstreetmap.org/index.php/Bayern Das Verfahren ist IMO eine sehr gute Sache. Allerdings glaub ich nicht daß der aktuelle Abgleich wirklich exakt ist - die Gemeinde Ismaning hab ich bis auf ein paar Feldwege systematisch gemappt - laut deiner Statistik fehlen trotzdem noch 15 Straßen. Von allen anderen Gemeinden kommt auch keine auf nahezu 100%. Ich hoffe mal daß das am Skript liegt - ansonsten ist an der Art wie ich kartographiere was falsch. Hast du mal einen Abgleich mit einer Gemeinde versucht, von der wir offizielle und vollständige Daten haben (Oldenburg?). Gruss, Grungelborz ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] RFC: Statustabellen für München
einige von euch haben schon die Statustabelle f?r den Landkreis München gesehen: http://wiki.openstreetmap.org/index.php/Landkreis_M%C3%BCnchen. Würde es nicht evtl. Sinn machen, diesen Fortschritt als Area mit entsprechendem Tag direkt in OSM zu halten. Dann könnte man per zusatzrender Regel das auch grafisch darstellen. Den Status als Tags zu halten hätte einige Vorteile. IMO braucht man eine Tabelle trotzdem, z.B. für Kommentare. Wenn man die mit JOSM lesen muss ist das doch eher unbequem. Die Tabelle könnte man dann mit den OSM Daten updaten. Ich hab mal die vorhandenen Tag-Vorschläge zu dem Thema angeschaut und nur den Tag 'More to be Mapped' gefunden: http://wiki.openstreetmap.org/index.php/Proposed_features/More_to_be_Mapped. Für Diskussion könnte es sorgen wenn man für den Status extra neue Areas anlegen muss die für die Karte keine Bedeutung haben. Bei Gebieten für die man ohnehin irgendwann Areas braucht (Dörfer, Stadtbezirke) sehe ich ansonsten keine Nachteile. Grungelborz ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] RFC: Statustabellen für München
Hallo, einige von euch haben schon die Statustabelle für den Landkreis München gesehen: http://wiki.openstreetmap.org/index.php/Landkreis_M%C3%BCnchen. Inzwischen wird sie auch in anderen Gebieten verwendet. Der Hauptgrund warum ich eine solche Tabelle wollte ist, daß man sieht wann München und Umgebung soweit vollständig ist, daß man die Karte für die allgemeine Verwendung empfehlen kann.Wenn man dass mit einer unvollständigen Karte macht schreckt man nur potentielle Benutzer ab. IMO ist eine Karte in diesem Sinn 'fertig' wenn sie für die Autonavigation taugt und i.w. alle Straßennamen da sind. Für München und Umgebung kann es durchaus sein, dass wir 2008 in diesem Sinne 'fertig' sind. Ansonsten kann die Tabelle natürlich noch als Fortschrittsanzeige und zur Koordinierung verwendet werden. Wenn jemand Kommentare dazu hat, bitte entweder hier posten oder auf die Diskussionsseite des Landkreises München: http://wiki.openstreetmap.org/index.php/Talk:Landkreis_M%C3%BCnchen. Insbesondere frage ich mich ob die aktuelle Bedeutung von 'Grün' so gut ist. Gruss, Grungelborz ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
