[Talk-de] Bedarf für Statistik bei OSM
Moin, ich treffe mich heute abend mit einem Statistiker der mir etwas über das Statistik Programmiersprache R [1] erzhählen möchte und von mir etwas zu OSM [2] lernen möchte. Daraus soll ein Vortrag zur nächsten Fossgis Konferenz werden. Hat jemand bedarf nach Statistiken zu OpenStreetMap oder eine Idee was man statistisch auswerten sollte? Gruß Sven [1] http://de.wikipedia.org/wiki/R_(Programmiersprache) [2] ;-) Den Artikel finde ich sehr umfassend: http://de.wikipedia.org/wiki/OpenStreetMap ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lonvia-Karte drucken?
On Wed, Nov 25, 2009 at 06:19:40PM +0100, Colin Marquardt wrote: > Am 25. November 2009 08:39 schrieb Sarah Hoffmann : > > On Wed, Nov 25, 2009 at 01:41:16AM +0100, Colin Marquardt wrote: > >> Am 24. November 2009 21:40 schrieb Colin Marquardt > >> : > >> > Idee waere jetzt, eine Art Gateway zu haben, welches die Tiles zu > >> > einem einzigen zusammenfasst und dann ausliefert. > >> > tilelite (http://bitbucket.org/springmeyer/tilelite/wiki/Home) koennte > >> > ein Startpunkt sein, das hat sogar schon Caching eingebaut. > >> > http://bitbucket.org/springmeyer/tilelite/src/tip/tilelite.py#cl-260 > >> > sieht wie eine passende Stelle aus, > >> > da macht es normalerweise mapnik.render() und kennt dort schon die > >> > Tilenamen, die angefordert werden. Unser Gateway muesste hier nur die > >> > interessierenden Tile-URLs kennen, PIL oder convert etc. auf die Tiles > >> > anwenden, und das Tile zurueckgeben. > > > > Für das Hiking-Overlay ist die Methode aber alles andere als optimal, > > eben weil viele Tiles gar nicht existieren. Es wäre also viel effizienter, > > vom Server ein Archiv mit Tiles in einem Bbox-Bereich herunterzuladen > > und das dann lokal weiterzuverarbeiten. Jetzt müsste nur noch jemand > > ein CGI-Script schreiben, dass solche Archive on-the-fly erstellt und > > ausliefert. > > *Nur* fuer das Hiking-Overlay vielleicht ja, aber wenn man eh noch > Hillshading oder Hoehenlinien reinmergen will, dann passt das schon > wieder. Nein, das Problem bleibt das selbe: der Massendownload erzeugt unnötige Serverlast, dann aber nicht nur auf einem Server, sondern auf vielen. Wenn man mehrere Layers mergen will, sollte man also mehrere solche Tile-Archive von verschiedenen Servern ziehen können und die dann lokal mergen. Es wäre schon interessant, soetwas auch für Mapnik-Tiles zu haben, eventuell auch mit einer Diff-Option, also der Möglichkeit, dass nur seit dem letzten Download neu gerenderten Tiles geliefert werden. Übrigens: für das Hillshading wäre so ein Archiv noch nützlicher: es würde ja völlig reichen, die entsprechnenden Tiles genau einmal herunter zu laden, da sie sich nie verändern. Gruss Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] layer=0
moin, das Wiki sagt auch: Description A raised bank to carry a road, railway, or canal across a low-lying or wet area. ich seh' da kein Problem, zumal das ja auch schon genutzt wird. Gruß Jörk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrthäufigkeit bei Buslinien
On Wed, Nov 25, 2009 at 10:14:25AM +0100, Stefan Popp wrote: > Martin Koppenhoefer schrieb: >> Gerade in Gegenden, wo der ÖPNV nicht nur gewährleistet werden muss, >> sondern sich die Frequenzen auch nach realem Verkehrsaufkommen richtet >> (also größere Städte), sind allerdings öfters auch die Takte zu >> Stoßzeiten (z.B. 7-9, 17-19h) dichter als in der übrigen Zeit. > Jetzt, wo du's erwähnst: Auch in meiner Gegend kann ich das brauchen, da > bestimmte Buslinien zu verkehrsschwachen Zeiten zusammengelegt werden > und dadurch bestimmte Bushaltestellen überhaupt nicht angefahren werden. > > Was evtl. auch brauchbar wäre, ist ein Tag, dass den Prozentsatz an > Niederflurfahrzeugen, oder Gelenk-/Doppelstockfahrzeugen angibt, z.B.: > >low_floor_vehicles = 50% (d.h. die Hälfte aller Fahrzeuge sind >Niederflurfahrzeuge, und deren Frequenz ist ungefähr halb so groß >wie die Gesamtfrequenz) >articulated_vehicles = ... (Gelenkfahrzeug, wie oben) >double_decker_vehicles = ... (Doppeldeckerfahrzug, w.o.) > > Alternativ könnten sich diese Tags auch wie das vorher beschriebene > frequency-Tag verhalten, frequency würde dann für /alle/ Fahrzeuge > gelten, auch die, die durch die drei obigen Tags abgedeckt sind, > low_floor, articulated, und double_decker könnten dann zur genaueren > Spezifizierung dienen. > > Über die Nötigkeit von articulated und double_decker kann man streiten, > vom Blickwinkel der Behindertengerechtheit wäre low_floor meiner Meinung > nach aber schon wichtig. > > Sarah Hoffmann schrieb: >> Wie das Variantenproblem gelöst werden kann, weiss ich auch nicht. >> Kleinere zu ignorieren, finde ich jedenfalls ok. > Vielleicht, indem man Teilrouten definiert, die über eine > "Meta-Relation" geordnet zusammengefasst sind? Die Frequenzen könnten in > den Teilrouten angegeben werden, die Frequenz einer "Meta-Relation" > ergäbe sich dann durch das Minimum der Teil-Relationen. Ein Beispiel von > um die Ecke (ich hoffe, die Leerzeichen werden nicht gefressen) > >.<-(D)-. .<-(C)-. >| \ | \ .--(B)--<>-. >|\ |\| \ >V \V \ |\ > > .>>+--<>---+-->-(E)-->+--<>--+--(F)--<>+---<>--(A)--<>---<>---[ZOB] > >Erläuterung: ><,^,V,>: Verkehr nur in Pfeilrichtung ><>:Vehrkehr in beide Richtungen >.,-Kante (nach Graphentheorie) >+ Knoten (nach Graphentheorie) >(X)Benennung einer Kante >[ZOB] Zentraler Omnibusbahnhof > > > Soviel zur Grafik, nun zu den Linien: > ZOB>A>B>C>E>B>A>ZOB: Im folgenden "Linie B" > ZOB>A>F>C>E>B>A>ZOB: Im folgenden "Linie F" > ZOB>A>B>C>D>E>B>A>ZOB: Im folgenden "Linie BD" > ZOB>A>F>C>D>E>B>A>ZOB: Im folgenden "Linie FD" > > Ich würde nun für A,B,...,F jeweils Teilrelationen aufstellen, und dort > die jeweiligen Frequenzen angeben: > Ach ja, alle Zeitintervalle verstehe ich in der Form [x,y], also x und y > sind Teil (Element) des Intervalls. IMHO schon zu kompliziert und schon sehr nahe daran, wirklich den Fahplan exakt abbilden zu wollen. > Kante B: > frequency:weekday_and_6h=1/hour//*Ob dieser Spezialfall > Aufnahmewürdig ist, wäre zu klären ;-) > frequency:weekday_and_8h-11h=1/hour > frequency:weekday_and_15h=2/hour //siehe * > frequency:weekday_and_18h=2/hour //siehe * > frequency:weekday_and_19h-22h=1/hour > frequency:weekday_and_default=none //Der Vollständigkeit halber, > default gibt alle Zeiten an, die nicht abgedeckt sind, hier also > wochentags 23h-5h,7h.12h-14h,16h-17h > > Kante F: > frequency:weekday_and_6h-8h=1.5/hour > frequency:weekday_and_12h-14h=1.5/hour > frequency:weekday_and_16h-17h=2/hour > frequency:weekday_and_default=none //Der Vollständigkeit halber. > > Kante D: > frequency:weekday_and_7h-18h=0.5/hour > frequency:weekday_and_default=none //Der Vollständigkeit halber. Ich würde da einfach zwei Busrouten einzeichnen, jeweils mit einer Variante um B und F und dann: Linie B/F: frequency=3/hour Linie BD/FD: frequency=two-hourly (Ich hoffe, dass ich die Zeiten jetzt richtig gedeuet habe.) Damit kann man zwar keine exakte Berechnung darüber machen, mit wieviel Wartezeit man an der Haltestelle zu rechnen hat, aber es ist völlig ausreichend, um den von dir erwähnten Überblick zu bekommen, welche Haltestelle vorzuziehen ist. (Zum Beispiel: C vor D, weil da mehr Linien in die gewünschte Richtung fahren. Oder, E vor B weil B als Variante mit Sicherheit seltener bedient wird.) > Für die Linien BD und FD, bestimmen wir nun die Minima für die einzelnen > Zeitintervalle, indem wir die Zeitintervalle passend zusammenfügen: > BD: (gemeinsames Intervall**; Intervall B & Intervall D **; Frequenz B & > Frequenz D; => gemeinsame Frequenz***) Das ist dann aber etwas, was man nicht mehr eben mal so im Kopf berechnet nach einem Bli
Re: [Talk-de] layer=0
Carsten Gerlach schrieb: Am Mittwoch 25. November 2009 21:28:00 schrieb Rainer Knaepper: Es gibt hier in der Nähe einen Radweg, der auf einem ehemaligen *Bahndamm* verläuft. Das wäre dann doch eher was für http://wiki.openstreetmap.org/wiki/Key:embankment, oder? Korrigiert mich (und das Wiki) wenn ich falsch liege, aber ist ein Embankment nicht ein reiner Flutdamm? Gerade ein Bahndamm kann aber auch nur zur Herstellung einer ebenen Trasse vorhanden sein, weitab von jeglichem Gewässer. Das Wiki sagt: An embankment is an artificial bank raised above the immediately-surrounding land *to redirect or prevent flooding by a river, lake or sea.* Eine Frage noch nebenbei, da ich recht neu in der Mailing-List bin: Ist es in Ordnung, Zitate in Englisch ohne Übersetzung anzugeben? Schließlich sind wir ja in talk-de, und nicht jeder kann Englisch. lg, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bringdienste, wie taggen?
Johann H. Addicks schrieb: > > Es gibt an jedem Ort in Deutschland ein sogenanntes "Wassertaxi", > welches rund um die Uhr "open" ist und die Anfahrt nur dann in Rechnung > stellt, wenn man keine Ware abnimmt. Der Telefonische Sammelruf ist > übrigens "112" > > -jha- Ich muss zugeben, ich musste das jetzt dreimal lesen, bis ich verstand, was du Scherzkeks meintest. Willst du uns damit sagen, dass wir noch ein Tag wie delivery:contact_telephone=* brauchen? :-) Übrigens liefern die nicht nur Wasser, sondern auch medizinische "Unterstützung", das wirft dann die Frage auf, wie und wo man lokale Notrufnummern erfassen könnte. Zumindest hier in der Gegend ist der (Kranken-)Notruf auch unter einer örtlichen Telefonnummer zu erreichen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fernsehbericht bei "planet wissen"
Wie sieht das rechtlich aus? Archivieren ja, Verbreiten??? Stefan Markus schrieb: > Wer kann das bitte in HD-Qualität aufzeichnen? > > Denn solche Bilder sagen mehr als 1000 Worte. > Wir sollten solch wertvolles Material archivieren. > ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fernsehbericht bei "planet wissen"
Hallo, ich habe zwar die Sendung aufgezeichnet, die Qualität ist aber nicht besonders gut. Stefan Tirkon schrieb: > Leider war gemäß meinem > http://tvbrowser.org/de/ueber-mainmenu-16.html > die letzte Wiederholung schon zum Zweitpunkt des Postings im Gange. > ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fernsehbericht bei "planet wissen"
Wer kann das bitte in HD-Qualität aufzeichnen? Denn solche Bilder sagen mehr als 1000 Worte. Wir sollten solch wertvolles Material archivieren. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bringdienste, wie taggen?
Andre Hinrichs schrieb: > delivery:opening_hours=* > delivery:min_cost=* Es gibt an jedem Ort in Deutschland ein sogenanntes "Wassertaxi", welches rund um die Uhr "open" ist und die Anfahrt nur dann in Rechnung stellt, wenn man keine Ware abnimmt. Der Telefonische Sammelruf ist übrigens "112" -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fernsehbericht bei "planet wissen"
"Stefan Dettenhofer (StefanDausR)" wrote: >gestern kam auf BR-alpha die "Planet Wissen"-Sendung "Die Geheimnisse >der Landkarten", in der auch OpenStreetMap vorgestellt wurde. >Kai Behnke und Frederik Ramm wirken auch mit. >http://www.planet-wissen.de/sendungen/2009/11/24_landkarten.jsp >In den dritten Programmen wird die Sendung wiederholt. Leider war gemäß meinem http://tvbrowser.org/de/ueber-mainmenu-16.html die letzte Wiederholung schon zum Zweitpunkt des Postings im Gange. Demgemäß beinhalten alle zukünftigen Sendungen von "Planet Wissen" andere Episoden. Allerdings wird bei einigen Ankündigungen nicht genannt, welche Episode gezeigt werden wird. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen besser als Tags?
Martin Koppenhoefer schrieb: > Ich plaediere fuer den Ansatz, die Spuren und divider separat zu mappen, und > dann ueber Relationen die Verbindung bzw. den Bezug herzustellen (z.B. auch, > wenn es eine trennende Mauer ist, aber auch, um bei parallelen Spuren eine > unterbrochene oder durchgezogene Linie abzubilden). Der vom Gehalt her zentrale Unterschied zwischen den Ansätzen besteht in der Lageinformation der Spuren: Die Erfassung als eigene Ways führt zu einer absoluten, die Erfassung über Tags oder Relationen zu einer lediglich relativen Positionierung. Allerdings kann man die absolute Positionierung bei einem Relationsansatz recht einfach nachrüsten: Mit einem Way (oder gar einer Area) als Member in der Relation kann die entsprechende Information zusätzlich eingebunden werden. Mit einem solchen Ansatz kann man also entweder nur relative oder auch absolute Lageangaben machen. Das Resultat wäre sogar der Way-basierten Erfassung recht ähnlich: durch Relationen verbundene Ways, zwischen denen man natürlich nach Belieben auch ein absolut positioniertes Straßenschild aufstellen könnte. Nur: Die absolute Positionierung wäre eine inhärent optionale Information. Diese Wahl hat man bei einem von vornherein auf Ways setzenden Konzept nicht: Hier muss man immer absolute Lageangaben bereitstellen, was zwangsläufig die bereits genannte "Pseudoinformation" produziert. Ich weiß nicht, ob ich hier repräsentativ bin, aber mir ist eine absolute Spurplatzierung den Erfassungsaufwand nicht wert. Was ich ausdrücken möchte, ist: "Fahrbahn hat zwei Spuren, getrennt von durchgezogener Linie. Links daneben verläuft ein Radweg, daneben von einem Bordstein getrennt ein Gehsteig" - also ausschließlich relative Angaben. > Neben der erhoehten Lagegenauigkeit sehe ich dabei auch einen Vorteil in der > unmittelbaren Abbildung der Realitaet (einfacher fuer den Mapper), und auch > ohne extreme Erweiterung der Tools ist das Resultat besser nachvollziehbar > und optisch ueberpruefbar. Meiner Ansicht nach ist letztlich kein Ansatz für die Spurerfassung ohne Tools handhabbar. Die Anlage und Anpassung von Relationen zur Verbindung von Spur-Ways ist ebenfalls viel zu aufwendig, als dass sie bei einem großflächigen Einsatz des Schemas von Hand erfolgen könnte. Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen besser als Tags?
Am 25. November 2009 15:36 schrieb qbert biker : > Was jedenfalls nicht in die DB gehoert, > sind nachgemalte Fehler der Trackaufzeichnung oder > Fehlinterpretationen wegen mangelnder Aufloesung der > Luftbilder. > > ja, da sind wir uns schon wieder einig. Fehler wollen wir nicht :D > Deshalb finde ich auch den vorgestellten Ansatz mit > dem Plugin so gut, denn der erweitert nicht die Anzahl der > Mapper, sondern deren Faehigkeiten, komplexer einzutragen. > > ach so? Na meine Fähigkeiten erweitern habe ich auch nichts dagegen, mir kam das zunächst so vor, als würde es die Anforderungen an den Mapper und die Tools deutlich erhöhen. > Wenn sie einen unabhaengigen Verlauf haben, gibts einen > eigenen way, da gabs ja nie Differenzen. Nur haben wir > offensichtlich unterschiedliche Vorstellungen, wann ein > Weg geometrisch fix mit einem anderen gekoppelt ist. > ja, sieht so aus. > Die klassische Abbiegespur ists jedenfalls und die > typischen Parallelwege in Wohngebieten auch. in typischen Wohngebieten, oder? > Na ja, lassen wirs auf den Vergleich ankommen. Du zeigst > mir einen ausgearbeiteten Entwurf mit dem man die > Einzelways mit all ihren Abhaengigkeiten in den Griff > bekommt und wie komplex das ist habe das schonmal etwas ausführlicher im Archiv nachlesbar beschrieben, konkret werde ich demnächst mal im Wiki einen Vorschlag machen. Ist ja schnell gemacht, da es wirklich einfach ist, und im Grunde dasselbe, was wir schon ewig machen, auf Spuren ausdehnt. Die barriers, die wir auch schon haben, integrieren sich da bestens. > und ich versuch mich weiter > an der querschnittsorientierten geometrischen Abbildung > nach dem hier vorgestellten Schema. Dann wird man ja > sehen, was besser rueberkommt. > ja. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] SVG to PDF
Am 25. November 2009 15:44 schrieb Mirko Küster : > > ja, aber halt weder verlustfrei, noch skalierbar. > > Deswegen musst du das denen auch nach Maß anliefern. 300 dpi ist die Regel. > > > das stimmt nicht, natürlich gehen Transparenzen, und auch Vektoren im > PDF, Du musst es nur richtig einstellen. > > Vektoren natürlich ja, Transparenzen bietet der Distiller im Standardformat > nicht an. Wo hast du denn eine entsprechende Einstellung gesichtet? > > eben gerade nicht im Distiller, im PDF-Writer. Der Distiller macht Dir (soweit ich weiss, die neueren Versionen machen diese Unterscheidung glaub ich gar nicht mehr) ein Bitmap, das er in ein PDF einbindet, genau das, was nicht gefragt ist. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] layer=0
> Das kann unter Umständen trotzdem interessant sein. Es gibt hier in > der Nähe einen Radweg, der auf einem ehemaligen Bahndamm verläuft. Dann käme da noch zusätzlich für interessierte ein railway=abandoned dazu und für den Damm haben wir zusätzlich embankment. > ...um auf den Radweg zu gelangen, weil wir keine Lust > hatten, den anderen Weg wieder zurückzuradeln. Deswegen erfassen wir ja, damit der nächste bescheid weiß, dass dort keine Verbindung besteht und eben nicht unwissend den Damm hochklettern muss. Auch da bedarf es keinerlei Layer. Paralele Wege auf unterschiedlichen Höhen findet man überall. Interessiert aber an der Stelle ohne direkte Verbindung nicht. Layer sind keine Höhenangaben sondernt schlicht eine Schichtangabe für eine Sortierung von sich auf unterschiedlichen Niveau kreuzenden Objekten. +1 Brücke über Straße, -1 Tunnel unter Straße oder eben auch +2 Bücke über +1 Brücke über Straße. Straße auf Boden ist default immer 0. In dem Fall wäre Rad- und Feldweg auch beides 0, auch wenn sich beides an einem 100 m hohen Steilhang befinden würde und dennoch zweidimensional optisch nebeneinander liegt. Layer sind kein simpler Ersatz für Multipolygone, Höhenangaben oder was auch immer. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] layer=0
Am Mittwoch 25. November 2009 21:28:00 schrieb Rainer Knaepper: > Das kann unter Umständen trotzdem interessant sein. Es gibt hier in > der Nähe einen Radweg, der auf einem ehemaligen Bahndamm verläuft. > Unmittelbar daneben und parallel dazu existiert an einer Stelle ein > Feldweg (frei für Landwirtschaft und Reiter), nur liegt der mindestens > vier Meter niedriger. Das wäre dann doch eher was für http://wiki.openstreetmap.org/wiki/Key:embankment, oder? Gruß, Carsten -- Hier ist mein öffentlicher GPG-Schlüssel: http://daswaldhorn.funpic.de/gpg.html = www.stopptdievorratsdatenspeicherung.de 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] Fahrthäufigkeit bei Buslinien
Stefan Popp schrieb: > Was evtl. auch brauchbar wäre, ist ein Tag, dass den Prozentsatz an > Niederflurfahrzeugen, oder Gelenk-/Doppelstockfahrzeugen angibt, z.B.: > Über die Nötigkeit von articulated und double_decker kann man streiten, > vom Blickwinkel der Behindertengerechtheit wäre low_floor meiner Meinung > nach aber schon wichtig. Einfacher zu erfassen und mindestens eben so wichtig wäre m.E. die Erfassung der Haltestellen- und Bordsteinform. Sprich ob es sich um eine Busbucht oder eine Fahrbahn- bzw. Kap-Haltestelle handelt. Die Bucht kann man normalerweise nicht so anfahren das die hintere Türe am Bordstein steht. Ich hab mir so beholfen das ich Haltestellen mit Flachbord als wheelchair=no, Haltestellen mit Hochbord mit wheelchair=yes und Haltestellen mit normalem Bord ohne Ausführungen zur Rollstuhltauglichkeit getaggt habe. > frequency:weekday_and_6h=1/hour//*Ob dieser Spezialfall In Aachen haben wir in den hauptrichtungen viele seltener verkehrende Linien zusammen ein Linienbündel mit dichtem Takt ergeben. So etwas ist schwierig rauszulesen. > frequency:weekday_and_7h-18h=0.5/hour Wenn ein Zug 4 Stunden unterwegs ist bringt die Angabe der Start- und Endzeit relativ wenig. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] layer=0
Moin Martin, >> Ein fehlendes Layertag kann auch bedeuten "Ist eine Hochstraße auf >> eine Erdwall, aber das hat bislang nur noch niemand explizit >> gemapt, muss noch geprüft werden". >> >Die kann ja trotzdem layer=0 (und damit default) sein, oder habe ich >da was verpasst? Bisher war ich davon ausgegangen, dass die Layer >relative nicht absolute Hoehenangaben sind. Das kann unter Umständen trotzdem interessant sein. Es gibt hier in der Nähe einen Radweg, der auf einem ehemaligen Bahndamm verläuft. Unmittelbar daneben und parallel dazu existiert an einer Stelle ein Feldweg (frei für Landwirtschaft und Reiter), nur liegt der mindestens vier Meter niedriger. In der Karte sieht das nicht anders aus als ein üblicher straßenbegleitender Radweg. Auf unserer Mapping-Radtour haben wir die Räder an der Stelle, wo der Feldweg dann endete, jeweils zu zweit die Böschung hochgewuchtet (und, nein, keinen Fußpfad dort gemapt :-)), um auf den Radweg zu gelangen, weil wir keine Lust hatten, den anderen Weg wieder zurückzuradeln. http://www.openstreetmap.org/?lat=51.56023&lon=7.72537&zoom=17&layers=0B00FTF Rainer -- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Richtung von Relationen
Moin ! ich beschäftige mich gerade ausgiebig mit den Bedarfsumleitungen [1] und da ist die Richtung ziemlich wichtig. Irgendwie habe ich nicht richtig etwas darüber gefunden - kann mir einer weiterhelfen? Ist es tatsächlich die Reihenfolge der Way-Abschnitte?? Gruß Jan :-) [1] http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Bedarfsumleitung ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zum Datenabruf unter XAPI
Und ich nutze die XAPI zum Finden der Bundesstrassen, Autobahnen und Landesstrassen für den Import der TMC-Codes. Ich hoffe mal bis zum 26C3 die wichtigsten Bundesstrassen und Autobahnen drin zu haben und manuell die Autobahn-Kreuze und Segmente um Berlin rum schonmal getagged zu haben. Marcus 2009/11/25 Jan Tappenbeck : > HI ! > > das würde mich auch brennt für die Postkästen interessieren ?? > > Gruß jan :-) > > Markus schrieb: >> Hallo Carsten, >> >>> Schau mal hier: http://wiki.openstreetmap.org/wiki/Platform_Status >> >> Gab es da nicht mal im Zusammenhang mit den neuen Strato-Servern >> konkrete Pläne zu einer "europäischen" XAPI? >> >> Wie ist da der aktuelle Stand? >> >> Gruss, Markus > > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-de > ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Widemann System Hamburg
Moin ! ich beschäftige mich gerade ausgiebig mit den Bedarfsumleitungen [1] und da ist die Richtung ziemlich wichtig. Irgendwie habe ich nicht richtig etwas darüber gefunden - kann mir einer weiterhelfen? Ist es tatsächlich die Reihenfolge der Way-Abschnitte?? Gruß Jan :-) [1] http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Bedarfsumleitung ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] 1. BA Ortsumgehung Bad Bramstedt
Moin ! ich habe kürzlich gelesen, dass der 1.BA der Ortsumgehung Bad Bramstedt dem Verkehr übergeben wurde [1] - vielleicht ist ja mal einer auf der Ecke. [1] http://www.schleswig-holstein.de/MWV/DE/Service/Presse/PI/2009/091106OU__BadBramstedt.html Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zum Datenabruf unter XAPI
HI ! das würde mich auch brennt für die Postkästen interessieren ?? Gruß jan :-) Markus schrieb: > Hallo Carsten, > >> Schau mal hier: http://wiki.openstreetmap.org/wiki/Platform_Status > > Gab es da nicht mal im Zusammenhang mit den neuen Strato-Servern > konkrete Pläne zu einer "europäischen" XAPI? > > Wie ist da der aktuelle Stand? > > Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fernsehbericht bei "planet wissen"
Hallo, Stefan Dettenhofer (StefanDausR) wrote: > gestern kam auf BR-alpha die "Planet Wissen"-Sendung "Die Geheimnisse > der Landkarten", in der auch OpenStreetMap vorgestellt wurde. > Kai Behnke und Frederik Ramm wirken auch mit. > http://www.planet-wissen.de/sendungen/2009/11/24_landkarten.jsp Lustig, das ist ein Beitrag, den sie fuer 3sat "nano" gedreht haben, das war im Sommer 2008, ich kam gerade von der SOTM in Irland zurueck. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Video
Am 25. November 2009 07:39 schrieb Markus : >> ich stehe ziemlich auf die ito-Videos. >> http://www.youtube.com/watch?v=0-z9AM7KOJc >> http://www.youtube.com/watch?v=Vx3dTBtGwWs&feature=related > > Ja, die gefallen mir auch sehr gut. > Zeigen beeindruckend die rasante Entwicklung von OSM. * > > Hat jemand diese Videos in HD-Qualität? Mit einem vimeo-(Fake-)Account kann man die in HD runterladen. Cheers Colin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lonvia-Karte drucken?
Am 25. November 2009 08:39 schrieb Sarah Hoffmann : > On Wed, Nov 25, 2009 at 01:41:16AM +0100, Colin Marquardt wrote: >> Am 24. November 2009 21:40 schrieb Colin Marquardt : >> > Idee waere jetzt, eine Art Gateway zu haben, welches die Tiles zu >> > einem einzigen zusammenfasst und dann ausliefert. >> > tilelite (http://bitbucket.org/springmeyer/tilelite/wiki/Home) koennte >> > ein Startpunkt sein, das hat sogar schon Caching eingebaut. >> > http://bitbucket.org/springmeyer/tilelite/src/tip/tilelite.py#cl-260 >> > sieht wie eine passende Stelle aus, >> > da macht es normalerweise mapnik.render() und kennt dort schon die >> > Tilenamen, die angefordert werden. Unser Gateway muesste hier nur die >> > interessierenden Tile-URLs kennen, PIL oder convert etc. auf die Tiles >> > anwenden, und das Tile zurueckgeben. > > Für das Hiking-Overlay ist die Methode aber alles andere als optimal, > eben weil viele Tiles gar nicht existieren. Es wäre also viel effizienter, > vom Server ein Archiv mit Tiles in einem Bbox-Bereich herunterzuladen > und das dann lokal weiterzuverarbeiten. Jetzt müsste nur noch jemand > ein CGI-Script schreiben, dass solche Archive on-the-fly erstellt und > ausliefert. *Nur* fuer das Hiking-Overlay vielleicht ja, aber wenn man eh noch Hillshading oder Hoehenlinien reinmergen will, dann passt das schon wieder. Danes Script ist jetzt uebrigens in http://mapnik-utils.googlecode.com/svn/sandbox/tileblender/ Cheers Colin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] SVG to PDF
> ja, aber halt weder verlustfrei, noch skalierbar. Deswegen musst du das denen auch nach Maß anliefern. 300 dpi ist die Regel. > das stimmt nicht, natürlich gehen Transparenzen, und auch Vektoren im PDF, Du > musst es nur richtig einstellen. Vektoren natürlich ja, Transparenzen bietet der Distiller im Standardformat nicht an. Wo hast du denn eine entsprechende Einstellung gesichtet? > meine Erfahrung ist genau anders rum: die Copyshops erwarten meist ein RGB > und haben ihre Maschinen so kalibriert, dass das CMYK in der Maschine > "optimal" gewandelt wird. Zumindest behaupten sie das. Wenns Dir um absolute > Farbtreue geht, kommst Du sowieso um Pantone nicht herum. Ich sprach von Druckereien und nicht von irgendwelchen Kopierklitschen. Bei ersten hat so ziemlich jede eigene Vorlieben, schicken dir oft auch eigene Presets für den Distiller. Da ist oft nicht die Frage was geht sondern wie man es gerne hätte. Es gibt aber auch gute die dann nochmal selbst an der Maschine nacharbeiten, andere zicken schon bei fehlendem Anschnitt herum und nehmen nicht an. Das Standardpreset funktioniert aber bei so ziemlich jeder. CMYK in ocated v2 reicht. Copyshop ist wieder etwas völlig anderes. Mit denen hatte ich bisher noch nicht zu tun und weiß nicht was die machen. Ich habe bisher nur für Auflagen von über 5000 inklusive Pressung als Komplettpaket für den Handel gearbeitet, nichts für Copyshops. Gruß Mirko___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bringdienste, wie taggen?
Andre Hinrichs schrieb: >> Ich zaehle 39, davon sind 27 aber ways mit "delivery=yes" (was wohl >> heissen soll: Lieferverkehr frei). 11 weitere sind italienische >> Restaurants oder Pizza-Bringdienste (amenity=restaurant oder >> amenity=fast_food, cusine=italian), und eins ist ein "Video-Taxi" >> (shop=video). > > Hmm, die Situation gefällt mir eigentlich nicht so sehr, wenn ein > tag-value-Paar verschiedene Bedeutungen haben kann. Gibt es da nicht > eine geschicktere Lösung? Für Zugangsrechte das dokumentierte access=delivery (oder =delivery) statt delivery=yes verwenden? Haben wir auch schon öfters (ca. 200 access=delivery, 100 hgv=delivery, je einige Dutzend vehicle/motor_vehicle/goods/...=delivery). Das heißt natürlich nicht, dass man nicht *auch* für "hat Lieferservice" eine Alternative wie delivering=yes einsetzen kann. Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen besser als Tags?
Original-Nachricht > Datum: Wed, 25 Nov 2009 13:05:17 +0100 > Von: Martin Koppenhoefer > An: talk-de@openstreetmap.org > Betreff: Re: [Talk-de] Relationen besser als Tags? > ja, und aus den Luftbildern und vor allem auch aus der Kenntnis der > Situation. Wenn ich weiss, dass der Schlenker an der Telefonzelle ist, > dann > mache ich ihn dort auch hin. Willst Du das nicht? Was ich will, spielt mal die allerkleinste Rolle und Luftbilder in der noetigen Aufloesung sind nur selten verfuegbar. Was jedenfalls nicht in die DB gehoert, sind nachgemalte Fehler der Trackaufzeichnung oder Fehlinterpretationen wegen mangelnder Aufloesung der Luftbilder. > ja, da sind wir uns ja einig. Daher würde ich darauf ja auch nicht > verzichten wollen. Genau darum geht es hier ja. Niemand will auf das Element der Linie verzichten, die einen Verlauf beschreibt. In der Diskussion steht ja nur, ob eine Linie mehr als nur einen Verlauf beschreiben kann. > wie gesagt, das wird jemand auch wieder richten. (crowd) Die Crowd ist erstmal nur ein Synonym fuer 'viele werkeln dran' mit allen Vor- und Nachteilen. Die Crowd ist kein Wunderding. > denke ich nicht. Es werden vor allem jede Sekunde mehr ;-). Masse alleine machts nicht, besonders wenn die Masse ueber Datenmodell und Werkzeugen in ihren Moeglichkeiten limitiert ist. Deshalb finde ich auch den vorgestellten Ansatz mit dem Plugin so gut, denn der erweitert nicht die Anzahl der Mapper, sondern deren Faehigkeiten, komplexer einzutragen. > Wenn es um einzelne Wege geht (gern als "straßenbegleitend" beschrieben, > aber in der Realität eben einfach in der Nähe einer Straße gelegene > unabhängige Wege mit eigenen Eigenschaften, Regeln, Verlauf im Detail, > Lage, > etc.), bin ich für eine Abbildung wie gehabt: zeichnen und taggen. Man > kann > so z.B. auch Kreuzungsmöglichkeiten genauer definieren, etc. (s.o., > eigentlich habe ich ja alles schon wiederholt geschrieben). Wenn sie einen unabhaengigen Verlauf haben, gibts einen eigenen way, da gabs ja nie Differenzen. Nur haben wir offensichtlich unterschiedliche Vorstellungen, wann ein Weg geometrisch fix mit einem anderen gekoppelt ist. Die klassische Abbiegespur ists jedenfalls und die typischen Parallelwege in Wohngebieten auch. Wenn ich daheim aus dem Fenster schaue, gibts eindeutige parallele Verlaeufe. Na ja, lassen wirs auf den Vergleich ankommen. Du zeigst mir einen ausgearbeiteten Entwurf mit dem man die Einzelways mit all ihren Abhaengigkeiten in den Griff bekommt und wie komplex das ist und ich versuch mich weiter an der querschnittsorientierten geometrischen Abbildung nach dem hier vorgestellten Schema. Dann wird man ja sehen, was besser rueberkommt. Gruesse Hubert -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM @ 26C3 ?
On Wed, 25 Nov 2009 13:56:19 +0100, Markus wrote: > Hallo Marcus, > > Im Wiki finde ich "Things presented": > > * routing on the OpenStreetMap > * map-editing using your mobile phone > * TMC decoding and traffic-announcements on OpenStreetMap > * special maps for special purposes > > In welcher Form präsentierst Du das? Mit einem Laptop jedem der fragt. Das ist ein Info-Tisch mitten auf dem Flur zwischen anderen Tischen. Kein Vortrag. > Vielleicht könntest Du daraus ein Video machen? > Das wir im Januar für die "boot" nutzen könnten? > > Ideal wäre zu jedem Thema ein Kurzvideo... > mit deutscher Tonspur. Nein, kann ich nicht. Hab keine Kamera, keinen Hintergrund und von Video-Schneiden und Vertonen keinen Schimmer. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] SVG to PDF
Am 25. November 2009 14:52 schrieb Mirko Küster : > > Das ist in der Form ein universelles Standardformat, was jede Druckerei > ohne mucken nimmt. > ja, aber halt weder verlustfrei, noch skalierbar. > > In PDF gedruckt wird das egal mit welchem Ausgangsformat so aussehen, > Transparenzen kannst du da garnicht extra behandeln. > das stimmt nicht, natürlich gehen Transparenzen, und auch Vektoren im PDF, Du musst es nur richtig einstellen. > Wichtig ist auch das alles in CMYK vorliegt. Bei RGB sind wieder einige zu > faul zum umwandeln und nehmen es nicht an. > meine Erfahrung ist genau anders rum: die Copyshops erwarten meist ein RGB und haben ihre Maschinen so kalibriert, dass das CMYK in der Maschine "optimal" gewandelt wird. Zumindest behaupten sie das. Wenns Dir um absolute Farbtreue geht, kommst Du sowieso um Pantone nicht herum. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] SVG to PDF
> auch ein jpg, daher geht das auch mit der Transparenz nicht (jpg kann keine > Transparenzen, man müsste dann den Alphakanal separat speichern). Mach es > lieber wie Frederik geschrieben hat: ein sauberes PNG in ordentlicher > Auflösung. Das ist in der Form ein universelles Standardformat, was jede Druckerei ohne mucken nimmt. In PDF gedruckt wird das egal mit welchem Ausgangsformat so aussehen, Transparenzen kannst du da garnicht extra behandeln. Wenn es die unbedingt braucht, muss das wie mit der Druckerei ausgekaspert werden. Hatte ich bisher noch nicht und weiß keine universelle Lösung. Ich mache normal nur Handbücher, Inlays und Labelfilme, brauchts da nicht. Wichtig ist auch das alles in CMYK vorliegt. Bei RGB sind wieder einige zu faul zum umwandeln und nehmen es nicht an. Für einige Medien brauchts auch volle Sättigung auf allen Kanälen, beispielsweise bei Labelfilmen. Zu den überflüssigen Vektoren und Bitmaps sage ich jetzt mal nichts. ;-) Gruß Mirko___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Fernsehbericht bei "planet wissen"
Hallo zusammen, gestern kam auf BR-alpha die "Planet Wissen"-Sendung "Die Geheimnisse der Landkarten", in der auch OpenStreetMap vorgestellt wurde. Kai Behnke und Frederik Ramm wirken auch mit. http://www.planet-wissen.de/sendungen/2009/11/24_landkarten.jsp In den dritten Programmen wird die Sendung wiederholt. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorgaerten und private Wohngebiete
On Wed, Nov 25, 2009 at 02:18:17PM +0100, Chris-Hein Lunkhusen wrote: > Die Straßen in dem Wohngebiet sind hoffentlich nicht mit access=private > markiert? ORS stört sich zwar nicht dran, aber in meiner Garmin Karte > route ich da nicht drüber. > > Ich tagge access=private an diejenigen Straßen/Gebiete wo ein > entsprechendes Schild steht. Und auch das ist nur richtig wenn das ein "Gesperrt" schild steht d.h. Zeichen 250 ff. Wenn das "Privatweg" steht - heisst das nichts - IMHO das ist ein Haftungsauschluss keine Nutzungsregelung. Flo -- Florian Lohoff f...@rfc822.org "Es ist ein grobes Missverständnis und eine Fehlwahrnehmung, dem Staat im Internet Zensur- und Überwachungsabsichten zu unterstellen." - - Bundesminister Dr. Wolfgang Schäuble -- 10. Juli in Berlin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorgaerten und private Wohngebiete
Torsten Leistikow schrieb: > - Wohngebiete und aehnliches sind mit access=private markiert. Das ist fuer > mich > eigentlich selbstverstaendlich und muss da nicht extra drangeschrieben werden. > Ich wuesste keinen Fall, wo das anders waere. Auf der anderen Seite macht eine > inflationaere Nutzung der Access-Tags es schwere die wirklich signifikanten > Faelle zu erkennen (z.B. bei Waldgebieten, die entgegen der Norm nicht > betreten > werden duerfen). +1 Die Straßen in dem Wohngebiet sind hoffentlich nicht mit access=private markiert? ORS stört sich zwar nicht dran, aber in meiner Garmin Karte route ich da nicht drüber. Ich tagge access=private an diejenigen Straßen/Gebiete wo ein entsprechendes Schild steht. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM @ 26C3 ?
> Ich habe schon vor über einem halben Jahr Flug und Hotel gebucht. Ich > bin auf jeden Fall vom ersten bis zum letzten Tag des 26C3 am > Start.Mitarbeiten würde ich auch - aber nicht wenn gerade ein Vortrag > läuft; von denen will ich möglichst viele hören. > Hallo, ich wohne im Norden von Berlin und könnte Übernachtungsplätze anbieten. Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM @ 26C3 ?
Hallo Marcus, Im Wiki finde ich "Things presented": * routing on the OpenStreetMap * map-editing using your mobile phone * TMC decoding and traffic-announcements on OpenStreetMap * special maps for special purposes In welcher Form präsentierst Du das? Vielleicht könntest Du daraus ein Video machen? Das wir im Januar für die "boot" nutzen könnten? Ideal wäre zu jedem Thema ein Kurzvideo... mit deutscher Tonspur. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM @ 26C3 ?
On Wed, 25 Nov 2009 13:14:47 +0100, Hartmut Holzgraefe wrote: > marcus.wolsc...@googlemail.com wrote: > >> > URL? >> >> Das Wiki zum 26C3 findet doch nun wirklich jede beliebige Suchmaschine. >> >> http://events.ccc.de/congress/2009/wiki/index.php/OpenStreetMap > > "The burden shall be on the writer, not the readers ..." ;) "It was hard to write, it should be hard to read." ;) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM @ 26C3 ?
marcus.wolsc...@googlemail.com wrote: > > URL? > > Das Wiki zum 26C3 findet doch nun wirklich jede beliebige Suchmaschine. > > http://events.ccc.de/congress/2009/wiki/index.php/OpenStreetMap "The burden shall be on the writer, not the readers ..." ;) -- hartmut ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen besser als Tags?
Am 25. November 2009 09:22 schrieb qbert biker : Man muss schon > sehr gut sein, um beim haendischen Reimmalen von Einzelspuren > die urspruengliche konstruktive Basislinie zu erhalten, die > dem ganzen das Gesicht gibt. > > so gut sind wir :D > Willst du tatsaechlich in den > Strassenschluchten der Stadt kleinste Schlenker im Fahrradweg > aus den GPS-Daten herausfiltern? > > ja, und aus den Luftbildern und vor allem auch aus der Kenntnis der Situation. Wenn ich weiss, dass der Schlenker an der Telefonzelle ist, dann mache ich ihn dort auch hin. Willst Du das nicht? > Der way ist und bleibt die unverzichtbare Basis, die der > Konstrukeur der Strasse mal angelegt hat. ja, da sind wir uns ja einig. Daher würde ich darauf ja auch nicht verzichten wollen. Genau darum geht es hier ja. > Entspechend > krumm und schief siehts mancherorts aus. wie gesagt, das wird jemand auch wieder richten. (crowd) > Um die Mitte einer > Strasse auch nur mittelmaessig genau aus tracks bestimmen > zu koennen, muss man sie mindestens in jede Richtung einmal > abgefahren haben und ueber beide tracks sauber mitteln. Das > wird wohl nur auf einen kleinen Teil der gemappten Strassen > zutreffen. > > denke ich nicht. Es werden vor allem jede Sekunde mehr ;-). Mit einigen/etlichen Tracks und Luftbild geht es jedenfalls. Ich glaube ausserdem auch daran, dass wir zumindest teilweise bessere Luftbilder bekommen werden, und dass es Leute gibt, die eine Straße auch mal klassisch aufmessen. Auch eine Freigabe von Katasterdaten / offiziellen Vermessungsplänen in Zukunft halte ich nicht für ausgeschlossen, Bebauungspläne kann man jetzt schon nutzen. > Die Einbeziehung von geometrischen Tatsachen kann das Mapping > verbessern und da gehoeren Bezugssysteme wie das vorgeschlagene > dazu. Davon bin ich wiederum so ueberzeugt wie du von deiner > Einzelspurabbildung. > Wenn es um einzelne Wege geht (gern als "straßenbegleitend" beschrieben, aber in der Realität eben einfach in der Nähe einer Straße gelegene unabhängige Wege mit eigenen Eigenschaften, Regeln, Verlauf im Detail, Lage, etc.), bin ich für eine Abbildung wie gehabt: zeichnen und taggen. Man kann so z.B. auch Kreuzungsmöglichkeiten genauer definieren, etc. (s.o., eigentlich habe ich ja alles schon wiederholt geschrieben). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorgaerten und private Wohngebiete
Am 24. November 2009 17:41 schrieb Torsten Leistikow : > > - Selbst kleinste Vorgaerten und Hinterhoefe werden als leisure=garden > eingetragen. Ich habe das Tag bisher nur fuer signifikante Gaerten > verwendet > z.B. bei Herrenhaeusern. Solche Wohngebiete haette ich einfach als > landuse=residential markiert, ohne da weiter unterscheiden zu wollen. > ich sehe bisher leisure=garden auch eher als Privatpark an, im Sinne von größeren Grünanlagen von Villen, Herrenhäusern und Schlössern, wobei ich es durchaus nicht für übertrieben halte, auch auf Privatgrundstücken zwischen versiegelten Flächen (z.B. Höfen und Terrassen) und Gärten/Wiese und Blumenbeeten zu unterscheiden. Das Wiki schreibt allerdings: "Place where flowers and other plants are grown in a decorative and structured manner or for scientific purposes.", von daher wäre der Tag m.E. nicht grundsätzlich falsch, und bei Privatgärten ist daher auch access=private nicht nur angebracht, sondern quasi notwendig. Problem: was macht man mit naturnahen/naturbelassenen "Ökogärten"? (andere würde evtl. sagen: verwildert und ungepflegt) ;-) die sind ja absichtlich weder dekorativ noch strukturiert, aber eben auch nicht disused=yes oder abandoned=yes. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorgaerten und private Wohngebiete
Am 24. November 2009 20:56 schrieb Ulf Möller : > Torsten Leistikow schrieb: > > > Wie seht ihr die Sachen? > > So wie du. > > access=private würde ich bei Gated Communities o.ä. setzen, aber nicht > bei normalen Wohngebieten. > ich halte es auch für _falsch_, access=private an Wohngebiete zu setzen, solange diese auch die Straßen und anderen öffentlichen Flächen beinhalten. Wenn es sich dagegen nur um reine Privatgrundstücke handelt (also grundstücksscharf gemappt ist), halte ich es für sinnvoll. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM @ 26C3 ?
On Wed, 25 Nov 2009 08:56:00 +0100, Hartmut Holzgraefe wrote: > Marcus Wolschon wrote: >> Ich hatte gestern schon die Projektseite im Wiki vom 26C3 angelegt. >> Wer Interesse hat kann sich halt eintragen >> > URL? Das Wiki zum 26C3 findet doch nun wirklich jede beliebige Suchmaschine. http://events.ccc.de/congress/2009/wiki/index.php/OpenStreetMap ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Video
Am 25. November 2009 07:39 schrieb Markus : > Hallo Martin, > > > ich stehe ziemlich auf die ito-Videos. > > http://www.youtube.com/watch?v=0-z9AM7KOJc > > http://www.youtube.com/watch?v=Vx3dTBtGwWs&feature=related > > Ja, die gefallen mir auch sehr gut. > Zeigen beeindruckend die rasante Entwicklung von OSM. * > > Hat jemand diese Videos in HD-Qualität? > Oder eine Mailadresse des Autors? > > Gruss, Markus > die Videos sind wie gesagt von ito, Peter Miller, die offizielle Webseite ist hier: http://www.itoworld.com/static/contact Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Karten-Quiz und Lernprogramm
Markus schrieb: > In dem Zusammenhang mit dem Bericht über das Rollstuhlfahrer-Routing > hat der WDR ein tolles Quiz erstellt: > http://www.wdr.de/tv/quarks/sendungsbeitraege/2009/0915/flash/flashpopup.jsp Kann das jemand nachbauen? Oder etwas Ähnliches selbst schreiben? Könnten wir auf der OSM-Website und für Veranstaltungen nutzen. Die Inhalte könnte man dann für OSM anpassen oder individuell gestalten. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] "Wayparts" - Ansatz für Fahrspure n, straßenbegleitende Wege etc.
Ich finde das Plugin sehr wichtig!
Gut das du dran arbeitest!
Gruß Sven
Am Samstag, 21. November 2009 12:46:38 schrieb Nils Heuermann:
> Hallo zusammen,
>
> hatte dieses Thema zuvor im Thread "Relationen besser als Tags" [1]
> angesprochen; da es inhaltlich aber doch auf etwas anderes abzielt, jetzt
> als eigener Thread.
>
> Hier eine kurze Einleitung:
> Ziel ist die Erfassung von Fahrspuren, straßenbegleitenden Wegen (Radweg,
> Bürgersteig) sowie weiteren Straßenteilen wie Parkstreifen, Grünstreifen
> usw. Zugeordnet/angelegt werden diese als Relationen, die den Weg (oder
> mehrere zusammenhängende Wege) sowie jeweils einen Start- und Endnode
> beinhalten.
>
> Den Ansatz habe ich im Wiki erläutert, wo es auch ein (noch unfertiges)
> JOSM-Plugin zur Visualisierung gibt:
>
> http://wiki.openstreetmap.org/wiki/DE:User:Ömmes/Wayparts
>
>
> Im anderen Thread gab es schon ein paar Antworten, die von Tobias greife
> ich hier jetzt auf:
>
>
> Am Fri, 20 Nov 2009 22:51:16 +0100 hat Tobias Knerr
>
> geschrieben:
> > Konzeptionelles:
> >
> > Du kombinierst hier die Angabe über Tag-Präfixe mit der über Relationen.
> > Ein durchaus gangbares Konzept wäre ja auch die Angabe komplett über
> > Tags, also so etwas wie
> > right4:lane_type=footway
> > right4:surface=cobblestone
> > ...
> > - also das, was du mehr oder weniger auch in der wayparts-Relation
> > verwendest. Nur: Warum dann die mit solchen Präfixen versehenen Tags
> > nicht direkt an den Way packen und auf eine Relation verzichten?
>
> Für die Verwendung von Relationen spricht für mich folgendes:
> - Die Tagliste von Ways wird nicht ellenlang
> - Man hat Geometrie (Way) von der näheren Beschreibung/dem Querschnitt
> (Relation) getrennt
> - Man kann mehrere Ways zusammenfassen, zum Beispiel bei Brücken oder wenn
> sich nur der Straßenname ändert. Die Fahrspuren führen dennoch weiter und
> sind zentral definiert (keine Redundanz an mehreren Ways -> weniger
> Fehler, wenn man was am Querschnitt ändert). So könnte man evtl. auch eine
> abknickende Vorfahrt erfassen.
> - Umgekehrt kann man einen Way in mehrere Bereiche aufteilen, ohne diesen
> zerstückeln zu müssen, wenn eine Spur hinzukommt oder wegfällt.
>
> > Falls es um die Vermeidung des Teilens von Ways geht: Wäre es dann nicht
> > besser, eben doch zunächst einmal Tags zu nehmen und diese dann mit
> > einer Eigenschaftsrelation - wie sie in diesem Thread vorgeschlagen
> > wurde - an den Way zu hängen? Denn für Tags, die den ganzen Way
> > betreffen, wäre eine solche ja ohnehin noch separat nötig. Und wenn man
> > eine Eigenschaftsrelation für name=* anlegen kann, dann doch sicher auch
> > für part4:type=*?
>
> Klar, das lässt sich natürlich kombinieren. Allerdings sollte man jetzt
> nicht erst anfangen, Tags zu verwenden und Ways zu spiltten, um diese
> später dann doch in Relationen auszulagern. Wenn, dann gleich als Relation
> (sofern sich das als funktioniernde Lösung herausstellt).
>
> > Ansonsten noch: Könnte man es irgendwie schaffen, die beiden
> > Relation-Typen zusammenzufassen? Abgesehen davon, dass wayparts, wenn
> > ich das richtig verstehe, für den "Kernbestand" an Weg-Teilen gedacht
> > sind, ist ein waypart doch mehr oder weniger nur ein wayparts mit
> > parts=1?
>
> jein ;)
> Ausschlaggebend war in der Tat die Angabe der Hauptspuren ("Kernbestand")
> im Gegensatz zu einzelnen Spuren. Die Hauptspuren (wayparts) können
> (derzeit) nur 1x für einen Abschnitt definiert werden und können durch
> weitere Spuren (waypart) ergänzt werden - das allerdings mehrfach.
> Vielleicht ist es auch unnötig, diese Unterscheidung anhand des
> Relations-Typs zu machen - man könnte auch einfach die Tags auswerten, die
> vorhanden sind. Dann ließe sich evtl. auch sowas machen wie: "Füge 2
> Abbiegespuren hinzu", wofür man im Moment 2 waypart-Relationen bräuchte.
>
> Ansonsten war es für das Schreiben des Plugins erstmal einfacher, diese
> Unterscheidung zu verwenden, da aus "wayparts" automatisch mehrere
> waypart-Elemente erzeugt werden, ein waypart aber direkt verwendet werden
> kann.
>
> > Wahl der Begriffe:
> >
> > Subjektiv empfinde ich "waypart" als etwas merkwürdige Bezeichnung, bin
> > aber kein Muttersprachler.
>
> Bin ich auch nicht, daher mag der Begriff nicht korrekt sein.
>
> > Da Begriffe wie "lane", die mir besser
> > gefallen würden, als zu eng aufgefasst werden könnten, habe ich gerade
> > keinen eindeutig besseren Vorschlag.
>
> So ging es mir auch, daher bin ich bei "waypart" hängengeblieben...
>
> Viele Grüße und schönes WE!
> Nils
>
>
> [1]
> http://lists.openstreetmap.org/pipermail/talk-de/2009-November/058720.html
>
> ___
> 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] Fahrthäufigkeit bei Buslinien
Martin Koppenhoefer schrieb: Gerade in Gegenden, wo der ÖPNV nicht nur gewährleistet werden muss, sondern sich die Frequenzen auch nach realem Verkehrsaufkommen richtet (also größere Städte), sind allerdings öfters auch die Takte zu Stoßzeiten (z.B. 7-9, 17-19h) dichter als in der übrigen Zeit. Jetzt, wo du's erwähnst: Auch in meiner Gegend kann ich das brauchen, da bestimmte Buslinien zu verkehrsschwachen Zeiten zusammengelegt werden und dadurch bestimmte Bushaltestellen überhaupt nicht angefahren werden. Was evtl. auch brauchbar wäre, ist ein Tag, dass den Prozentsatz an Niederflurfahrzeugen, oder Gelenk-/Doppelstockfahrzeugen angibt, z.B.: low_floor_vehicles = 50% (d.h. die Hälfte aller Fahrzeuge sind Niederflurfahrzeuge, und deren Frequenz ist ungefähr halb so groß wie die Gesamtfrequenz) articulated_vehicles = ... (Gelenkfahrzeug, wie oben) double_decker_vehicles = ... (Doppeldeckerfahrzug, w.o.) Alternativ könnten sich diese Tags auch wie das vorher beschriebene frequency-Tag verhalten, frequency würde dann für /alle/ Fahrzeuge gelten, auch die, die durch die drei obigen Tags abgedeckt sind, low_floor, articulated, und double_decker könnten dann zur genaueren Spezifizierung dienen. Über die Nötigkeit von articulated und double_decker kann man streiten, vom Blickwinkel der Behindertengerechtheit wäre low_floor meiner Meinung nach aber schon wichtig. Sarah Hoffmann schrieb: Wie das Variantenproblem gelöst werden kann, weiss ich auch nicht. Kleinere zu ignorieren, finde ich jedenfalls ok. Vielleicht, indem man Teilrouten definiert, die über eine "Meta-Relation" geordnet zusammengefasst sind? Die Frequenzen könnten in den Teilrouten angegeben werden, die Frequenz einer "Meta-Relation" ergäbe sich dann durch das Minimum der Teil-Relationen. Ein Beispiel von um die Ecke (ich hoffe, die Leerzeichen werden nicht gefressen) .<-(D)-. .<-(C)-. | \ | \ .--(B)--<>-. |\ |\| \ V \V \ |\ .>>+--<>---+-->-(E)-->+--<>--+--(F)--<>+---<>--(A)--<>---<>---[ZOB] Erläuterung: <,^,V,>: Verkehr nur in Pfeilrichtung <>:Vehrkehr in beide Richtungen .,- Kante (nach Graphentheorie) +Knoten (nach Graphentheorie) (X) Benennung einer Kante [ZOB]Zentraler Omnibusbahnhof Soviel zur Grafik, nun zu den Linien: ZOB>A>B>C>E>B>A>ZOB: Im folgenden "Linie B" ZOB>A>F>C>E>B>A>ZOB: Im folgenden "Linie F" ZOB>A>B>C>D>E>B>A>ZOB: Im folgenden "Linie BD" ZOB>A>F>C>D>E>B>A>ZOB: Im folgenden "Linie FD" Ich würde nun für A,B,...,F jeweils Teilrelationen aufstellen, und dort die jeweiligen Frequenzen angeben: Ach ja, alle Zeitintervalle verstehe ich in der Form [x,y], also x und y sind Teil (Element) des Intervalls. Kante B: frequency:weekday_and_6h=1/hour//*Ob dieser Spezialfall Aufnahmewürdig ist, wäre zu klären ;-) frequency:weekday_and_8h-11h=1/hour frequency:weekday_and_15h=2/hour //siehe * frequency:weekday_and_18h=2/hour //siehe * frequency:weekday_and_19h-22h=1/hour frequency:weekday_and_default=none //Der Vollständigkeit halber, default gibt alle Zeiten an, die nicht abgedeckt sind, hier also wochentags 23h-5h,7h.12h-14h,16h-17h Kante F: frequency:weekday_and_6h-8h=1.5/hour frequency:weekday_and_12h-14h=1.5/hour frequency:weekday_and_16h-17h=2/hour frequency:weekday_and_default=none //Der Vollständigkeit halber. Kante D: frequency:weekday_and_7h-18h=0.5/hour frequency:weekday_and_default=none //Der Vollständigkeit halber. Wochenenden schenk ich mir, die Mail ist eh schon viel zu lange :-) Wir stellen uns aber vor, ich hätte sie angegeben. A,C,E lasse ich bewusst ungetaggt, sie sollen bei der Bestimmung der minimalen Frequenz einfach nicht berücksichtigt werden Linie B hat nun nur Kante B spezifiziert, es gelten also die Frequenzen von Kante B. Selbiges bei Linie F/Kante F. Für die Linien BD und FD, bestimmen wir nun die Minima für die einzelnen Zeitintervalle, indem wir die Zeitintervalle passend zusammenfügen: BD: (gemeinsames Intervall**; Intervall B & Intervall D **; Frequenz B & Frequenz D; => gemeinsame Frequenz***) 00h-05h; defaultB & defaultD; none , none; none 06h; 6h & defaultD; 1/hr , none; none 07h; defaultB & 7h-18h; none , 0.5/hr; none 08h-11h; 8h-11h & 7h-18h; 1/hr , 0.5/hr; 0.5/hr 12h-14h; defaultB & 7h-18h; none , 0.5/hr; none 15h; 15h & 7h-18h; 2/hr , 0.5/hr; 0.5/hr 16h-17h; defaultB & 7h-18h; none , 0.5/hr; none 18h; 18h & 7h-18h; 2/hr , 0.5/hr; 0.5/hr 19h-22h; 19h-22h & defaultD; 1/hr , none; none 23h; defaultB & defaultD; none , none; none **Alle Schnittmengen der Intervalle von B und D werden berücksichtigt, leere Schnittmengen ignorieren wir (z.B. 6h & 7h-18h) *** Die gemeinsame Frequenz ergibt sich auch der Minima
Re: [Talk-de] Mapnik: Pfaelzer Wald kaputt
Martin Koppenhoefer schrieb: (Im ReplyTo stand, Du magst die Mails nochmal an Deine eMail-Adresse haben. Drum mach ich das mal so.) > Am 24. November 2009 10:21 schrieb Steffen Wolf : >> > Allerdings ist es in der Realtität meistens so, dass das, was >> > gemeinhin als _ein Wald_ gesehen wird, dann doch bei näherem Hinsehen >> > zig einzelne Waldstücke sind, >> Hmm, das ist hier allerdings nicht gegeben, soweit ich das ueberblicken >> kann. > Nicht, dass ich mich dort auskennen würde, aber ein Blick in Wikipedia gibt > zumindest schonmal Anhaltspunkte für eine Grobgliederung: > - nördlicher Pfälzer Wald mit weiterer Unterteilung in Diemersteiner Wald, > Stumpfwald und Leininger Land (und diese sind garantiert nochmal mindestens > eine weitere Ebene unterteilt, vermutlich aber mehrere) > - mittlerer Pfälzer Wald (weiter: Gräfensteiner Land, Pfälzisches Holzland, > Frankenweide) > - südlicher Pfälzer Wald (Wasgau, Dahner Felsenland, oberer Mundatwald, ...) > wie gesagt sind auch die genannnten Namen und Landschaften sicher noch > weiter unterteilt und auch sicher nur exemplarische Teilbereiche, um das > genauer zu machen braucht man allerdings gute Ortskenntnis. Oh, fuer mich sieht hier alles nach einem kontinuierlichen Wald aus. Aber ich kenn eigentlich nur den noerdlichen und den oestlichen Teil. Die Namen der einzelnen Landstriche kenne ich auch nicht, ich bin aber nur ein Zugereister. Hmm, wenn sich jemand die Muehe macht, und die einzelnen Waldstuecke (da Nadelwald, da Laubwald, da Mischwald, da eine Schonung) eintraegt, hab ich nix dagegen. > Apropos: mir ist aufgefallen dass Manche erstmal davon ausgehen, dass alles > Felder sind, und dann wird der Rest Stück für Stück wieder anders definiert. > Finde ich vor diesem Hintergrund nicht so optimal. Erstens haben Felder ja > auch Eigennamen, und zweitens ist beileibe nicht alles Feld, was nicht Wald > oder Straße ist. Es gbit massig andere Flächen, die so erstmal pauschal als > Feld (Acker) definiert werden, aber eigentlich Brachflächen, > Abstandsflächen, Unterholz, Gebüsch, Sumpf oder sonstwas sind. Zustimmung. Da ich aber kein Auge fuer sowas habe, lasse ich die Finger von den leeren Flaechen hier in der Gegend. Wald kann ich grade noch erkennen. Manche Luecken im Wald hab ich als farmland, meadow, oder aehnliches eingetragen. Ich muss mir mal die Tags angucken, die Mirko verwendet, ich glaub, die koennen als Vorbild dienen. cu, stw -- Wer sind wir? Was machen wir hier eigentlich? - Amnesy International ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zum Datenabruf unter XAPI
Hallo Carsten, > Schau mal hier: http://wiki.openstreetmap.org/wiki/Platform_Status Gab es da nicht mal im Zusammenhang mit den neuen Strato-Servern konkrete Pläne zu einer "europäischen" XAPI? Wie ist da der aktuelle Stand? Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bringdienste, wie taggen?
Am Mittwoch, den 25.11.2009, 04:15 + schrieb Bartosz Fabianowski: > > Wie wäre es mit "delivers=yes" wenn ein Bringdienst angeboten wird? > > Um mir selbst zu antworten... "delivering=yes" wäre wohl besser denn das > ist grammatisch konsistent mit "dispensing=yes" bei Apotheken. +1 Andre ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen besser als Tags?
Original-Nachricht > Datum: Wed, 25 Nov 2009 00:50:05 +0100 > Von: Martin Koppenhoefer > An: qbert biker > CC: Openstreetmap allgemeines in Deutsch > Betreff: Re: [Talk-de] Relationen besser als Tags? > > Dazu brauchts aber Konzepte und Technik. 'Frei Auge' hat > > natuerliche Limitierungen. Iterativ wird ab einem bestimmten > > Niveau nur noch hin und her geschoben, aber wenig verbessert. > > Sind jedenfalls meine Beobachtungen. > > > > > soweit sind wir m.E. noch praktisch nirgends (von Mirkos Ecke mal > abgesehen). Erst bei richtig vielen Details, die ja jeweils auch wieder > Korrekturen des Bestehenden mit sich bringen, wird sich das einstellen. Das sehe ich etwas anders. Sauber gerade eingetragene Strassen die so der Realitaet entsprechen, werden z.B. beim nachbessern gerne mal in krumme Kurvenstrecken verwandelt. Man muss schon sehr gut sein, um beim haendischen Reimmalen von Einzelspuren die urspruengliche konstruktive Basislinie zu erhalten, die dem ganzen das Gesicht gibt. Wenn es mal flaechendeckend Bilder in 10cm-Aufloesung als Basis gibt, laesst sich sowas sauber abzeichenen. Aber in der Stadt sind die GPS-Fehler um Groessenordnungen groesser als die von dir angedachte Aufloesung. Willst du tatsaechlich in den Strassenschluchten der Stadt kleinste Schlenker im Fahrradweg aus den GPS-Daten herausfiltern? > ja, aber noch unübersichtlicher geht es kaum. Man könnte auch auf die > Ways > komplett verzichten und alles beschreiben, nur: wollen wir das? Sei doch nicht so sparsam mit Superlativen ;) Der way ist und bleibt die unverzichtbare Basis, die der Konstrukeur der Strasse mal angelegt hat. Und warum ein relativ sparsames Bezugssystem unuebersichtlicher sein soll als ein Wald von nodes, ways und relations erschliesst sich mir jetzt nicht so ganz. > klar, das ist wie bei allen Straßen und Wegen: einen Way in der > Mittellinie. > Alles andere ist "falsch", das kein richtig und falsch bezieht sich aufs > tagging, nicht darauf, wo man die nodes und ways einträgt. Noe, dass es die Mittellinie ist, ist keine Frage von falsch oder richtig bei OSM, sondern einfach nur Gewohnheit, denn es gibt keine Definition dafuer. Ich bin da langgefahren und habs getrackt, also wirds eben die Mitte sein. Entspechend krumm und schief siehts mancherorts aus. Um die Mitte einer Strasse auch nur mittelmaessig genau aus tracks bestimmen zu koennen, muss man sie mindestens in jede Richtung einmal abgefahren haben und ueber beide tracks sauber mitteln. Das wird wohl nur auf einen kleinen Teil der gemappten Strassen zutreffen. Die Einbeziehung von geometrischen Tatsachen kann das Mapping verbessern und da gehoeren Bezugssysteme wie das vorgeschlagene dazu. Davon bin ich wiederum so ueberzeugt wie du von deiner Einzelspurabbildung. Gruesse Hubert -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
