Re: [Talk-de] Gebaeude und Restaurants (Reit und Wanderkarte)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ekkeh...@gmx.de schrieb: Wichtig für das Reiten und Wandern ist eine genaue Aufschlüsselung der Tracks. Die sac_scale wird absichtlich nur so weit ausgewertet, wie sie für einen Nicht-Alpinisten nützlich ist. - footway wird nicht ausgewertet, ein Gehweg mit sac_scale macht für mich keinen Sinn - path normal oder mit sac_scale 1: rot gestrichelt - sac_scale 2 : rot gepunktet - sac_scale = 3: lila gepunktet, für Gelegenheitswanderer nicht empfehlenswert, für Pferde unpassierbar, Thema für eine echte Alpenkarte Sollte ich vielleicht mal in die Legende aufnehmen. :-) Hallo Nop, diese gepunkteten Wege sind auf dem Garmin schlecht zu erkennen. (Gestrichelt weiß ich jetzt nicht). Ich denke, daß sac_scale=hiking (T1) in der Regel genau so gut für Gelegenheitswanderer geeignet ist wie Tracks. sac_scale=mountain_hiking (T2) ist oft auch noch gut zum Wandern geeignet, vielleicht nicht mehr so gut zum Reiten. siehe Erklärung: sac_scale=hiking; T1 Wandern; Weg gut gebahnt.; Gelände flach oder leicht geneigt, keine Absturzgefahr; Keine Anforderungen sac_scale=mountain_hiking; T2; Bergwandern; Durchgehend gut ersichtlicher und gut begehbarer Weg.; Teilweise steil. Absturzgefahr möglich; Trekkingschuhe, Etwas Trittsicherheit, Etwas Ausdauer Das Problem bei sac_scale ist, daß hier mehrere verschiedene Kriterien enthalten sind. Deshalb ist die Einstufung etwas schwierig. Beispiele: Ist ein teilweise steiler Weg ohne Absturzgefahr T1 oder T2? Ist ein kaum erkennbarer, teilweise steiler Weg, bei dem man gelegentlich die Hände braucht, um eine meterhohe Stufe zu überwinden, immer T4? Auch wenn es keinerlei Absturzgefahr oder Seilsicherungen gibt? In meinem Fall (Insel Giglio) würde ich die meisten Wege als mountain_hiking einstufen, weil es manchmal steil ist und Stufen (Steine) vorkommen. Absturzgefahr gibt es eher selten.Einige der T2-Wege werden von den italienischen Urlaubern mit Badelatschen begangen. Es gibt dort eben 400m Höhenunterschied vom hoch gelegenen Hauptort zum Strand. Früher wurden nahezu sämtliche Wege mit Eseln zum Lastentransport genutzt. Auf einigen könnte man vermutlich auch reiten. Das ist dort aber nicht relevant. Ich schlage vor, die Darstellung etwas zu verändern: 1 rot durchgehend 2 rot gestrichelt 3 rot gepunktet, vielleicht etwas größere Punkte = 4 lila gepunktet Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqLn5IACgkQnMz9fgzDSqeXVACfaMpCaBPTp1Ranj/l7ymNRON9 QHcAoIp1COn372HBXfGYJi7DNumI8CCm =XlsB -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Trunk oder primary
Original-Nachricht Datum: Tue, 18 Aug 2009 23:44:35 +0200 Von: Garry garr...@gmx.de An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Trunk oder primary Ich stelle nicht das Tagen von kreuzungsfrei in Frage sondern das was Du daraus offenbar direkt ableiten willst. Mehr als kein Querverkehr ist da halt nicht sicher möglich... Kein Querverkehr ist hoechstens 'kreuzungsfrei' und das kann ich auch in der Sahara ueber ein paar 100 km haben. Was man unter 'kreuzungsfreiem Ausbau' versteht, sind Bauwerke wie Bruecken und Rampen und das nicht zu knapp. Das ist keine xbeliebige Definition, sondern Stand der (Verkehrs-)technik und dazu gibts umfangreiches Wissen und Erfahrungen dazu. Uebrigends habe ich bei dieses ganzen trunk gegen primary Umwidmungen gut beobachten koennen, dass andere Tagger das sehr praezise erfassen und Begin und Ende des kreuzungsfreien Ausbaus gut ermitteln koennen. Nur ist das dann eben nach kurzer Zeit wieder geloescht, weil jemand meint, dass die zweite Spur fehlt und wieder primary draus macht... Wenn ich mit gerinstem Zeitaufwand von A nach B muss interessiert mich der Ausbauzustand nur am Rande und ich wähle lieber eine wenig befahrene Nebenstrecke als eine kreuzungsfrei ausgebaute einspurige Hauptstrecke auf der ich dann bei Stau gefangen bin. Dagegen spricht ja nichts. Ich finde es nur schade, dass Informationen, die den anderen nutzen koennten, kleingeredet werden, weil man selber persoenliche Praeferenzen hat und lieber an zig Ampeln steht, als im Stau. Ein gutes Konzept loest die Ebenen auf und liefert die Informationen getrennt, so dass ich mir den Ausbauzustand ansehe und vielleicht spaeter mal die Belastungskurve und Stauneigung. Dann kann ich anhand meiner Praeferenzen meine eigenen Schluesse ziehen, die nicht von einem anderem schon vorgekaut sind. Wenn du versuchst, das alles plump mit einer groben Klassifizierung zu erschlagen, nimmst du den anderen die Moeglichkeit, eigende Praeferenzen zu setzen. TomTom wirbt AFAIK gerade mit unabhaengig vom Ausbauzustand erfassten Verkehrszustaenden. Hier verliert OSM gerade mal wieder den Anschluss. In den Fällen geht es auf den Ausweichstrecke dann in der Regel auch nicht schneller - schon gar nicht wenn die Ausweichstrecke vom Navi vorgeschlagen wird. Das ist eben die Kunst dabei. Mit vielen und differenzierten Informationen kann man die beste Route finden, mit Pauschalierungen ist man schon am Ende, bevor man angefangen hat. Gruesse Hubert -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Erzeugung eines Permalinks mit aktivierten Elementen im openstreetbrowser?
Thomas Ineichen schrieb: Mit einem Link auf die Relations-ID (ersichtlich unter OSM Internal): http://www.openstreetbrowser.org/#rel_161712 Vielleicht könnte man ganz allgemein im OSB unter OSM Internal eine Verlinkung anbieten/darauf hinweisen, dass das so geht? Danke, funktioniert gut. Einen Hinweis wie von dir vorgeschlägen hielte ich auch für hilfreich. Grüße Jens ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Warum immer die ...more OSM coming soon Kacheln
Am Sonntag 16 August 2009 09:32:29 schrieb Jens von Elling: In letzter Zeit gibt?s immer wieder diese häßlichen more OSM coming soon Kacheln. Das kann ich bei der höchsten Zoomstufe bestätigen. Dann wollte ich mir diese eine Kachel anschauen, die dann auch nicht da war. Beim klick auf den Zurück-Button war ich leider wieder ganz woanders. Dann war aber auch die OSM com... Kachel weg und alles war okay. Im Browser (Firefox) habe ich in den Einstellungen nichts dazu gefunden. Auch seltsam finde ich dieses ominöse Ende des Weges, der da eigentlich gar nicht aufhört - beim rauszoomen erkennbar: http://www.openstreetmap.org/?lat=50.98606lon=6.176zoom=18 MfG ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Postal_code oder addr:postcode
On Tue, Aug 18, 2009 at 11:23:47PM +0200, Peter Körner wrote: Tobias Wendorff schrieb: Jan Tappenbeck schrieb: Nun möchte ich auch noch pro PLZ-Zelle die Zahl darstellen lassen. Sollte ich hierfür einen Node mit addr:postcode oder postal_code setzen ??? Öhm, wieso nicht beides? Weil duplizierte Daten immer dann böse werden, wenn sie voneinander abweichen. Daher sollte man von vorneherin verhindern, dass Daten doppelt erfasst werden. Im Gegenteil: Duplizierte Daten sind prima, wenn sie voneinander abweichen. Dann erkennt man nämlich sehr einfach, dass was nicht stimm und kann es fixen. Wenn man die Daten nur einmal hat und sie sind falsch, kann ich das nicht erkennen. :-) Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neues ÖPNV-Schema - Linien(varianten )relationen
On Tue, Aug 18, 2009 at 08:46:01PM +0200, Claudius wrote: Aus gegebenem Anlass habe mir gerade nochmal die Linienerfassung laut neuem ÖPNV-Schema durchgelesen und bin etwas unsicher, ob meine Tramlinienerfassung so richtig ist: - eine Relation für Linienvariante Hinweg; Als Tags enthält diese *nur* from=Stötteritz und to=Gohlis; Mitglieder sind die Streckenführung und Haltestellen - eine Relation für Linienvariante Rückweg; Als Tags enthält diese *nur* to=Gohlis und from=Stötteritz; Mitglieder sind die Streckenführung und Haltestellen - eine übergeordnete Linienrelation getaggt mit line=tram; ref=4; color=#09519D usw.; Mitglieder sind nur die beiden obigen Relationen [ ] Richtig - [ ] Falsch - [ ] Knapp vorbei Als Auswerter müsste ich also, um die Liniennummer und den Betreiber einer Linie an einer Haltestelle erst die Überrelation ermitteln und dort die Werte ermitteln. Richtig. Eventuell willst Du die Tags aus der Linienrelation in die Linienvarianten auch nochmal reinschreiben. Falls es Software gibt, die es sich einfacher macht. Bisher gibt noch kaum Software, die das überhaupt auswertet, deswegen kann man schlecht sagen, in welche Richtung sich das bewegt. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neues ÖPNV-Schema - Linien(varianten )relationen
Am 19.08.2009 10:44, Jochen Topf: On Tue, Aug 18, 2009 at 08:46:01PM +0200, Claudius wrote: Aus gegebenem Anlass habe mir gerade nochmal die Linienerfassung laut neuem ÖPNV-Schema durchgelesen und bin etwas unsicher, ob meine Tramlinienerfassung so richtig ist: - eine Relation für Linienvariante Hinweg; Als Tags enthält diese *nur* from=Stötteritz und to=Gohlis; Mitglieder sind die Streckenführung und Haltestellen - eine Relation für Linienvariante Rückweg; Als Tags enthält diese *nur* to=Gohlis und from=Stötteritz; Mitglieder sind die Streckenführung und Haltestellen - eine übergeordnete Linienrelation getaggt mit line=tram; ref=4; color=#09519D usw.; Mitglieder sind nur die beiden obigen Relationen [ ] Richtig - [ ] Falsch - [ ] Knapp vorbei Als Auswerter müsste ich also, um die Liniennummer und den Betreiber einer Linie an einer Haltestelle erst die Überrelation ermitteln und dort die Werte ermitteln. Richtig. Eventuell willst Du die Tags aus der Linienrelation in die Linienvarianten auch nochmal reinschreiben. Falls es Software gibt, die es sich einfacher macht. Bisher gibt noch kaum Software, die das überhaupt auswertet, deswegen kann man schlecht sagen, in welche Richtung sich das bewegt. Danke für die Antwort. Ein Hinweis a lá Jede Linie, die keine Rundroute ist und in beiden Richtungen befahren wird besteht also aus drei Relationen. sollte in die Dokumentation aufgenommen werden. Soll ich das machen oder pflegt das Sebastian noch weiter? Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Firmware f?r GPSmap 60CSx sinnvoll?
Moin, urgs Nein, Linux tut sowas nicht. Linux vielleicht nicht, Netatalk AFAIR schon. -- Beste Grüße, Best regards, ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neues ÖPNV-Schema - Linien(varianten )relationen
On Wed, Aug 19, 2009 at 10:56:15AM +0200, Claudius wrote: Danke für die Antwort. Ein Hinweis a lá Jede Linie, die keine Rundroute ist und in beiden Richtungen befahren wird besteht also aus drei Relationen. sollte in die Dokumentation aufgenommen werden. Soll ich das machen oder pflegt das Sebastian noch weiter? Sebastian pflegt das wohl nicht weiter. Allerdings haben die Leute auf der talk-transit-Liste sich schon dessen angenommen und irgendwo anders eine öffentlichere Version der Seite angefangen, wo sie Sebastians Kram übernommen haben und dabei sind das zu überarbeiten. Weiss grad nicht mehr, wo das ist, aber das wirst Du finden. Vielleicht macht es mehr Sinn, Sebastians Version ruhen zu lassen und die neue Seite zu pflegen. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummerntool?
On Wed, Aug 19, 2009 at 11:22:19AM +0200, Andreas Neumann wrote: Der scheint Probleme bei addr:interpolation=alphabetic zu haben... http://tools.geofabrik.de/osmi/?view=addresseslon=10.92582lat=50.67726zoom=16overlays=interpolation_errors oder gibt's da mittlerweile ein anderes Schema? Das wird nicht unterstützt. Ist einfach ein fehlendes Feature, das auch schon auf der TODO-Liste steht. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Postal_code oder addr:postcode
Im Gegenteil: Duplizierte Daten sind prima, wenn sie voneinander abweichen. Dann erkennt man nämlich sehr einfach, dass was nicht stimm und kann es fixen. Wenn man die Daten nur einmal hat und sie sind falsch, kann ich das nicht erkennen. :-) Das sehe ich anders. man bezieht sich hierbei nur auf ortskundige Menschen. Weder ein Ortsfremder noch ein elektronisches System (z.B. Routenplaner oder Navi) sind in der Lage, solche Konflikte aufzulösen. Damit sind für die Mehrheit der Nutzer der OSM Daten unstimmigkeiten ein nicht zu lösendes Problem. Ein Praktisches Beispiel: Ich gebe in einem Routenplaner eine PLZ als Ziel ein. Er zeigt mir eine Karte, welche eine völlig andere PLZ abbildet und routet mich dahin. Wenn ich nicht ortskundig bin, würde ich denken, dass der Router falsche Daten liefert, dabei verwendet er nur einen anderen Tag als der Renderer... Oder noch schlimmer: Ich bemerke nicht, dass der Router mich zur falschen PLZ führt, weil auf der Karte ja die richtige angezeigt wird. Man könnte natürlich an dieser Stelle auf die Tools drauf hauen, aber die Erfahrung zeigt dass die meisten Tools so gebaut werden, dass sie grade so funktionieren. Solche Tools beachten dann entweder nur den einen oder den anderen Tag (was in 99% der Fälle ja auch funktioniert) und erkennen die Inkonsistenz nicht. Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Knicks (Wallhecken) einzeichnen
Tobias Wendorff schrieb: Christian H. Bruhn schrieb: Hier in Schleswig-Holstein sind Knicks sehr typisch in der Kulturlandschaft. [...] Wie tagt man diese am besten? Ich finde, das sind eindeutig als Barrieren/Grenzen angelegte Hecken, also barrier=hedge. barrier = hedge ist vielleicht zu unbedeutend, oder? barrier = hedge_bank steht auch bei dict.leo.org. Das ist ganz klar ein Fall, wo man *keinen* neuen Top-Level-Tag erfinden sollte. In den meisten Fällen kann man das nämlich durchaus 1:1 wie eine normale Hecke behandeln. Wenn man Wert auf die Unterscheidung legt, lieber als Untertag, also so was wie barrier=hedge + hedge=bank/Knick/o.ä. Alternativ oder zusätzlich gehen natürlich auch width/height oder ähnliche Attribute. Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [tagging] Vorschlag - Abstimmung - power_rating
Moin, die Abstimmung ist ja inzwischen gelaufen, folgende Infos zusammenfassend für die Diskussion noch mal: - niemand _muss_ die Nennleistung einer Windkraftanlage oder eines anderen Kraftwerks eintragen - es gibt einige, die diese Informationen interessant finden (mich natürlich eingeschlossen :-) - es gibt eine ganze Menge Quellen, die Nennnleistung von Kraftwerken herauszufinden - einige wurden schon genannt (Unternehmensveröffentlichungen, Anfragen an UBA oder Unternehmen, etc.). Nicht zu vergessen sind auch die Pflichtveröffentlichungen der Netzbetreiber im Rahmen des EEG (ob es, seit der Änderung des EEG 2008/2009 trat hier eine Änderung in Kraft, von Seiten der Bundesnetzagentur auch Veröffentlichungen geben wird, ist mir nicht bekannt). Diese sind meistens etwas versteckt auf den www-Seiten der Netzbetreiber zu finden und enthalten Listen mit allen PV-, Wind-, Biogas- und Thermieanlagen, denen man (manchmal?) auch die Nennleistung entnehmen kann. - ob die Information auf einer normalen Karte gerendert wird, ist mir erst mal nicht so wichtig - ich finde, sie gehört in die Datenbank; vielleicht gibt es ja auch mal (eine) Karte(n) zur (Energie-)Infrastruktur in den entsprechenden Ländern - installed_power wäre wohl auch eine Option gewesen ... wobei beides seine Schwächen hat. Nun ist es aber power_rating (ich hätte vom Begriff her rated_power auch besser gefunden, finde aber das vorne stehende power gut zur schnelleren Erfassung, was hier ausgezeichnet wurde) Grüße, Schusch___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Alten Weg wiederherstellen
hast du dir schon http://wiki.openstreetmap.org/wiki/DE:Potlatch#Rückgängig-Funktion angeschaut? Hierbei ist Potlatch nämlich ganz gut ;-) Gruß, Schusch___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Postal_code oder addr:postcode
Hallo Claudius, mir geht es nicht um KOSMOS - das habe ich umgangen. Ich ziele vielmehr darauf ab jeder PLZ mit einer Nummer zu versehen und diese irgendwo / -wie zu hinterlegen. Diese an eine Ort- oder Stadtteilbeschreibung zu hängen macht aus meiner Sicht wenig sinn, da diese nicht immer vollständig in der einen oder anderen liegen müssen. Gruß Jan :-) Claudius schrieb: Am 18.08.2009 14:46, Jan Tappenbeck: Moin ! ich habe eine Karte [1] erstellt mit welcher ich die zugewiesenen Postleitzahlen für Lübeck und Umgebung auf Basis des Karlsruher Schemas sichtbarmachen kann. Nun möchte ich auch noch pro PLZ-Zelle die Zahl darstellen lassen. Sollte ich hierfür einen Node mit addr:postcode oder postal_code setzen ??? Verstehe ich dich richtig, dass du einen neuen Knoten in die OSM-Daten einfügen willst, damit auf deiner PLZ-Karte die PLZ in der jeweiligen Zelle zentriert angezeigt wird? In dem Fall würde meine Antwort Garantiert nicht lauten. Kenne mich mit Kosmos leider nicht aus, vielleicht gibt es dort aber so etwas wie den Mittelpunkt eine Eigenschaftenwolke als Platzierungsmöglichkeit. Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Action!
Hi, hier ein Mailing bzgl. unserer Aktionen, in der talk-Liste gesendet... (sri for english, aber viele sind der Sprache ja mächtig!) --- Hi, I provide some error reports for OSM and wanted the errors to be corrected. Of course I could handle some of them on my own. But since there were 10s of thouands I surely wouldn't be able to inspect and correct them all. So I thought why not set up a joint action of some sort? And so I did - not knowing whether I would get help or not. But amazingly we had so many volunteers who picked working packages that in a few days hundreds of erros could be corrected. And since the edits were supposedly made with JOSM using the validator plugin many other errors (beside the initially listed ones) were corrected as well. In the first action 1000 errors were closed in 5 days. The third action (1000 dupe ways) I suppose will make it in under 24h! That's crazy!!! So far we handled unconnected residentials in Bayern/Germany and dupe ways also in Germany. For details please have a look at - http://wiki.openstreetmap.org/wiki/DE:Aktionen - http://wiki.openstreetmap.org/wiki/Aktion_01 - http://wiki.openstreetmap.org/wiki/DE:Aktionen/Aktion_03 Of course the pages are in German but look at the work tables and maybe the error lists. Maybe others could set up actions like these for other countries? I assure you to provide reports if needed and I am quite confident that a lot of our helpers would support these actions from here - if we get to know about the actions... Cheers Gerhard gary68 http://wiki.openstreetmap.org/wiki/User:Gary68 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Trunk oder primary
qbert biker schrieb: Was keinen Unterschied macht. Auch der Divider ist wirkungsvoll und einfach und versauert trotzdem. Ich denke unter kreuzungsfrei können sich ohne Erklärung mehr Leute was vorstellen als unter Divider... Das ist zwar häufig so, ist aber doch schon wieder etwas mehr hineininterpretiert als das Tag tatsächlich aussagen kann. Nö, man kann klare Definitionen treffen. An der benachbarten A35 im Elsass gibt es z.B. einseitige Autobahnausfahrten um teuere Überführungsbauwerke zu sparen. Kreuzen die etwas? Auf dem Mittleren Ring in M gibts auch Nein, man kommt dort nicht auf die andere Autobahnseite, dazu muss man ein paar Kilometer bis zum nächsten Kreuzungsbauwerk fahren. eine linksseitige Ausfahrt üeber die Gegenspur drüber und in den USA gibts das oft. Aber es gibt keine Ampel da und keinen kreuzenden Verkehr auf gleicher Ebene. Kreuzungsfreier Ausbau ist ein Prinzip, keine Beliebigkeit. Was allerdings beliebig ist, ist die Forderung nach der Überholspur, die an technischen Prinzip nichts ändert. Ja, eben oder - da kann kreuzungsfrei bedeuten dass hier mit sehr viel Verkehr - gegebenfalls mit viel Stau zu rechnen ist, Na eben - willst du als Mapper mittels Klassifizierung reinbringen, wie hoch das Verkehrsaufkommen ist? Soll man jetzt Bundesstrassen zu unclassified abwerten, weil sie chronisch überstaut sind? Ist ein Tag zum kreuzungsfreien Ausbau unnötig, weil ein Teil dieser Strassen manchmal überstaut ist? Meine Aussage ist dass kreuzungsfrei alleine noch kein ausreichendes Merkmal für trunk ist. Ausserdem gibt es dann nocht so Zwischenlösungen die halb Kreuzungsfrei sind - die kreuzende Strasse selbst ist mit einer Brücke kreuzungsfrei abgekoppelt, der Verbindungsverkehr zwischen den beiden Strassen wird aber per halbseitiger Kreuzung (Einmündungen mit Linksabbieger) angebunden. Für den durchgehenden Verkehr ergibt sich kaum ein Unterschied zur kreuzungsfreien Strasse, dennoch gibt es kreuzenden Verkehr durch die Linksabbieger. Und was ist auf den 10 km? Pampa, durchgehende Vorfahrt oder eine kreuzungsfrei ausgebaute Strasse? In den Gegenden, in denen es solche Strassen gibt, gibts auf der Alternativstrecke meist mehr als eine Ampel auf 10 km ;) Kommt darauf an wie grossräumig man es betrachtet. Such mal z.B. eine ideale Route vom Oberrhein in den Bodenseeraum... Nicht wirklich - ohne zu wissen wie die Daten entstanden sind kann man da ganz schön danben liegen Wenn man die Daten gar nicht nutzt, Strecken nach Gefühl und Belieben attributiert, liegt man sicher noch etwas mehr daneben. Das ist ein Problem der OSM-Philosophie - Regeln bilden sich quasi selbst und unterliegen einer ständigen Veränderung... schon alleine der Vergleich zwischen Hauptreisezeit und normalem Berufsverkehr zeigt da abschnittsweise erhebliche Differenzen - mit 10 oder 20 Tracks für einen Abschnitt kommt man da nicht weit. Wenn man nicht anfängt, kommt man nirgendwo hin. Es gibt Projekte, da wird aus den GPS-Daten einer Taxiflotte dynamisch ein Netzzustand errechnet und die Massen an tracks sollen nicht für eine statistische Annäherung reichen? Die gezielte Auswertung einer grossen Menge von Taxidaten ist ein bischen was anderes wie die Auswertung einer willkürlichen Tracksammlung mit unbekannter Entstehungsgeschichte. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Knicks (Wallhecken) einzeichnen
Robert S. schrieb: 2009/8/18 Christian H. Bruhn br...@arcor.de mailto:br...@arcor.de Hallo! Hier in Schleswig-Holstein sind Knicks sehr typisch in der Kulturlandschaft. Das sind Wallhecken zwischen den einzelnen Feldern und Wegen [1] [2]. SIe bieten im Freien auch eine gewisse Orientierung, daher finde ich, sollte man sie in OSM auch übernehmen. Wie tagt man diese am besten? Als Fläche eintragen (Breite 1 - 2 Meter) und dann natural=scrub. Halte ich für etwas überzogen jetzt auch schon Mauern als Flächen erfassen zu wollen. Wer will das den erfassen und anwenden? Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Knicks (Wallhecken) einzeichnen
Tobias Wendorff schrieb: Robert S. schrieb: Als Fläche eintragen (Breite 1 - 2 Meter) und dann natural=scrub. Das ist doch nichts natürliches? So wie ich das Wiki verstanden habe, wurden sie zur Grenzmarkierung abgelegt. Aus lange Weile? Warum sollte man dafür soviel Aufwand treiben? Die Erklärung die ich dafür kenne ist der Schutz vor Verwehungen in windreichen Gegenden. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Trunk oder primary
qbert biker schrieb: - Kein Querverkehr ist hoechstens 'kreuzungsfrei' und das kann ich auch in der Sahara ueber ein paar 100 km haben. Was man unter 'kreuzungsfreiem Ausbau' versteht, sind Bauwerke wie Bruecken und Rampen und das nicht zu knapp. Das ist dann aber ehr eine Angabe für den bautechnisch interessierten. Als Strassenbenutzer ist es mir relativ egal warum ich auf den nächsten -zig Kilometern keinen kreuzenden Verkehr habe. Wichtig ist da nur dass es so ist und ich diesbezüglich keinen Zeitverlust haben werde. Das ist keine xbeliebige Definition, sondern Stand der (Verkehrs-)technik und dazu gibts umfangreiches Wissen und Erfahrungen dazu. Uebrigends habe ich bei dieses ganzen trunk gegen primary Umwidmungen gut beobachten koennen, dass andere Tagger das sehr praezise erfassen und Begin und Ende des kreuzungsfreien Ausbaus gut ermitteln koennen. Nur ist das dann eben nach kurzer Zeit wieder geloescht, weil jemand meint, dass die zweite Spur fehlt und wieder primary draus macht... Das liegt ganz einfach daran dass trunk nicht geeignet ist kreuzungsfrei zu erfassen. Und die beobachtet Genauigkeit kommt wohl auch daher dass Kreuzungsfrei häufig mit Kraftfahrstrasse zusammenfällt (für einige immer noch das Merkmal für trunk) - da diese immer ausgeschildert ist ist es auch kein Wunder dass der Eindruck der genau erfassten Kreuzungsfreiheit entsteht Wenn ich mit gerinstem Zeitaufwand von A nach B muss interessiert mich der Ausbauzustand nur am Rande und ich wähle lieber eine wenig befahrene Nebenstrecke als eine kreuzungsfrei ausgebaute einspurige Hauptstrecke auf der ich dann bei Stau gefangen bin. Dagegen spricht ja nichts. Ich finde es nur schade, dass Informationen, die den anderen nutzen koennten, kleingeredet werden, weil man selber persoenliche Praeferenzen hat und lieber an zig Ampeln steht, als im Stau. Es geht mir nicht um das kleinreden der Erfassung von Kreuzungsfrei ausgebaut sondern darum dass z.b. kreuzungsfrei ausgebaute einspurige (je Richtung) Ortsumfahrungen nicht als trunk eingestuft werden. Sonst wird hier ein Zeitvorteil sugeriert den es so kaum gibt. Ein gutes Konzept loest die Ebenen auf und liefert die Informationen getrennt, so dass ich mir den Ausbauzustand ansehe und vielleicht spaeter mal die Belastungskurve und Stauneigung. Dann kann ich anhand meiner Praeferenzen meine eigenen Schluesse ziehen, die nicht von einem anderem schon vorgekaut sind. Wenn du versuchst, das alles plump mit einer groben Klassifizierung zu erschlagen, nimmst du den anderen die Moeglichkeit, eigende Praeferenzen zu setzen. Die highway-Klassifizierung war schon immer eine grobe Klassifizierung um eine schnelle und einfache Erfassung und Anwendung der Verkehrswege zu ermöglichen. Für die feinere Unterscheidung gibt es die Möglichkeit mit beliebig vielen Zusatztags jedes Detail zu erfassen..Gegebenfalls kann man dann in der Anwendung völlig auf die Auswertung des Highway-Tags verzichten während einfachere Anwendungen nach wie vor einfach nur den highway-Tag auswerten können. TomTom wirbt AFAIK gerade mit unabhaengig vom Ausbauzustand erfassten Verkehrszustaenden. Hier verliert OSM gerade mal wieder den Anschluss. Geworben wird mit viel wenn etwas verkauft werden soll - von TMC hat man sich auch viel versprochen, der zuverlässige(!) Nutzen ist ausgeblieben, insbesondere für Gelegenheitsnutzer ohne Ortskenntnis die dann gerne mal vom Regen in die Traufe geschickt werden. In den Fällen geht es auf den Ausweichstrecke dann in der Regel auch nicht schneller - schon gar nicht wenn die Ausweichstrecke vom Navi vorgeschlagen wird. Das ist eben die Kunst dabei. Mit vielen und differenzierten Informationen kann man die beste Route finden, mit Pauschalierungen ist man schon am Ende, bevor man angefangen hat. So schwarz-weiss ist die Welt hier nicht... Wenn der Routenplaner minutenlang braucht um aus tausenden von Details die optimale Route zu berechnen die dann wegen nicht erfasster Baustellen, Unfälle, etc dann doch wieder nicht eingehalten werden kann und neu berechnet werden muss dann kann der Gewinn in der praktischen Anwendung durchaus auch negativ ausfallen. Und nochmals: Ich will nicht die genaue Erfassung schlechtreden, ganz im Gegenteil! Aber die genauere Erfassung darf nicht zu Lasten der einfachen Lösungen gehen (umgekehrt natürlich auch nicht)! Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Trunk oder primary
qbert biker schrieb: Was keinen Unterschied macht. Auch der Divider ist wirkungsvoll und einfach und versauert trotzdem. Ich denke unter kreuzungsfrei können sich ohne Erklärung mehr Leute was vorstellen als unter Divider... Das ist zwar häufig so, ist aber doch schon wieder etwas mehr hineininterpretiert als das Tag tatsächlich aussagen kann. Nö, man kann klare Definitionen treffen. An der benachbarten A35 im Elsass gibt es z.B. einseitige Autobahnausfahrten um teuere Überführungsbauwerke zu sparen. Kreuzen die etwas? Auf dem Mittleren Ring in M gibts auch Nein, man kommt dort nicht auf die andere Autobahnseite, dazu muss man ein paar Kilometer bis zum nächsten Kreuzungsbauwerk fahren. eine linksseitige Ausfahrt üeber die Gegenspur drüber und in den USA gibts das oft. Aber es gibt keine Ampel da und keinen kreuzenden Verkehr auf gleicher Ebene. Kreuzungsfreier Ausbau ist ein Prinzip, keine Beliebigkeit. Was allerdings beliebig ist, ist die Forderung nach der Überholspur, die an technischen Prinzip nichts ändert. Ja, eben oder - da kann kreuzungsfrei bedeuten dass hier mit sehr viel Verkehr - gegebenfalls mit viel Stau zu rechnen ist, Na eben - willst du als Mapper mittels Klassifizierung reinbringen, wie hoch das Verkehrsaufkommen ist? Soll man jetzt Bundesstrassen zu unclassified abwerten, weil sie chronisch überstaut sind? Ist ein Tag zum kreuzungsfreien Ausbau unnötig, weil ein Teil dieser Strassen manchmal überstaut ist? Meine Aussage ist dass kreuzungsfrei alleine noch kein ausreichendes Merkmal für trunk ist. Ausserdem gibt es dann nocht so Zwischenlösungen die halb Kreuzungsfrei sind - die kreuzende Strasse selbst ist mit einer Brücke kreuzungsfrei abgekoppelt, der Verbindungsverkehr zwischen den beiden Strassen wird aber per halbseitiger Kreuzung (Einmündungen mit Linksabbieger) angebunden. Für den durchgehenden Verkehr ergibt sich kaum ein Unterschied zur kreuzungsfreien Strasse, dennoch gibt es kreuzenden Verkehr durch die Linksabbieger. Und was ist auf den 10 km? Pampa, durchgehende Vorfahrt oder eine kreuzungsfrei ausgebaute Strasse? In den Gegenden, in denen es solche Strassen gibt, gibts auf der Alternativstrecke meist mehr als eine Ampel auf 10 km ;) Kommt darauf an wie grossräumig man es betrachtet. Such mal z.B. eine ideale Route vom Oberrhein in den Bodenseeraum... Nicht wirklich - ohne zu wissen wie die Daten entstanden sind kann man da ganz schön danben liegen Wenn man die Daten gar nicht nutzt, Strecken nach Gefühl und Belieben attributiert, liegt man sicher noch etwas mehr daneben. Das ist ein Problem der OSM-Philosophie - Regeln bilden sich quasi selbst und unterliegen einer ständigen Veränderung... schon alleine der Vergleich zwischen Hauptreisezeit und normalem Berufsverkehr zeigt da abschnittsweise erhebliche Differenzen - mit 10 oder 20 Tracks für einen Abschnitt kommt man da nicht weit. Wenn man nicht anfängt, kommt man nirgendwo hin. Es gibt Projekte, da wird aus den GPS-Daten einer Taxiflotte dynamisch ein Netzzustand errechnet und die Massen an tracks sollen nicht für eine statistische Annäherung reichen? Die gezielte Auswertung einer grossen Menge von Taxidaten ist ein bischen was anderes wie die Auswertung einer willkürlichen Tracksammlung mit unbekannter Entstehungsgeschichte. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Postal_code oder addr:postcode
On Wed, Aug 19, 2009 at 11:58:34AM +0200, Peter Körner wrote: Im Gegenteil: Duplizierte Daten sind prima, wenn sie voneinander abweichen. Dann erkennt man nämlich sehr einfach, dass was nicht stimm und kann es fixen. Wenn man die Daten nur einmal hat und sie sind falsch, kann ich das nicht erkennen. :-) Das sehe ich anders. man bezieht sich hierbei nur auf ortskundige Menschen. Weder ein Ortsfremder noch ein elektronisches System (z.B. Routenplaner oder Navi) sind in der Lage, solche Konflikte aufzulösen. Aber die Mapper sind dazu in der Lage. Und es gibt Tools, die dabei helfen wie der OSM Inspector, Keepright, die Sachen von gary68 und andere mehr. Der Nutzer soll das natürlich nicht sehen. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Open Rhein Ruhr
Hi! Am 7. und 8. November 2009 ist in Bottrop die Open Rhein Ruhr (Kongress und Messe, http://openrheinruhr.de/). Der Call for Papers läuft noch bis zum 23.8. Will da vielleicht jemand einen Vortrag einreichen und/oder einen OSM-Stand organisieren? Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen überwechen
Am 18. August 2009 17:37 schrieb Florian Lohoff f...@rfc822.org: On Mon, Aug 17, 2009 at 04:42:15PM +0200, Matthias Versen wrote: Weit haeufiger als gekillt oder elemente entfernt werden bei den boundarys non-simple d.h. self-intersecting ways gebaut - Und _die_ sind weitaus schwieriger zu finden ... der geometrie-layer der Geofabrik zeigt die an. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Trunk oder primary
Original-Nachricht Datum: Wed, 19 Aug 2009 13:47:11 +0200 Von: Garry garr...@gmx.de An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Trunk oder primary qbert biker schrieb: - Kein Querverkehr ist hoechstens 'kreuzungsfrei' und das kann ich auch in der Sahara ueber ein paar 100 km haben. Was man unter 'kreuzungsfreiem Ausbau' versteht, sind Bauwerke wie Bruecken und Rampen und das nicht zu knapp. Das ist dann aber ehr eine Angabe für den bautechnisch interessierten. Nein, es ist das, was viele Verkehrsteilnehmer interessiert. Die Bruecken und Rampen werden ja nicht gebaut, dass sie von bautechnisch interessierten begutachtet werden, sondern von Verkehrsteilnehmern benutzt. Es ist der Unterschied zwischen 'da kreuzt eben keine Strasse' und 'da hat jemand ziemlich grossen Aufwand getrieben, dass man besser vorwarts kommt'. Und ums nochmal deutlich zu machen: Es geht hier um einen Basiswert der Reisezeitschaetzung, die typische erreichbare Geschwindigkeit ohne Betrachtung von Staus. Will man Staus mit einbeziehen, muss man eben Aufwand treiben und die Staugefahr ueber Fahrprofilauswertung einstufen. Simple Pauschalisierungen wie 'wenn keine zweite Spur da ist, steh ich eh im Stau' ohne Datenbasis kann man fuer sich selber treffen, aber bitte nicht fuer die andern. Wichtig ist da nur dass es so ist und ich diesbezüglich keinen Zeitverlust haben werde. Und das solltest du anhand der Daten selber entscheiden. Du kannst ja die Reiszeitschaetzung mit deinen Prioitaeten befuettern und dann spuckt sie aus, was dir behagt. Und die beobachtet Genauigkeit kommt wohl auch daher dass Kreuzungsfrei häufig mit Kraftfahrstrasse zusammenfällt (für einige immer noch das Merkmal für trunk) - da diese immer ausgeschildert ist ist es auch kein Wunder dass der Eindruck der genau erfassten Kreuzungsfreiheit entsteht Die Beispiele die ich meine haben nichts mit KFZ-Strasse zu tun. Ich kenne diese Strecken gut und fuer die Erfasser ist eben die Kreuzungsfreiheit ein objektives Kriterium, das sie erkennen und erfassen koennen. Es geht mir nicht um das kleinreden der Erfassung von Kreuzungsfrei ausgebaut sondern darum dass z.b. kreuzungsfrei ausgebaute einspurige (je Richtung) Ortsumfahrungen nicht als trunk eingestuft werden. Und mir darum, dass moeglichst wenig Info verloren geht und dass idealerweise kreuzungsfreiheit, KFZ-Strasse und Spuren unabhaengig voneinander attributiert werden. Es laeuft ja schon wieder auf so eine versteckte Regel hinaus, dass man von trunk gleich auf die Spuranzahl zurueckschliessen koennen soll, statt die Spuranzahl einfach richtig einzutragen. Sonst wird hier ein Zeitvorteil sugeriert den es so kaum gibt. Der Zeitvorteil ist da. Mit 80 ueber die kreuzungsfreie Landstrasse zu zuckeln ist fast immer schneller als durch die Kaeffer zu gurken. Für die feinere Unterscheidung gibt es die Möglichkeit mit beliebig vielen Zusatztags jedes Detail zu erfassen.. Bin ich ja auch uneingeschraenkt dafuer. Ich wuerde es gerne sehen, wenn trunk in D-Land gar nicht mehr verwendet wuerde, denn trunk bildet bei uns nicht mal ansatzweise eine Verbindungsklasse ab, eher Stueckwerk. Geworben wird mit viel wenn etwas verkauft werden soll - Es geht hier um eine ganz konkrete Anwendung. Die sammeln selber Fahrprofile und werten sie aus und koennen dann statistische Aussagen ueber die Belastung treffen. Das ist von der Aussage her viel stabiler als TMC, kann aber keine spontanen Staus 'sehen'. So schwarz-weiss ist die Welt hier nicht... Wenn der Routenplaner minutenlang braucht um aus Dazu gibts die Datenaufbereitung, die das Netz optimiert und die vielen Daten strukturiert, bevor der Datensatz dem Navi uebergeben wird. Info wegzulassen, weil das navi es nicht mehr schaffen koennte, ist eine sehr schlechte Idee, da geabe es ganz andere Optimierungsmoeglichkeiten. Ich will nicht die genaue Erfassung schlechtreden, ganz im Gegenteil! Aber die genauere Erfassung darf nicht zu Lasten der einfachen Lösungen gehen (umgekehrt natürlich auch nicht)! Aehem - was ist daran komplex, einer Strecke das Attribut mitzugeben, dass sie kreuzungsfrei ausgebaut ist? Gruesse Hubert -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wofuer alles Loecher in landuse
Am 18. August 2009 22:49 schrieb Tobias Wendorff tobias.wendo...@uni-dortmund.de: Christian H. Bruhn schrieb: Das layer-Tag finde ich in solchen Fällen unschön. Ich finde den Landuse-Layer mehr als grausam! Hier in Dortmund sieht es teiweise so aus, als wurde er auf einem LANDSAT-Bild vor 3 Jahren ganz grob gemacht. Jetzt gehen verschiedene Nutzungen mitten durch Gebiete, wo es nur eine Nutzung gibt. dazu ist es ja eine Wiki-Karte... Landuse könnte man geschickt auch automatisch erzeugen, indem man den Inhalt überprüft. Wenn Residential-Straßen mit enger Bebauung vorhanden sind = Wohngebiet ec. -1. Am ehesten geht es mit residential, aber auch da ist das Ergebnis m.E. nicht zufriedenstellen, insb. an den Rändern zum unbebauten Gebiet. Wozu sollte man das tun? Wir haben doch genügend Mapper, die diese Dinge eintragen können, von Namen und anderen tags mal abgesehen, die Du nie automatisch hinzufügen willst. Wenn man Landuse denn schon manuell macht, dann sollte man auch irgendwelche Qualitätschecks einführen, die das aktuell halten. m.E. ändert sich das noch wesentlich seltener als z.B. Einbahnstraßenregelungen. Ist nicht mehr Thema als bei anderen Daten auch, tendenziell aber eher weniger als bei anderen Daten. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wofuer alles Loecher in landuse
Am 18. August 2009 23:01 schrieb Robert S. osm-m...@autobahnen-europa.eu: 2009/8/18 Christian H. Bruhn br...@arcor.de Meist fange ich bei Orten an rund um die Wohnbebauung ein landuse=residential. ich habe zum Thema Mischgebiet und Kerngebiet vor längerem mal einen Vorschlag im Wiki gemacht (eigentlich nur zu Kerngebiet, Definition s. BauNVO). http://wiki.openstreetmap.org/wiki/Proposed_features/centre_zone auch wenn das vielleicht noch nicht das Gelbe vom Ei ist, sollte man m.E. in die Richtung Mischgebiet/Kerngebiet weiter arbeiten, um nicht alles als residential zu kennzeichnen (und damit einige Abstufungen zu unterschlagen). Wie sieht es da es aus, wenn dort z.B. ein Park, Sportplatz oder ein Parkplatz ist. Spart man diese Flächen mittels Multipolygon aus dem residential aus? Ja, per Multipolygon. Ausgeschnitten werden muss aber nur, was nicht zu so einem Gebiet gehört. +1. M.E. besser sind mehrere kleinere residential-areas, die jeweils eigene/abgeschlossene/zusammengehörige Gebiete bezeichnen, da braucht man dann auch weniger Relationen, kann lokale Namen hinzufügen, etc. Also zu einem Wohngebiet gehören auch Parkplätze und Spielplätze oder auch Schulgelände, die müssen dann nicht ausgeschnitten werden. je nachdem. Ein Schulgelände IM Wohngebiet muss nicht ausgeschnitten werden, aber nicht jedes Schulgelände ist automatisch landuse=residential, und auch bei Parkplätzen kommt es drauf an, ob sie zum Wohngebiet gehören oder zu was anderem. Wenn in einem Wohngebiet nun aber ein Industriebetrieb liegt, muss dem sein landuse=industrial natürlich ausgeschnitten werden. Das layer-Tag finde ich in solchen Fällen unschön. layer ist in diesem Fall schlichtweg falsch! ja, leider gibt es beim rendern ohne allerdings Probleme. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vermessung der Höhen von Hessen
Am 19. August 2009 00:29 schrieb Tobias Wendorff tobias.wendo...@uni-dortmund.de: Viele LVAs gestatten mittlerweile ein Freikaufen der Daten. Allerdings für OSM-User unbezahlbar :-) wir brauchen allerdings nicht sämtliche Höhenfixpunkte, ausreichen tut doch in der Regel einer. Wenn man auf dessen Basis andere Punkte festlegt, kann man die doch in OSM über nehmen, oder übersehe ich das was? 1 Punkt kostet so zwischen 3,50 und 12 EUR (kann evtl. auch je nach LVA mehr schwanken). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wofuer alles Loecher in landuse
Martin Koppenhoefer schrieb: dazu ist es ja eine Wiki-Karte... ... die aber an wichtigeren Stellen Lücken hat, die ich eher füllen will. Landuse könnte man geschickt auch automatisch erzeugen, indem man den Inhalt überprüft. Wenn Residential-Straßen mit enger Bebauung vorhanden sind = Wohngebiet ec. -1. Am ehesten geht es mit residential, aber auch da ist das Ergebnis m.E. nicht zufriedenstellen, insb. an den Rändern zum unbebauten Gebiet. Wozu sollte man das tun? Wir haben doch genügend Mapper, die diese Dinge eintragen können, von Namen und anderen tags mal abgesehen, die Du nie automatisch hinzufügen willst. Könnten, aber mal ernst: Setzt Du Dich gerne hin, schätzt und korrigierst Landuses? Man sollte vielleicht zwischen temporären und finalen Landuses unterscheiden: Temporäre Landuses sind Bereiche, in denen man die Nutzung schätzt und sie nur grob einzeichnet. Wenn dann jemand konkreter wird und die genauen Straßen (etc.) einzeichnet, ersetzt er diese gegen finaleren, darf die vorhandenen aber vorher löschen. Hier in Dortmund haben wir jetzt Leichen, die aufgrund ihrer Großflächigkeit kaum noch gut bearbeitbar sind. Vorallem, weil sie über Nodes drüberschweben und man bei jedem Node erst reinzoomen muss, um nicht aus versehen eine Straße anzufassen. Wenn man Landuse denn schon manuell macht, dann sollte man auch irgendwelche Qualitätschecks einführen, die das aktuell halten. m.E. ändert sich das noch wesentlich seltener als z.B. Einbahnstraßenregelungen. Ist nicht mehr Thema als bei anderen Daten auch, tendenziell aber eher weniger als bei anderen Daten. Es geht mir nicht um Änderungen, sondern erstmal um eine Basis zu schaffen. Ich bin der Meinung, Landuse kann man erst bestimmen, wenn wirklich jemand da war. Luftbilder alleine reichen da nicht, vorallem Landsat aus dem 2006er OSM-Bestand nicht. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Briest - Wohnstraße anstatt an die Stadt Havelsee an Libanese versteigert
Privatmann trickst Amt aus http://www.maerkischeallgemeine.de/cms/beitrag/11584851/60889/Fuer-Euro-geht-eine-Strasse-in-Briest-der.html - Am Mühlenberg, Briest Vielleicht kommt jemand dort vorbei und kann die Straße mal einzeichnen, damit der neue Besitzer sie auch findet. ;-) http://sautter.com/map/?lat=52.4369lon=12.42762zoom=16layers=B0TF Ciao André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Open Rhein Ruhr
Jochen Topf schrieb: Am 7. und 8. November 2009 ist in Bottrop die Open Rhein Ruhr (Kongress und Messe, http://openrheinruhr.de/). Der Call for Papers läuft noch bis zum 23.8. Will da vielleicht jemand einen Vortrag einreichen und/oder einen OSM-Stand organisieren? MMh, je nachdem wie sich das Treffen morgen und mein mein Lizenz-Artikel entwickelt, hätte ich gerne was eingereicht - aber 4 Tage sind mir echt zu wenig :-( ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Trunk oder primary
Original-Nachricht Datum: Wed, 19 Aug 2009 13:45:34 +0200 Von: Garry garr...@gmx.de An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Trunk oder primary Ich denke unter kreuzungsfrei können sich ohne Erklärung mehr Leute was vorstellen als unter Divider... Die beiden beschreiben Unterschiedliches. Der eine, was in der Mitte der Strasse, also zwischen den Richtungsfahrbahnen und der andere, dass ein Abschnitt durchgaengig ueber Rampen und Bruecken beschleunigt wurde. Meine Aussage ist dass kreuzungsfrei alleine noch kein ausreichendes Merkmal für trunk ist. Ein paar links dazu: http://www.openstreetmap.org/?lat=48.0032lon=10.7342zoom=13layers=B000FTF Die B12 hier, die von der Autobahn abgeht ist die wichtigste Verkehrsader der Region, aber nicht wirklich mehrspurig ausgebaut (man kommt aber aneinander vorbei). Geht die noch als trunk durch? http://www.openstreetmap.org/?lat=47.8524lon=12.1398zoom=14layers=B000FTF Die St2095 in Rosenheim is eine gut ausgebaute Umgehung mit einer Spur/Richtung und faellt, weil Staatsstrasse, auf secondary zurueck. Die B15 ist schoen rot und quaelt sich mitten durch die Stadt mit permaneten Ampelstau. Aber andersrum gibts auch: http://www.openstreetmap.org/?lat=48.3592lon=11.8718zoom=13layers=B000FTF Hier sind wir bei Erding und die Staatsstrassen St5080 ist 'nur' Staatsstrasse und bindet Autobahn und Grossflughafen an das Hinterland an. Eine Anbindung an eine weitere Autobahn ist in Bau. Soll die secondary sein, obwohl sie die Hauptverbindung in der Region ist, nur weil sie nur eine Spur/Richtung hat? Mir ist trunk soweit egal, aber irgendwie funktioniert das Konzept einfach nicht. Die Hirarchie beim Ausbau von Strassen ist typischerweise: 'normale Strasse' kreuzungsfrei ausgebaut 1 Spur/Richtung kreuzungsfrei ausgebaut 2+ Spuren/Richtung Autobahn Und die wird nicht wirklich gut ueber das derzeitige Modell abgebildet. Oft genug wird auch beim kreuzungsfreien Ausbau erst spaeter die zweite Spur dazugebaut. Gruesse Hubert -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - 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
Re: [Talk-de] Vermessung der Höhen von Hessen
Martin Koppenhoefer schrieb: wir brauchen allerdings nicht sämtliche Höhenfixpunkte, ausreichen tut doch in der Regel einer. Wenn man auf dessen Basis andere Punkte festlegt, kann man die doch in OSM über nehmen, oder übersehe ich das was? 1 Punkt kostet so zwischen 3,50 und 12 EUR (kann evtl. auch je nach LVA mehr schwanken). Ja, darum haben wir uns das auch mit der Basisstation überlegt, die man an einem festen Punkt installiert. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Warum immer die ...more OSM coming soon Kacheln
Am 19. August 2009 09:58 schrieb Adiac teamad...@gmx.de: Am Sonntag 16 August 2009 09:32:29 schrieb Jens von Elling: In letzter Zeit gibt?s immer wieder diese häßlichen more OSM coming soon Kacheln. Das kann ich bei der höchsten Zoomstufe bestätigen. Dann wollte ich mir diese eine Kachel anschauen, die dann auch nicht da war. Beim klick auf den Zurück-Button war ich leider wieder ganz woanders. Kleiner Tipp: permalink anclicken, danach die Seite neu laden. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Briest - Wohnstraße anstatt an die Stadt Havelsee an Libanese versteigert
André Riedel schrieb: Privatmann trickst Amt aus http://www.maerkischeallgemeine.de/cms/beitrag/11584851/60889/Fuer-Euro-geht-eine-Strasse-in-Briest-der.html Sauber :-) Das mit dem Kanalnetz erinnert mich an Recklinghausen ... die Stadt musste es teuer von einem Investor wieder zurück kaufen :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummerntool?
Am 18. August 2009 19:07 schrieb Peter Herison pheri...@web.de: Martin Koppenhoefer schrieb: Am 17. August 2009 20:46 schrieb Carsten Gerlach daswaldh...@gmx.de: Woher kennst du die Nummern der Grundstücke, wenn da noch kein Haus steht, welches ein Schild mit der Nummer tragen würde? zum Beispiel, indem das Grundstück links davon 11 hat und rechts davon 9, dann hat das unbebaute Grundstück 10. Und woher weisst Du, dass da nicht 2 Doppelhaeuser mit 10-10c hinkommen? z.B. aus dem Baubauungsplan. Auch aus den örtlichen Gegegebenheiten. 2 Doppelhäuser erfordern i.d.R. 4 Grundstücke (Ausnahme: wenn es groß genug ist, kann man auch eins aufteilen, das wird aber bei neu parzellierten Gebieten eher nicht vorkommen, da nicht groß genug). Üblicherweise ein Grundstück=1 Nummer. Wie schlimm wäre es denn, wenn das unbebaute Grundstück erstmal die Nummer 10 erhält (also richtig zum aktuellen Zeitpunkt), und wenn dann tatsächlich irgendwann mal 2 Doppelhäuser da hingebaut werden, macht man daraus 10a-10d ? Solange an dem Haus / den Haeusern keine Nummern dran sind wuerde ich auch keine eintragen. wenn man überhaupt keine Anhaltspunkte hat, dann natürlich nicht, wenn man sich dagegen sicher ist, warum denn nicht? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Trunk oder primary
Moin, Robert S. schrieb: 2009/8/17 Martin Koppenhoefer dieterdre...@gmail.com Am 17. August 2009 14:27 schrieb Robert S. osm-m...@autobahnen-europa.eu : Wobei ich inzwischen von trunk=autobahnänlich zu trunk=kreuzungsfrei umgeschwenkt bin; autobahnänlich kann durch 2 oneway-trunks nebeneinander (sprich baulich getrennte Fahrtrichtungen) dargestellt werden. autobahnähnlich ist doch kreuzungsfrei, inwiefern bist Du da umgeschwenkt? Autobahnähnlich ist kreuzungsfrei UND richtungsgetrennt. Zumindest Wikipedia schreibt das im ersten Satz: Unter einer autobahnähnlichen Straße versteht man in Deutschland eine Straße, die durch Kreuzungsfreiheit, nicht notwendigerweise baulich getrennte Richtungsfahrbahnen und Beschilderung einer Autobahn ähnelt. http://de.wikipedia.org/wiki/Autobahn%C3%A4hnliche_Stra%C3%9Fe Sowohl Wikipedia wie auch die OSM-Wiki berufen sich als Quelle auf die RWB, und dort ist eine autobahnähnliche Straße explizit als zweibahnige Straße definiert. wort- und sinngemäß gebe ich Dir recht, aber: Ich kenne diverse kreuzungsfrei ausgebaute Stellen, die gemäß RWB mit den Zeichen 332 und 333 in gelb ausgeschildert sind, aber weder - 2-bahnig - baulich getrennt - mehr als 1 Fahrspur je Fahrtrichtung erfüllen. Da zum 1. September 2009 ja die neue StVO in Kraft tritt, ist demzufolge wohl auch http://www.umwelt-online.de/PDFBR/2009/0154_2D09.pdf und dort insbesondere Punkt 114 Absatz 1 auf Seite 67 vom Bundesrat ratifiziert worden. Entweder werden an allen solchen Stellen zukünftig die Zeichen 333 entfernt oder es gilt wohl im Umkehrschluss ((kreuzungsfrei UND Richtungstrennung durch durchgezogene Linie) == autobahnähnlich ausgebaut). Bald wissen wir mehr ... (Wehe die reden sich raus, angeordnet werden sei ja Zukunft - und belassen die Altlasten!) ;-) Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Knicks (Wallhecken) einzeichnen
Am 18. August 2009 22:51 schrieb Robert S. osm-m...@autobahnen-europa.eu: 2009/8/18 Tobias Wendorff tobias.wendo...@uni-dortmund.de Robert S. schrieb: Als Fläche eintragen (Breite 1 - 2 Meter) und dann natural=scrub. Das ist doch nichts natürliches? So wie ich das Wiki verstanden habe, wurden sie zur Grenzmarkierung abgelegt. Wie kommst Du denn auf scrup? Unsere Wiki sagt, das ist für Unterholz / Busch und JOSM nutzt das für Buschland. Sowas kommt von allen (existierenden) Tags so einer Hecke am nähsten. Nein, m.E. nicht. Buschland/Unterholz hat mit einer Hecke auf einem Wall nichts zu tun. Ich halte auch barrier für das bessere tag. Wenn man (evtl. zusätzlich und je nach Breite und Breitenänderung) auch eine Fläche markieren will, sollte man dafür was neues erfinden und nicht was Existierendes mit einer anderen Bedeutung aber einem Rendering, das evtl. OK sein könnte. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Knicks (Wallhecken) einzeichnen
Am 19. August 2009 13:45 schrieb Garry garr...@gmx.de: Halte ich für etwas überzogen jetzt auch schon Mauern als Flächen erfassen zu wollen. Wer will das den erfassen und anwenden? kommt auf die Mauer an: http://maps.google.it/maps?hl=deie=UTF8ll=41.873967,12.493593spn=0.000897,0.00239t=kz=19 (habe ich noch als Linie drin, wird aber irgendwann man eine Fläche werden). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Knicks (Wallhecken) einzeichnen
Martin Koppenhoefer schrieb: Nein, m.E. nicht. Buschland/Unterholz hat mit einer Hecke auf einem Wall nichts zu tun. Ich halte auch barrier für das bessere tag. Wenn man (evtl. zusätzlich und je nach Breite und Breitenänderung) auch eine Fläche markieren will, sollte man dafür was neues erfinden und nicht was Existierendes mit einer anderen Bedeutung aber einem Rendering, das evtl. OK sein könnte. Wenn man es als Fläche markieren will, hat man aber automatisch das nächste Problem: Wem gehört die Fläche? [Bauer 1][Wall][Bauer 2][Wall] Es ist doch sicherlich viel mehr: [Bauer 1, Wall][Bauer 2, Wall] ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Knicks (Wallhecken) einzeichnen
Nein, m.E. nicht. Buschland/Unterholz hat mit einer Hecke auf einem Wall nichts zu tun. Ich halte auch barrier für das bessere tag. Wenn man (evtl. zusätzlich und je nach Breite und Breitenänderung) auch eine Fläche markieren will, sollte man dafür was neues erfinden und nicht was Existierendes mit einer anderen Bedeutung aber einem Rendering, das evtl. OK sein könnte. Dafür gibt's den width=-Tag Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Knicks (Wallhecken) einzeichnen
Martin Koppenhoefer schrieb: kommt auf die Mauer an: http://maps.google.it/maps?hl=deie=UTF8ll=41.873967,12.493593spn=0.000897,0.00239t=kz=19 (habe ich noch als Linie drin, wird aber irgendwann man eine Fläche werden). Da könnte man sogar mit etwas Geduld die Höhe der einzelnen Türme aus den Fotos ableiten :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Warum immer die ...more OSM coming soon Kacheln
Hallo, da es doch immer wieder Fragen zum rendering gibt wollte ich noch mal kurz den ganzen mapnik Prozess beschreiben um hoffentlich etwas Klarheit zu schaffen, den die Ergebnisse sind aus Usersicht wirklich nicht immer offensichtlich. Wenn sich ein User eine Gegend auf der Karte anschaut und tiles vom Server anfordert, schaut dieser (der Server), ob die tiles bereits gerendert wurden und sie auf aktuellen Daten basieren. Wenn sie es tun, ist alles in Ordnung und werden an den User uebertragen. Wenn einer der tiles zwar vorhanden ist, aber alt ist, versucht der Server die tile on-the-fly neu zu renderen vorausgesetzt er ist nicht zu beschaeftigt (basierend auf load average). Ansonsten wird sofort die alte tile uebertragen und ein Vermerk in einer Warteschlange gemacht das diese tile neu gerendert werden muss. Dies geschieht dann im Hintergrund der Reihe nach und kann bis zu 10 - 15 Minuten dauern. Fuer das on-the-fly rendering gibt es jedoch einen 3 Sekunden timeout, nachdem wiederum die alte tile herausgegeben wird. Ich weis zwar nicht was der Grenzwert des load averages ist, aber ich wuerde sagen das dieser tags ueber fast immer ueberschritten ist. Somit sind dann die tiles erst bei der zweiten Ansicht ein paar Minuten spaeter aktuell. Wenn eine tile gar nicht vorhanden ist, passiert im Prinzip das gleiche nur das der load average Grenzwert etwas hoeher ist, da es nicht die Möglichkeit gibt auf eine alte tile zurueck zu fallen. Aber auch dieser ist zu Stosszeiten vermutlich haeufig ueberschritten, woraufhin man dann die more OSM coming soon... tiles bekommt. Das updaten der rendering Datenbank, (sie ist separat von der haupt OSM Datenbank), geschieht per minutely-diff. Somit sind diese Daten ca. 5 - 10 Minuten hinter dem Stand der haupt Datenbank. Beim updaten der Datenbank wird gleichzeitig all die tiles die betroffen sind als dirty markiert, also als alt. Damit werden sie das naechste mal wenn sie betrachtet werden, wie oben beschrieben, neu gerendert, jedoch nicht vorher. Ausserdem werden nur die zoom stufen 10 und hoeher als dirty markiert. Low zoom tiles werden nicht automatisch durch die minutely tiles upgedatet und koennen somit ein paar Wochen alt sein. Mit den minutely diffs gibt es leider jedoch Probleme und es werden immer mal wieder Daten verschluckt die in sehr grossen changesets hochgeladen wurden. Ausserdem habe ich gehoert das es moeglicherweise Probleme mit Multi-Polygonen und den imports der minutely-difs gibt. Des weiteren veraendert sich auch gelegentlich das rendering style sheet welches dann das neu rendern aller tiles benoetigt. Insofern werden in unregelmaessigen Intervallen (alle paar Wochen) die gesamte rendering Datenbank neu importiert. Dies dauert jedoch inzwischen fast 24 Stunden und bis die Datenbank neu geladen ist koennen in der Zwischenzeit keinerlei tiles neu gerendert werden auch fehlende tiles nicht. Des weiteren, nach einem gesamt Import sind automatisch alle tiles als dirty markiert (inklusive der low zoom tiles), somit muessen sie auch alle ploetzlich neu gerendert werden. Da das nicht auf einen Schlag passieren kann, ist in der Zeit nach einem Import der rendering Server vollkommen ueberlastet. Da auch die Warteschlangen eine sehr begrenzte Länge von 1000 (meta)tiles haben, werde in der Zeit auch viele tiles die eigentlich neu gerendert werden sollten auch im Hintergrund nicht neu gerendert und sie muessen ein weiteres mal besucht werden bevor sie moeglicherweise gerendert werden. Bis sich das ganze wieder einigermassen stabilisiert hat vergehen schon ein paar Tage, sodass nach dem Import fast eine ganze Woche vergeht bis sich das ganze wieder vollkommen eingependelt hat. In der Zeit ist es dann nicht voraussagbar was neu gerendert wird und wann das geschieht. Wer mehr Informationen erhalten moechte wie es um die Performance des tile servers steht kann unter http://munin.openstreetmap.org/openstreetmap/tile.openstreetmap.html nach schauen. Dort kann man auch sehen wie viele tiles gerade gerendert werden und welcher Prozentsatz davon on-the-fly gerendert werden, bzw. ob die Queues voll sind. Insgesamt fuert dieses Komplexe System also zu einigen sichtbaren Artefakten in den Karten. In sich schnell aendernden Gegenden, kann es immer wieder dazu kommen das benachbarte tiles unterschiedlichen Alters sind und somit neue Wege ploetzlich an Tilegrenzen aufhoeren, versetzt oder sonst wie inkonsistent sind. Meist sind diese Probleme dann behoben wenn man in einer halben Stunde noch mal nachschaut, da dann der Hintergrund Prozess die tiles neu gerendert hat. Machmal kann es aber eben auch schon mal tage dauern bis alles wieder fluessig laueft und uptodate ist. Hinzu kommt dann noch das aus Performance Gruenden (sowohl Server als auch client seitig) die tiles zum Teil in Proxy servern und im browser cache zwischen gespeichert werden. Aber das beschreibe ich jetzt nicht mehr, da sonst die email
Re: [Talk-de] Wofuer alles Loecher in landuse
Am 19. August 2009 14:52 schrieb Tobias Wendorff tobias.wendo...@uni-dortmund.de: Martin Koppenhoefer schrieb: dazu ist es ja eine Wiki-Karte... ... die aber an wichtigeren Stellen Lücken hat, die ich eher füllen will. tja, dann beschwer Dich nicht und warte, bis jemand anderes es macht ;-) Temporäre Landuses sind Bereiche, in denen man die Nutzung schätzt und sie nur grob einzeichnet. Wenn dann jemand konkreter wird und die genauen Straßen (etc.) einzeichnet, ersetzt er diese gegen finaleren, darf die vorhandenen aber vorher löschen. alle unsere Daten sind insofern temporär, als man sie fast immer verfeinern kann (vielleicht von Roßleben mal abgesehen ;-) ). Hier in Dortmund haben wir jetzt Leichen, die aufgrund ihrer Großflächigkeit kaum noch gut bearbeitbar sind. Vorallem, weil sie über Nodes drüberschweben und man bei jedem Node erst reinzoomen muss, um nicht aus versehen eine Straße anzufassen. ja, reinzoomen ist grundsätzlich zu empfehlen. M.E. regst Du Dich darüber auf, dass mit zunehmender Detailfülle auch die Komplexität beim Bearbeiten gestiegen ist, aber das ist m.E. zwangsläufig. Ich empfehle für landuses, diese möglichst kleinteilig zu halten (einzelne kleine Gebiete), und daher für Deinen Fall: erstmal das große Monster in mehrere kleinere zerlegen, dann findet sich vermutlich auch eher jemand, der da Korrekturen vornimmt. m.E. ändert sich das noch wesentlich seltener als z.B. Einbahnstraßenregelungen. Ist nicht mehr Thema als bei anderen Daten auch, tendenziell aber eher weniger als bei anderen Daten. Es geht mir nicht um Änderungen, sondern erstmal um eine Basis zu schaffen. Ich bin der Meinung, Landuse kann man erst bestimmen, wenn wirklich jemand da war. Luftbilder alleine reichen da nicht, vorallem Landsat aus dem 2006er OSM-Bestand nicht. ja, sehe ich auch so, Felder, Gärten, Wohnhäuser kann man in Luftbildern noch gut erkennen, aber viel geht nur vor Ort. Ich war ja von Anfang an dagegen, erstmal großflächig pauschale (und damit im Detail falsche) Landuses einzutragen, das führt ja zwangsläufig zu den von Dir geschilderten Problemen (vor allem, wenn man bei Ergänzen von Details bestehende Landuses nicht auch verfeinert/korrigiert). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wofuer alles Loecher in landuse
Martin Koppenhoefer schrieb: ja, reinzoomen ist grundsätzlich zu empfehlen. M.E. regst Du Dich darüber auf, dass mit zunehmender Detailfülle auch die Komplexität beim Bearbeiten gestiegen ist, aber das ist m.E. zwangsläufig. Ich empfehle für landuses, diese möglichst kleinteilig zu halten (einzelne kleine Gebiete), und daher für Deinen Fall: erstmal das große Monster in mehrere kleinere zerlegen, dann findet sich vermutlich auch eher jemand, der da Korrekturen vornimmt. Das sind aber im Endeffekt nur Meta-Informationen ... Dürfen die denn wenigstens gemeinsame Nodes haben? m.E. ändert sich das noch wesentlich seltener als z.B. Einbahnstraßenregelungen. Ist nicht mehr Thema als bei anderen Daten auch, tendenziell aber eher weniger als bei anderen Daten. Es geht mir nicht um Änderungen, sondern erstmal um eine Basis zu schaffen. Ich bin der Meinung, Landuse kann man erst bestimmen, wenn wirklich jemand da war. Luftbilder alleine reichen da nicht, vorallem Landsat aus dem 2006er OSM-Bestand nicht. ja, sehe ich auch so, Felder, Gärten, Wohnhäuser kann man in Luftbildern noch gut erkennen, aber viel geht nur vor Ort. Ich war ja von Anfang an dagegen, erstmal großflächig pauschale (und damit im Detail falsche) Landuses einzutragen, das führt ja zwangsläufig zu den von Dir geschilderten Problemen (vor allem, wenn man bei Ergänzen von Details bestehende Landuses nicht auch verfeinert/korrigiert). Wenn ich mir die Flächennutzungskartierung des RVRs ansehe, verstehe ich die Kosten - bei dem Aufwand... die geben u.a. Schrägluftbilder in Auftrag: Objektklassengenauigkeit: 150 Klassen - Kein Kommentar :-)) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Knicks (Wallhecken) einzeichnen
Am 19. August 2009 15:30 schrieb Tobias Wendorff tobias.wendo...@uni-dortmund.de: Martin Koppenhoefer schrieb: kommt auf die Mauer an: http://maps.google.it/maps?hl=deie=UTF8ll=41.873967,12.493593spn=0.000897,0.00239t=kz=19 (habe ich noch als Linie drin, wird aber irgendwann man eine Fläche werden). Da könnte man sogar mit etwas Geduld die Höhe der einzelnen Türme aus den Fotos ableiten :-) könnte man, ja, interessanter sind aber sicher erstmal die Tore: http://maps.google.it/maps?hl=deie=UTF8t=kll=41.873486,12.501827spn=0.000897,0.00239z=19 die haben Namen und sind oft auch skulptural dekoriert / ornamentiert. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wofuer alles Loecher in landuse
Am 19. August 2009 15:53 schrieb Tobias Wendorff tobias.wendo...@uni-dortmund.de: Wenn ich mir die Flächennutzungskartierung des RVRs ansehe, verstehe ich die Kosten - bei dem Aufwand... die geben u.a. Schrägluftbilder in Auftrag: Objektklassengenauigkeit: 150 Klassen - Kein Kommentar :-)) was aber m.E. eindeutig dafür spricht, dass wir auch genauer differenzieren. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Trunk oder primary
Am 18. August 2009 18:00 schrieb Garry garr...@gmx.de: oder kreuzungsfreie baulich getrennte 1-spurige Straßen, die sowohl langsamen Verkehr aber auch LKWs ausschließen? Kommt evtl. bei Platzmangel mal vor. Zu sehr Sonderfall Wenn kreuzungsfrei, Kraftfahrstrasse mit LKW-Verbot dann trunk als dass diese Ausnahme wirklich einen Mehrwert bringt. gemeint war, dass man im Einzelfall durchaus immer die Freiheit hat, aus gutem Grund von der Hauptdefinition abzuweichen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wofuer alles Loecher in landuse
Martin Koppenhoefer schrieb: Objektklassengenauigkeit: 150 Klassen - Kein Kommentar :-)) was aber m.E. eindeutig dafür spricht, dass wir auch genauer differenzieren. Ja, aber die vermischen das nicht alles in einem Werk. Das nervt mich. Auf einen eigenen Layer - das wäre eine Möglichkeit, oder OpenLanduseMap. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Warum immer die ...more OSM coming soon Kacheln
2009/8/19 Kai Krueger kakrue...@gmail.com Das updaten der rendering Datenbank, (sie ist separat von der haupt OSM Datenbank), geschieht per minutely-diff. Somit sind diese Daten ca. 5 - 10 Minuten hinter dem Stand der haupt Datenbank. Wer nach seinen Bearbeitungen ein schnelles Erfolgserlebnis haben will, kann nach den besagten 5 - 10 Minuten auch über den Export-Tab einen Bereich individuell gerendert bekommen. Wenn der 'load average' des Servers zu Groß ist, wird das allerdings abgelehnt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wofuer alles Loecher in landuse
Am 19. August 2009 16:00 schrieb Tobias Wendorff tobias.wendo...@uni-dortmund.de: Martin Koppenhoefer schrieb: Objektklassengenauigkeit: 150 Klassen - Kein Kommentar :-)) was aber m.E. eindeutig dafür spricht, dass wir auch genauer differenzieren. Ja, aber die vermischen das nicht alles in einem Werk. Das nervt mich. Auf einen eigenen Layer - das wäre eine Möglichkeit, oder OpenLanduseMap. ja, und open pedestrian-map, open-military-map, open watermap, open bordermap, open Hausnummermap, open ... ?? Wenn die Landuses erstmal in einem anderen Projekt verschwinden, gibt es m.E. erst Recht Inkosistenzen und Probleme. Ich bleibe bei meinem Statement: ja, reinzoomen ist grundsätzlich zu empfehlen. M.E. regst Du Dich darüber auf, dass mit zunehmender Detailfülle auch die Komplexität beim Bearbeiten gestiegen ist, aber das ist m.E. zwangsläufig. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wofuer alles Loecher in landuse
Martin Koppenhoefer schrieb: ja, reinzoomen ist grundsätzlich zu empfehlen. M.E. regst Du Dich darüber auf, dass mit zunehmender Detailfülle auch die Komplexität beim Bearbeiten gestiegen ist, aber das ist m.E. zwangsläufig. Nein, ich rege mich darüber auf, dass den Mist keiner mehr fixed. Wenn man es jedoch fixen will, *dann* wird es aufgrund der Komplexität schwerer. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neues ÖPNV-Schema - Linien(varianten )relationen
Claudius claudiu...@gmx.de wrote: Aus gegebenem Anlass habe mir gerade nochmal die Linienerfassung laut neuem ÖPNV-Schema durchgelesen und bin etwas unsicher, ob meine Tramlinienerfassung so richtig ist: Auch ich versuche mich gerade an dem neuen Konzept mit Potlatch, und zwar für Busse. In der Beschreibung des Schemas kommt bei Relationen type=* nicht mehr vor. Ist das nicht notwendig? Eine Endhaltestelle ist gleichzeitig Starthaltestelle für die Gegenrichtung. Ich muss jetzt zwei Relationen erstellen mit from:A-Stadt to:B-Stadt, sowie from:B-Stadt to:A-Stadt. Diese beiden Relationen erscheinen lediglich unter dem lapidaren Namen Relation. Wenn jetzt an dieser Haltestelle mehrere Buslinien abfahren, habe ich mehrere solcher lapidar beschrifteter Relationen, ohne nur die geringste Ahnung zu haben, welche dieser Relationen jetzt zu welcher Buslinie gehört. Wie also soll das funktionieren, insbesondere wenn jemand Anderes diese Relationen erstellt hat und ich diese nicht nachvollziehen kann? Nach dem neuen Haltestellenkonzept muss ich mehrfach in die nodes und die Überrelationen bus eintragen. Ist da die Inkonsistenz nicht schon vorprogrammiert? In den Großstädten mögen ja genügend Mapper sein, um das Konzept umzusetzen. Hier auf dem Land kann man froh sein, wenn überhaupt jemand die Busse taggt. Bei Straßen mag es einfach sein, mal eben einen Stadtteil zu mappen. Bei den Bussen ist das etwas Anderes. Da braucht man die Mitarbeit vieler Ortskundiger, um den Verlauf einer einzigen Linie zu rekonstruieren. Und hier fährt wegen des schlechten Angebotes kaum jemand mit dem Bus. Man kann also froh sein, wenn sich überhaupt jemand eine Teilstrecke kennt und sich dann noch erbarmt. Und ob gerade derjenige dann auch das im Vergleich zum alten Konzept das neue erheblich weniger intuitive versteht? Meist schaut man sich das Tagging in der Nachbarschaft an und lernt so, wie es funktioniert. Ich versuche gerade, die auf weiter Flur erste Buslinie als Samenkorn zu legen, obwohl ich selbst nur einmal vor über zehn Jahren gefahren bin. Wenn aber schon eine popelige zweiseitige Bushaltestelle eine Relation benötigt und die Linienrichtungen weitere zwei Relationen und die Gesamtlinie nochmals eine Überrelation, wie soll man dann beim Editieren dem Punkt noch die Buslinie zuordnen können? Es ist auch nicht verständlich, wieso ich mehrfach bus taggen muss. Es reicht doch, wenn eine Haltestelle Member einer Buslinie ist. Daraus geht dies doch schon hervor. Ferner befürchte ich Probleme beim Tagging der zwei Punkte auf der Straße für die Stops der beiden Fahrtrichungen. Ob die dann immer sauber getrennt auf die Fahrtrichtungsrelationen sortiert bleiben? Wenn die Haltestelle neben der Straße ist, bleibt es intuitiv klar, zu welcher Fahrtrichtung gehört. Bei zwei nahe zusammen liegenden Punkten auf dem Straßenway ist das nicht mehr der Fall. Außerdem sind die Stop-Punkte schwer vermittelbar, wenn es schon Punkte für die Haltestellen gibt. Kann man nicht die Stops für eine Punkthaltestelle automatisch senkrecht auf die Straße projezieren? Ich finde es sehr schön, dass man sich die Arbeit gemacht habt, dieses Konzept zu erarbeiten. Aber bei der Umsetzung und deren Konsistenz sehe ich derzeit noch schwarz. Abschließend wollte ich noch auf das Problem aufmerksam machen, dass im Wiki das Problem auch diskutiert wird, ohne dass vermutlich dort jemand eine Ahnung davon hat, dass dies in der Mailingliste ebenfalls geschieht. Möglicherweise kennt man nicht einmal Mailinglisten und insbesondere diese. http://wiki.openstreetmap.org/wiki/DE_talk:Relation:route Gtüße Tirkon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Karte entlang eines Tracks
Moin ! etwas vergleichbares wie die Atlas-Funktion suche ich auch. Ich stelle mir dabei vor das ein Track (GPX) definiert wird und ein Korridors entlang dieser Definition wird als Karte, ggf. über mehrer A4-Blätter ausgegeben. Weiß einer von Euch ob es soetwas öder ähnliches gibt ??? Vielleicht auch nur erste Gedanke dazu Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wofuer alles Loecher in landuse
- Ursprüngliche Nachricht - Von: Tobias Wendorff tobias.wendo...@uni-dortmund.de An: m...@koppenhoefer.com; Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Gesendet: 19.08.09 14:52 Betreff: Re: [Talk-de] Wofuer alles Loecher in landuse Martin Koppenhoefer schrieb: dazu ist es ja eine Wiki-Karte... ... die aber an wichtigeren Stellen Lücken hat, die ich eher füllen will. Landuse könnte man geschickt auch automatisch erzeugen, indem man den Inhalt überprüft. Wenn Residential-Straßen mit enger Bebauung vorhanden sind = Wohngebiet ec. -1. Am ehesten geht es mit residential, aber auch da ist das Ergebnis m.E. nicht zufriedenstellen, insb. an den Rändern zum unbebauten Gebiet. Wozu sollte man das tun? Wir haben doch genügend Mapper, die diese Dinge eintragen können, von Namen und anderen tags mal abgesehen, die Du nie automatisch hinzufügen willst. Könnten, aber mal ernst: Setzt Du Dich gerne hin, schätzt und korrigierst Landuses? Man sollte vielleicht zwischen temporären und finalen Landuses unterscheiden: Temporäre Landuses sind Bereiche, in denen man die Nutzung schätzt und sie nur grob einzeichnet. Wenn dann jemand konkreter wird und die genauen Straßen (etc.) einzeichnet, ersetzt er diese gegen finaleren, darf die vorhandenen aber vorher löschen. Hier in Dortmund haben wir jetzt Leichen, die aufgrund ihrer Großflächigkeit kaum noch gut bearbeitbar sind. Vorallem, weil sie über Nodes drüberschweben und man bei jedem Node erst reinzoomen muss, um nicht aus versehen eine Straße anzufassen. Wenn man Landuse denn schon manuell macht, dann sollte man auch irgendwelche Qualitätschecks einführen, die das aktuell halten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neues ÖPNV-Schema - Linien(varianten )relationen
On Wed, Aug 19, 2009 at 04:40:51PM +0200, Tirkon wrote: Claudius claudiu...@gmx.de wrote: Aus gegebenem Anlass habe mir gerade nochmal die Linienerfassung laut neuem ÖPNV-Schema durchgelesen und bin etwas unsicher, ob meine Tramlinienerfassung so richtig ist: Auch ich versuche mich gerade an dem neuen Konzept mit Potlatch, und zwar für Busse. In der Beschreibung des Schemas kommt bei Relationen type=* nicht mehr vor. Ist das nicht notwendig? Nein. Der type-Tag enthält keine Information, die nicht auch schon in den anderen Daten wäre. Eine Endhaltestelle ist gleichzeitig Starthaltestelle für die Gegenrichtung. Ich muss jetzt zwei Relationen erstellen mit from:A-Stadt to:B-Stadt, sowie from:B-Stadt to:A-Stadt. Diese beiden Relationen erscheinen lediglich unter dem lapidaren Namen Relation. Wenn jetzt an dieser Haltestelle mehrere Buslinien abfahren, habe ich mehrere solcher lapidar beschrifteter Relationen, ohne nur die geringste Ahnung zu haben, welche dieser Relationen jetzt zu welcher Buslinie gehört. Wie also soll das funktionieren, insbesondere wenn jemand Anderes diese Relationen erstellt hat und ich diese nicht nachvollziehen kann? Ich nehme an, die Editoren zeigen den Namen einer Relation da an, wenn es einen hat. Dann vergib halt einen Namen. Schad ja nicht. Nach dem neuen Haltestellenkonzept muss ich mehrfach in die nodes und die Überrelationen bus eintragen. Ist da die Inkonsistenz nicht schon vorprogrammiert? In den Großstädten mögen ja genügend Mapper Inkonsistenz ist einfach zu finden mit Checking Tools. Dann kann man sowas fixen. sein, um das Konzept umzusetzen. Hier auf dem Land kann man froh sein, wenn überhaupt jemand die Busse taggt. Bei Straßen mag es einfach sein, mal eben einen Stadtteil zu mappen. Bei den Bussen ist das etwas Anderes. Da braucht man die Mitarbeit vieler Ortskundiger, um den Verlauf einer einzigen Linie zu rekonstruieren. Und hier fährt wegen des schlechten Angebotes kaum jemand mit dem Bus. Man kann also froh sein, wenn sich überhaupt jemand eine Teilstrecke kennt und sich dann noch erbarmt. Und ob gerade derjenige dann auch das im Vergleich zum alten Konzept das neue erheblich weniger intuitive versteht? Meist schaut man sich das Tagging in der Nachbarschaft an und lernt so, wie es funktioniert. Ich versuche gerade, die auf weiter Flur erste Buslinie als Samenkorn zu legen, obwohl ich selbst nur einmal vor über zehn Jahren gefahren bin. Wenn aber schon eine popelige zweiseitige Bushaltestelle eine Relation benötigt und die Linienrichtungen weitere zwei Relationen und die Gesamtlinie nochmals eine Überrelation, wie soll man dann beim Editieren dem Punkt noch die Buslinie zuordnen können? Das ist zugegebenermassen schwierig. Aber es gibt halt keine einfache Lösung. Es zwingt Dich auch keiner das System bis zum Ende alles genau durchzumachen. Man kann auch nach dem einfachen alten System taggen. Oder eine Mischform. Oder man macht halt den Teil, den man machen kann. So ist OSM. Jeder macht, was er kann und dann schaut man, was man aus den Daten herausholen kann. Es ist auch nicht verständlich, wieso ich mehrfach bus taggen muss. Es reicht doch, wenn eine Haltestelle Member einer Buslinie ist. Daraus geht dies doch schon hervor. Ferner befürchte ich Probleme beim Aber wenn dann die Buslinie verloren geht, kann ich auch die Haltestelle nicht mehr zeichnen. Und ein Renderer, der keine Buslinien einzeichen will, sondern nur Haltestellen, wird viel einfacher. Redundanz ist gut. Tagging der zwei Punkte auf der Straße für die Stops der beiden Fahrtrichungen. Ob die dann immer sauber getrennt auf die Fahrtrichtungsrelationen sortiert bleiben? Wenn die Haltestelle neben der Straße ist, bleibt es intuitiv klar, zu welcher Fahrtrichtung gehört. Bei zwei nahe zusammen liegenden Punkten auf dem Straßenway Wenn die Punkte nahe zusammen liegen, dann mach nur einen für beide Richtungen. ist das nicht mehr der Fall. Außerdem sind die Stop-Punkte schwer vermittelbar, wenn es schon Punkte für die Haltestellen gibt. Kann man nicht die Stops für eine Punkthaltestelle automatisch senkrecht auf die Straße projezieren? Kann man schon, aber das ist halt technisch viel aufwändiger und es wird daher einfach weniger Software geben, die das macht. Und es ist nicht unbedingt eindeutig bei komplexeren Straßenführungen. Ich finde es sehr schön, dass man sich die Arbeit gemacht habt, dieses Konzept zu erarbeiten. Aber bei der Umsetzung und deren Konsistenz sehe ich derzeit noch schwarz. Du solltest das nicht alles so absolut sehen. Wenn Du keinen Haltepunkt auf der Straße angegeben hast, sondern nur das Schild neben der Straße, dann ist das so und die Software muss sehen, wie sie damit zurecht kommt. Manche wird es können, andere nicht. Die Zeit wird zeigen, ob das Konzept funktioniert. Ist es Dir zu blöd die Punkte einzutragen, dann lass es. Vielleicht wird ein anderer Mapper Deine Arbeit ergänzen. Das ÖPNV-Schema ist ein
[Talk-de] Feldweg, aber kein Schild
Hallo zusammen, ich trage gerade meine Radtour ein und stolper’ über ein Feldwegnetz (ein langer Weg und 2 Abzweigungen) welches an allen Einfahrten (vom öffentlichen Verkehr aus gesehen) ein Schild Verbot für Fahrzeuge aller Art und Landwirtschaftlicher Verkehr frei hat. Nur an einem Weg nicht. Meinem gesunden Menschenverstand entsprechend tagge ich das trotzdem als Feldweg. Was meint Ihr? MfG, Adiac ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Warum immer die ...more OSM coming soon Kacheln
Am 19. August 2009 15:36 schrieb Kai Krueger kakrue...@gmail.com: da es doch immer wieder Fragen zum rendering gibt wollte ich noch mal kurz den ganzen mapnik Prozess beschreiben um hoffentlich etwas Klarheit zu schaffen, den die Ergebnisse sind aus Usersicht wirklich nicht immer offensichtlich. [ausführliche Beschreibung] Vielen Dank für diese ausführlich Beschreibung. Machst Du sie noch an passender Stelle im Wiki verfügbar? Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feldweg, aber kein Schild
Hallo zusammen, ich trage gerade meine Radtour ein und stolper’ über ein Feldwegnetz (ein langer Weg und 2 Abzweigungen) welches an allen Einfahrten (vom öffentlichen Verkehr aus gesehen) ein Schild Verbot für Fahrzeuge aller Art und Landwirtschaftlicher Verkehr frei hat. Nur an einem Weg nicht. Meinem gesunden Menschenverstand entsprechend tagge ich das trotzdem als Feldweg. Was meint Ihr? Was wie ein Feldweg aussieht ist auch einer. Das hängt nicht von irgendwelchen Schildern ab. Bei uns haben 99% der Feldwege standardmäßig kein Schild. Im Wald dutzende unterschiedliche oder auch keine. Je nachdem von wo man kommt gilt was anderes oder garnichts. Wenn ich da nur nach Schildern gehen würde, hätten wir keine Feldwege. Bei letzteren kannst du nur das Stück zwischen Schild und erster Abzweigung mit den entsprechenden Verboten taggen. Richtiger wirds dadurch auch nicht, ist aber in dieser Situation garnicht anders machbar. Ansonsten müsste man für jeden einzelnen access noch eine Richtung mit anhängen. Bei vielen Abzweigungen würde da am Ende kein Mensch mehr durchblicken, da man ein Monster von Bestimmungen anhängen müsste. Hier kommst du mit taggen nicht weiter. Da ist der Menschenverstand vor Ort gefragt. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feldweg, aber kein Schild
Am 19. August 2009 19:30 schrieb Mirko Küster webmas...@ts-eastrail.de: Hallo zusammen, ich trage gerade meine Radtour ein und stolper’ über ein Feldwegnetz (ein langer Weg und 2 Abzweigungen) welches an allen Einfahrten (vom öffentlichen Verkehr aus gesehen) ein Schild Verbot für Fahrzeuge aller Art und Landwirtschaftlicher Verkehr frei hat. Nur an einem Weg nicht. Meinem gesunden Menschenverstand entsprechend tagge ich das trotzdem als Feldweg. Was meint Ihr? ja, als Feldweg (track) schon, allerdings würde ich unter Umständen (je nach Bundesland) nicht unbedingt eine access-restriction für diesen unbeschilderten Weg angeben, wenn der wirklich kein Schild hat (gibt ja vielliecht auch einen Grund ausser, dass es vergessen wurde). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feldweg, aber kein Schild
(gibt ja vielliecht auch einen Grund ausser, dass es vergessen wurde). Grund kann ich dir für den Osten sagen. Die waren hier ausser wenn es wirklich etwas nutzte nie beschildert. Nach der Wende hat man nur versucht z.B. die Wälder zu sperren, was bis heute keinen juckt und in dem bereits genannten Chaos endete. Trotz Verbot herscht reger Verkehr. Da haben bestimmt schon einige auswärtige Radwegbenutzer große Augen bekommen. Bei den Feldwegen hat man sich den Schilderwald gespart, bringt sowieso nichts. Den brauchts ehrlich gesagt auch nicht. Der urtypische Feldweg ist hier Grade 3 bis 4. Zwei vom Traktor ausgefahrene Spuren die schonmal 50 cm tiefer als die mittlere Grasnabe liegen können. Je nach Wetter oder Bewirtschaftung die reinsten Schlammbahnen oder so zugewachsen das man einen Mähbalken vorm Fahrzeug haben sollte. Stellenweise liegen da auch mal ordentliche Sandsteinquader im Weg. Selten gibts mal Schotter, noch seltener Betonplatten und Asphalt ist schon Rarität. Da muss man kein Schild setzen um zu erkennen das man da mit den heutigen Autos eher nicht reinfahren sollte. Wenn das trotzdem ein auswärtiger versucht dann halte ich das wie Nelson von dem Simpsons. Access erfinden werde ich bestimmt nicht. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feldweg, aber kein Schild
Am 19. August 2009 19:30 schrieb Mirko Küster webmas...@ts-eastrail.de: Was wie ein Feldweg aussieht ist auch einer. Das hängt nicht von irgendwelchen Schildern ab. Da hat jemand Jehova gesagt. Deshalb zu dieser Aussage mein altbekannter Widerspruch :-) Man kann es einem Weg nicht ohne weiteres ansehen, ob er ein Feldweg ist. Stichwort Widmung. Ausbauzustand hin oder her. Ich bleibe dabei: unbefestigte highway=unclassified existieren. Wo man sich sicher sein kann ist, dass die Beschilderung nach StVO nie über den Widmungszweck hinausgehen darf. Man kann also mit ziemlicher Sicherheit die zwei beschilderten Wege zu Feldwegen qualifizieren. Beim nicht beschilderten Weg müsste man schauen was am anderen Ende liegt. Kommt dort wieder ein Ort, dann spricht viel gegen einen Feldweg. Genau so, wenn auch am Ende des Weges ein entsprechendes beschränkendes Verkehrsschild fehlt. Andernfalls ist der Fall klar. Ein Anhaltspunkt (und nicht mehr) liefert ggf. auch die Gegend in der du (Adiac) unterwegs bist und wie es sich dort sonst mit der Beschilderung verhält. Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Fahrradknotenpunkt
Hallo, Entsprechend dem Wiki [1] tagge ich einen Fahrradknotenpunkt (an dem auch eine Radwanderkarte hängt) so: information=board name=Fahrradknotenpunkt 7 network=rcn rcn_ref=7 tourism=information Okay so? MfG [1] http://wiki.openstreetmap.org/wiki/Radverkehrsnetz_NRW#Knotenpunktsystem_in_den_Kreises_Aachen_und_Heinsberg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feldweg, aber kein Schild
Am Mittwoch 19 August 2009 19:59:47 schrieb Falk Zscheile: Man kann es einem Weg nicht ohne weiteres ansehen, ob er ein Feldweg ist. Ich verstehe und akzeptiere Deinen Widerspruch; aber in diesem Fall ist 99%ig klar dass das ein Feldweg ist (ich bin mit’m Rad da durch). Man kann also mit ziemlicher Sicherheit die zwei beschilderten Wege zu Feldwegen qualifizieren. Beim nicht beschilderten Weg müsste man schauen was am anderen Ende liegt. Eben der beschilderte Feldweg: Agrar frei Agrar frei I I I I I I I fehlendes Schild? öffentl.Straße --- Genau so, wenn auch am Ende des Weges ein entsprechendes beschränkendes Verkehrsschild fehlt. Richtig, da steht auch kein Schild - was ja auch nicht muss, wenn man weiß, dass der oberere Weg ein Feldweg ist. Gruß, Falk MfG ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schreibweisen/Abkürzungen von Straße nnamen
2009/8/19 Ropino rop...@online.de Hallo, im Zuge der Auswertung der Straßenlisten (http://osm.gt.owl.de/Strassenliste/) bin ich auf das Problem mit der zum Teil sehr unterschiedlichen Schreibweise von Straßennamen gestoßen. Die Regel, man schreibt es so wie es auf dem Schild steht, scheitert spätestens wenn eine Straße im gleichen Ort unterschiedliche Schreibweisen/Abkürzungen hat. Allgemeiner Konsens dürfte die Langform von Straße / -straße sein. Wie verfahren wir mit den Abkürzungen für: 1. Doktor - Dr. 2. Professor - Prof. 3. Sankt - St. Für Dr. und Prof. würde ich die Kurzform als üblich ansehen, bei Sankt tendiere ich eher zur Langform. Die amtlichen Straßenverzeichnisse helfen nicht wirklich weiter, da gibt es auch alle möglichen Varianten. [...] Ich würde mich freuen, wenn wir insbesondere bei Dr. / Prof. und Sankt einen allgemeinen Konsens finden können. Ausnahmen bestätigen dabei wie immer die Regel. ;-) Bei uns hat uns die Stadtverwaltung (auf Nachfrage) mitgeteilt, dass die offiziellen, amtlichen Straßennamen Dr.-... lauten, was auch so auf den Straßenschildern steht. Wir haben es hier deshalb so gehandhabt: name=Dr.-... alt_name=Doktor-... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Trunk oder primary
2009/8/19 Georg Feddern ne...@bavarianmallet.de wort- und sinngemäß gebe ich Dir recht, aber: Ich kenne diverse kreuzungsfrei ausgebaute Stellen, die gemäß RWB mit den Zeichen 332 und 333 in gelb ausgeschildert sind, aber weder - 2-bahnig - baulich getrennt - mehr als 1 Fahrspur je Fahrtrichtung erfüllen. Das liegt nicht zuletzt daran, dass in der RWB nur stinknormale Straßen oder 2-bahnige, mehrspurige, baulich getrennte Straßen betrachtet werden - alles dazwischen muss dann daraus abgeleitet werden und da nimmt man dann meist die autobahnähnliche Beschilderung. Da zum 1. September 2009 ja die neue StVO in Kraft tritt, ist demzufolge wohl auch http://www.umwelt-online.de/PDFBR/2009/0154_2D09.pdf und dort insbesondere Punkt 114 Absatz 1 auf Seite 67 vom Bundesrat ratifiziert worden. Entweder werden an allen solchen Stellen zukünftig die Zeichen 333 entfernt oder es gilt wohl im Umkehrschluss ((kreuzungsfrei UND Richtungstrennung durch durchgezogene Linie) == autobahnähnlich ausgebaut). Man könnte Zeichen 333 ja z.B. durch einen Pfeilwegweiser (Z. 415/418) ersetzten... Oder man lässt alles beim alten. Es wäre dann zwar nicht durch die StVO gedeckt -aber das war es bisher auch nicht. Bald wissen wir mehr ... Aber nicht ganz so bald. Bei sowas gilt immer eine Übergangsfrist von 10 Jahren. (Wehe die reden sich raus, angeordnet werden sei ja Zukunft - und belassen die Altlasten!) ;-) Wäre auch eine Möglichkeit. ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schreibweisen/Abkürzungen von Straße nnamen
On Wed, Aug 19, 2009 at 09:30:27PM +0200, Ropino wrote: Hallo, im Zuge der Auswertung der Straßenlisten (http://osm.gt.owl.de/Strassenliste/) bin ich auf das Problem mit der zum Teil sehr unterschiedlichen Schreibweise von Straßennamen gestoßen. Die Regel, man schreibt es so wie es auf dem Schild steht, scheitert spätestens wenn eine Straße im gleichen Ort unterschiedliche Schreibweisen/Abkürzungen hat. Allgemeiner Konsens dürfte die Langform von Straße / -straße sein. Wie verfahren wir mit den Abkürzungen für: 1. Doktor - Dr. 2. Professor - Prof. 3. Sankt - St. Das enfachste ist IMMER die langform zu nehmen - Abkuerzen ist einfach via Dictionary moeglich - Verlaengern aus einer abkuerzung ist zeitweise schwierig ... Schwieriger wird es bei Personen die es in verschieden Versionen gibt oder auch die Kurzform(en) üblich sind. Beispiel A: Annette-von-Droste-Hülshoff-Weg Von-Droste-Hülshoff-Weg Droste-Hülshoff-Weg Das sind unterschiedliche Straßen - nicht unterschiedliche abkuerzungen. Hier würde ich nur die 1. Variante als richtig ansehen, eventl. auch Variante 3? Beispiel C: John-F.-Kennedy-Straße Hier dürfte kaum jemand den kompletten Namen John-Fitzgerald-Kennedy-Straße erwarten. Hier sehe ich das aehnlich - John F. Kennedy wie auch George W. Bush aber Rainer M. Rilke ist wieder quatsch ... Ich würde mich freuen, wenn wir insbesondere bei Dr. / Prof. und Sankt einen allgemeinen Konsens finden können. Ausnahmen bestätigen dabei wie immer die Regel. ;-) Ich habe das immer den regionalen Mappern ueberlasen - Ich fuer mich selber habe St. und Str. immer in die langform korrigiert - aehnliches mit A.-v.-D.-Hülshoff - Prof. und Dr. habe ich kurz gelassen aber quasi als einzige Abkuerzung. Und auch da bin ich geneigt sie zur Langform zu konvertieren ... Es gibt halt kein Richtig oder Falsch - es ist Geschmacksfrage 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] OpenStreetBugs / JOSM Plugin and other bugs
Also josm-tested geht bei mir problemlos mit den Bugs. Kann mir jemand erklären, warum manche sehr einfache Bugs erfassen, aber den Bug nicht gleich korrigieren. Welchen Sinn macht das? P. -Ursprüngliche Nachricht- Von: talk-de-boun...@openstreetmap.org [mailto:talk-de-boun...@openstreetmap.org] Im Auftrag von Florian Lohoff Gesendet: Mittwoch, 19. August 2009 11:22 An: talk-de@openstreetmap.org Betreff: [Talk-de] OpenStreetBugs / JOSM Plugin and other bugs Hi, kann jemand derzeit im JOSM die gezeigten OSM Bugs anklicken wenn das OpenStreetBugs layer aktiv ist? Bei mir geht das seit einer geraumen zeit nicht mehr d.h. einen speziellen bug sich durchzulesen ist gerade - schwierig ... Ausserdem ist mein Karte Spring rum bug wieder da ... Nicht mehr so leicht zu triggern wie vorher - aber als ich gestern mich mal zum Bug Squashing hingesetz habe und meine Tour nach Hause planen wollte, dabei ein paar Bugs geschlossen, neu geoeffnet etc war der nach ein paar minuten wieder da ... Die Qualitaet ist gerade irgendwie im Sturzflug seit dem Wir machen alles besser ohne Xav *grmpf* 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 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feldweg, aber kein Schild
Am Mittwoch, 19. August 2009 20:00:08 schrieb Mirko Küster: Den brauchts ehrlich gesagt auch nicht. Der urtypische Feldweg ist hier Grade 3 bis 4. Zwei vom Traktor ausgefahrene Spuren die schonmal 50 cm tiefer als die mittlere Grasnabe liegen können. Je nach Wetter oder Bewirtschaftung die reinsten Schlammbahnen oder so zugewachsen das man einen Mähbalken vorm Fahrzeug haben sollte. Stellenweise liegen da auch mal ordentliche Sandsteinquader im Weg. Selten gibts mal Schotter, noch seltener Betonplatten und Asphalt ist schon Rarität. Hört sich aber sehr gut fürs biken an. Mit einem entsprechenden Bike (Cross oder MTB) ist das gar kein Problem (und macht Spaß). So long Werner ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feldweg, aber kein Schild
2009/8/19 Falk Zscheile falk.zsche...@googlemail.com Man kann es einem Weg nicht ohne weiteres ansehen, ob er ein Feldweg ist. Stichwort Widmung. Ausbauzustand hin oder her. Widmung als Feldweg!? Wo gibt es denn sowas? Gewidmet wird nur als öffentliche Straße. Und dann wird beim widmen die Straßenklasse mit festgelegt, von denen es die folgenden gibt: - Bundesautobahn - Bundesstraße - Landesstraße / Staatsstraße - Kreisstraße - Gemeindestraße Ich bleibe dabei: unbefestigte highway=unclassified existieren. Gibt sogar unbefestigte highway=residential. Wobei ein unbefestigte highway=unclassified niemals grade 4 oder 5 haben wird. Wo man sich sicher sein kann ist, dass die Beschilderung nach StVO nie über den Widmungszweck hinausgehen darf. Man kann also mit ziemlicher Sicherheit die zwei beschilderten Wege zu Feldwegen qualifizieren. Beim nicht beschilderten Weg müsste man schauen was am anderen Ende liegt. Kommt dort wieder ein Ort, dann spricht viel gegen einen Feldweg. Genau so, wenn auch am Ende des Weges ein entsprechendes beschränkendes Verkehrsschild fehlt. Andernfalls ist der Fall klar. Ein Anhaltspunkt (und nicht mehr) liefert ggf. auch die Gegend in der du (Adiac) unterwegs bist und wie es sich dort sonst mit der Beschilderung verhält. Bitte nie vergessen: Diese Beschilderung von Feldwegen ist Bundeslandspezifisch! In NDS und BW ist es wohl so üblich - in NRW aber definitiv nicht. Böse gesagt: hier hat man nicht das Geld, um an jeden Feldweg ein Schild zu stellen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feldweg, aber kein Schild
Robert S. schrieb: Widmung als Feldweg!? Wo gibt es denn sowas? Zum Beispiel in Schleswig-Holstein (§ 3 (1) 4. a StrWG), Baden-Württemberg (§ 3 (2) 4. 1 StrG) und Bayern (Art. 3 (1) 4. BayStrWG). ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schreibweisen/Abkürzungen von Straß ennamen
Am Mittwoch 19 August 2009 schrieb Florian Lohoff: On Wed, Aug 19, 2009 at 09:30:27PM +0200, Ropino wrote: Hallo, im Zuge der Auswertung der Straßenlisten (http://osm.gt.owl.de/Strassenliste/) bin ich auf das Problem mit der zum Teil sehr unterschiedlichen Schreibweise von Straßennamen gestoßen. Die Regel, man schreibt es so wie es auf dem Schild steht, scheitert spätestens wenn eine Straße im gleichen Ort unterschiedliche Schreibweisen/Abkürzungen hat. Allgemeiner Konsens dürfte die Langform von Straße / -straße sein. Wie verfahren wir mit den Abkürzungen für: 1. Doktor - Dr. 2. Professor - Prof. 3. Sankt - St. Das enfachste ist IMMER die langform zu nehmen - Abkuerzen ist einfach via Dictionary moeglich - Verlaengern aus einer abkuerzung ist zeitweise schwierig ... das sehe ich nicht so! ueber die schreibweise von strasse vs. str. kann man ja gerne streiten, aber namen und titel sollten so eingetragen werden, wie's am schild steht. wenn ich mit hilfe meiner karte/meines navis eine prof.-huber-strasse suche, dann erwarte ich auch ein strassenschild mit der entsprechenden bezeichnung vorzufinden, und keine professor-hubert-strasse. 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] OpenStreetBugs / JOSM Plugin and other bugs
Am Mittwoch, 19. August 2009 schrieb Florian Lohoff: kann jemand derzeit im JOSM die gezeigten OSM Bugs anklicken wenn das OpenStreetBugs layer aktiv ist? Auf der Karte nicht, aber in der Liste (Seitenleiste). Das Plugin stammt übrigens weder von Xav noch von mir. Bugreports gehören soweit ich weiss ins Trac von JOSM. Ausserdem ist mein Karte Spring rum bug wieder da ... Nicht mehr so leicht zu triggern wie vorher - aber als ich gestern mich mal zum Bug Squashing hingesetz habe und meine Tour nach Hause planen wollte, dabei ein paar Bugs geschlossen, neu geoeffnet etc war der nach ein paar minuten wieder da ... Das wurde wahrscheinlich beim Bug schließen getriggert. Sollte jetzt wieder funktionieren (Skript bitte neu laden). Die Qualitaet ist gerade irgendwie im Sturzflug seit dem Wir machen alles besser ohne Xav Pass bitte auf was du hier von dir gibst. Angefangen habe ich mit Xav, ich würde auch jetzt noch gerne mit ihm zusammenarbeiten, wenn er das auch wollte. Meine ursprüngliche Motivation war beim Laden einer BBOX nicht nur neuere Bugs von außerhalb der BBOX zurückzubekommen und ein ordentlicher GPX Export. Hier ist die Qualität in meinen Augen extrem gestiegen und damit war mein Ziel erreicht. Ich kenne mich mit Javascript nicht wirklich aus, habe momentan viel um die Ohren und fixe trotzdem die Fehler im Client, auch wenn sie mich selbst nicht betreffen. Du schimpfst hier rum, gibst dir selber aber keine große Mühe die Probleme zu lösen. Wenn es ständig auftritt, versuche es doch reproduzierbar zu machen (zum Beispiel mit der Firebug Extension). Grüße, Mitja ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neues ÖPNV-Schema - Linien(varianten )relationen
Jochen Topf joc...@remote.org wrote: Eine Endhaltestelle ist gleichzeitig Starthaltestelle für die Gegenrichtung. Ich muss jetzt zwei Relationen erstellen mit from:A-Stadt to:B-Stadt, sowie from:B-Stadt to:A-Stadt. Diese beiden Relationen erscheinen lediglich unter dem lapidaren Namen Relation. Wenn jetzt an dieser Haltestelle mehrere Buslinien abfahren, habe ich mehrere solcher lapidar beschrifteter Relationen, ohne nur die geringste Ahnung zu haben, welche dieser Relationen jetzt zu welcher Buslinie gehört. Wie also soll das funktionieren, insbesondere wenn jemand Anderes diese Relationen erstellt hat und ich diese nicht nachvollziehen kann? Ich nehme an, die Editoren zeigen den Namen einer Relation da an, wenn es einen hat. Dann vergib halt einen Namen. Schad ja nicht. Wenn aber schon eine popelige zweiseitige Bushaltestelle eine Relation benötigt und die Linienrichtungen weitere zwei Relationen und die Gesamtlinie nochmals eine Überrelation, wie soll man dann beim Editieren dem Punkt noch die Buslinie zuordnen können? Das ist zugegebenermassen schwierig. Aber es gibt halt keine einfache Lösung. Es ist nicht so, dass ich das neue System nicht schätze. Bei meinem Tagging der Düsseldorfer Linien konnte ich mit dem alten System einen variantenreichen Bus einfach nicht taggen, so dass momentan einfach alle Routen in einer Relation eingesammelt wurden. Dann hat es jemand mit Varianten versucht. Die Folge davon war, dass jetzt in der ÖPNV Karte auf dem langen Rattenschwanz von Linien in der Nähe von einem Bahnhof obendrein die Buslinie mehrfach aufgezählt wurde. Hier würde das neue ÖPNV Schema durchaus das Problem lösen. Das größte Problem dabei ist aber der notwendige aber von den Editierwerkzeugen nicht bereitgestellte Blick zur übernächsten Relation, weil zur nächsten explizit im Schema gesagt wird, es solle nur from und to getaggt werden. Wenn sich jemand ans Schema hält, wird es später sehr schwierig für ihn selbst und Andere, welche die Buslinie fortführen. Der Nutzen, wenn nur ich neben from und to auch die Namen dranschreibe, ist minimal. Es hilft eigentlich nur, wenn es alle Nutzer des Schemas tun. Im Moment werden sie aber zum Gegenteil aufgefordert. Wenn die Datenstruktur im Falle der Haltestellen zwingend komplex sein muss, wäre es eine Alternative, den Editierwerkzeugen beizubringen, damit umzugehen. Hierzu müssten sie auch die übernächste Relation anzapfen und in geeigneter Form in die Anzeige der nächstniedrigen einbinden. Dann blieben solche Konstruktionen leicht handhabbar und würden im Zuge dessen automatisch konsistent gehalten: Der User bekommt beispielsweise ein Formular für Haltestellen präsentiert, in das er an nur einer Stelle bus eingibt. Sobald ein weiteres Mitglied in die Relation aufgenommen wird, werden die Daten dort übernommen und es wird vom Editor automatisch richtig eingetragen und somit konsistent gehalten. Man kann die Sache jetzt weiterspinnen, wie man das Ganze am besten gestaltet. Dass so etwas funktioniert, zeigt sich beispielsweise in Musikverwaltungen. Man trägt beispielsweise bei einem Album den Namen des Interpreten nur einmal ein. Dennoch vervollständigt sie die Einträge soweit, dass in jeden MP3Tag der MP3-Dateien dieses Albums der Interpretenname eingetragen wird. Im Falle eines Samplers unterbleibt dieses natürlich. Der Editor der Musikverwaltung und die Form der Formulare sorgt für ein konsistentes Tagging. Wäre dies nicht auch in OSM zumindest in Bezug auf unvermeidliche verschachtelte Konstruktionen wie beispielsweise bei Haltestellen möglich? Um den User nicht einzuschränken, bleibt die Formularmethode optional. Ich bin aber sicher, dass bei einer guten Implementierung die große Mehrheit kaum mehr etwas Anderes benutzen möchte. Dies könnte womöglich auch dazu beitragen, dass die derzeitigen hier in der Liste diskutierten automatischen Checking-Läufe weniger horrende Fehlerzahlen ausspucken. Momentan entwickelt man Software, die Fehler ermittelt, die dann von Hand repariert werden. Warum nicht mit dem Arbeitsprinzip der Check-Software schon zum Editierzeitpunkt die Konsistenz bewahren? Das Ergebnis bleibt dasselbe und daher auch der - mir fällt kein treffenderes Wort ein - Bevormundungsgrad des Users gleich. Ein Beispiel wäre möglicherweise, ein einheitliches ID für die Verwaltung der Variantenrelationen sicherzustellen, so dass der Renderer dies einfacher erkennen kann. Dies ist zumindest besser, als wenn nachher mit Checkprogrammen und mühsamer Handarbeit nachgebessert werden muss. Es ist auch nicht verständlich, wieso ich mehrfach bus taggen muss. Es reicht doch, wenn eine Haltestelle Member einer Buslinie ist. Daraus geht dies doch schon hervor. Ferner befürchte ich Probleme beim Aber wenn dann die Buslinie verloren geht, kann ich auch die Haltestelle nicht mehr zeichnen. Man könnte eine solche Haltestelle genau so behandeln, wie eine disused nach dem neuen Konzept. ;-) Möglicherweise also mit einem rot durchkreuzten
Re: [Talk-de] Schreibweisen/Abkürzungen von Straß ennamen
Guenther Meyer wrote: ueber die schreibweise von strasse vs. str. kann man ja gerne streiten, aber namen und titel sollten so eingetragen werden, wie's am schild steht. wenn ich mit hilfe meiner karte/meines navis eine prof.-huber-strasse suche, dann erwarte ich auch ein strassenschild mit der entsprechenden bezeichnung vorzufinden, und keine professor-hubert-strasse. Deswegen packe bei zweifeln die abgekürzten Namen des Schildes mit alt_name auf die Straße und die Langform als name. Abkürzungen unterscheiden sich des öfteren, s.b. bei Joh.-Seb.-Bach Straße habe ich auch schon eine J.-Seb.-Bach gesehen und ähnliches, da ist nur die Langform wirklich nutbar für mich. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schreibweisen/Abkürzungen von Straße nnamen
Guenther Meyer d@sordidmusic.com wrote: das sehe ich nicht so! ueber die schreibweise von strasse vs. str. kann man ja gerne streiten, aber namen und titel sollten so eingetragen werden, wie's am schild steht. wenn ich mit hilfe meiner karte/meines navis eine prof.-huber-strasse suche, dann erwarte ich auch ein strassenschild mit der entsprechenden bezeichnung vorzufinden, und keine professor-hubert-strasse. Seien wir doch mal ehrlich. Bevor wir für Openstreetmap gearbeitet haben, war es uns Schegal, was genau auf den Schildern stand. Man wusste eben, wer gemeint war. Und genauso geht es den Leuten in den Stadträten und den Verwaltungen. Sie als Nicht-OSM-Mitarbeiter denken über solche Buchstabenknausereien nicht nach. Mitunter stimmen da auch Ratsbeschluss (Was schreibt der Protokollant?), Eintrag in der städtischen Datenbank sowie Straßenschild (z.B. wegen möglicher physischer Schildüberlänge oder der Schilderhersteller hat es anders interpretiert etc.) nicht überein. Beispielsweise hat man in Düsseldorf Abweichungen zwischen gespeichertem Namen und Straßenschild bezüglich neuer und alter Rechtschreibung (ss vs ß) sowie Abweichungen bei den Personennamenstraßen gefunden. Niemandem fällt das auf und daher weiß eigentlich auch keiner, wieso das so ist. Der Name wurde zumindest in den Vorzeiten des Computers den Herstellern der Karten womöglich in wieder anderer Form weitergegeben. Wer also heute penibel sein will und seine Anwendung auf der Straße hat, erwartet hier die richtige Schreibweise. Wer hingegen die OSM Daten in Amtsstuben verwendet, möchte sie dort stimmig haben. Man kann es also ohnehin nicht jedem gerecht machen. Gut, man wird wohl keine Unterscheissheimer Straße sehen wollen. Aber hier sollten wir nicht päpstlicher sein, als der Pabst selbst. Folgen wir hier seiner Arbeitsweise und überlassen es ebenfalls dem Zufall der Mapperentscheidung. Letzendlich bleibt uns auch nichts Anderes übrig. Es sei denn, man mag Millionen von Straßen kontrollieren. By the way: Ist eigentlich bekannt, wieviel Straßen es derzeit bei OSM in Deutschland gibt? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feldweg, aber kein Schild
Robert S. osm-m...@autobahnen-europa.eu wrote: Widmung als Feldweg!? Wo gibt es denn sowas? In Düsseldorf: http://www.openstreetmap.org/?lat=51.20801lon=6.90168zoom=17layers=0B00FTFTway=2672 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [Osmf-talk] EVERYONE: PLEASE VOTE
First I think you just breached the data protection act and are using data which even I don't have access to, but lets ignore that and the fact that Nick has actually been pushing to make the list more open. A list which only you, Mike and 80n have. I really wish we could just pay people in Kiev to do exactly what I say, but we can't. It's insulting to their integrity and intelligence to suggest that they simply become members of OSMF to vote for Nick or I. Everyone at CloudMade is encouraged to be a member of the Foundation. From me, to the ambassadors we had, to our executives to our developers. The majority of us have been members for some time. I don't know all the details as I don't deal with them on a daily basis but from my understanding is that this 'mass joining' was simply because they didn't have individual credit cards that would work from the Ukraine on paypal. To be clear, we've not told staff at CloudMade to vote for anyone. You clearly have no respect for Nick, me or anyone we employ in the Ukraine, but you could ask some of our London team to confirm this if you have any respect for them? We're in a very difficult position and don't always make the right choices. CloudMade has contributed tens of thousands of pounds in cash to the Foundation for things like sponsorship and servers. We've spent man years on coding work. Nick, me and many other in CloudMade spend far beyond 9-5 working to promote OSM and make it fly. But if we make a small mistake we're hung up to dry by people like Frederik as some kind of map-based Darth Vader figure. If we don't encourage people to join then we're not part of the community and engaged. If we do then you can interpret it as being a take over. So we walk a fine balancing act. That's just the way it is, and we try hard to make the right decisions. This is something we'll learn from. But I sincerely hope that the majority of people look at how much hard work we've put in and the good we've done for OSM despite a sometimes fractious community and the pot shots like this taken. From a practical point of view I have no idea what conspiracy we'd be trying to achieve anyway. If we really were deranged enough to try and 'take over' then firstly we could just register tens or hundreds of fake people with hotmail email addresses and avoid this. Second, I don't know what we'd be taking over. The data has very clear protections all over it to stop people taking it over and I want them only to be made stronger (not weaker Public Domain which is what Frederik wants). The Foundation has very little assets and I've put the last 5 years of my life in to making OSM better since I founded. It would be super dumb, gain me nothing and destroy my reputation and OSM to be Evil and do any of that. Anyway, the Ukraine has it's own strong community, just have a look at http://mapping.in.ua/ and I think you have your numbers wrong in assuming everyone in the Ukraine works for CloudMade. I and CloudMade are very open to learning from these kinds of hiccups and am all ears for how we can do better. I'd go so far as to suggest that maybe we could ask our Ukraine staff not to vote at all, but that would lack the same respect you don't have for them. But lets look at the real issue, Frederik. You're intensely jealous that your own firm, GeoFabrik, which you didn't bother to declare in your anti-CM email, has had little success compared to CloudMade. Your jealous to the point of stripping all references to me out of your book on OpenStreetMap. You don't want anyone who's not from Germany to come to your German-only German SOTM your planning because you want your own little empire and fame. I wouldn't normally point to all of that because I have a lot of respect for you and I want GeoFabrik, ITO World and all the other companies using OpenStreetMap to succeed. But you keep doing this stuff without getting any push back, and if you're going to attack people like this in public then you should declare the other side of the coin. We have a larger goal. OpenStreetMap is going to be the best map of the world and we need to work together to make it happen. Let's not squabble over this stuff because we're David right now and there is a Goliath in terms of TeleAtlas and NavTeq. We need mappers, the Foundation, the sysadmin team, developers, academia and companies to work together in an ecosystem to make it happen. Let's deal with each other in a more respectful way, don't automatically assume people are evil and assume that people are acting in good faith. That way, we can all work on a better map. I'm very contactable by anyone who has any concerns over this and encourage people to judge me and Nick on what we do and not what Frederik says. Feel free to phone me, IM or whatever. Details here: http://wiki.openstreetmap.org/wiki/User:Steve Yours c. Steve
[Talk-de] OSM Foundation: Mitglied werden und mit abstimmen!
Hallo talk-de, ich hatte mich ja bislang immer zurueckgehalten, hier gross dafuer zu werben, dass Leute Mitglied in der OSMF werden sollen - Mappen geht ja auch auch ohne, und ich wollte denjenigen, die sich nicht von selbst dafuer interessieren, das Hickhack ersparen. Die juengsten Entwicklungen bringen mich nun aber doch dazu, nochmal was zu schreiben. Es stehen ja gerade Wahlen fuer den OSMF-Vorstand an. Und im kommenden Jahr gibt es sicherlich viele wichtige Entscheidungen, die die OSMF treffen muss; es wird um die neue Lizenz gehen, aber auch um das Wachstum - ein Bewerber (Nick) hat den Plan vorgelegt, bis Ende 2010 eine fuenfstellige Anzahl Mitglieder samt bezahltem Verwaltungs- und Geschaeftsfuehrungspersonal zu erreichen, andere sind da eher behutsam. Es gab im Vorfeld der Wahl eine laengere Diskussion ueber den grossen Einfluss der Firma Cloudmade auf die OSMF; die derzeitigen Vorstands- mitglieder Steve Coast und Nick Black sind ja zugleich die Cloudmade- Gruender und stellen sich auch zur Wiederwahl, und zusaetzlich bewirbt sich auch Hurricane McEwen, die bis vor kurzem Cloudmade-Angestellte war und der Cloudmade-Fuehrung immer noch sehr nahe steht. Einige haben vorgeschlagen, man sollte eine Regel einfuehren, die sagt, dass maximal eine Person pro Firma in den OSM-Vorstand kommt. Das wurde aber vom Cloudmade-Establishment mit der Begruendung abgelehnt, man solle hier doch einfach die Waehler entscheiden lassen. (Es waere auch zu spaet gewesen, eine solche Regel verbindlich einzufuehren - es waere nur im Wege der freiwilligen Selbstbeschraenkung gegangen, zu der Cloudmade aber eben nicht bereit war. Und das, obwohl es bei 11 Bewerbern fuer 7 Posten ja nun wirklich auch ohne drei Cloudmade-Leute genug Arbeitswillige gibt.) Das ist ja alles schoen und gut. Bis vor kurzem waren von den rund 150 Mitgliedern der OSMF etwa 10 bei Cloudmade angestellt, das ist ja nicht weiter wild. Allerdings sind nun vor wenigen Tagen [*] 20 weitere Cloudmade-Mitarbeiter der OSMF beigetreten. Wenn man nun annimmt, dass (wie im letzten Jahr) von den normalen OSMF-Mitgliedern nur etwa jedes vierte eine Stimme abgibt, waehrend die Cloudmade-Mitarbeiter sich alle an der Wahl beteiligen, dann ergibt sich rechnerisch, dass rund 60% aller Stimmen, die abgegeben werden, von einem Cloudmade-Mitarbeiter kommen. [*] Nun sind die Cloudmade-Mitarbeiter natuerlich nicht alles Drohnen ohne eigene Meinung, aber trotzdem finde ich diese Entwicklung besorgniserregend, und die Sprueche von wegen lassen wir doch die Mitglieder entscheiden, wieviele Cloudmade-Leute im Vorstand sind klingen angesichts dieser Zahlen in meinen Ohren wie Hohn. Ich will mich nicht auf das Niveau herablassen, dass ich sage: Bitte tretet doch alle noch schnell in die OSMF ein und waehlt die folgenden Kandidaten. (Wenn in meiner Firma 20 Leute arbeiten wuerden und ich fuer den OSMF-Vorstand kandidierte, wuerde ich die vermutlich sogar bitten, sich zu enthalten - aber mir scheint, ich bin da wesentlich pingeliger als andere.) Aber wer von Euch ein kleines bisschen politisch interessiert ist und bislang vielleicht mehr aus Faulheit gezoegert hat, in die OSM-Foundation einzutreten, der hat zumindest am Donnerstag noch die Chance, fuer 15 Pfund einzutreten: http://foundation.openstreetmap.org/join/ und sich danach ein Bild ueber die Bewerber zu machen: http://wiki.openstreetmap.org/wiki/Foundation/AGM09/Election_to_Board und danach abzustimmen (per Email, Anleitung ist am Ende der vorgenannten Seite). Man kann je eine Stimme fuer bis zu 7 Bewerber abgeben. (Es kann nicht schaden, in der E-Mail kurz darauf hinzuweisen, dass man gerade erst eingetreten ist.) Bye Frederik [*] Die Liste der OSMF-Mitglieder ist derzeit nicht oeffentlich, ich kriege nur mit, wenn jemand eintritt, weil ich Mit-Admin der OSMF-Mitglieder-Mailingliste bin. Daher ist da immer auch ein gewisses Fehlerpotential in meinen Aussagen. Ich habe etwas mehr Details auf der OSMF-Talk-Liste geschrieben, hier: http://lists.openstreetmap.org/pipermail/osmf-talk/2009-August/000195.html Eventuell gibt es ja in den naechsten Stunden auch noch Stellungnahmen/Kommentare/Richtigstellungen dazu von anderen Leuten auf osmf-talk, die ihr dann da nachlesen koennt. -- 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] [Osmf-talk] EVERYONE: PLEASE VOTE
SteveC schrieb: We're in a very difficult position and don't always make the right choices. CloudMade has contributed tens of thousands of pounds in cash to the Foundation for things like sponsorship and servers. We've spent man years on coding work. Nick, me and many other in CloudMade spend far beyond 9-5 working to promote OSM and make it fly. But if we make a small mistake we're hung up to dry by people like Frederik as some kind of map-based Darth Vader figure. If you're in such a difficult position, then I would suggest to be more open in your communication to the community. In fact, I've suggested that already before. At the start of the voting period, something like: Please note: CloudMade is currently domination the OSMF board of directors and also last years votes. If you want to change this, join the OSMF now and vote would probably have reduced a lot of headache. That's what I would call open. Having ~20 CloudMade employees joining the OSMF just before the board votes closes is like raising the fuel prices just before holiday season. It might have it's reasons but it just smells to anyone outside. I wouldn't normally point to all of that because I have a lot of respect for you and I want GeoFabrik, ITO World and all the other companies using OpenStreetMap to succeed. But you keep doing this stuff without getting any push back, and if you're going to attack people like this in public then you should declare the other side of the coin. From Frederik I often get insights, from you I'm too often only hearing excuses. Regards, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenStreetBugs / JOSM Plugin and other bugs
Hallo. Am Mittwoch, 19. August 2009 schrieb Peter Loos: Kann mir jemand erklären, warum manche sehr einfache Bugs erfassen, aber den Bug nicht gleich korrigieren. Welchen Sinn macht das? Mögliche Erklärungen: - OSB ist wesentlich einfacher zu bedienen als ein OSM-Editor - Die Wahrscheinlichkeit wegen Fehlbedienung kollektiv auf den Deckel zu bekommen ist bei OSB wesentlich geringer - OSB braucht nur einen Browser, ist also evtl auf mehr Geräten nutzbar Gruß, Bernd -- Ein Diplomat ist jemand, der dich in einer Art und Weise zum Teufel wünscht, daß du dich auf den Trip freust. 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] Duden Schreibweise ... von Straß ennamen
Hallo, vorweg habe ich als Ergänzung noch das Problem/Frage mit der neuen Rechtschreibung bei Straßennamen wie Schloßstraße oder Schlossstraße Haselnußweg oder Haselnussweg Greift die Regel für 'ss' oder gilt der historische Namen ? In verschiedenen Städten wird das auf OSM unterschiedlich geschrieben. In Dormagen zum Beispiel wird das 'ß' auf den Schildern verwendet, aber auf der Straßenreinigungsliste schreibt die Verwaltung das als 'ss'. Für Dr. und Prof. würde ich die Kurzform als üblich ansehen, bei Sankt tendiere ich eher zur Langform. ... Ich würde mich freuen, wenn wir insbesondere bei Dr. / Prof. und Sankt einen allgemeinen Konsens finden können. Ausnahmen bestätigen dabei wie immer die Regel. ;-) diese Namen schreibe ich auch so, obwohl ich bei Kirchen St. Josef schreibe. Viele Grüße Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schreibweisen/Abkürzungen von Straß ennamen
Zitat Ropino: Hallo, im Zuge der Auswertung der Straßenlisten (http://osm.gt.owl.de/Strassenliste/) bin ich auf das Problem mit der zum Teil sehr unterschiedlichen Schreibweise von Straßennamen gestoßen. Die Regel, man schreibt es so wie es auf dem Schild steht, scheitert spätestens wenn eine Straße im gleichen Ort unterschiedliche Schreibweisen/Abkürzungen hat. Allgemeiner Konsens dürfte die Langform von Straße / -straße sein. Wie verfahren wir mit den Abkürzungen für: 1. Doktor - Dr. 2. Professor - Prof. 3. Sankt - St. Für Dr. und Prof. würde ich die Kurzform als üblich ansehen, bei Sankt tendiere ich eher zur Langform. Die amtlichen Straßenverzeichnisse helfen nicht wirklich weiter, da gibt es auch alle möglichen Varianten. [...] Erster Aspekt fuer die Entscheidung ist fuer mich, was auf dem Schild steht. Man stelle sich vor, Leute aus Gegenden, in denen andere Schriftzeichen als die lateinischen verwendet werden, wollen sich orientieren. Da hilft es ungemein, wenn die Zeichenfolge auf dem Schild mit dem in der Karte uebereinstimmt. Zumal man als jemand aus einem anderen Kulturkreis nicht selten die Bedeutung dessen, was da steht, gar nicht kennt. Chinesische Schriftzeichen zum Beispiel sind mir weitestgehend unbekannt und so wuerde ich im Fall der Faelle Karteneintrag und Strassenschild quasi als Grafik vergleichen. Bestuenden da auch nur kleine Unterschiede, waere ich schon etwas verunsichert. Aktuell habe ich hier in Hamburg so einen Fall. Es gibt eine St. Georgstraße und den St. Georgs Kirchhof, ja der ganze Stadtteil heisst St. Georg, im offiziellen Strassenverzeichniss wird auch die Kurzform verwendet. Warum also sollte man hier die Langform benutzen? -- Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenStreetBugs / JOSM Plugin and other bugs
On Thu, Aug 20, 2009 at 12:24:20AM +0200, Mitja Kleider wrote: Am Mittwoch, 19. August 2009 schrieb Florian Lohoff: kann jemand derzeit im JOSM die gezeigten OSM Bugs anklicken wenn das OpenStreetBugs layer aktiv ist? Auf der Karte nicht, aber in der Liste (Seitenleiste). Das Plugin stammt übrigens weder von Xav noch von mir. Bugreports gehören soweit ich weiss ins Trac von JOSM. Wie finde ich den von den 20 die ich sehe in der Liste? Und das genau war anders - Man konnte die in der Karte anklicken - und _DAS_ geht seit ein paar Wochen nicht mehr .. Ausserdem ist mein Karte Spring rum bug wieder da ... Nicht mehr so leicht zu triggern wie vorher - aber als ich gestern mich mal zum Bug Squashing hingesetz habe und meine Tour nach Hause planen wollte, dabei ein paar Bugs geschlossen, neu geoeffnet etc war der nach ein paar minuten wieder da ... Das wurde wahrscheinlich beim Bug schließen getriggert. Sollte jetzt wieder funktionieren (Skript bitte neu laden). Die Qualitaet ist gerade irgendwie im Sturzflug seit dem Wir machen alles besser ohne Xav Pass bitte auf was du hier von dir gibst. Ich pass schon auf - Dann setzt virtuelle rant /rant drumherum. Ich bin bloss ein wenig davon genervt das ein ehemals von mir viel und gerne genutztes tool heute fuer mich an allen stellen auseinanderbroeselt und fuer mich zumindest nicht mehr funktioniert. Angefangen habe ich mit Xav, ich würde auch jetzt noch gerne mit ihm zusammenarbeiten, wenn er das auch wollte. Meine ursprüngliche Motivation war beim Laden einer BBOX nicht nur neuere Bugs von außerhalb der BBOX zurückzubekommen und ein ordentlicher GPX Export. Hier ist die Qualität in meinen Augen extrem gestiegen und damit war mein Ziel erreicht. Ich kenne mich mit Javascript nicht wirklich aus, habe momentan viel um die Ohren und fixe trotzdem die Fehler im Client, auch wenn sie mich selbst nicht betreffen. Du schimpfst hier rum, gibst dir selber aber keine große Mühe die Probleme zu lösen. Wenn es ständig auftritt, versuche es doch reproduzierbar zu machen (zum Beispiel mit der Firebug Extension). Ich war schon vorher OSB poweruser und seit dem umzug d.h. seit dem hier Schokokecks als das beste seid geschnitten Brot verkauft wird versuche ich da mitzuziehen - Aber Sorry - Ich habe keinen spass mehr an OSB - Weder beim Eroeffnen wobei das sogar mit dem JOSM Plugin noch geht - Aber systematisches durchgehen der ~500 Bugs in meinem Einzugsbereich ist mit den derzeitigen tools ein ding der unmoeglichkeit. Im JOSM kann ich die bugs nicht denen zuordnen die ich sehe - Im Webfrontend spring das zeugs hin und her. Mit welchem Frontend soll ich denn bitte meine Fahrtstrecke planen in dem ich mir da mal ein paar Bugs raussuche die ich systematisch abgrase? Einen GPX Export brauche ich nicht - ich will die Bugs wiederfinden die ich sehe. Und Firebug habe ich permament installiert und es ist ja kein klassischer Javascript fehler der einen backtrace wirft - d.h. kein syntaktischer sondern ein semantischer fehler. Das ich selber schon ein OSB Overlay gebaut habe weiss ich wie das grundsaetzlich funktioniert. 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] OSM Foundation: Mitglied werden und mit abstimmen!
Hi Frederik Am 20. August 2009 03:30 schrieb Frederik Ramm frede...@remote.org: Das ist ja alles schoen und gut. Bis vor kurzem waren von den rund 150 Mitgliedern der OSMF etwa 10 bei Cloudmade angestellt, das ist ja nicht weiter wild. Allerdings sind nun vor wenigen Tagen [*] 20 weitere Cloudmade-Mitarbeiter der OSMF beigetreten. Wenn man nun annimmt, dass (wie im letzten Jahr) von den normalen OSMF-Mitgliedern nur etwa jedes vierte eine Stimme abgibt, waehrend die Cloudmade-Mitarbeiter sich alle an der Wahl beteiligen, dann ergibt sich rechnerisch, dass rund 60% aller Stimmen, die abgegeben werden, von einem Cloudmade-Mitarbeiter kommen. [*] Danke für diese Information! Es ist richtig und wichtig so etwas zu erfahren. Danke für deinen Mut. Natürlich hast auch du eigene Interessen, aber alles was erst dann offiziell bestätigt wird, wenn jemand anderes anfängt zu plaudern, kotzt mich an. Netter Gruß Torstiko „Ihr unterschätzt meine Macht!“ — Darth Vader zu Obi-Wan Kenobi ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenStreetBugs / JOSM Plugin and other bugs
Hallo. Am Donnerstag, 20. August 2009 schrieb Florian Lohoff: Ich pass schon auf - Dann setzt virtuelle rant /rant drumherum. Was deine kompletten Postings als destruktives Flaming beschreibt und somit keinen irgendwie weiter bringt. Es hält dich keinen davon ab - mit Xav zu reden ob er Patches von außen annehmen möchte - selbst etwas auf die Beine zu stellen was besser ist - dich an Entwicklung und Bugfixing aktiv zu beteiligen Wildes rumflamen gegen Leute, die versuchen was tolles zu programmieren schädigt jedenfalls die Stimmung (und Motivation!) und hilft dir nicht im geringsten. Gruß, Bernd -- Homer Simpson: Jetzt sei doch nicht so betrübt über Krustys Tod. Tagtäglich sterben viele Menschen. Das ist doch ganz normal. Vielleicht wachst auch Du morgen früh tot auf. 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
