[Talk-de] ÖPNV-Schema: aktueller Status / wei tere Schritte?
Hallo zusammen! Da ich in den letzten Tagen aus purem Eigennutz ;) das U-Bahn-Netz von Barcelona erfasst habe, frage ich mich jetzt, ob ich die Vorschläge von Oxoma (also das neue ÖPNV-Schema von http://wiki.openstreetmap.org/wiki/User:Oxomoa/ÖPNV-Schema) schon verwenden will. Wie ist denn hier so der aktuelle Status? Ist geplant, daraus bald mal ein offizielles Proposal zu machen und darüber abzustimmen? Wenn nein, warum nicht? Ich denke, es besteht doch jetzt schon eine gewisse Erfahrung damit - und als Ergänzung für das bisherige Tagging erlaubt es schonmal die schöne Erfassung von z.B. stop_areas. Gibt es außer der öpnvkarte.de schon irgendwelche Applikationen, die das unterstützen? -- Gernot ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Routen-Relationen für Bahn-Kursbuchst recken
Hallo nochmal! Als Pendler spiele ich mit dem Gedanken, mal meine Kursbuchstrecke (Landshut-München) mit entsprechenden Routen-Relationen zu erfassen. Jetzt frage ich mich nur, wie man das sinnvoll macht. Der Gleiskörper zwischen Landshut und München ist schon sehr gut erfasst - z.B. sind getrennte Gleise für beide Richtungen in OSM, die Bahnhöfe haben alle Bahnsteige und Gleise, etc. Das ist zwar schön, stellt mich aber bei der Relation vor größere Probleme. Ich frage mich, welche Gleisstücke ich in die Relation aufnehmen will. Zwei Unterprobleme: die offene Strecke: wenn ich das neue ÖPNV-Schema verwende, kann ich beide Fahrtrichtungen getrennt erfassen, damit macht es auch Sinn, beide Richtungs-Gleise einzupflegen. Aber für eine normale route-Relation - macht es da auch Sinn? Und vor allem: was ist mit den Bahnhöfen? Bei den kleinen ist es noch relativ einfach, weil die Züge von/nach München meist auf denselben Gleisen halten - aber in München sind es je nach Verbindung x verschiedene Gleise. Welches soll ich nun in die Relation packen? Alle? Das schaut dann gerendert sicher furchtbar aus... -- Gernot ___ 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 04:23:20 +0200 Von: Martin Koppenhoefer dieterdre...@gmail.com An: qbert biker qbe...@gmx.de CC: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Trunk oder primary was denn jetzt, kreuzungfrei oder alle 20 m ein Feldweg? So ne Straße, die dann wahrscheinlich noch von Traktoren mit Anhängern befahren wird, etc., ist dann schon ziemlich weit weg von den autobahnähnlichen, um die es hier geht. Das mit den 20m war eine stilistische Uebertreibung meinerseits, sorry. ;) Aber das ist ja auch nicht das Problem. Ich habe jede Menge Tags, die eine autobahnaehnliche Strasse beschreiben, aber eben keine fuer den Ausbauzustand der zwischen dem autobahnaehlichem Ausbau und einer besseren Landstrasse liegt. Wenn dir persoenlich es egal ist, ob eine normale Strasse kreuzungsfrei ausgebaut ist, dann brauchst du das ja nicht einzutragen, aber fuer andere ist dieses Detail vielleicht interessant. m.E. ist das die eine klare und einfache Möglichkeit, und wenn es ein explizites Verbot gibt, sollte man das irgendwann auch mappen. Man kann dem Mapper aber auch die Moeglichkeit geben, alle diese Einzelverbote nach der Systematik einzutragen, nach der sie erstellt wurden. Ein Fahrer schaut bei einer kreuzungsfrei ausgebauten normalen Strasse ja auch nicht auf die Schilder, weil er weiss, dass er nur rechts runter kommt und die Ausfahrt auf der Gegenseite fuer ihn tabu ist (meistens jedenfalls). Ganz einfach in der Form eines Attributes, das aussagt, dass die Strecke von A nach B ueber X km kreuzungsfrei ausgebaut ist. Das kann ein Mapper vor Ort gut erkennen und ohne grossen Aufwand eintragen. Ansonsten ists eben eine Information, die 'die anderen' haben und wir nicht. 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] Gebaeude und Restaurants (Reit und Wanderkarte)
Hi! elchtrei...@gmx.net schrieb: ich finde es schade, daß in der Reit und Wanderkarte die Restaurants untergehen, wenn die Eigenschaft an einem Gebäude dran hängt. Beispiel ist die Auer Alm, die ist korrekt eingetragen (mit Gebäude) aber leider nicht sichtbar: http://topo.geofabrik.de/?zoom=15lat=47.68901lon=11.67314layers=BT Hier ist eine Alm, welche nicht als Gebäude, nur als Punkt makiert ist, die taucht in der Karte auf: http://topo.geofabrik.de/?zoom=15lat=47.69749lon=11.71578layers=BT Du mußt das nicht schade finden, Du kannst Erweiterungen einfach vorschlagen. :-) Das gleiche Problem besteht bei Spielplätzen, wenn die als Area und nicht als Punkt eingetragen sind. Hast Du dafür ein Beispiel? Spielplätze sollten mit einem eigenen Muster gefüllt werden. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Schema: aktueller Status / weit ere Schritte?
Hi! On Tue, Aug 18, 2009 at 08:09:58AM +0200, Gernot Hillier wrote: Da ich in den letzten Tagen aus purem Eigennutz ;) das U-Bahn-Netz von Barcelona erfasst habe, frage ich mich jetzt, ob ich die Vorschläge von Oxoma (also das neue ÖPNV-Schema von http://wiki.openstreetmap.org/wiki/User:Oxomoa/ÖPNV-Schema) schon verwenden will. Wie ist denn hier so der aktuelle Status? Die Diplomarbeit von Sebastian (Oxomoa) ist abgeschlossen. (Sie kann übrigens von http://www.kahlfrost.de/dateien/diplomarbeit.pdf heruntergeladen werden.) Sebastian hat jetzt einen Job und sich anderen Themen zugewandt. Für ÖPNV-Themen gibt es die (englischsprachige) Mailingliste talk-transit: http://lists.openstreetmap.org/listinfo/talk-transit . Die Leute dort haben sich des Vorschlags angenommen und Modifikationen eingebaut und wollen da dran weiterarbeiten bzw. das allgemeiner einführen. Ist aber alles viel Arbeit und dauert lang. Weitere Mitstreiter sind erwünscht. 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] JOSM: Weg aufteilen bzw. Attribute neu vergeben
Am 17.08.2009 23:25, Sebastian Klemm: Bernd Hohmann schrieb: Hinter eines bin ich noch nicht gekommen: Gegeben sei irgendein langer Waldweg, den irgendjemand mal als grade2 eingetragen hat. Nun stell ich aber fest, dass sich da Schotter, Asphalt und Matsch abwechseln und möchte nun die Streckenattribute zwischen zwei oder mehreren Knoten neu vergeben. Ich bekomm das aber ums Verrecken nicht hin - nur über irgendein ganz mühsames Auftrennen mit folgendem Merge oder gar Neuzeichnen des Pfades weil JOSM irgenwie meint, dass die Punkt nicht einem Weg zugehörig sind. Irgendeine Lösung (oder anderen Editor) für einen armen Gelegenheits-OSMer? Bernd Entweder ich verstehe Dein Problem nicht, oder Du siehst den Wald vor lauter Bäumen nicht ;-) Ich trenne Wege in JOSM folgendermaßen: - Node auswählen an dem Weg getrennt werden soll - Taste [P] oder übers Menü: Werkzeuge-Weg aufspalten Kleiner Nachtrag: Das Aufteilen klappt auch mit mehreren gleichzeitig ausgewählten Knoten eines Weges. Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Metadaten in OSM
Am 17.08.2009 20:30, Alexander Menk: Hi! wenn ich jetzt ein paar Tags und Relationen austüftle um Koordination und Qualitätsmangement in der Datenbank zu fördern, welche dann eben auch in OSM gespeichert werden -- findet ihr das gut? Oder ist der OpenStreetBugs Ansatz - soetwas extern zu halten - besser? Oder haben wir irgendwo mal festgelegt, dass wir das nicht wollen? Grüße, Alexander PS: Siehe dazu auch: http://wiki.openstreetmap.org/index.php/Coordination, wobei ich am überlegen bin, dass vielleicht mit http://wiki.openstreetmap.org/wiki/Quality_Assurance zu verschmelzen. Ich würde diese eher temporären Metadaten auch aus praktischen Gründen extern halten. Ich denke dabei auch an die DB-Exporte, die eher an den Kern-Geodaten interessiert sein dürften. Wenn deine Daten sehr sprechend sind (bspw. qa=checked and approved 13082009 ) könnte es allerdings Sinn machen, sie direkt bei OSM zu hinterlegend. Denke auch daran, dass viele Mapper direkt auf den Text-Ebene mit den Daten arbeiten. Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Radfernweg Berlin-Kopenhagen Relation 28441
Hallo MM ;-) vielen Dank für die klarstellenden Anleitung zum wiederherstellen von Relationen. Werde sie nachvollziehen und dann eine entsprechende Wiki-Seite einrichten. Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebaeude und Restaurants (Reit und Wanderkarte)
Hi, -Original Message- From: talk-de-boun...@openstreetmap.org [mailto:talk-de- boun...@openstreetmap.org] On Behalf Of elchtrei...@gmx.net Sent: lunedì 17 agosto 2009 23.25 To: talk-de@openstreetmap.org Subject: [Talk-de] Gebaeude und Restaurants (Reit und Wanderkarte) ich finde es schade, daß in der Reit und Wanderkarte die Restaurants untergehen, wenn die Eigenschaft an einem Gebäude dran hängt. Das gleiche Problem besteht bei Alpine_hut. Beispiel ist die Rifugio Prabello Berghütte, die ist korrekt eingetragen (mit Gebäude) aber leider nicht sichtbar: http://topo.geofabrik.de/?zoom=15lat=45.9133189916611lon=9.072915315628la yers=BT Gruß Alberto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routen-Relationen für Bahn-Kursbuchstr ecken
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Gernot, habe bestimmte Eisenbahnstrecken im Rhein-Main-Gebiet angefangen zu benennen, bspw. die Homburger Bahn und die Main-Weser-Bahn, siehe http://osm.org/go/0D0YL0AS Dabei habe ich mich im Gleisvorfeld von FFM Hbf am Wiki-Artikel orientiert: http://de.wikipedia.org/wiki/Homburger_Bahn Im Bahnhof Frankfurt-Höchst http://osm.org/go/0D0SC217f- bspw. habe ich die entsprechenden Gleise nach Gleis x benannt und die zuführenden Hauptgleise sowie die entsprechenden Gleise der KBS alle der route zugeschlagen. Allerdings habe ich das aus dem Bauch heraus gemacht. Insbesondere finde ich die Variante der Platformbezeichnungen Gleis 3/4 bisher mehr als unglücklich. Ich würde auf jeden Fall beide Richtungsgleise in die KBS-Relation einsetzen und dann den Gleisen - sofern sie nicht in einem Bahnhof oder einer speziell benannten Brücke sind - auch den Namen der KBS geben (soweit ich weiss, haben alle KBS einen Namen zusätzlich zur Nummer). Ob aber in den ref=-Tag die KBS oder die Streckennummer kommt, habe ich noch nicht verstanden. Es sieht gerendert nicht grade toll aus, stimmt, aber wir mappen ja nicht für ;-) Btw. wäre es glaub ich für die Anwendung der Karte auch sehr hilfreich, wenn an der Strecke Landshut-München die Bahnsteige richtig eingetragen werden :-) Soweit erstmal meine Erfahrungen damit... Gruß - Fips - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqKcWoACgkQnHVyAFIfTkENdQCeM20z9/w8KZJK8EBlbfS2c4rD evYAnjH8avxpGgLHWqwQKkRp6VdynI1a =5hJf -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebaeude und Restaurants (Reit und Wanderkarte)
Hallo, das gleiche ist mir bei der Kürsinger Hütte aufgefallen. Gibt es die Möglichkeit das Problem zu lösen? Z.B. ein Ecke des Gebäudes als Anzeige zu verwenden. Wenn nicht, schlage ich vor dies einzubauen Grüße Jules -Ursprüngliche Nachricht- Von: talk-de-boun...@openstreetmap.org [mailto:talk-de-boun...@openstreetmap.org] Im Auftrag von Alberto Nogaro Gesendet: Dienstag, 18. August 2009 10:40 An: 'Openstreetmap allgemeines in Deutsch' Betreff: Re: [Talk-de] Gebaeude und Restaurants (Reit und Wanderkarte) Hi, -Original Message- From: talk-de-boun...@openstreetmap.org [mailto:talk-de- boun...@openstreetmap.org] On Behalf Of elchtrei...@gmx.net Sent: lunedì 17 agosto 2009 23.25 To: talk-de@openstreetmap.org Subject: [Talk-de] Gebaeude und Restaurants (Reit und Wanderkarte) ich finde es schade, daß in der Reit und Wanderkarte die Restaurants untergehen, wenn die Eigenschaft an einem Gebäude dran hängt. Das gleiche Problem besteht bei Alpine_hut. Beispiel ist die Rifugio Prabello Berghütte, die ist korrekt eingetragen (mit Gebäude) aber leider nicht sichtbar: http://topo.geofabrik.de/?zoom=15lat=45.9133189916611lon=9.072915315628la yers=BT Gruß Alberto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Firmware f?r GPSmap 60CSx sinnvoll?
Hab' nochmals ein wenig recherchiert: Es bestand da mal ein Problem bei einigen Garmin GPSmap Modellen, wenn man MicroSD-Karten eingesetzt hat, die vorher am Mac befuellt worden sind, da Mac OS X, wie wahrscheinlich andere UNIX-Derivate auch unsichtbare Dateien mit auf die Karte schreibt (.*). Die betroffenen Geräte sind dann teilweise beim Starten in irgendwelchen Endlosschleifen (Dauer-Piepton etc.) hängen geblieben. Ich habe auf meinem GPSmap 60 CSx jetzt 4.0 installiert und habe keinerlei Probleme dieser Art. Jürgen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebaeude und Restaurants (Reit und Wanderkarte)
Hallo Nop, Original-Nachricht Datum: Tue, 18 Aug 2009 09:30:28 +0200 Von: Nop ekkeh...@gmx.de An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Gebaeude und Restaurants (Reit und Wanderkarte) Hi! Du mußt das nicht schade finden, Du kannst Erweiterungen einfach vorschlagen. :-) Dann hätte ich das gerne... Das gleiche Problem besteht bei Spielplätzen, wenn die als Area und nicht als Punkt eingetragen sind. Hast Du dafür ein Beispiel? Spielplätze sollten mit einem eigenen Muster gefüllt werden. Anscheinend sind die gelegentlich zu klein. Habe da nur ein grün, wie bei einem Sportplatz gefunden. Hier mal ein Beispiel dazu: http://www.openstreetmap.org/browse/way/32790100 Die meisten Spielplätze haben noch extra einen Punkt in der Mitte, der dann als Spielplatz getaggt ist, und damit kommen die Spielplätze dann auch in die Karte. An dieser Stelle nochmals herzlichen Dank für die Karte, die wird von mir gerne benutzt. Gruß Kai -- 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
[Talk-de] Konvertierungstool gmapsupp.img - .gmapi (Garmin RoadTrip)?
Hallo Sven, .gmapi ist das Dateiformat, das Garmin für RoadTrip (das Mac-Pendant zu Mapsource unter Windoof) verwendet. Es gibt auch ein Script, das die MapSource-Dateien (eine .img als Übersicht, eine .tdb und viele .img als Kacheln und optional eine .typ), die beispielsweise Computerteddy anbietet, zu diesem .gmapi umwandelt. Würde man dieses als Zwischenschritt akzeptieren, käme auch ein Tool in Betracht, das aus dem gmapsupp.img die MapSource-Dateien generiert, worauf man wieder das Script Gmapi Builder anwenden könnte. Sollte natürlich auch ein Mac Tool oder Script sein. Jürgen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] 1. OSM-Treff der Städteregion Aachen am Mittwoch, den 26. August - Jeder ist willko mmen
Herzliche Einladung zum 1. OSM-Treff der Städteregion Aachen Am Mittwoch, den 26. August 2009, ist es so weit. Um 19 Uhr treffen wir uns im La Bahia, Bachstraße 30, (derzeit für 10 Personen reserviert, kann natürlich noch angepaßt werden) , um über OSM zu reden, uns kennenzulernen und die Community durch gegenseitige Hilfe zu stärken. Uns schwebt ein Treffen zum Meinungs- und Erfahrungsaustausch vor, bei dem Neulinge ihre offenen Fragen klären können, die alten Hasen mit Rat und Tat zur Seite stehen, man sich über die genutzten Techniken und Geräte austauschen und den Communitygedanken etwas pflegen kann. Jeder ist eingeladen! Egal ob Neuling, Profi oder sonstwie Interessierter, einfach vorbeikommen (kuze Anmeldung wäre nett)! Mehr Infos und Kontaktmöglichkeiten gibt es hier: http://wiki.openstreetmap.org/wiki/Aachen_Community#1._OSM-Treff_der_St.C3.A4dteregion_Aachen Netter Gruß Torstiko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Gebaeude und Restaurants (Reit und Wanderkarte)
Hi! Das gleiche Problem besteht bei Alpine_hut. Das ist doch kein Problem. Es gibt einfach noch keine Renderregeln dafür, weil ich mich im Mittelgebirge und nicht in den Alpen tummele. Macht einfach Vorschläge, dann kommen die Objekte auch nach und nach auf die Karte. bye Nop -- 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] Routen-Relationen für Bahn-Kursbuchst recken
Moin, Als Pendler spiele ich mit dem Gedanken, mal meine Kursbuchstrecke (Landshut-München) mit entsprechenden Routen-Relationen zu erfassen. trifft wahrscheinlich vieles nicht auf Deine Strecke zu, aber mal etwas allgemein die Abgründe beleuchtend, die sich zumindest für mich dabei auftun: Ich frage mich, welche Gleisstücke ich in die Relation aufnehmen will. Was möchtest Du mit der Relation denn zusammenfassen: - Die physikalische Strecke (analog route=road, vielleicht route=track/railway) - Den Verkehr, der darüber läuft (also route=rail wie im ÖPNV-Schema linienbezogen) Wie bindest Du im letzteren Fall dann den KBS-übergreifenden Regional- oder den Fernverkehr (übergreifend und/oder nur punktuell berührend) mit ein? In Analogie zum Bus wird eine KBS ja quasi von normaler Linie, Nachtbuslinie und Schnellbuslinie benutzt, die dort ja wohlweislich getrennt sind und auch in getrennten Relationen erfasst werden. Also dann doch eher eine Relation je Zuglauf oder zumindest identischer Zugläufe? Zwei Unterprobleme: die offene Strecke: wenn ich das neue ÖPNV-Schema verwende, kann ich beide Fahrtrichtungen getrennt erfassen, damit macht es auch Sinn, beide Richtungs-Gleise einzupflegen. Aber für eine normale route-Relation - macht es da auch Sinn? Was ist eine normale route-Relation? Sowohl Strecke (road) als auch Verkehr (ÖPNV) ist doch eine normale route-Relation. In Analogie zu Autobahnen - auch wenn es dort noch nicht so ist - würde es in meinen Augen Sinn machen, die Strecke richtungsbezogen in getrennten Richtungs-Relationen zu erfassen und dann beide in eine Strecken-Relation zu stecken. Aber was wäre dann mit planmäßigem Gleiswechselbetrieb? (Nein, nicht auf der BAB!) Und gleisgenau: Welche Gleise im Bahnhof werden denn in welcher Richtung benutzt? Zugriff auf Fahrplan / Bahnhofsfahrordnung? aber in München sind es je nach Verbindung x verschiedene Gleise. Welches soll ich nun in die Relation packen? Alle? Ist doch eindeutig ;-) Streckenbezogen: Alle! Ähm, d. h. ... zählen Nebengleise evtl. doch gar nicht zur Strecke, sondern nur die Hauptgleise (durchgehende Streckengleise)? Aber im Kopfbahnhof gibt es ja keine durchgehenden Streckengleise ... ;-) Egal, weiter: Strecke richtungsbezogen: Siehe vorheriger Absatz und noch weiter oben. Verkehrsbezogen (Linie): Oft eins, aber manchmal eben auch mehrere ... Zuglaufbezogen: Immer nur (s)eins - ahh, wäre das schön. ;-) Das schaut dann gerendert sicher furchtbar aus... Zum Glück für mich ein PAL ;-) Aber mein Fazit: Streckenbezogen als KBS-Gesamtstrecke ist noch machbar, richtungsbezogen schon etwas schwieriger. Verkehrsbezogen ist m. E. nur möglich wenn es sich nur und ausschließlich um echten Linienverkehr handelt (siehe z. B. Verkehrsverbünde), was aber heutzutage eher zufällig mit der KBS übereinstimmt. Gruß Georg (Eisenbahn interessiert, aber nicht dort Routen-Relationen erstellend) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Meinen selbstgerenderten Tiles fehlt etwas
Jan-Benedict hat mir eine sehr gute Anleitung geschrieben, die super funktioniert. Habe sie etwas verbessert und kann sie dir Montag schicken. Hast du deine verbesserte Anleitung mittlerweile vorliegen? Ich habe bisher noch nichts erhalten. Am Besten schickst du das wohl über diese Liste. Dann haben andere auch etwas davon ... Danke schon mal im Voraus. Cornelius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bäume (Naturdenkmäler)
Am 17. August 2009 18:52 schrieb Jan-Benedict Glaw jbg...@lug-owl.de: Hi! Ich bin die Tage im Wald über eine Eiche gestolpert, die das NRW-Wappen mit der Unterschrift Naturdenkmal getragen hat. Für diese hab' ich mehrere abweichende Tagging-Vorschläge gefunden: http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Kulturdenkmale natural=tree monument=yes http://wiki.openstreetmap.org/wiki/Proposed_features/Key:natural_protection natural_protection=natural_monument http://wiki.openstreetmap.org/wiki/L%C3%BCbeck/Schutzgebiete leisure=nature_reserve name=ND Nachtkoppel area=yes Mir scheinen die ersten beiden Ansätze sinnvoller zu sein. Das sehe ich genau so. Es sind zwei unterschiedliche Blickwinkel auf die gleiche Sache. natural=tree monument=yes Hat die Bedeutung des Baumes selbst zum Gegenstand. natural_protection=natural_monument Stellt demgegenüber auf des rechtlichen Status ab. Allerdings geht aus natural_protection=natural_monument nicht hervor, dass es sich um einen geschützten Baum handelt. Ein Naturdenkmal kann auch ein Stein oder Loch in der Erde sein. Bei einem geschützten Baum müsste man also beide Tags setzen. Der Baum ist dann nicht nur bedeutend sondern gleichzeitig auch unter besonderen rechtlichen Schutz gestellt. Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Trunk oder primary
qbert biker schrieb: Man kann dem Mapper aber auch die Moeglichkeit geben, alle diese Einzelverbote nach der Systematik einzutragen, nach der sie erstellt wurden. Ein Fahrer schaut bei einer kreuzungsfrei ausgebauten normalen Strasse ja auch nicht auf die Schilder, weil er weiss, dass er nur rechts runter kommt und die Ausfahrt auf der Gegenseite fuer ihn tabu ist (meistens jedenfalls). Ganz einfach in der Form eines Attributes, das aussagt, dass die Strecke von A nach B ueber X km kreuzungsfrei ausgebaut ist. Das kann ein Mapper vor Ort gut erkennen und ohne grossen Aufwand eintragen. Ansonsten ists eben eine Information, die 'die anderen' haben und wir nicht. Warum so unpragmatisch? Wenn es noch kein entsprechendes Tag gibt dann führe es doch einfach ein... crossingfree=yes oder ähnlich und das Problem ist gelöst - würde ich so auch unterstützen. Die Aussage von dem Tag ist dann Es ist nicht mit querendem Verkehr zu rechnen, deuted aber nicht zwangsläufig auf eine schnelle Strasse hin, ehr auf eine bessere Verkehrsentflechtung Gruss Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konvertierungstool gmapsupp.img - .gmapi (Garmin?RoadTrip)?
Jürgen Frank o...@juergen-frank.de wrote: Würde man dieses als Zwischenschritt akzeptieren, käme auch ein Tool in Betracht, das aus dem gmapsupp.img die MapSource-Dateien generiert, worauf man wieder das Script Gmapi Builder anwenden könnte. Sollte natürlich auch ein Mac Tool oder Script sein. Gmaptool kann die einzelnen Bestandteile eines gmapsupp.img extrahieren. Gibts leider nur als exe, läuft aber unter wine. Sven -- Kernel panic: I have no root and I want to scream (Linux Kernel Error Message) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Postal_code oder addr:postcode
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 ??? Was mein Ihr ?? - Kleiner Hinweis noch - da KOSMOS addr:postcode nicht auswerten kann konvertiere ich diesen vorab in addrpostcode (ohne den Doppelpunkt). Dieses geht sehr schnell auf Perl-Basis mit der Funktion: perl -p -i.bak -e ~s|addr:postcode|addrpostcode| %osmworkfolder%\osmosis\hl_postcode.osm (bei diesem Aufruf wird autom. eine bak-Datei erstellt) Gruß jan :-) [1] http://www.tappenbeck.net/osm/kosmos/data/luebeck_plz/deu/ ___ 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 14:10:57 +0200 Von: Garry garr...@gmx.de An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Trunk oder primary Warum so unpragmatisch? Weil ich ganz pragmatisch kein Freund von privaten tags, bzw. der chaotischen Verbreiterung der Tagbasis bin... Die Aussage von dem Tag ist dann Es ist nicht mit querendem Verkehr zu rechnen, Steckt schon etwas mehr dahinter, denn kreuzungsfreier Ausbau bedeutet ja nicht, dass es keinen kreuzenden Verkehr gibt, sondern dass der mit relativ hohem technischen Aufwand entkoppelt ist, also drunter oder drueber weg gefuehrt wird. Das ist teuer und wird eigentlich nur dann gemacht, wenn es gute Gruende dafuer gibt, also Verbesserung des Durchsatzes und/oder bessere Reisezeiten. deuted aber nicht zwangsläufig auf eine schnelle Strasse hin, ehr auf eine bessere Verkehrsentflechtung Schnell ist relativ und es ist eine Eigenschaft von mehreren. Kreuzungsfreien Ausbau gibt in Kombination mit eventuellem Tempolimit, KFZ-strasse, Ueberholverbot, etc. schon Aufschluss ueber die erreichbare Reisezeit. Die Reisezeit geht eben gewaltig in die Knie, wenn man wegen Ampeln oder Linksabbiegern immer wieder zum Stehen kommt. Man kann ja die Reisezeit als Integral der Geschwindigkeitsfunktion sehen und mit kontinuierlichen 80 kommt man i.A. frueher an, als wenn man zwischen den Ampeln auf 100kmh hochjagt. Die Spritsache kommt dann auch noch dazu. Und mir ist auch klar, dass derartige Strecken meist dann gebaut werden, wenn vorher schon viel Verkehr war und LKW-Dichte und Staugefahr nicht ohne sind, aber Voraussetzung fuer Staumodellierung ist nun mal eine gute Beschreibung der Strecke, auf der sich der Stau aufbaut. So ganz nebenbei hat man mit den archivierten tracks ein probates Mittel, mit realen Reisezeiten Mythen und Legenden auszuraeumen. Die Daten sind da, man braucht sie nur auswerten ;) 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] Metadaten in OSM
Hi ich würde auf den on the ground-Ansatz verweisen: Wenn etwas tatsächlich auf der Erde existiert (z.B. fixme=incomplete - der weg existiert tatsächlich, fehlt aber in osm) würd ich's als Tag hinterlegen. Meta-Infos, die keinen direkten Bezug zu Dingen auf der Erde haben (reserved_by=mazdermind - dieser Bereich wird von MaZderMind abgezeichnet), gehören nicht in die DB. Die Trennung ist jedoch wie immer der subjektivität unterworfen. Peter wenn ich jetzt ein paar Tags und Relationen austüftle um Koordination und Qualitätsmangement in der Datenbank zu fördern, welche dann eben auch in OSM gespeichert werden -- findet ihr das gut? Ich würde diese eher temporären Metadaten auch aus praktischen Gründen extern halten. Ich denke dabei auch an die DB-Exporte, die eher an den Kern-Geodaten interessiert sein dürften. Wenn deine Daten sehr sprechend sind (bspw. qa=checked and approved 13082009 ) könnte es allerdings Sinn machen, sie direkt bei OSM zu hinterlegend. Denke auch daran, dass viele Mapper direkt auf den Text-Ebene mit den Daten arbeiten. ___ 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 14:57 schrieb qbert biker qbe...@gmx.de: Weil ich ganz pragmatisch kein Freund von privaten tags, bzw. der chaotischen Verbreiterung der Tagbasis bin... Du kannst ja auch im Wiki ein Proposal einstellen, wenn Dir chaotisch nicht so liegt. Das ist i.d.R. ein guter Anfang, damit auch andere das Tag nutzen. Die Reisezeit geht eben gewaltig in die Knie, wenn man wegen Ampeln oder Linksabbiegern immer wieder zum Stehen kommt. wobei für Linksabbieger auf jeder größeren Straße, auch wenn sie nicht kreuzungsfrei ausgebaut ist, normalerweise eine Abbiegespur eingerichtet ist. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebaeude und Restaurants (Reit und Wanderkarte)
ekkeh...@gmx.de wrote: Das ist doch kein Problem. Es gibt einfach noch keine Renderregeln dafür, weil ich mich im Mittelgebirge und nicht in den Alpen tummele. Macht einfach Vorschläge, dann kommen die Objekte auch nach und nach auf die Karte. Das ist mir die Tage auch aufgefallen, dass die ganze Sache wohl eher für Mittelgebirge optimiert ist... Bergwege sieht man teilweise kaum und Pfade verwechselt man leich mit boundary. Letzteres interessiert in der Regel kaum. Was man haben möchte sind sichtbarere Renderingregeln für path sowie Darstellung von SAC-Scale auf path und footway (eventuell auch auf track). Hier mal ein Beispiel mit SAC-Scale Rendering: http://informationfreeway.org/?zoom=17lat=46.41617lon=7.71723layers=B000FF http://topo.geofabrik.de/?zoom=15lat=46.41474lon=7.71795 Gruss Sven -- All bugs added by David S. Miller da...@redhat.com Linux Kernel boot message from /usr/src/linux/net/8021q/vlan.c /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Firmware f?r GPSmap 60CSx sinnvoll?
Jürgen Frank o...@juergen-frank.de wrote: da Mac OS X, wie wahrscheinlich andere UNIX-Derivate auch unsichtbare Dateien mit auf die Karte schreibt *urgs* Nein, Linux tut sowas nicht. Sven -- Whenever there is a conflict between human rights and property rights, human rights must prevail. (Abraham Lincoln) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Metadaten in OSM
Hallo! dahin ging meine Frage .. gibt es irgendwo solche richtlinien (aehnlich wie was gehoert in die Wikipedia, was nicht). On the ground ist schon ein guter Ansatz, aber was ist mit unbefestigten Laendergrenzen, und eben diesen ganzen Relationen. Werde versuchen die Qualitaetssicherung mehr relationsorientiert zu machen. Habe Addis Ababa jetzt zwar mit einem Riesen Raster versehen, aber ich werde das wohl längerfristig wieder wegräumen und dann die Qualitätssicherung Stadtteileweise oder orientiert an Straßenzügen in Relationen codieren. Das ganze hat den praktischen Vorteil, das man nicht ständig zwischen OSM Editor und Wiki hin und herspringen muss - inbesondere da Geocodierte (Meta) Informationen im Wiki ja nicht ganz einfach darstellbar sind. Freue mich aber über Hinweise zu anderen QC-Ansätzen - was richtig vergleichbares hab ich aber noch nicht gefunden. Grüße, Alexander Peter Körner wrote: ich würde auf den on the ground-Ansatz verweisen: Wenn etwas tatsächlich auf der Erde existiert (z.B. fixme=incomplete - der weg existiert tatsächlich, fehlt aber in osm) würd ich's als Tag hinterlegen. Meta-Infos, die keinen direkten Bezug zu Dingen auf der Erde haben (reserved_by=mazdermind - dieser Bereich wird von MaZderMind abgezeichnet), gehören nicht in die DB. Die Trennung ist jedoch wie immer der subjektivität unterworfen. Peter wenn ich jetzt ein paar Tags und Relationen austüftle um Koordination und Qualitätsmangement in der Datenbank zu fördern, welche dann eben auch in OSM gespeichert werden -- findet ihr das gut? Ich würde diese eher temporären Metadaten auch aus praktischen Gründen extern halten. Ich denke dabei auch an die DB-Exporte, die eher an den Kern-Geodaten interessiert sein dürften. Wenn deine Daten sehr sprechend sind (bspw. qa=checked and approved 13082009 ) könnte es allerdings Sinn machen, sie direkt bei OSM zu hinterlegend. Denke auch daran, dass viele Mapper direkt auf den Text-Ebene mit den Daten arbeiten. -- Grüße, Alexander Die o.a. eMail Adresse ist nur begrenzt gültig. Unbegrenzter Kontakt: http://address-protector.com/RXRQbgTtrGWITEgLdf-4UqZsVw2UhXhYixF1VykbX4oPQEOFcHPgPVitw9SWT4tk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Metadaten in OSM
Claudius wrote: Am 17.08.2009 20:30, Alexander Menk: Hi! wenn ich jetzt ein paar Tags und Relationen austüftle um Koordination und Qualitätsmangement in der Datenbank zu fördern, welche dann eben auch in OSM gespeichert werden -- findet ihr das gut? Oder ist der OpenStreetBugs Ansatz - soetwas extern zu halten - besser? Oder haben wir irgendwo mal festgelegt, dass wir das nicht wollen? Grüße, Alexander PS: Siehe dazu auch: http://wiki.openstreetmap.org/index.php/Coordination, wobei ich am überlegen bin, dass vielleicht mit http://wiki.openstreetmap.org/wiki/Quality_Assurance zu verschmelzen. Ich würde diese eher temporären Metadaten auch aus praktischen Gründen extern halten. Ich denke dabei auch an die DB-Exporte, die eher an den Kern-Geodaten interessiert sein dürften. Wenn deine Daten sehr sprechend sind (bspw. qa=checked and approved 13082009 ) könnte es allerdings Sinn machen, sie direkt bei OSM zu hinterlegend. Denke auch daran, dass viele Mapper direkt auf den Text-Ebene mit den Daten arbeiten. werde mir natürlich Mühe geben das entsprechend zu strukturieren, so das man es entsprechend rausfiltern kann (oder vielleicht auch irgendwann mal nur die Daten holen kann, welche eben approved sind). -- Grüße, Alexander Die o.a. eMail Adresse ist nur begrenzt gültig. Unbegrenzter Kontakt: http://address-protector.com/RXRQbgTtrGWITEgLdf-4UqZsVw2UhXhYixF1VykbX4oPQEOFcHPgPVitw9SWT4tk ___ 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 15:16:21 +0200 Von: Martin Koppenhoefer dieterdre...@gmail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Trunk oder primary wobei für Linksabbieger auf jeder größeren Straße, auch wenn sie nicht kreuzungsfrei ausgebaut ist, normalerweise eine Abbiegespur eingerichtet ist. Mit den ueblichen Problemen wie begrenzter Kapazitaet dieser Spuren oder kuerzeren Gruenphasen wegen Ampeln mit Linksabbiegerschaltungen, usw. Ums kurz zu machen. Wir brauchen uns hier nicht um diese Kleinigkeiten zu streiten. Verkehrstechniker haben zu diesen Themen ausgezeichnete Zahlen zur Kapazitaet mit und ohne kreuzungsfreiem Ausbau und keiner wuerde Bruecken und Rampen bauen, wenns nix bringen wuerde. 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] Trunk oder primary
Am 18. August 2009 15:38 schrieb qbert biker qbe...@gmx.de: Ums kurz zu machen. Wir brauchen uns hier nicht um diese Kleinigkeiten zu streiten. Verkehrstechniker haben zu diesen Themen ausgezeichnete Zahlen zur Kapazitaet mit und ohne kreuzungsfreiem Ausbau und keiner wuerde Bruecken und Rampen bauen, wenns nix bringen wuerde. ja, mappen wir ja daher auch alles schön. Das Thema ist auch komplett gelöst (s. Abbiegerestriktionen) und funktioniert, das einzige was Dir fehlt ist ein expliziter Tag für kreuzungsfrei (weil Dir die Restriktionsrelations nicht behagen). Du beschwerst Dich, dass es den nicht gibt, aber erfinden willst Du ihn auch nicht. Dann musst Du halt warten, bis jemand anders das für Dich macht. 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: Tue, 18 Aug 2009 15:55:55 +0200 Von: Martin Koppenhoefer dieterdre...@gmail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Trunk oder primary ja, mappen wir ja daher auch alles schön. Das Thema ist auch komplett gelöst (s. Abbiegerestriktionen) und funktioniert, Geloest vielleicht, aber sicher nicht komplett. Ich kann zwar relativ einfach von einem Status 'kreuzungsfreier Ausbau' die davon anhaengigen Restriktionen errechnen, aber eben nicht so einfach von den einzelnen Restriktionen auf den kreuzungsfreien Ausbau zurueckschliessen, selbst wenn sie vollstaendig und absolut richtig eingetragen waeren. Das Auge des Betrachters vor Ort ist hier nicht zu unterschaetzen. das einzige was Dir fehlt ist ein expliziter Tag für kreuzungsfrei (weil Dir die Restriktionsrelations nicht behagen). Ob mir etwas behagt oder nicht, spielt eigentlich keine Rolle. Offen bleibt, was besser fuers Projekt ist und wie man die hoehere Qualitaet mit weniger Aufwand erzielt. Ein Tag 'kreuzungsfrei' koennen auch Mapper eintragen, die keine Relationen anfassen, aus welchem Grund auch immer. Ist das Tag fuer eine Strecke vergeben, kann jeder geuebte Mapper die Einzelabbiegerestriktionen nachtragen. Du beschwerst Dich, dass es den nicht gibt, aber erfinden willst Du ihn auch nicht. Dann musst Du halt warten, bis jemand anders das für Dich macht. Ich beschwere mich nicht, ich diskutiere hier in der Liste und bringe so vielleicht ein paar Infos unter die Leute, die hier mitlesen. Im Wiki hab ich frueher einiges gemacht, heute nicht mehr - ist und bleibt aber meine persoenliche Entscheidung. Gruesse Hubert -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Alten Weg wiederherstellen
Hallo, wie kann ich denn einen alten Versionsstand eines Weges wiederherstellen? Mir ist da kürzlich ein Potlatch-Unfall mit dem Weg 24929645 passiert (der ist jetzt fasst kreisrund), der trotz der Revert-Funktion von Potlatch Einzug in die Datenbank gefunden hat (ich hatte Potlatch schon immer gehasst, dachte aber, dass diese Fehler mittlerweile nicht mehr existieren - falsch gedacht) und ich bin erst durch einen Mitmapper heute darauf aufmerksam geworden. Nun kann ich wohl in JOSM mir die alten Versionen anzeigen lassen, aber wie bekomme ich diese alte Version (vom Oktober 2008) wiederhergestellt? TIA Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Gebaeude und Restaurants (Reit und Wanderkarte)
Hi! Das ist mir die Tage auch aufgefallen, dass die ganze Sache wohl eher für Mittelgebirge optimiert ist... Das ist auch so gewollt. Der Fokus ist eine Reit- und Wanderkarte, keine alpine Karte. Für eine echte Bergsteigerkarte müßte noch einiges zusätzlich mit rein. Da die Anzahl an unterschiedlichen Linientypen auf dem Garmin begrenzt ist und zuviele verschiedene Ziele und Objekte die Karte nur unübersichtlich machen (man beobachte wie die große Mapnikkarte zur Zeit in landuse=farmland untergeht), ist eine bedingte Bergwandertauglichkeit nur ein angenehmer Nebeneffekt. Bergwege sieht man teilweise kaum und Pfade verwechselt man leich mit boundary. Letzteres interessiert in der Regel kaum. Wie das? Pfade sind rot gestrichelt, Grenzen sind als einziges Cyan? Was man haben möchte sind sichtbarere Renderingregeln für path sowie Darstellung von SAC-Scale auf path und footway (eventuell auch auf track). 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. :-) bye Nop -- 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
[Talk-de] Fehler Meldung Josm-Einstellung
Beim starten von josm-Einstellung kommt vorher folgende Fehlermeldung Kann mir einer erzählen wo die Datei ist. Jens ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fehler Meldung Josm-Einstellung
Link zum screenshot www.von-elling.net/screenshot_josm.jpg Jens Jens von Elling schrieb: Beim starten von josm-Einstellung kommt vorher folgende Fehlermeldung Kann mir einer erzählen wo die Datei ist. Jens ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen überwechen
On Mon, Aug 17, 2009 at 04:42:15PM +0200, Matthias Versen wrote: Das Relationen gekillt werden passiert Bundesweit nicht gerade selten, zumindest kann man es bei den Boundary (grenzen) und Multipolygonen beobachten weil diese sich automatisch testen lassen ob die in sich geschlossen sind. Bei dem Relation-Check von Garry86 tauchen deswegen immer wieder welche auf, die beschädigt wurden. 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 ... 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] Neue Firmware f?r GPSmap 60CSx sinnvoll?
Am 18.08.2009 um 11:31 schrieb Jürgen Frank: Es bestand da mal ein Problem bei einigen Garmin GPSmap Modellen, wenn man MicroSD-Karten eingesetzt hat, die vorher am Mac befuellt worden sind, da Mac OS X, wie wahrscheinlich andere UNIX-Derivate auch unsichtbare Dateien mit auf die Karte schreibt (.*). Bei Mac OS X werden .Trashes-Ordner erstellt (die Papierkörbe) und scheinbar gelöschte Dateien, scheinen dann im Garmin-Gerät auf einmal wieder auf, da das Gerät auch diese versteckten Ordner durchsucht. (Beobachtet auf einem nüvi 550 mit aktueller (Juli 2009) Firmeware) Ähnliche Effekte sind von WIndows berichtet worden (Recycle Bin). Grüße, Ingo -- Ingo Lantschner 1060 Vienna-Austria Mobil +43-664-143 84 18 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Trunk oder primary
qbert biker schrieb: Mit den ueblichen Problemen wie begrenzter Kapazitaet dieser Spuren oder kuerzeren Gruenphasen wegen Ampeln mit Linksabbiegerschaltungen, usw. Ums kurz zu machen. Wir brauchen uns hier nicht um diese Kleinigkeiten zu streiten. Verkehrstechniker haben zu diesen Themen ausgezeichnete Zahlen zur Kapazitaet mit und ohne kreuzungsfreiem Ausbau und keiner wuerde Bruecken und Rampen bauen, wenns nix bringen wuerde. Die Frage ist nur für wen bringt es etwas? Als lokaler Nutzer (z.B.Berufspendler) freue ich micht wenn durch den kreuzungsfreien Ausbau ein staubildendes Nadelöhr entschärft wird und ich mit 30 statt 10km/h Durchschnittsgeschwindigkeit den Weg zur Arbeitsstätte bewältige. Als Reisender ärgere ich mich aber wenn ich angesichts der gut ausgebauten Strasse einen Umweg über die Autobahn spare dafür aber statt mit den erwarteten 80km/h nur mit 30km/h im Schnitt vorankomme. 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: Original-Nachricht Datum: Tue, 18 Aug 2009 14:10:57 +0200 Von: Garry garr...@gmx.de An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Trunk oder primary Warum so unpragmatisch? Weil ich ganz pragmatisch kein Freund von privaten tags, bzw. der chaotischen Verbreiterung der Tagbasis bin... Die meisten Tags haben wohl so angefangen. Hier geht es ja um eine relativ klare Eigenschaft und nicht um ein komplexes Taggingschema mit tausenden von Auslegungsmöglichkeiten. Die Aussage von dem Tag ist dann Es ist nicht mit querendem Verkehr zu rechnen, Steckt schon etwas mehr dahinter, denn kreuzungsfreier Ausbau bedeutet ja nicht, dass es keinen kreuzenden Verkehr gibt, sondern dass der mit relativ hohem technischen Aufwand entkoppelt ist, also drunter oder drueber weg gefuehrt wird. Das ist zwar häufig so, ist aber doch schon wieder etwas mehr hineininterpretiert als das Tag tatsächlich aussagen kann. An der benachbarten A35 im Elsass gibt es z.B. einseitige Autobahnausfahrten um teuere Überführungsbauwerke zu sparen. Das ist teuer und wird eigentlich nur dann gemacht, wenn es gute Gruende dafuer gibt, also Verbesserung des Durchsatzes und/oder bessere Reisezeiten. Ja, eben oder - da kann kreuzungsfrei bedeuten dass hier mit sehr viel Verkehr - gegebenfalls mit viel Stau zu rechnen ist, aber auch man möchte den Verkehr aus den umliegenden Dörfern draussen haben und bietet deshalb eine schnelle Alternative... - Darum mein Aussage Es ist nicht mit querendem Verkehr zu rechnen deuted aber nicht zwangsläufig auf eine schnelle Strasse hin, ehr auf eine bessere Verkehrsentflechtung Schnell ist relativ und es ist eine Eigenschaft von mehreren. Kreuzungsfreien Ausbau gibt in Kombination mit eventuellem Tempolimit, KFZ-strasse, Ueberholverbot, etc. schon Aufschluss ueber die erreichbare Reisezeit. Die Reisezeit geht eben gewaltig in die Knie, wenn man wegen Ampeln oder Linksabbiegern immer wieder zum Stehen kommt. Man kann ja die Reisezeit als Integral der Das hängt vom Verkehr ab - in strukturschwachen Gegenden kann man da trotzdem auf beachliche Reisegeschwindigkeiten kommen während man auf kreuzungsfrei ausgebauten schwerverkehrsreichen Strecken deutlich langsamer ist. Geschwindigkeitsfunktion sehen und mit kontinuierlichen 80 kommt man i.A. frueher an, als wenn man zwischen den Ampeln auf 100kmh hochjagt. Die Spritsache kommt dann auch noch dazu. Das ist auch alles relativ - wenn ich auf 10km nur eine Ampel habe dann fällt die kaum ins Gewicht. Gelegentlich wird vor Ampeln auch auf zwei Fahrspuren aufgeweitet so dass sich hier eine Überholmöglichkeit an einzelnen langsameren Fahrzeugen vorbei bietet. Und mir ist auch klar, dass derartige Strecken meist dann gebaut werden, wenn vorher schon viel Verkehr war und LKW-Dichte und Staugefahr nicht ohne sind, aber Voraussetzung fuer Staumodellierung ist nun mal eine gute Beschreibung der Strecke, auf der sich der Stau aufbaut. So ganz nebenbei hat man mit den archivierten tracks ein probates Mittel, mit realen Reisezeiten Mythen und Legenden auszuraeumen. Die Daten sind da, man braucht sie nur auswerten ;) Nicht wirklich - ohne zu wissen wie die Daten entstanden sind kann man da ganz schön danben liegen 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. . 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: Diese 'Wichtigkeit' ist sehr relativ und auf das eigene Fahrempfinden bezogen. Das einzelne langsame Fz vorne wird ja keineswegs ausgebremst und der Fahrer freut sich vielleicht drueber, dass er mit 80 durchrollen kann, statt an jeder Ampel stehenbleiben zu muessen. Stau ist nur lästig wenn man ihn vor sich hat... ;-) Ich denke die meisten sehen es als wichtig an nicht durch einen einzelnen, langsameren Verkehrsteilnehmer vom eigenen bevorzugten Tempo ausgebremst zu werden - egal ob man das jetzt auf Autobahnen, Radwege oder Supermarktkassen bezieht. Daher sollte trunk in D dem autobahnähnlichen Ausbau vorbehalten bleiben. Da ist nichts dagegen zu sagen, aber deshalb sollte man trotzdem noch eine normale kreuzungsfreie Strasse von der Alternative, die mit Ampeln und behindernden Linksabbiegern gespickt ist, unterscheiden koennen duerfen. Kannst Du ja - setze ein crossingfree = yes wenn es noch nichts entsprechendes gibt. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Trunk oder primary
Martin Koppenhoefer schrieb: Am 17. August 2009 16:30 schrieb Garry garr...@gmx.de: Daher sollte trunk in D dem autobahnähnlichen Ausbau vorbehalten bleiben.Gegebenfalls könnte man eine wechselnde Überholspur (wenn es nicht nur eine einzelne Schleicherspur an Steilstrecken ist)noch mit dazunehmen Aber Kreuzungsfrei ohne Überholmöglichkeit bringt nichts... 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. Garry ___ 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 18:00:33 +0200 Von: Garry garr...@gmx.de An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Trunk oder primary Die Frage ist nur für wen bringt es etwas? Der perfekte Ansatz um jede Modellierung schon im Ansatz zu stören. In erster Linie sollte es doch darum gehen, was es jemand bringen kann, sondern darum wie man abbildet, was man vorfindet. Wenn eine Strecke regelmaessig ueberstaut ist, kann man dafuer entsprechende Werte eintragen. Das machen moderne Navis bzw. deren Datenlieferanten ja auch so. Aber ein Stau macht aus einer gut ausgebauten Strasse keinen Feldweg. Baulicher Zustand und Verkehrsaufkommen bleiben zwei unterschiedliche Dinge, auch wenn sie in Zusammenhang stehen. aber statt mit den erwarteten 80km/h nur mit 30km/h im Schnitt vorankomme. Was auf der Autobahn durchaus auch vorkommen kann ;) 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] Radfernweg Berlin-Kopenhagen Relation 28441
Moin moin, ich habe den deutschen Artikel zu Relationen um einen Abschnitt Gelöschte Relationen wieder herstellen ergänzt.[1] Gruß, Falk [1] http://wiki.openstreetmap.org/wiki/DE:Relations#Gel.C3.B6schte_Relationen_wieder_herstellen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummerntool?
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? Solange an dem Haus / den Haeusern keine Nummern dran sind wuerde ich auch keine eintragen. Dei Gebaeude (source=extrapolation) kann man aber ja schon mal eintragen (auch wenn vielleicht erst der Keller fertig ist). ;) ___ 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 18:00:40 +0200 Von: Garry garr...@gmx.de An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Trunk oder primary Hier geht es ja um eine relativ klare Eigenschaft und nicht um ein komplexes Taggingschema mit tausenden von Auslegungsmöglichkeiten. Was keinen Unterschied macht. Auch der Divider ist wirkungsvoll und einfach und versauert trotzdem. 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 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? aber auch man möchte den Verkehr aus den umliegenden Dörfern draussen haben und bietet deshalb eine schnelle Alternative... Eine Karte sollte hier neutral sein und den Istzustand aufnehmen. Dann und nur dann kann jemand ein Reisezeitmodell bauen, das die Parameter mit den persönlichen Vorlieben abgleicht und die beste Route findet. Wer im Beispiel nicht umgeleitet werden will, gibt kürzeste Strecke ein und er darf durchs Dorf schleichen. Jeder wie er mag. Das ist auch alles relativ - wenn ich auf 10km nur eine Ampel habe dann fällt die kaum ins Gewicht. 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 ;) 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. 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? Aus der Praxis weiss ich - a bisserl was geht immer... 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] Trunk oder primary
Original-Nachricht Datum: Tue, 18 Aug 2009 18:00:57 +0200 Von: Garry garr...@gmx.de An: m...@koppenhoefer.com, Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Trunk oder primary Zu sehr Sonderfall Wenn kreuzungsfrei, Kraftfahrstrasse mit LKW-Verbot dann trunk als dass diese Ausnahme wirklich einen Mehrwert bringt. Falsch - Es gibt keine Sonderfälle, sonder mehr oder weniger häufige Kombinationen. Trunk ist und bleibt eine schwammige Definition und ich sehe teil verärgert, teils belustigt zu wie mit Umdefinitionen von trunk auf primary und zurück und woanders hin, Information vernichtet wird. Jedenfalls wirds nicht langweilig, wenn man ab und zu reinschaut, welche Farbe die Strasse um die Ecke grade hat ;) -- 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] Yahoo-Luftbilder von Addis Abeba
Wenn die Geofabrik täglich Dumps bereitstellen könnte könnte ich nahezu täglich neue Checks für die Region erstellen. ... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] ZoneImport
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 L.S., Deutsch-Version kommt nach dem niederländischen Absatz. Vandaag heb ik een grote import gedaan in Nederland op basis van de OV zone tabel die ons door onze lieve Rijksoverheid beschikbaar is gesteld. Alle bushaltes die ik kon vinden en nog niet waren getagd met zone= zijn gevuld. Zo ook de internationale zones rond Aachen (dat is waarom talk-de ook is aangeschreven). Wat mist zijn de daadwerkelijke zone grenzen. Momenteel zou ik voor de tagging kiezen: zonegrens_0=nummer zonegrens_1=nummer Omdat je dan nog wel op de value kunt zoeken in de database. De normale tags zijn getagged met zone=nummer. - Thanks to google translate! Heute habe ich eine große Einfuhr in die Niederlande auf der Grundlage der OV-Zone Tabelle, die uns von unseren lieben Regierung zur Verfügung gestellt worden ist. Alle Haltestellen, die ich finden konnte und noch nicht getaggt mit zone = gefüllt. Auch die internationalen Bereichen rund um Aachen (das ist der Grund, warum die Rede ist). Was fehlt, sind die eigentlichen Grenzen Zone. Derzeit würde ich sich für die Kennzeichnung: zonegrens_0 = Anzahl zonegrens_1 = Anzahl Da Sie noch finden Sie den Wert in der Datenbank. Normal-Tags sind mit Zone = Anzahl. http://www.openstreetmap.org/browse/changeset/2190060 Grüße, Stefan de Konink -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAkqK6ZcACgkQYH1+F2Rqwn0+OQCfSJa+qF3jX8Z5p0WC6FQXpvOJ UpkAoIGySTr9HzBBePS61s9LPlepQUN3 =u6Hx -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Eine gute und eine schlechte Nachricht - Bereinigungsaktion 03 - Dupes
hi, die gute: waydupes ist nun viel schneller und kann viel mehr prüfen... die schlechte: daher gibt es nun wieder über 1000 dupes, die es zu beseitigen gilt. habe eine neue aktion aufgesetzt zur behebung dieser fehler: http://wiki.openstreetmap.org/wiki/DE:A … /Aktion_03 bitte helft alle mit! jetzt 50er pakete. ciao und danke gerhard gary68 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Neues ÖPNV-Schema - Linien(variante n)relationen
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. Claudius [1] http://wiki.openstreetmap.org/wiki/User:Oxomoa/ÖPNV-Schema ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Metadaten in OSM
Hi Warum nicht eine Liste mit den BoundingBoxen der Regionen machen, wo man seine Teilnahme eintragen kann. Die BBox kann man dann mit einem Josm-Link (siehe Josm-Remote-Plugin) schnell mal in Josm runter laden. Lg, Peter Werde versuchen die Qualitaetssicherung mehr relationsorientiert zu machen. Habe Addis Ababa jetzt zwar mit einem Riesen Raster versehen, aber ich werde das wohl längerfristig wieder wegräumen und dann die Qualitätssicherung Stadtteileweise oder orientiert an Straßenzügen in Relationen codieren. Das ganze hat den praktischen Vorteil, das man nicht ständig zwischen OSM Editor und Wiki hin und herspringen muss - inbesondere da Geocodierte (Meta) Informationen im Wiki ja nicht ganz einfach darstellbar sind. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] All in One Europa jetzt wöchentlich a ktuell
Am Samstag, 15. August 2009 16:21:31 schrieb Christoph Wagner: Hallo Liste, der neue Tilesplitter hat es echt in sich und schafft jetzt mal eben ganz Europa zu splitten ohne extrem viel Speicher zu fressen. Das wiederum gibt mir die Möglichkeit die Europakarte regelmäßig auf Svens Server berechnen zu lassen. (Update jeden Mittwoch) Des weiteren stelle ich jetzt regelmäßig auch die Teilkarten genau wie bei der Deutschlandversion auch für Europa zur Verfügung. Ich werde mal versuchen demnächst wieder etwas Zeit in die Verbesserung der Karte zu stecken. Momentan stressen eben gerade die Prüfungen etwas... Viel spaß mit der Karte. Grüße Christoph http://wiki.openstreetmap.org/wiki/DE:All_in_one_Garmin_Map Vielen Dank, werde ich demnächst mal ausprobieren. Da derartige Downloads neuerdings mein wlan-Router (frtz.box), der über eine eigene USB-Platte verfügt und immer läuft, erledigt, stört mich auch die Downloadgröße: etwa 1,2GiB nicht, da dies des nachts mittels wget und cron-job geschieht. So long Werner ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Batchverarbeitung von OSM Daten
Am Samstag, 15. August 2009 18:17:43 schrieb Martin Garbe: Hallo, wir haben in Rostock jetzt von der Stadt auch die Hoehendaten der Gebaeude zur Verfuegung gestellt bekommen. Ich versuche diese Daten einzupflegen, habe damit aber so meine Probleme. Ziel ist es: - OSM Daten des Bereichs Rostock runterladen - Script darueber laufen lassen, welches die Hoehendaten hinzufuegt - geaenderte Daten wieder hochladen Ich hatte jetzt mehrere Ideen 1. Mit JOSM Daten runterladen, in eine Datei speichern, per Script aendern und anschliessend mit JOSM wieder hochladen. Das ist aber ohne weiteres nicht moeglich, da man Rostock mit mehreren Schritten runterladen muesste, also per Hand die Karte in Kacheln aufteilen und dann runterladen. Ich vermute mal es wuerden ueber 20 Kacheln werden. Die Kacheln dann alle bearbeiten und wieder hochladen. Also per Hand ist das sehr aufwaendig. 2. Mit einem Skript runterladen, aendern und dann mit einem Skript geaendert hochladen. Ich habe zwei Bibliotheken gefunden, welche dafuer in Frage kommen. osmlib - (fuer ruby) kann leider keine Changesets handhaben Geo::OSM library - (fuer perl) ist nicht API 0.6 kompatibel Gibt es noch andere Bibliotheken oder hat jemand eine bessere Idee wie man eine grosse Anzahl Daten runterladen, veraendern und danach wieder hochladen kann? Gruss, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Dies ist nicht nur beim Bereitstellen von (Höhendaten-)Daten durch Behörden problematisch. Auch, wenn man mit einem Garmin GPSmap 60 CSx mappt, hat man massenhaft Höhendaten von einem barometrisch geeichten Höhenmesser (denke diese Quelle ist recht brauchbar), aber es kann doch keiner verlangen, dass man bei hunderten von Trackpunkten jede einzelne Höhe manuell eingibt. Dies sollte automatisiert werden. So long Werner ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen überwechen
Ich kenne mich mit Relationen noch nicht sonderlich gut aus, aber das gibt doch jedes mal eine aktualisierung der Version der Relation, oder? Also könnte sich eine entsprechende Überwachung doch darauf stützen.. Peter Florian Lohoff schrieb: On Mon, Aug 17, 2009 at 04:42:15PM +0200, Matthias Versen wrote: Das Relationen gekillt werden passiert Bundesweit nicht gerade selten, zumindest kann man es bei den Boundary (grenzen) und Multipolygonen beobachten weil diese sich automatisch testen lassen ob die in sich geschlossen sind. Bei dem Relation-Check von Garry86 tauchen deswegen immer wieder welche auf, die beschädigt wurden. 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 ... Flo ___ 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 Samstag, 15. August 2009 22:40:02 schrieb Tobias Wendorff: Am Sa, 15.08.2009, 18:24 schrieb Fips Schneider: kann man sowas irgendwie gebrauchen bzw. an die Daten offen rankommen, weil es von einem Bundesland gemacht wird? *verzweifel* Oder sind die Höhenzüge schon erfasst, wie in der Reit- und Wanderkarte bspw. zu sehen? (wo kommen die da denn her?) Sascha Silbe und ich arbeiten an einem genauen Höhenmesser auf barometrischer Basis. wie schon mehrfach in der Liste von mir angesprochen. Jedes Garmin GPSmap 60CSx hat einen barometrischen Höhenmesser und zeichnet für jeden Trackpunkt diese Daten mit auf. Für meine tracks kann ich diese Daten zur Verfügung stellen. Außerdem gibt es doch auch andere Leute, die dieses GPS-Gerät nutzen. Auch diese Mapper müssten derartige Daten haben. Nur wie bekommt man diese in die OSM-Datenbank (manuell wohl eher nicht). So long Werner ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Stelen am Waldrand
Hallo! Hier stehen am Waldrand oft Stelen, die farbig markiert sind und eine Nummer tragen [1]. Ich weiß nicht welche Funktion sie haben. Ich weiß im Moment leider auch nicht, ob überall unterschiedlich Zahlen draufstehen. Und warum gibt es manchmal gleich mehrere an einem Standort? Einerseits habe ich gehört, es solle etwas mit den Jagdrechten zu tun haben, andererseits sollen es Orientierungspunkte sein, um z.B. den Rettungsdienst seine Position mitzuteilen. Weiß jemand mehr? Tagt man so etwas in OSM? Und wenn ja wie? Christian [1] http://img9.imageshack.us/img9/736/img8399wiu.jpg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vermessung der Höhen von Hessen
Werner König schrieb: wie schon mehrfach in der Liste von mir angesprochen. Jedes Garmin GPSmap 60CSx hat einen barometrischen Höhenmesser und zeichnet für jeden Trackpunkt diese Daten mit auf. Für meine tracks kann ich diese Daten zur Verfügung stellen. Außerdem gibt es doch auch andere Leute, die dieses GPS-Gerät nutzen. Das haben wir schon mindestens 200x durchgekaut. Das Problem ist, dass diese Geräte die barometrische Höhe anhand der vom GPS ermittelten Höhe kalibriert. Wenn man es genau haben will, muss man erst irgendwo einen Höhenpunkt mit Zahl dran finden und das Gerät manuell eichen. Wenn das Wetter dann umschlägt, ist die Kalibrierung wieder für'n Arsch. Sascha und ich haben uns daher eine Differential-Messung überlegt: Eine Basisstation und ein Mobilgerät, beide loggen auf SD-Karten. Die Basisstation steht z.B. zuhause bei bekannter Höhe. Wenn man nun in der Stadt rummappt und der Luftdruck sich ändert, kann man anhand der Basisstation den Korrekturwert berechnen, mit dem die mobil erhobenen Höhen korrigiert werden. Der Luftdruck ist i.d.R. auf mehrere Kilometer stabil. Auch diese Mapper müssten derartige Daten haben. Nur wie bekommt man diese in die OSM-Datenbank (manuell wohl eher nicht). Das Garmin exportiert doch auch Höhendaten?! Grüße Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ZoneImport
I'm sorry from the german part I did not understand what you're trying to do or what you're doing. Is any one able to translate the dutch text to english or directly to proper german? Entschuldige bitte, ich konnte aus dem deutschen Teil nicht erkennen, was du zu tun planst oder bereits umsetzt. Kann jemand den Niederländischen Text nach Englisch oder direkt in gutes Deutsch übersetzen? Peter Stefan de Konink schrieb: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 L.S., Deutsch-Version kommt nach dem niederländischen Absatz. Vandaag heb ik een grote import gedaan in Nederland op basis van de OV zone tabel die ons door onze lieve Rijksoverheid beschikbaar is gesteld. Alle bushaltes die ik kon vinden en nog niet waren getagd met zone= zijn gevuld. Zo ook de internationale zones rond Aachen (dat is waarom talk-de ook is aangeschreven). Wat mist zijn de daadwerkelijke zone grenzen. Momenteel zou ik voor de tagging kiezen: zonegrens_0=nummer zonegrens_1=nummer Omdat je dan nog wel op de value kunt zoeken in de database. De normale tags zijn getagged met zone=nummer. - Thanks to google translate! Heute habe ich eine große Einfuhr in die Niederlande auf der Grundlage der OV-Zone Tabelle, die uns von unseren lieben Regierung zur Verfügung gestellt worden ist. Alle Haltestellen, die ich finden konnte und noch nicht getaggt mit zone = gefüllt. Auch die internationalen Bereichen rund um Aachen (das ist der Grund, warum die Rede ist). Was fehlt, sind die eigentlichen Grenzen Zone. Derzeit würde ich sich für die Kennzeichnung: zonegrens_0 = Anzahl zonegrens_1 = Anzahl Da Sie noch finden Sie den Wert in der Datenbank. Normal-Tags sind mit Zone = Anzahl. http://www.openstreetmap.org/browse/changeset/2190060 Grüße, Stefan de Konink -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAkqK6ZcACgkQYH1+F2Rqwn0+OQCfSJa+qF3jX8Z5p0WC6FQXpvOJ UpkAoIGySTr9HzBBePS61s9LPlepQUN3 =u6Hx -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Knicks (Wallhecken) einzeichnen
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? Christian [1] http://schleswig-holstein.nabu.de/naturvorort/knicks/ [2] http://de.wikipedia.org/wiki/Knick ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ZoneImport
Peter Körner schrieb: I'm sorry from the german part I did not understand what you're trying to do or what you're doing. Is any one able to translate the dutch text to english or directly to proper german? Entschuldige bitte, ich konnte aus dem deutschen Teil nicht erkennen, was du zu tun planst oder bereits umsetzt. Kann jemand den Niederländischen Text nach Englisch oder direkt in gutes Deutsch übersetzen? Er hat eindeutig Google Translate benutzt :-)) So wie ich es verstanden habe, hat die niederländische Regierung die Tarifzonen des ÖPNVs bereitgestellt. Diese möchte er nun importieren und mit den vorhandenen Haltestellen verbinden. Was allerdings fehlt, sind die Grenzbereiche (EUREGIO etc.). @Thomas: *freu* Peter Stefan de Konink schrieb: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 L.S., Deutsch-Version kommt nach dem niederländischen Absatz. Vandaag heb ik een grote import gedaan in Nederland op basis van de OV zone tabel die ons door onze lieve Rijksoverheid beschikbaar is gesteld. Alle bushaltes die ik kon vinden en nog niet waren getagd met zone= zijn gevuld. Zo ook de internationale zones rond Aachen (dat is waarom talk-de ook is aangeschreven). Wat mist zijn de daadwerkelijke zone grenzen. Momenteel zou ik voor de tagging kiezen: zonegrens_0=nummer zonegrens_1=nummer Omdat je dan nog wel op de value kunt zoeken in de database. De normale tags zijn getagged met zone=nummer. - Thanks to google translate! Heute habe ich eine große Einfuhr in die Niederlande auf der Grundlage der OV-Zone Tabelle, die uns von unseren lieben Regierung zur Verfügung gestellt worden ist. Alle Haltestellen, die ich finden konnte und noch nicht getaggt mit zone = gefüllt. Auch die internationalen Bereichen rund um Aachen (das ist der Grund, warum die Rede ist). Was fehlt, sind die eigentlichen Grenzen Zone. Derzeit würde ich sich für die Kennzeichnung: zonegrens_0 = Anzahl zonegrens_1 = Anzahl Da Sie noch finden Sie den Wert in der Datenbank. Normal-Tags sind mit Zone = Anzahl. http://www.openstreetmap.org/browse/changeset/2190060 Grüße, Stefan de Konink -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAkqK6ZcACgkQYH1+F2Rqwn0+OQCfSJa+qF3jX8Z5p0WC6FQXpvOJ UpkAoIGySTr9HzBBePS61s9LPlepQUN3 =u6Hx -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vermessung der Höhen von Hessen
Wenn das Wetter dann umschlägt, ist die Kalibrierung wieder für'n Arsch. Mein WSG 1000 misst dise Höhen auch mit. Die sind aber wirklich meistenteils für Tonne. Vorgestern hatte ich bei der Tour einen raschen Wetterumschwung von heiß auf kühl und Gewitter. Durch diese Luftdruckveränderung kamen annähernd plötzlich 100 Meter Unterschied zustande. Sowas könnte man vielleicht unter Umständen noch rausrechen. Mein GPS loggt ebenfalls den den Luftdruck, Temperatur usw. mit. Vielleicht könnte man so anhand der paralel aufgezeichneten Änderungen irgendwelche Korrekturberechnungen machen, die Lufdruckschankungen glätten. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Knicks (Wallhecken) einzeichnen
2009/8/18 Christian H. Bruhn 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. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Knicks (Wallhecken) einzeichnen
Christian H. Bruhn schrieb: 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? Nunja, es sind Wälle und dienen der Befriedung - also barrier. barrier = hedge ist vielleicht zu unbedeutend, oder? barrier = hedge_bank steht auch bei dict.leo.org. [2] http://de.wikipedia.org/wiki/Knick Auf den Stock gesetzter Knick, nur noch Wall und Überhälter OMG :-)) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ZoneImport
Ich danke dir. Peter So wie ich es verstanden habe, hat die niederländische Regierung die Tarifzonen des ÖPNVs bereitgestellt. Diese möchte er nun importieren und mit den vorhandenen Haltestellen verbinden. Was allerdings fehlt, sind die Grenzbereiche (EUREGIO etc.). @Thomas: *freu* ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wofuer alles Loecher in landuse
Hallo! Die Flächennutzung ist hier sehr eingeschränkt erfaßt. Grundsätzlich bin ich auch der Meinung, daß am besten, jede Fläche entsprechend getagr wird. Hier in Deutschland wären freie Flächen sicherlich landwirtschaftlich genutzte Flächen, in anderen Ländern (z.B. Schweden) Wald und in anderen z.B. Wüste. Meist fange ich bei Orten an rund um die Wohnbebauung ein landuse=residential. 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? Das layer-Tag finde ich in solchen Fällen unschön. Christian P.S. Antworten bitte nur an die Liste, ich lese diese auch. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vermessung der Höhen von Hessen
Hallo Mirko, Mirko Küster schrieb: Vorgestern hatte ich bei der Tour einen raschen Wetterumschwung von heiß auf kühl und Gewitter. Durch diese Luftdruckveränderung kamen annähernd plötzlich 100 Meter Unterschied zustande. In welcher Ecke wohnst Du nochmal? Vielleicht können wir irgendwo eine Referenzstation für Dich finden. Sowas könnte man vielleicht unter Umständen noch rausrechen. Mein GPS loggt ebenfalls den den Luftdruck, Temperatur usw. mit. Vielleicht könnte man so anhand der paralel aufgezeichneten Änderungen irgendwelche Korrekturberechnungen machen, die Lufdruckschankungen glätten. Yepp. Da ich für die Klimastation an der Uni zuständig bin, habe ich mich damals in das ganze Material eingearbeitet. Für solche Zwecke gibt es auch extra Formeln, wir sind ja nicht die ersten, die diese Idee haben (Patente??). Wäre cool, wenn Du selbst ein zweites Gerät hast, dann könnte ich die Formeln mal in ein Script packen - aber erst, wenn ich meine dummen Seminararbeiten abgegeben habe :-)) Grüße Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Batchverarbeitung von OSM Daten
Ooops, falscher Thread, hm? Peter Dies ist nicht nur beim Bereitstellen von (Höhendaten-)Daten durch Behörden problematisch. Auch, wenn man mit einem Garmin GPSmap 60 CSx mappt, hat man massenhaft Höhendaten von einem barometrisch geeichten Höhenmesser (denke diese Quelle ist recht brauchbar), aber es kann doch keiner verlangen, dass man bei hunderten von Trackpunkten jede einzelne Höhe manuell eingibt. Dies sollte automatisiert werden. So long ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Knicks (Wallhecken) einzeichnen
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? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wofuer alles Loecher in landuse
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. 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. Wenn man Landuse denn schon manuell macht, dann sollte man auch irgendwelche Qualitätschecks einführen, die das aktuell halten. P.S. Antworten bitte nur an die Liste, ich lese diese auch. Du musst Dich aus dem Reply-To entfernen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Knicks (Wallhecken) einzeichnen
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. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ZoneImport
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Peter Körner schreef: So wie ich es verstanden habe, hat die niederländische Regierung die Tarifzonen des ÖPNVs bereitgestellt. Diese möchte er nun importieren und mit den vorhandenen Haltestellen verbinden. Was allerdings fehlt, sind die Grenzbereiche (EUREGIO etc.). @Thomas: *freu* Nein, in einigen grenznahen Gebieten überschneiden sich die niederländischen öffentlichen Verkehrsmitteln mit der deutschen. Sie können visuell überwachen http://tile.openstreetmap.nl/ dann blättern Sie zu Aachen und damit OV Zones (Test). Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAkqLFK0ACgkQYH1+F2Rqwn1OhgCfds3PMddxudbuDauU4a3S2/ZT 3agAnRWyHAyLGkPCDcieKAtV0guPigpp =93pb -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vermessung der Höhen von Hessen
In welcher Ecke wohnst Du nochmal? Vielleicht können wir irgendwo eine Referenzstation für Dich finden. http://www.openstreetmap.org/?lat=51.2996lon=11.4387zoom=13layers=B000FTF Nicht hoch, aber ich vermesse seit 4 Wochen den ganzen Ziegelrodaer Forst und da hats einige Buckel im Gelände. Morgen machen ich den 1000 Kilometer voll. Der Druckabfall kam zwischen Flugplatz und Landgrafroda. Nächste Wetterstatitionen dürften Artern und glaube Langenroda sein. Ich kenne aber auch sämtliche Geodätische Festpunkte, davon hats hier einige im Wald. Einer befindet sich direkt am Waldeingang, da wo die L1217 in den Wald eintaucht, am Pakplatz vor dem Mühltal. Man müsste nur mal rausfinden welche Daten der Klotz nun hat. Yepp. Da ich für die Klimastation an der Uni zuständig bin, habe ich mich damals in das ganze Material eingearbeitet. Für solche Zwecke gibt es auch extra Formeln, wir sind ja nicht die ersten, die diese Idee haben (Patente??). Interessiert mich ehrlich gesagt null ob da einer irgendein Patent auf eine pille palle Zahlenreihe hat. Ich möchte meine Daten nutzen, nicht irgendwen mit einer Erfindung abziehen. Wäre cool, wenn Du selbst ein zweites Gerät hast, dann könnte ich die Formeln mal in ein Script packen - aber erst, wenn ich meine dummen Seminararbeiten abgegeben habe :-)) Von dem Gerät nur eines. Das andere ist ist eine Maus und wird für genaue Ermittlung am Notebook genutzt, Nummer drei ist im Handy für Spontanaufzeichnungen, für mehr taugen die Handy GPS leider noch nicht. Das WSG 1000 dient eigentlich nur dazu um am Bike vor sich hin zu loggen, um dann später den Geotag an die Bilder zu bekommen. Wäre natürlich nich vekehrt, wenn der Rest der ohnhin aufgezichneten Daten nicht sinnlos im Eimer landen würde. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Was tun bei massiver Abweichung zwischen OSM und GPX-Daten?
Am Sonntag, 16. August 2009 20:47:15 schrieb Chris-Hein Lunkhusen: Bernd Hohmann schrieb: Daher würde mich ein ad-hoc Verfahren für die Mittelung eines Referenzpunktes schon stark interessieren. Also bei meinem Etrex brauch ich beim Setzen eines WP nur auf Mitteln zu klicken und dann möglichst lange stehen bleiben oder im Kreis um den Referenzpunkt herum laufen, oder Gerät liegen lassen und Tasse Kaffee trinken. ;-) Chris geht mit dem GPSmap 60CSx genauso. So long Werner ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vermessung der Höhen von Hessen
Mirko Küster schrieb: Interessiert mich ehrlich gesagt null ob da einer irgendein Patent auf eine pille palle Zahlenreihe hat. Ich möchte meine Daten nutzen, nicht irgendwen mit einer Erfindung abziehen. Ich verstehe auch nicht, wieso ich einen Führerschein zum Autofahren brauche. Okay, ich verstehe aber auch nicht, wofür manche einen Führerschein brauchen, wenn der ÖPNV gut ist :-) Wäre cool, wenn Du selbst ein zweites Gerät hast, dann könnte ich die Formeln mal in ein Script packen - aber erst, wenn ich meine dummen Seminararbeiten abgegeben habe :-)) Von dem Gerät nur eines. Das andere ist ist eine Maus und wird für genaue Ermittlung am Notebook genutzt, Nummer drei ist im Handy für Spontanaufzeichnungen, für mehr taugen die Handy GPS leider noch nicht. Das WSG 1000 dient eigentlich nur dazu um am Bike vor sich hin zu loggen, um dann später den Geotag an die Bilder zu bekommen. Wäre natürlich nich vekehrt, wenn der Rest der ohnhin aufgezichneten Daten nicht sinnlos im Eimer landen würde. Also hast Du nur eines mit Barometrik? Schade :-( ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ZoneImport
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Peter Körner schreef: I'm sorry from the german part I did not understand what you're trying to do or what you're doing. Is any one able to translate the dutch text to english or directly to proper german? Ok lets try again; There is a zone system in The Netherlands in use that splits up the country in regions. These regions are used to pay for public transport, each region you travel through adds +1 to what you pay on a ticket that has for example 15 zones. So if you travel in one, you pay 2 strips, and if you travel through 2, you pay 3 strips. So mathematically (zones traveled through + 1) = total amount of things that is removed from your card. In Limburg there seems to be a way to travel to Germany using these cards. I don't know what operator this is, but looking at the map there are two zones overlaping Aachen. My annoucement was to inform the German community about this 'additions'. If required please rename it to zone:nl or something like it. Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAkqLFowACgkQYH1+F2Rqwn0FRACfZR6lDs0N/opeuvt1jWgBwfy1 TgIAoIB/q1jxZWOuAC+PtwfccZNnRkgJ =dXPw -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wofuer alles Loecher in landuse
2009/8/18 Christian H. Bruhn br...@arcor.de Hallo! Die Flächennutzung ist hier sehr eingeschränkt erfaßt. Grundsätzlich bin ich auch der Meinung, daß am besten, jede Fläche entsprechend getagr wird. Hier in Deutschland wären freie Flächen sicherlich landwirtschaftlich genutzte Flächen, in anderen Ländern (z.B. Schweden) Wald und in anderen z.B. Wüste. Meist fange ich bei Orten an rund um die Wohnbebauung ein landuse=residential. 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. Also zu einem Wohngebiet gehören auch Parkplätze und Spielplätze oder auch Schulgelände, die müssen dann nicht ausgeschnitten werden. 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! Da hat es sich wohl jemand einfach gemacht, denn die Landnutzung ordentlich erfasst braucht Zeit. Das können dann schonmal 30 - 60 Minuten pro Quadratkilometer sein. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Knicks (Wallhecken) einzeichnen
Robert S. schrieb: 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. Aber zumindest in Europa hatten Hecken und Wälle doch schon immer eine Befestigungs- oder Grenzbedeutung (Hadrianswall etc.). Das Wiki soll ja nur Hinweise geben - vermutlich müssen wir es nun erweitern :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Bezirke Bayerns auf download.geofabrik.de
Hallo, Bayern ist bei OSM nicht nur das datenreichste deutsche Bundesland; mit einer XML-Groesse von rund 1.5 GB unkomprimiert gibt es fuer Bayern auch mehr Daten als fuer die meisten Laender Europas. Damit sich nicht jeder mit dem kompletten Bayern-File herumplagen muss, wenn er sich nur fuer einen Teilbereich interessiert, gibt es ab heute auf http://download.geofabrik.de/osm/europe/germany/bayern/ auch taeglich aktualisierte Extrakte der sieben Bezirke Bayerns. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Postal_code oder addr:postcode
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 ??? Was mein Ihr ?? Öhm, wieso nicht beides? 1. addr:postcode und postal_code gesetzt und identisch? eines 2. addr:postcode und postal_code gesetzt und nicht identisch? checken 3. addr:postcode gesetzt und postal_code nicht gesetzt = addr:postcode 4. addr:postcode nicht gesetzt und postal_code gesetzt = postal_code ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wahl zum OSMF-Vorstand
Hallo, bis Donnerstag nacht koennen Mitglieder der OSMF noch ihre 7 Stimmen per E-Mail auf die 11 Kandidatinnen und Kandidaten zum OSMF-Vorstand verteilen. Wer bis dahin nicht abgestimmt hat, kann am Samstag persoenlich bei der Mitgliederversammlung erscheinen oder jemanden, der dort hinfaehrt, zur Abstimmung ermaechtigen. Ich vermute zwar, dass alle Mitglieder auf der OSMF-Talk-Mailingliste sind und die Nachricht dort bekommen haben, hier bloss noch mal zur Erinnerung. Genaue Anleitung mit Link zu Selbstvorstellung der Kandidaten hier: http://wiki.openstreetmap.org/wiki/Foundation/AGM09/Election_to_Board Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Postal_code oder addr:postcode
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. Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: Weg aufteilen bzw. Attribute neu vergeben
Entweder ich verstehe Dein Problem nicht, oder Du siehst den Wald vor lauter Bäumen nicht ;-) Ich trenne Wege in JOSM folgendermaßen: - Node auswählen an dem Weg getrennt werden soll - Taste [P] oder übers Menü: Werkzeuge-Weg aufspalten Viele Grüße Sebastian Hallo, mache das mit dem Auftrennen auch so, hatte aber auch schon Probleme in Josm, das dies nicht richtig funktioniert (manchmal). So long Werner ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Postal_code oder addr:postcode
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
Re: [Talk-de] Metadaten in OSM
das ist z.B. nicht Potlatch Kompatibel - da kann man nicht so recht erkennen wo denn jetzt die Box aufhört. Und Bounding boxen ins Wiki dauert länger bzw. ist viel Tipparbeit - im Gegensatz zum Zusammenstellen von Relationen für die Grenzen. Diese kann man dann auch schön über openstreetmap.org/browse/relation verlinken. Gruß, Alexander Peter Körner wrote: Warum nicht eine Liste mit den BoundingBoxen der Regionen machen, wo man seine Teilnahme eintragen kann. Die BBox kann man dann mit einem Josm-Link (siehe Josm-Remote-Plugin) schnell mal in Josm runter laden. Werde versuchen die Qualitaetssicherung mehr relationsorientiert zu machen. Habe Addis Ababa jetzt zwar mit einem Riesen Raster versehen, aber ich werde das wohl längerfristig wieder wegräumen und dann die Qualitätssicherung Stadtteileweise oder orientiert an Straßenzügen in Relationen codieren. Das ganze hat den praktischen Vorteil, das man nicht ständig zwischen OSM Editor und Wiki hin und herspringen muss - inbesondere da Geocodierte (Meta) Informationen im Wiki ja nicht ganz einfach darstellbar sind. ___ 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 Dienstag, 18. August 2009 22:21:30 schrieb Tobias Wendorff: Werner König schrieb: wie schon mehrfach in der Liste von mir angesprochen. Jedes Garmin GPSmap 60CSx hat einen barometrischen Höhenmesser und zeichnet für jeden Trackpunkt diese Daten mit auf. Für meine tracks kann ich diese Daten zur Verfügung stellen. Außerdem gibt es doch auch andere Leute, die dieses GPS-Gerät nutzen. Das haben wir schon mindestens 200x durchgekaut. Das Problem ist, dass diese Geräte die barometrische Höhe anhand der vom GPS ermittelten Höhe kalibriert. Wenn man es genau haben will, muss man erst irgendwo einen Höhenpunkt mit Zahl dran finden und das Gerät manuell eichen. Ich habe bisher auf Wanderungen etc. festgestellt, dass diese Daten fast immer mit den Daten auf Wegweisern übereinstimmen. Auch diese Mapper müssten derartige Daten haben. Nur wie bekommt man diese in die OSM-Datenbank (manuell wohl eher nicht). Das Garmin exportiert doch auch Höhendaten?! klar werden diese Daten exportiert z.B. in gpx-Dateien, die man in Josm einlesen kann. Und dann, dann vervollständige ich die OSM-Daten, in dem ich manuell den Track nachzeichne. Dabei gehen die Höhendaten verloren. Was fehlt ist ein Tool (wie bei den Bildern mit Zeitstempel, das den eingetragenen Punkten, die Höhe aus dem GPS-Track automatisch zuordnet). So long Werner Grüße Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Trunk oder primary
qbert biker schrieb: Die Frage ist nur für wen bringt es etwas? Der perfekte Ansatz um jede Modellierung schon im Ansatz zu stören. In erster Linie sollte es doch darum gehen, was es jemand bringen kann, sondern darum wie man abbildet, was man vorfindet. 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... Wenn eine Strecke regelmaessig ueberstaut ist, kann man dafuer entsprechende Werte eintragen. Das machen moderne Navis bzw. deren Datenlieferanten ja auch so. Aber ein Stau macht aus einer gut ausgebauten Strasse keinen Feldweg. Baulicher Zustand und Verkehrsaufkommen bleiben zwei unterschiedliche Dinge, auch wenn sie in Zusammenhang stehen. 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. aber statt mit den erwarteten 80km/h nur mit 30km/h im Schnitt vorankomme. Was auf der Autobahn durchaus auch vorkommen kann ;) 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. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Yahoo-Luftbilder von Addis Abeba
FlaBot wrote: Wenn die Geofabrik täglich Dumps bereitstellen könnte könnte ich nahezu täglich neue Checks für die Region erstellen. ... Welche Art von Checks denn? es gibt ein africa.osm. Plane OSM extracts für ET und ggf. andere Afrikanische Länder bereitzustellen, aber leider fehlt mir momentan die Hardware :) -- Grüße, Alexander ___ 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 Dienstag, 18. August 2009 22:41:38 schrieb Tobias Wendorff: Hallo Mirko, Mirko Küster schrieb: Vorgestern hatte ich bei der Tour einen raschen Wetterumschwung von heiß auf kühl und Gewitter. Durch diese Luftdruckveränderung kamen annähernd plötzlich 100 Meter Unterschied zustande. In welcher Ecke wohnst Du nochmal? Vielleicht können wir irgendwo eine Referenzstation für Dich finden. Sowas könnte man vielleicht unter Umständen noch rausrechen. Mein GPS loggt ebenfalls den den Luftdruck, Temperatur usw. mit. Vielleicht könnte man so anhand der paralel aufgezeichneten Änderungen irgendwelche Korrekturberechnungen machen, die Lufdruckschankungen glätten. Yepp. Da ich für die Klimastation an der Uni zuständig bin, habe ich mich damals in das ganze Material eingearbeitet. Für solche Zwecke gibt es auch extra Formeln, wir sind ja nicht die ersten, die diese Idee haben (Patente??). Wäre cool, wenn Du selbst ein zweites Gerät hast, dann könnte ich die Formeln mal in ein Script packen - aber erst, wenn ich meine dummen Seminararbeiten abgegeben habe :-)) Also ich mache das mit den Schwankungen so: bei uns sind sehr viele Wegweiser mit Höhendaten versehen (Schwarzwald). Wenn ich dann an einem Wegweiser vorbeikomme, kontrolliere ich die Höhe und gegebenenfalls wird der baromtrische Höhenmesser neu kalibriert. Auch bei Alpenwanderungen funktioniert das wunderbar. So long Werner ___ 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 Di, 18.08.2009, 23:50 schrieb Werner König: Am Dienstag, 18. August 2009 22:41:38 schrieb Tobias Wendorff: Hallo Mirko, Mirko Küster schrieb: Also ich mache das mit den Schwankungen so: bei uns sind sehr viele Wegweiser mit Höhendaten versehen (Schwarzwald). Wenn ich dann an einem Wegweiser vorbeikomme, kontrolliere ich die Höhe und gegebenenfalls wird der baromtrische Höhenmesser neu kalibriert. Auch bei Alpenwanderungen funktioniert das wunderbar. Versuch das mal 150 km weiter nördlich :-) ___ 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 Di, 18.08.2009, 23:41 schrieb Werner König: klar werden diese Daten exportiert z.B. in gpx-Dateien, die man in Josm einlesen kann. Und dann, dann vervollständige ich die OSM-Daten, in dem ich manuell den Track nachzeichne. Dabei gehen die Höhendaten verloren. Was fehlt ist ein Tool (wie bei den Bildern mit Zeitstempel, das den eingetragenen Punkten, die Höhe aus dem GPS-Track automatisch zuordnet). Mit OSM-Babel aus den Tracks Waypoints machen und dann auf die JOSM-Datenebene kopieren. Kann Dir ggf. ein Script dafür schreiben, was direkt OSM rauswirft. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wofuer alles Loecher in landuse
Tobias Wendorff schrieb: 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. 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. Die OSM-Landschaft entsteht aber häufig dadurch dass man in nicht erfassten Gebieten erstmal eine residential - Fläche anlegt damit man erst mal sieht dass es dort einen Ort gibt, dann kommen die Strassen und sehr viel später die Häuser Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vermessung der Höhen von Hessen
Also ich mache das mit den Schwankungen so: bei uns sind sehr viele Wegweiser mit Höhendaten versehen (Schwarzwald). Wenn ich dann an einem Wegweiser vorbeikomme, kontrolliere ich die Höhe und gegebenenfalls wird der baromtrische Höhenmesser neu kalibriert. Auch bei Alpenwanderungen funktioniert das wunderbar. Das nützt dir nur nichts, wenn wie hier nirgends eine Höhe angegeben ist und die einzigen Quellen die Festpunkte des Landesvermessungsamtes sind, deren Daten du kaufen könntest aber wieder klären musst, ob du die Daten auf dieser Grundlage veröffentlichen darfst. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vermessung der Höhen von Hessen
Soweit ich weiß werden die Höhenangaben über die hochgeladenen gpx-Tracks mit erfasst (s. z.B. http://www.openstreetmap.org/trace/462593/data . da stehen ele-Tags mit der Höhenangabe drin.) Damit sind diese Daten durchaus in OSM verfügbar, nur nicht in der Haupt-Datenbank. Diese Daten sollten nur an Orten an denen dies sinnvoll ist in die Haupt-Datenbank übernommen werden (Berge usw.), nicht aber automatisch auf jeder Node. Peter Tobias Wendorff schrieb: Am Di, 18.08.2009, 23:41 schrieb Werner König: klar werden diese Daten exportiert z.B. in gpx-Dateien, die man in Josm einlesen kann. Und dann, dann vervollständige ich die OSM-Daten, in dem ich manuell den Track nachzeichne. Dabei gehen die Höhendaten verloren. Was fehlt ist ein Tool (wie bei den Bildern mit Zeitstempel, das den eingetragenen Punkten, die Höhe aus dem GPS-Track automatisch zuordnet). Mit OSM-Babel aus den Tracks Waypoints machen und dann auf die JOSM-Datenebene kopieren. Kann Dir ggf. ein Script dafür schreiben, was direkt OSM rauswirft. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wofuer alles Loecher in landuse
Am Mi, 19.08.2009, 00:06 schrieb Garry: Die OSM-Landschaft entsteht aber häufig dadurch dass man in nicht erfassten Gebieten erstmal eine residential - Fläche anlegt damit man erst mal sieht dass es dort einen Ort gibt, dann kommen die Strassen und sehr viel später die Häuser Ich kann aber vor ganzer unverbundener Landuse-Flächen meime Ways und Areas nicht mehr erkennen. Commercial in der eh schon vollen Innenstadt toppt das Ganze dann noch. ___ 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 Mi, 19.08.2009, 00:08 schrieb Mirko Küster: Das nützt dir nur nichts, wenn wie hier nirgends eine Höhe angegeben ist und die einzigen Quellen die Festpunkte des Landesvermessungsamtes sind, deren Daten du kaufen könntest aber wieder klären musst, ob du die Daten auf dieser Grundlage veröffentlichen darfst. Viele LVAs gestatten mittlerweile ein Freikaufen der Daten. Allerdings für OSM-User unbezahlbar :-) ___ 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 Mittwoch, 19. August 2009 00:12:06 schrieb Peter Körner: Soweit ich weiß werden die Höhenangaben über die hochgeladenen gpx-Tracks mit erfasst (s. z.B. http://www.openstreetmap.org/trace/462593/data . da stehen ele-Tags mit der Höhenangabe drin.) Damit sind diese Daten durchaus in OSM verfügbar, nur nicht in der Haupt-Datenbank. Diese Daten sollten nur an Orten an denen dies sinnvoll ist in die Haupt-Datenbank übernommen werden (Berge usw.), nicht aber automatisch auf jeder Node. Peter falsch, in den Gebieten, wo die baromtrische Höhenerfassung durch entsprechende Kalibrirungsmaßnahmen genau erfassbar ist, können hier die srtm-Daten sinnvoll ersetzt werden. Das heißt man kann genauere Höhenlinien erstellen, das ist jedoch mit einer punktuellen Erfassung nicht möglich. So long Werner ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vermessung der Höhen von Hessen
Viele LVAs gestatten mittlerweile ein Freikaufen der Daten. Allerdings für OSM-User unbezahlbar :-) Die Dinger liegen alle drüben in Sachsen-Anhalt. Die Lage habe ich, 8 sind auch schon in OSM drin, die wichtigen Daten fehlen.. Einer war war noch aus Holz und vom VEB für Kartographie und Gedäsoie Erfurt lol Wundert mich das der noch unberührt steht und nicht schon längst in irgendeinem westdeutschen Keller verschwunden ist. Der normale Preis reicht mir schon http://www.lvermgeo.sachsen-anhalt.de/de/leistungen/grundlagenvermessung/hoehenfestpunkte/hoehenfestpunkte.htm Man bräuchte halt jemanden der da mal ohne dein Wissen reinschaut und du ganz zufällig denjenigen fragst. ;-) Gruß Mirko ___ 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 Mi, 19.08.2009, 00:49 schrieb Mirko Küster: lol Wundert mich das der noch unberührt steht und nicht schon längst in irgendeinem westdeutschen Keller verschwunden ist. Die drohende Geldstrafe ist erheblich. Der normale Preis reicht mir schon Für barometrische Messung ja, direkt für OSM nein. Man bräuchte halt jemanden der da mal ohne dein Wissen reinschaut und du ganz zufällig denjenigen fragst. ;-) Ich habe das Wissen für NRW. Aber leider steht zu wissenschaftlichen Zwecken drüber. Schon genial, wie genau die messen... und auch schön zu sehen, WIE die messen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eine gute und eine schlechte Nachricht - Bereinigungsaktion 03 - Dupes
bei mir ist jedenfalls http://wiki.openstreetmap.org/wiki/DE:Aktionen/Aktion_03 unvollständig als Link angekommen ! gruß Jan :-) Gary68 schrieb: hi, die gute: waydupes ist nun viel schneller und kann viel mehr prüfen... die schlechte: daher gibt es nun wieder über 1000 dupes, die es zu beseitigen gilt. habe eine neue aktion aufgesetzt zur behebung dieser fehler: http://wiki.openstreetmap.org/wiki/DE:A … /Aktion_03 bitte helft alle mit! jetzt 50er pakete. ciao und danke gerhard gary68 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
