Re: [Talk-de] routing auf dem garmin
Hallo. Am Samstag, 7. März 2009 schrieb Chris-Hein Lunkhusen: Hmmm, bei meiner D-Karte (erstellt mit splitter.jar und mkgmap) konnte ich gerade problemlos nach Bad Tölz (700 km) routen (Auto, schnellste Route). Ah. (*Kopf - Tisch*) Ja, klar, wenn man auf Kürzeste Strecke gestellt hat, muss er natürlich wesentlich mehr rechnen. Okay, mit Kürzeste Zeit (sic!) weiß auch mein Legend wie man von Murrhardt nach Flensburg kommt (knapp 800 km). :) Danke für den Tipp mit der Einstellung... Gruß, Bernd -- Zuviel Freizeit kann dazu führen, daß die Menschen in Zukunft dazu übergehen, das zu tun, was sie schon immer gern getan haben, nämlich sich gegenseitig umzubringen. - Alexander Mitscherlich (dt. Psychoanalytiker und Sozialpsychologe) signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] routing auf dem garmin
Hi Bernd, Wenn man bei den Kauf-Karten eine wesentlich ausgeglichenere Verteilung annimmt Sorry. Grad Deutschland und der Alpenraum sind bei Navteq bis zum Hundehaufen an der Ecke erfasst, mit viel mehr Parametern als in OSM. Sehr viele Feld- und Waldwege sind drin, sogar Schotterpisten die sonst nur im Denzel Alpenstraßenführer erwähnt werden. Andere Gebiete sind deutlich lockerer erfasst. Andererseits hat Florian bestimmt auch recht: Unsere Rohdaten enthalten viele Kleinst-Wege, die man für die Navi-Funktion nicht unbedingt unterteilen müsste. cgpsmapper fasst sowas automatisch zusammen, denn da gibt es Limits in den Karten. Allerdings wird beim Routing auch nicht die Feinansicht zur Berechnung der Strecke herangezogen hoffe ich, sondern eine vereinfachte Netzdatenbank. Dabei sind dann die kleinen Stücke einer Straße wurscht. -- Ciao, Holger (GUS-KOTAL, GUS#1100, GRR#51) 90-92 Honda CB400 10 Mm | 93-95 Yamaha TDM 850 26 Mm 95-97 KTM 620 LC4 13 Mm | seit 97 BMW R1100GS 69 Mm (Die Renndrecksau!) cu @ http://www.issle.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] routing auf dem garmin
Hallo. Am Sonntag, 8. März 2009 schrieb Holger Issle: Wenn man bei den Kauf-Karten eine wesentlich ausgeglichenere Verteilung annimmt Sorry. Grad Deutschland und der Alpenraum sind bei Navteq bis zum Hundehaufen an der Ecke erfasst, mit viel mehr Parametern als in OSM. Sehr viele Feld- und Waldwege sind drin, sogar Schotterpisten die sonst nur im Denzel Alpenstraßenführer erwähnt werden. Andere Gebiete sind deutlich lockerer erfasst. Vielleicht kennst du mehr Daten als ich, denn ich kenne nur was man öffentlich im Netz von Navteq sieht (map24.de) bzw. die bei Medion mitgelieferte Karte. Im meiner Region ist das meiste was abseits des Autoverkehrs stattfindet (um bei deiner Analogie zu bleiben) Hundekacke. Sowohl Fußwege im Ort als auch Wanderwege im Wald sind sehr oft nicht oder nur als Stummel eingezeichnet. Auch wenn Medion mit Navigation für Auto, Fahrrad und Fußgänger wirbt, so ist dieses Kartenmaterial was dort mitgeliefert wird nur für Auto und eingeschränkt für Fahrrad tauglich. Es entspricht aber dem was map24 anzeigt. Leider hat Map24 soweit ich sehen konnte keine Permalink-Funktion, aber falls du Lust hast kannst du ja den Ausschnitt http://www.openstreetmap.org/?lat=48.96796lon=9.59921zoom=15 mal in Navteq-Daten suchen. Klar ist das nicht überall gleich, sowohl bei OSM als auch bei Navteq. Aber ich denke mal in den Regionen wo ernsthaft jemand mapped, ist bei OSM schnell mindestens gleich viel drin. Andererseits hat Florian bestimmt auch recht: Unsere Rohdaten enthalten viele Kleinst-Wege, die man für die Navi-Funktion nicht unbedingt unterteilen müsste. cgpsmapper fasst sowas automatisch zusammen, denn da gibt es Limits in den Karten. Allerdings wird beim Routing auch nicht die Feinansicht zur Berechnung der Strecke herangezogen hoffe ich, sondern eine vereinfachte Netzdatenbank. Dabei sind dann die kleinen Stücke einer Straße wurscht. Ja, ich weiß nicht wie diese vereinfachte Netzdatenbank erstellt wird. Aber ich gehe davon aus, dass diese Datenbank von mkgmap gemacht wird und nicht auf dem Embedded-Device zusammengesucht werden muss. Wenn mkgmap also nicht so großzügig zusammenfasst, wär das ne schöne Erklärung dafür. Gruß, Bernd -- Conny Ja, Nein, Vielleicht... Ich kann mich nicht entscheiden... mAZZe warte ich werf ne SD-Karte Bo_Wallace Willkommen in der Hitech-Generation - german-bash.org signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] keep right - Fehler in OSM-Daten finden
On Sat, 7 Mar 2009, Jonas Krückel (John07) wrote: ich glaube, dass es hier noch nicht erwähnt wurde. Im Wiki bei den templates ist es bereits eingebaut. Auf http://keepright.ipax.at/report_map.php gibt es eine sehr schöne Karte mit Fehlern in den OSM-Daten. Manche mehr, manche weniger gravierend. Mittels Layern kann man ganz einfach die angezeigten Fehlertypen einstellen. Besonders nicht verbundene Wege lassen sich hier leicht finden und direkt in JOSM (mit remote plugin) bzw. in Potlach editieren. Sehr hübsch. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] SRTM-Daten
Hi! Torsten Leistikow schrieb: Dimitri Junker schrieb: Ist es nicht möglich mit SRTM2OSM ein dichtes Netz von Höhenlinien zu erstellen und dann im OSM-File, das ja deutlich handlicher sein sollte zu filtern? Bei SRTM2OSM kann man sich schon mal die Hoehenlinien in drei Schrittweisen erzeugen lassen, die sind dann als minor, medium und major unterschiedlich markiert, und lassen sich entsprechend auch auf den Garmin ueber die Zoom-Stufen filtern. Dafuer muessen sie aber alle erstmal in der Karte enthalten sein, womit man bei dem Pronblem der maximalen Kachelgroesse ist. In wieweit man in den OSM-Daten sonst noch sinnvoll filtern kann, wuesste ich jetzt nicht. Sie lassen sich gut filtern, entweder man programmiert es selber und erhält ein kleineres OSM File oder über Regeln im mkgmap style. Und mir fehlen auch jegliche Erfahrungswerte, welche Hoehenliniendichte man in den Bergen brauchen kann. 2,5m sind sicherlich arg unrealistisch, diese Genauigkeit haben die SRTM-Daten sowieso nicht. Im Flachland kann man mit 5m Abstaenden gut leben. Aber ob das in den Bergen auch noch brauchbar ist, oder ob man da vor lauter Hoehenlinien nichts anderes mehr erkennen kann, kann ich mangels praktischer Erfahrung nicht sagen. Wenn man enge Höhenlinien mag, kann man 5m im Mittelgebirge und Flachland verwenden, 10m sind in den Alpen schon absolute Obergrenze. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] technische Anfrage Radio Bremen
Norbert Kück wrote: Hallo Michael, Michael Buege schrieb: Zitat Max Moritz Sievers: [...] Die öffentlich-rechtlichen Sendeanstalten machen doch jede Kommerzkacke mit. Die sollen sich bei OSM nicht so anstellen. Wo ein Hotel ist, gehört in eine Karte. So wie Tempolimits und minimale und maximale Bekleidung. Wenn das denen zu abgefahren ist, sollen sie eine andere Karte nehmen. Danke, Max, ich werde das so ausrichten. Bescheidene Frage: Habe ich dich richtig verstanden, dass das der Inhalt seiner Antwort an RB ist? Ich würde mal grob schätzen, dass du dir hier die sarcasm-Tags um den Text von Michael selbst hinzufügen musst. Norbert smime.p7s Description: S/MIME Cryptographic Signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] SRTM-Daten
Hallo Torsten, Hoehenliniendichte Die Schweizer Landestopografie verwendet folgende Äquidistanz: 1:100.000 50 m, Zählkurve 200 m, Zwischenkurven 25 m 1:50.000 20 m, Zählkurve 200 m, Zwischenkurven 10 m 1:25.000 Mittelland: 10 m (Zwischenkurven 10 m) Alpen: 20 m (Zwischenkurven 10 m) beschriftet jede 100m-Linie, plus Höhenpunkte im Fels werden nur 100m-Höhenkurven dargestellt Maschenweite 25 m _Digitalisierung_ erfasst sind 49 Millionen Punkte (Höhenlinien und Einzelhöhen) (rund 835 Punkte pro km2, mittlerer Punktabstand 28m) Vektordarstellung und anschliessende Interpolation mit Ergänzung der Bruchkanten (Grat): http://www.toposhop.admin.ch/pub/down/about/publi/WSGK-1998.pdf _Grafische Darstellung_ Braun (Höhenkurven auf normalem Erdboden) Schwarz (Höhenkurven in Fels und Geröll, Höhenkoten) Blau (Höhenkurven auf Gletschern, Seekonturen) Auflösung 203 dpi (max. Abweichung 1px = 1,56m) grafische Elemente Erdböschung, Steinböschung Damm, Einschnitt Doline Fels, Geröll, Erdrutsch Gletscher, Moräne Kiesgrube, Lehmgrube, Steinbruch Interessant ist auch die Definition für Orientierungslauf-Karten: http://www.kartographie.ch/archiv/2003_herbsttagung/geschichte_ol-karten.pdf Äquidistanz 5 m, spezielle Signaturen für Högel und Senken sowie Böschungen. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] planetosm-to-db.pl und Osm2pgsql für MapServer geeignet?
Frank Glück schrieb: Hallo zusammen, ich würde gern einen Planet.osm-Auszug von Deutschland in meine postgreSQL/Postgis-Datenbank bekommen, um die Daten mit dem UMN MapServer für die Kartenausgabe auslesen zu können. ... 2. Dagegen scheint Osm2pgsql der Beschreibung nach (nur?) auf die Bedürfnisse speziell von Mapnik abgestimmt zu sein. Auch hier meine Frage: Heißt das, für den MapServer nützt mir dieses Programm gar nichts? Oder inwieweit bin ich damit eingeschränkt? Gibt es sonst noch (fertige) Alternativen, wie ich die (Deutschland-)Daten in einem für den MapServer brauchbaren Format möglichst vollständig in meine PostgreSQL/Postgis-Datenbank bekomme? Danke und Grüße, Frank Hallo Frank, eine Alternative wären die Shape-Files, die von der Geofabrik täglich zur Verfügung gestellt werden: http://download.geofabrik.de/osm/europe/germany/ Diese lassen sich einfach nach PostGIS konvertieren, die Datenstruktur ist sehr nah dran an dem, was der Mapserver braucht. Die Shapes enthalten aber (noch?) nicht alle Daten. Es fehlen z.B. Parkplätze. Jochen wollte das mal weiter entwickeln. Osm2pgsql habe ich mir mal angesehen. Die Daten sind vermutlich vollständiger. Aber die Tags sind über zahlreiche Spalten verstreut. Die nicht benötigten Spalten bleiben dann leer. Da müsste man noch die Struktur ein wenig nachbearbeiten, bevor sie für den Mapserver optimal ist. Mit dem Mapserver wird man nie die Karten-Qualität hinbekommen, die Mapnik bietet, die Vorteile liegen in anderen Bereichen. Beipiel: Du machst einen (Mapserver-)Layer 'Straßen' und einen Layer 'Eisenbahn'. Dann wird - je nach Reihenfolge im Mapfile - immer Straße über Bahn liegen. Man kann nicht individuell je Kreuzung entscheiden, was oben liegt (Layer-Tag aus OSM). Die Vorteile eines WMS sind dagegen: - jeder (Zwischen-)Maßstab - Layer einzeln abrufbar - Karte so aktuell wie die Datenbank -- Frank Jäger ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] keep right - Fehler in OSM-Daten finden
Hallo Jonas, Im Wiki bei den templates ist es bereits eingebaut. Auf http://keepright.ipax.at/report_map.php Schönes Tool. Aber wenn ich den JOSM-Link von einen Fehler in meinem Bereich in JOSM unter Koordinate eingebe, lädt JOSM einen ganz anderen Bereich... (Klick auf JOSM funktioniert nicht) Wie ist der Wiki-Link zur Doku? Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] keep right - Fehler in OSM-Daten finden
Markus schrieb: Hallo Jonas, Im Wiki bei den templates ist es bereits eingebaut. Auf http://keepright.ipax.at/report_map.php Schönes Tool. Aber wenn ich den JOSM-Link von einen Fehler in meinem Bereich in JOSM unter Koordinate eingebe, lädt JOSM einen ganz anderen Bereich... (Klick auf JOSM funktioniert nicht) Du musst das remote plugin installiert haben, dann kannst du klicken, JOSM lädt den Bereich und markiert dir den betroffenen weg. Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] keep right - Fehler in OSM-Daten finden
Markus schrieb: Hallo Jonas, Im Wiki bei den templates ist es bereits eingebaut. Auf http://keepright.ipax.at/report_map.php Schönes Tool. Aber wenn ich den JOSM-Link von einen Fehler in meinem Bereich in JOSM unter Koordinate eingebe, lädt JOSM einen ganz anderen Bereich... (Klick auf JOSM funktioniert nicht) Wie ist der Wiki-Link zur Doku? Gruss, Markus Wenn Du den Potlatch-Link nimmst und bei JOSM einfügst, lädt er den richtigen Bereich. Allerdings wirst Du dann noch ein wenig rauszoomen müssen um damit arbeiten zu können. -- Gruß Mario signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] SRTM-Daten
Hallo, In wieweit man in den OSM-Daten sonst noch sinnvoll filtern kann, wuesste ich jetzt nicht. sollte im Zweifelsfall einfach sein so etwas zu programieren. Man könnte dann z.B. je nach Höhe( z.B. aus SRTM-Daten) die Minor-Linien rausschmeißen. diese Genauigkeit haben die SRTM-Daten sowieso nicht. Im Flachland kann man mit 5m Abstaenden gut leben. Ich hab gestern was von einem Fehler von 15m gelesen. Ich habe nämlich eine Einleseroutine für SRTM-Daten geschrieben und kann damit jetzt meine Höhenkarte per SRTM initialisieren und dann per GPX-Files verfeinern. Aber ob das in den Bergen auch noch brauchbar ist, oder ob man da vor lauter Hoehenlinien nichts anderes mehr erkennen kann, kann ich mangels praktischer Erfahrung nicht sagen. Man könnte ja auch lokal eine Höhenliniendichte berechnen und wenn die zu hoch ist die Minor,... löschen bis es paßt. Gruß Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] keep right - Fehler in OSM-Daten finden
Jonas Krückel (John07) schrieb: Du musst das remote plugin installiert haben, dann kannst du klicken, JOSM lädt den Bereich und markiert dir den betroffenen weg. Moin, RC crashed bei mir in der latest(1469), ticket ist angelegt. WMS Plugin lädt er auch nicht mehr (Nachricht:Plugin scheint fehlerhaft zu sein oder lässt sich nicht autom. herunterladen) Grüße Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] keep right - Fehler in OSM-Daten finden
Dirk Stöcker schrieb: Sehr hübsch. Find ich auch. Besonders gut finde ich, dass man abgearbeitete Fehler markieren kann. Ebenso kann man false-positives markieren. Eine guter Beitrag zur Qualitätssicherung. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] planetosm-to-db.pl und Osm2pgsql für MapServer geeignet?
Frank Jäger schrieb: Frank Glück schrieb: Gibt es sonst noch (fertige) Alternativen, wie ich die (Deutschland-)Daten in einem für den MapServer brauchbaren Format möglichst vollständig in meine PostgreSQL/Postgis-Datenbank bekomme? Hallo Frank, eine Alternative wären die Shape-Files, die von der Geofabrik täglich zur Verfügung gestellt werden: http://download.geofabrik.de/osm/europe/germany/ Diese lassen sich einfach nach PostGIS konvertieren, die Datenstruktur ist sehr nah dran an dem, was der Mapserver braucht. Gibt es dafür bereits Perl-Skripts oder Ähnliches? Ich stehe im Moment nämlich noch ziemlich am Anfang und weiß noch gar nicht recht, _was_ der MapServer eigentlich braucht. Und bisher hatte ich die Shapefiles bei meinen Überlegungen immer noch außen vor gelassen ... Mit dem Mapserver wird man nie die Karten-Qualität hinbekommen, die Mapnik bietet, die Vorteile liegen in anderen Bereichen. Beipiel: Du machst einen (Mapserver-)Layer 'Straßen' und einen Layer 'Eisenbahn'. Dann wird - je nach Reihenfolge im Mapfile - immer Straße über Bahn liegen. Man kann nicht individuell je Kreuzung entscheiden, was oben liegt (Layer-Tag aus OSM). Schönes Beispiel, ich verstehe ... Die Vorteile eines WMS sind dagegen: - jeder (Zwischen-)Maßstab - Layer einzeln abrufbar - Karte so aktuell wie die Datenbank Ja, ich denke, für meine Zwecke überwiegen dann eher die Vorteile des MapServers. Danke und Grüße, Frank ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OSM für Entscheider in der Wirtschaft
In der WiM 3/2009 - Wirtschaft in Mittelfranken - Verbandszeitschrift der IHK für die Metropolregion Nürnberg-Fürth-Erlangen ist ein Artikel über OSM erschienen (Seite 28): http://www.wim-magazin.de/bk/index.jsp?ausgabe=200903 Auf Seite 24 ein Artikel über Handynavigation Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] =?iso-8859-1?Q?H=F6hennetz/H=F6hendatenbank_Vergleich_mit_SRTM_(was:_Re:_[T alk-de]_H=F6hennetz/H=F6hendatenbank)?=
Hallo, Wie beschrieben habe ich ein Programm geschrieben, welches automatisch eine Höhenkarte aus GPS Daten berechnet, also GPX-Files rein Höhenkarte raus. Ich habe wenige GPX-Files per hand eliminiert, weil sie laut Log-File weit von der Realität waren (Höhen in Aachen über 1000m). Dies liesse sich in Zukunft automatisieren wenn man die SRTM-Höhen als Filter-Kriterium verwendet. Im Augenblick läuft das Verfahren in 3 Schritten: 1) Höhen entlang der Tracks berechnen 2) Löcher auffüllen 3) mit SRTM-Daten kombinieren alternativ kann man auch: 1) mit SRTm-Daten initialisieren 2) Höhen entlang der Tracks berechnen Das Füllen der Löcher entfällt hier, da es fast keine gibt. Für jeden Punkt berechne ich die Höhe incl. statistischem Fehler. Dieser hängt von dem geschätzten Fehler der GPS-Daten ab und per Fehlerfortpflanzung von der Kombination der Meßwerte (Mitteln mehrerer Meßergebnisse für das gleiche Pixel, extrapolation,...) Wie gut die Ergebnisse sind müßte man anhand der 'richtigen' Höhen berechnen, und zwar indem man für jeden Punkt die Abweichung berechnet: abw=berechneteHöhe-wirklicheHöhe und zur Überprüfung des angegebenen Fehler diese durch den berechneten Fehler teilt: FehlerBreite=abw/berechneterFehler Diese Werte werden dann über alle Punkte gemittelt. Einfach einsehbar ist, daß die Abweichung möglichst 0 sein sollte. Die FehlerBreite sollte 1 sein, sonst stimmt der berechnete Fehler nicht. So und jetzt das Ergebnis nach den 3 o.g. Schritten: 1) 5.68 0,61 2) 0.93 0.055 3) 0.046 0.66 Das ist fast zu gut um wahr zu sein. Der Wert von 3) ist natürlich wenig aussagekräftig, da in den Löchern die SRTM-Werte genauer sind als die extrapolierten ist der gewichtete Mittelwert dort nahe am SRTM-Wert - wenn ich beide vergleiche muß es stimmen. Aber auch die Abweichungen von 1-6m in den beiden Stufen ohne SRTM sind besser als das was ich befürchtet hatte. Nur die Fehlerbreite nach dem Füllen der Löcher zeigt, daß ich bei der Extrapolation die Fehler überschätzt habe - die Werte sind docht besser als erwartet. Das hängt aber sehr von der Geländeform ab. Im Gebirge wird da sicher ein Wert 1 rauskommen in der Ebene ein noch kleinerer. Daraus ergibt sich folgende Optimierung: 1.: mit SRTM-Daten initialisieren 2.: aus den SRTM-Daten die Rauhigkeit der Gegend bestimmen und danach den Extrapolationsfehler abschätzen, also in der Ebene ein kleiner Wert, im Gebirge ein großer. Außerdem könnte man alle GPX-Tracks einer Quelle mithilfe von SRTM-Daten kalibrieren. Das berechnete Gebiet ist etwa: LON: 6.06-6.15 und LAT: 50.73-50.79 mit einer Auflösung von je 1024 Pixel. Also eine Pixelgröße von etwa 4*6m Gruß Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich mit SRTM
PS die genannten Abweichungen zwischen meinen aus GPS-Meßwerten und SRTM-Werten von 5.68 bzw 0.93m sind ja sigma(gpsHöhe-srtmHöhe)/anz sie sagen also nur aus, ob es einen systematischen Fehler gibt, hier also, daß die ausgegebenen Höhen z.B. im Duchschnitt 5.68m zu hoch sind. Interessant ist aber auch: sigma( abs(gpsHöhe-srtmHöhe) )/anz Also wie weit die Werte im duchschnitt absolut von den SRTM-Daten abweichen, es sind 13 bzw 14m. Bedenkt man, daß die SRTM-Daten einen Fehler von 15m haben sollen, wäre dies vereinbar mit der Aussage, die GPS-Werte sind genauer als die SRTM-Daten und lassen sich deshalb nicht mehr wirklich über diese bewerten. bei sqrt(sigma( (gpsHöhe-srtmHöhe)^2 )/anz) kommt etwa 21m raus. Fazit das Verfahren scheint zu funktionieren, es sei denn ich hätte Bugs drin die sich zufällig gegenseitig aufheben. Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] keep right - Fehler in OSM-Daten finden
Hallo Jonas, Du musst das remote plugin installiert haben Braucht man das remote plugin auch noch für andere Anwendungen? Dann würde es ja sinn machen, dieses gleich in den JOSM-Installer aufzunehmen? http://wiki.openstreetmap.org/wiki/de:JOSM-install.exe Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] planetosm-to-db.pl und Osm2pgsql für MapServer geeignet?
Frank Glück schrieb: Frank Jäger schrieb: Frank Glück schrieb: Gibt es sonst noch (fertige) Alternativen, wie ich die (Deutschland-)Daten in einem für den MapServer brauchbaren Format möglichst vollständig in meine PostgreSQL/Postgis-Datenbank bekomme? Hallo Frank, eine Alternative wären die Shape-Files, die von der Geofabrik täglich zur Verfügung gestellt werden: http://download.geofabrik.de/osm/europe/germany/ Diese lassen sich einfach nach PostGIS konvertieren, die Datenstruktur ist sehr nah dran an dem, was der Mapserver braucht. Gibt es dafür bereits Perl-Skripts oder Ähnliches? Ich stehe im Moment nämlich noch ziemlich am Anfang und weiß noch gar nicht recht, _was_ der MapServer eigentlich braucht. Und bisher hatte ich die Shapefiles bei meinen Überlegungen immer noch außen vor gelassen ... Shell-Scripte und SQL-Scripte zum Laden und Optimieren der PostGIS. Mapfiles für die Darstellung. Habe ich nicht veröffentlicht, kann ich aber bei Interesse einzeln zusenden. Die Icons stammen aus dem SVN von OSM. -- Frank Jäger ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] keep right - Fehler in OSM-Daten finden
Markus schrieb: Hallo Jonas, Du musst das remote plugin installiert haben Braucht man das remote plugin auch noch für andere Anwendungen? Naja, es ist ja für solche Anwendungszwecke gedacht, es wird auch von ein paar anderen (Tagwatch imo...) unterstützt und ist da ganz nützlich. Da das aber eher schon für Profis ist und das Plugin noch experimentell ist, bin ich dagegen es in den allgemeinen Installer aufzunehmen. Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich mit SRTM
Dimitri Junker o...@dimitri-junker.de [Sun, Mar 08, 2009 at 02:47:28PM CET]: PS die genannten Abweichungen zwischen meinen aus GPS-Meßwerten und SRTM-Werten von 5.68 bzw 0.93m sind ja sigma(gpsHöhe-srtmHöhe)/anz sie sagen also nur aus, ob es einen systematischen Fehler gibt, hier also, daß die ausgegebenen Höhen z.B. im Duchschnitt 5.68m zu hoch sind. Ich kann nicht genau nachvollziehen, was Du da gemacht hast, aber eine Formel zu einem systematischen Fehler sollte nicht mit anz - oo gegen Null gehen. Wenn ein systematischer Fehler drin ist, hilft viel messen nur bis zu einem bestimmten Punkt. Oder soll das ein großes Sigma = Summenzeichen sein? Interessant ist aber auch: sigma( abs(gpsHöhe-srtmHöhe) )/anz Also wie weit die Werte im duchschnitt absolut von den SRTM-Daten abweichen, es sind 13 bzw 14m. Bedenkt man, daß die SRTM-Daten einen Fehler von 15m haben sollen, wäre dies vereinbar mit der Aussage, die GPS-Werte sind genauer als die SRTM-Daten und lassen sich deshalb nicht mehr wirklich über diese bewerten. sqrt(sigma( (gpsHöhe-srtmHöhe)^2 )/anz) kommt etwa 21m raus. Tja, was bezeichnet denn den Fehler bei SRTM? Wenn die Standardabweichung gemeint ist, kannst Du davon ausgehen, dass die 21 m sich nach der Fehleraddition durch 21^2 = 15^2 + x^2 ergeben können, wobei x dann die Standardabweichung für GPS wäre. Demnach tun sich die beiden Fehler nichts, mit x=15 kommt man etwa auf das richtige Ergebnis. Möglicherweise sind die beiden Messfehler auch positiv assoziiert: Häuserschluchten und Wälder schränken die Messgenauigkeit für beide Verfahren ein. -- Johannes Hüsing There is something fascinating about science. One gets such wholesale returns of conjecture mailto:johan...@huesing.name from such a trifling investment of fact. http://derwisch.wikidot.com (Mark Twain, Life on the Mississippi) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] technische Anfrage Radio Bremen
Zitat Michael Buege: Moin Folgende Mail ist gerade bei mir eingegangen: . Hallo, ich schreibe Ihnen von Radio Bremen mit folgendem Problem: Wir haben gerade neu gerelauncht und haben Ihr Kartenmaterial auf unseren Seiten verknüpft. Zum Beispiel hier: http://www.radiobremen.de/nachrichten/land_und_leute/lalehansestaedteverlust100.html Wir finden diesen Dienst sehr nützlich und Ihr Kartenmaterial prima. Möglicherweise bekommen wir als öffentlich-rechtlicher Sender ein Problem mit Werbeeinblendungen oder bestimmten Einträgen in den Karten, die vermuten lassen, dass kommerzielle Interessen dahinter stehen. Nun wissen wir natürlich, dass sie nicht kommerziell sind, aber Einträge von Hotels oder Restaurants sind vielleicht schon problematisch. Nun meine Frage: Ist es möglich, bei Ihnen das Kartenmaterial ohne diese Einblendungen zu nutzen? Arbeiten Sie mit Layern, Ajax oder ähnlichem, so dass wir beim Einbinden Ihrer Karten per Link darauf verzichten können? Für eine Antwort dankt Ihnen Loretta Findeisen . Wer kann helfen? Email-Adresse gibt es bei mir. Unabhaengig davon sollten wir ueber eine Loesung natuerlich hierzulist diskutieren. Fuehlt sich jemand Willens und in der Lage, Kontakt mit Radio Bremen auzunehmen und eine Loesung des Problems zu erarbeiten? -- Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] routing auf dem garmin
Hi Bernd, http://www.openstreetmap.org/?lat=48.96796lon=9.59921zoom=15 In der gegend ist Navteq in der Tat abseits der Straße schlechter als OSM. Ja, ich weiß nicht wie diese vereinfachte Netzdatenbank erstellt wird. Aber ich gehe davon aus, dass diese Datenbank von mkgmap gemacht wird und nicht auf dem Embedded-Device zusammengesucht werden muss. Es kann nur vom Compiler (mkgmap, cgpsmapper) gemacht werden. Zumindest letzterer kann es ordentlich. Wenn mkgmap also nicht so großzügig zusammenfasst, wär das ne schöne Erklärung dafür. In der Tat. -- Ciao, Holger (GUS-KOTAL, GUS#1100, GRR#51) 90-92 Honda CB400 10 Mm | 93-95 Yamaha TDM 850 26 Mm 95-97 KTM 620 LC4 13 Mm | seit 97 BMW R1100GS 69 Mm (Die Renndrecksau!) cu @ http://www.issle.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] keep right - Fehler in OSM-Daten finden
für meine checks kann man es auch nutzen. ich selber nutze es und hatte bisher keine probleme. gary68 gerhard On Sun, 2009-03-08 at 16:42 +0100, Jonas Krückel (John07) wrote: Markus schrieb: Hallo Jonas, Du musst das remote plugin installiert haben Braucht man das remote plugin auch noch für andere Anwendungen? Naja, es ist ja für solche Anwendungszwecke gedacht, es wird auch von ein paar anderen (Tagwatch imo...) unterstützt und ist da ganz nützlich. Da das aber eher schon für Profis ist und das Plugin noch experimentell ist, bin ich dagegen es in den allgemeinen Installer aufzunehmen. Gruß Jonas ___ 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] Höhennetz/Höhendatenbank Vergleich mit SRTM
Hallo, Oder soll das ein großes Sigma = Summenzeichen sein? Ja was denn sonst? Demnach tun sich die beiden Fehler nichts, Ganz meine Aussage. Möglicherweise sind die beiden Messfehler auch positiv assoziiert: Häuserschluchten und Wälder schränken die Messgenauigkeit für beide Verfahren ein. Nö, bei SRTM ergeben sie einen systematischen Fehler weil die Oberkannte der Häuser/Bäume gemessen wird, bei GPS ergeben sie 'nur' einen größeren statistischen Fehler ohne Vorzugsrichtung. Ein entsprechender systematischer Fehler der GPS-Messungen ist die Höhe des Gps-Empfängers über dem Boden ;-) Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] planetosm-to-db.pl und Osm2pgsql für MapServer geeignet?
Hallo Frank, Frank Jäger schrieb: Shell-Scripte und SQL-Scripte zum Laden und Optimieren der PostGIS. Mapfiles für die Darstellung. Habe ich nicht veröffentlicht, kann ich aber bei Interesse einzeln zusenden. Sehr gern, auch die Mapfiles würden mich als Vorlage brennend interessieren. Die MapServer-Doku zu den Mapfiles sind ja leider nicht sehr ausführlich. Danke und Grüße, Frank ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Editor für Android veröffentlicht
Habe doch jetzt schon die Zeit gefunden und zwei Pakete online gestellt: Eins für den Emulator, das andere für echte Endgeräte: http://code.google.com/p/osmeditor4android/ Viel Spaß! Habs heute erst gesehen und reingeschaut. Komme aber nicht ganz klar, immer wenn ich was editieren will, meint er, ich soll reinzoomen. Nur, wie geht das? Hab ich da Tomaten auf den Augen? Gibt es eine Kurzreferenz zur GUI? Im übrigen: Ich finde Konzept und Umsetzung wirklich gut! JJ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM
Dimitri Junker o...@dimitri-junker.de [Sun, Mar 08, 2009 at 06:06:14PM CET]: Hallo, Oder soll das ein großes Sigma = Summenzeichen sein? Ja was denn sonst? Ein kleines Sigma eben. Das steht im allgemeinen für die Standardabweichung, die bei Deinen Überlegungen ja auch eine Rolle spielt. Demnach tun sich die beiden Fehler nichts, Ganz meine Aussage. Möglicherweise sind die beiden Messfehler auch positiv assoziiert: Häuserschluchten und Wälder schränken die Messgenauigkeit für beide Verfahren ein. Nö, bei SRTM ergeben sie einen systematischen Fehler weil die Oberkannte der Häuser/Bäume gemessen wird, aber wegen wechselnder Höhe der Bäume und Häuser doch stark schwankend. Das ist schon eine Einschränkung der Messgenauigkeit in beiden Fällen. bei GPS ergeben sie 'nur' einen größeren statistischen Fehler ohne Vorzugsrichtung. Ein entsprechender systematischer Fehler der GPS-Messungen ist die Höhe des Gps-Empfängers über dem Boden ;-) Genau, wenn ich die Höhenangabe auf Fuß stelle, kann ich meine Kniebeugen ablesen. -- Johannes Hüsing There is something fascinating about science. One gets such wholesale returns of conjecture mailto:johan...@huesing.name from such a trifling investment of fact. http://derwisch.wikidot.com (Mark Twain, Life on the Mississippi) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Editor für Android veröffentlicht
Jan Jesse wrote: Habe doch jetzt schon die Zeit gefunden und zwei Pakete online gestellt: Eins für den Emulator, das andere für echte Endgeräte: http://code.google.com/p/osmeditor4android/ Viel Spaß! Habs heute erst gesehen und reingeschaut. Komme aber nicht ganz klar, immer wenn ich was editieren will, meint er, ich soll reinzoomen. Nur, wie geht das? Hab ich da Tomaten auf den Augen? Gibt es eine Kurzreferenz zur GUI? Ja, das ist einer der Gründe, warum ich es nicht wirklich für die breite Öffentlichkeit zugänglich machen wollte. Das zoomen geht über lauter/leister-Tasten, bzw. Lupe/Shift-Tasten. Das muss dem Benutzer noch mitgeteilt werden... Im übrigen: Ich finde Konzept und Umsetzung wirklich gut! Danke :-) Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Welche Straßenschreibweise ist anzuhalte n ?
Lutz Horn wrote: Hallo, On Fri, 06 Mar 2009 11:14 +0100, Jan Tappenbeck o...@tappenbeck.net wrote: bei uns gibt es eine HOESCHstraße und in der offiziellen Liste der Stadt steht HÖSCHstraße. Das Straßenschild gewinnt. Keinesfalls - Straßenschilder sind beliebig falsch. Es gibt genügend Straßen mit unterschiedlichen Schreibenweisen am einen und anderen Ende Die offizielle Liste würde ich nur verwenden, wenn ihre Lizenzbedingungen ihre Einarbeitung in OSM-Daten erlauben. Oftmals reicht gesunder Menschenverstand und ein Nachschlagewerk - wobei oftmals sich auch die Frage stellt, wem man wohl folgen solle. Sehr beliebt ist z.B. der Gerhard-Hauptmann-Weg (statt Gerhart-Hauptmann-Weg). Auch die Bismarkstraße findet sich oft statt der Bismarckstraße. Die Albert-Schweizer-Straße findet sich dutzendweise. Die meisten derartigen Fehler werden aber offiziell früher oder später korrigiert. Beispielsweise wurde in Baden-Baden vor ein paar Jahren ein ganzes Neubauviertel mit französischen Namen aus dem Boden gestampft, wo nicht nur die Regeln deutscher Rechtschreibung beliebig ignoriert wurden und Akzente bunt gemischt werden. Was die Presse oder Google oder oder oder daraus macht, ist Realsatire. Beispiele: * De Beauvoir-Weg oder De-Beauvoir-Weg * Moliére-Weg oder Molière-Weg (richtig wäre es nebenbei ohne Bindestrich) * Sainte-Exupery-Weg, St. Exupéry-Weg oder Saint-Exupéry-Weg usw. In meiner eigenen Nicht-OSM-Anwendung bevorzuge ich wo immer möglich die richtige und in der Regel ausgeschriebene Schreibweise (also statt der zig Varianten wie Frh. v. Stein-Str. lieber die Freiherr-vom-Stein-Str.), habe aber die Freiheit, beliebig viele bekanntermassen falsche Schreibweisen als Suchalternativen zuzulassen. Wer hat allerdings schon die Möglichkeit, Namen mit ausländischen Sonderzeichen korrekt wiederzugeben? Antonín Dvořák? Пётр Ильи́ч Чайко́вский? Schönen Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Welche Straßenschreibweise ist anzuhalte n ?
Hallo, Martin Trautmann wrote: * Moliére-Weg oder Molière-Weg (richtig wäre es nebenbei ohne Bindestrich) Wieso das? Meine Meinung zu der Strassenschildfrage ist glaube ich hinlänglich bekannt; ich bin der Ansicht, dass eine Stadt, wenn sie denn gern eine Göthestraße haben will, diese auch beschließen kann. Die Strasse heisst danach Göthestraße. Sie heisst nicht etwa Goethestraße und ist nur falsch beschildert. Dass das ganze vielleicht peinlich ist und dass die Strasse eventuell umbenannt werden sollte, steht auf einem anderen Blatt, aber es ist sicherlich nicht unsere Aufgabe als Mapper, diesen Verwaltungsakt vorwegzunehmen. (So a la irgendwann wird hier bestimmt eine Ortsumgehung gebaut, die kann ich auch schonmal mappen.) Natürlich kann es auch Fälle geben, in denen die Strasse tatsächlich Goehtestraße heisst und nur falsch beschildert ist... 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] Pavel Machek zur neuen Lizenz
Moin, Kernel Hacker Pavel Machek hat in seinem Blog einen Kommentar zur neuen OSM Lizenz: http://pavelmachek.livejournal.com/73535.html naja, kein wirklich aufschlussreiches Posting. Genau so sehe ich das eigentlich auch. Um einen Fork zu vermeiden der beim Lizenzwechsel IMO fast unvermeidlich ist sollten wir besser die ungeeignete CC-SA Lizenz beibehalten. Sollte es Forks geben, werden die IMO nicht lange überleben. Andererseits denke ich ähnlich wie Du. Einerseits sehe ich ein, dass ein Lizenzwechsel ein Stück weit durchgepeitscht werden muss. Sonst diskutieren wir in 20 Jahren immer noch ergebnislos herum. Insofern ist es richtig, dass die OSMF Gas gibt und versucht, Störenfriede so weit wie möglich draußen zu halten. Andererseits bin ich etwas mißtrauisch gegenüber der OSMF, was wahrscheinlich daher kommt, dass die sich so zugeknöpft geben. Zwar wird ständig beteuert, dass man das Projekt bzw. die Daten nicht kontrollieren wolle, ich bin mir aber nicht so ganz sicher, inwieweit da Anspruch und Wirklichkeit in Deckung zu bringen sind. Steve Coast hat (ebenfalls am Mittwoch) in seiner unnachahmlichen Art ein längliches Posting¹ losgelassen. Auch dieses lässt sich dahingehend interpretieren, dass versucht werden soll, potentielles Störfeuer möglichst in einen Kugelfang umzuleiten, den man nicht weiter zu beachten braucht. Im Anhang weist er darauf hin, dass ihm persönlich mit PD am meisten gedient sei. Das kaufe ich ihm nicht so ganz ab. Ich glaube im Gegenteil, dass es Cloudmades vitales Interesse ist, eine PD-Lizemz zu verhindern. Mich würde mal interessieren, inwieweit die OSMF mit Cloudmade verflochten ist und inwieweit Cloudmade über die OSMF versucht, die Lizenz durchzudrücken. Die Lizenz ist ja nicht grundsätzlich schlecht. Wenn Cloudmade denkt, dass diese Lizenz ihnen nutzt, und sie daher versuchen, die möglichst schnell durchzubekommen, dann ist das eigentlich keine schlechte Sache. Aber wenn es so wäre, dass Cloudmade eine PD-Lizenz als gefährlich erachtet und sie deshalb ihren Einfluss in der OSMF zu nutzen versuchen, PD zu verhindern, dann hätte das Ganze doch schon ein G'schmäckle, gell :) . Der Lizenzwechsel wird auf jeden Fall einiges Geknarze im Gebälk verursachen. Einige Leute werden das Projekt vielleicht verlassen, andere werden einen Fork versuchen, aber sehr viele werden, wenn vielleicht auch murrend, dann doch mitziehen. Wenn ich mir ansehe, welchen Aufwand wir treiben, nur um unsere Daten in einen güldenen Käfig zu sperren, von dem noch keiner weiß, ob er auch wirklich sicher ist, dann frage ich mich, welcher Nutzen dem Aufwand gegenübersteht. Als ich vor knapp drei Jahren angefangen habe, mich für OSM zu interessieren, fand ich es gut, diese SA-Komponente in der Lizenz zu haben. Inzwischen denke ich anders. Wenn unsere Daten gemeinfrei wären, würde vielleicht der ein oder andere ein Geschäft damit machen, ohne uns was zurückzugeben. Im Gegenzug würde es aber auch freie Anwendungen geben, die wir momentan durch unsere Lizenz verhindern. Ich weiß, dass es viele Mapper gibt, die gegen eine PD-Lizenz sind. Ich finde das schade. Wir verlören in meinen Augen nichts, aber die Allgemeinheit könnte nur davon profitieren. Zurück zum Ausgangspunkt: Sollte es wirklich so sein, dass CC-by-SA nicht auf unsere Daten anwendbar ist, dann hieße das, unsere Daten sind faktisch bereits PD. Und da würde ich Dir zustimmen: Lieber PD beibehalten als einen Lizenzwechsel zu riskieren. Beste Grüße, ce ¹ http://www.nabble.com/License-to-kill-td22323485.html ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Welche Straßenschreibweise ist anzuhalte n ?
Frederik Ramm wrote: Hallo, Martin Trautmann wrote: * Moliére-Weg oder Molière-Weg (richtig wäre es nebenbei ohne Bindestrich) Wieso das? Meine Meinung zu der Strassenschildfrage ist glaube ich hinlänglich bekannt; ich bin der Ansicht, dass eine Stadt, wenn sie denn gern eine Göthestraße haben will, diese auch beschließen kann. Die Strasse heisst danach Göthestraße. Sie heisst nicht etwa Goethestraße und ist nur falsch beschildert. Dass das ganze vielleicht peinlich ist und dass die Strasse eventuell umbenannt werden sollte, steht auf einem anderen Blatt, aber es ist sicherlich nicht unsere Aufgabe als Mapper, diesen Verwaltungsakt vorwegzunehmen. (So a la irgendwann wird hier bestimmt eine Ortsumgehung gebaut, die kann ich auch schonmal mappen.) Natürlich kann es auch Fälle geben, in denen die Strasse tatsächlich Goehtestraße heisst und nur falsch beschildert ist... Straße, Straße, Straße, Straße, Straße, Straße, Straße, Straße, Straße, Straße, Straße, Straße, Straße, Straße, Straße, Straße, Straße, Straße, Straße, Straße, Straße, Straße, Straße, Straße, Straße, Straße, Straße, Straße, Straße, Straße, Straße, Straße, Straße, Straße, Straße, Straße Ein paar auf Vorrat. Und noch einzelne ß, zum flexiblen Einsatz: ßß Einfach copypasten (auch mehrfach verwendbar)... Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Welche Straßenschreibweise ist anzuhalte n ?
Moin, Meine Meinung zu der Strassenschildfrage ist glaube ich hinlänglich bekannt; ich bin der Ansicht, dass eine Stadt, wenn sie denn gern eine Göthestraße haben will, diese auch beschließen kann. Die Strasse heisst danach Göthestraße. Sie heisst nicht etwa Goethestraße und ist nur falsch beschildert. wenn ich auf der Gasse stehe und ein Straßenschild sehe, auf dem Götestrasse steht, dann heißt das noch lange nicht, dass die Straße offiziell so heißt. Ich würde vermuten, dass das Ding wohl offiziell Goethestraße heißt (schon alleine deshalb weil jede Gemeinde mit mehr als 1000 Einwohnern meint eine Goethestraße haben zu müssen, auch wenn dort noch niemand was von dem guten Mann gelesen hat ;-) und der Schildermacher des Tiefbauamtes das Schild an einem Rosenmontag gemalt hat. Gruß, ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM
Ein kleines Sigma eben. Das steht im allgemeinen für die Standardabweichung, die bei Deinen Überlegungen ja auch eine Rolle spielt. Ok, aber da anz in der Größenordnung 10-1Million ist konnte es nur Sigma sein. aber wegen wechselnder Höhe der Bäume und Häuser doch stark schwankend. Das ist schon eine Einschränkung der Messgenauigkeit in beiden Fällen. Und? SRTM ist die beste mir bekannte Quelle um meine Daten zu prüfen. Wir kennen alle deren Nachteile. Nehmen wir an, die SRTM-Daten liefern für das berechnete Gebiet im Durchschnitt eine um 5m zu große Höhe (Häuser/Bäume). Dann erhöht sich der Fehler entsprechend. Damit sind wir aber immer noch weit entfernt von den vor kurzem hier raufgeschworenen Fehlern, und das mit relativ wenig Daten die zum größten Teil aus Altbeständen bestehen von denen nicht bekannt ist wie die Geräte kalibriert (Höhenkorektur,...) waren. Genau, wenn ich die Höhenangabe auf Fuß stelle, kann ich meine Kniebeugen ablesen. Wieso kann Dein Gerät/Software keine Nachkommastellen? Glopus liefert 5 Nachkommastellen, damit kann ich erkennen ob ich auf einem Blatt Papier stehe. ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM-Vorlagen
Am 3. März 2009 17:18 schrieb Olaf Hannemann ohannem...@gmx.de: Hallo Markus, On Tuesday 03 March 2009 16:27:28 Markus wrote: Bei mir ist amenity = school oftmals das Schulgelände die einzelnen Gebäude sind lediglich mit building = yes eingezeichnet. Also: Gebäude Schulhaus Gebäude Sporthalle Gebäude Mensa Landnutzung Schulgelände (und die passenden Attribute werden automatisch gesetzt) das wäre der Idealfall, wobei zur Zeit das Problem besteht, dass in den Map_Features lediglich der Tag amenity = school existiert. Dieser reicht nicht aus um alle Formen zu beschreiben. Ein Schulhaus hätte in der Kartendarstellung die gleiche Farbe wie ein Schulgelände. Ich habe mir gerade einmal 6 umliegende Orte mit Schulen angeschaut. Hier in dieser Gegend wird amenity = school immer für das Gelände verwendet. Das Problem scheint also eher zu sein, dass der Tag doppeldeutig ist. Man bräuchte also einen zweiten Tag landuse = schoolyard um deine Vorschläge korrekt abbilden zu können. Gleiches gilt für Kindergarten und Universität. das gilt im Prinzip für alle Arten von Gebäuden bzw. Gebäudekomplexen. Anstatt da dann jeweils eigene toplevel-tags zu machen wäre es m.E. gut, das ganze hierarchisch zu strukturieren in einer Art, die man dann universell verwenden kann (s. z.B. das Adress-system für Hausnummern), also mit Doppelpunkt als Trenner für die Hierarchie-Ebenen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] technische Anfrage Radio Bremen
Hallo, Norbert Wenzel schrieb: Ich würde mal grob schätzen, dass du dir hier die sarcasm-Tags um den Text von Michael selbst hinzufügen musst. Das war auch meine Einschätzung, aber man weiß ja nie. Und dann frage ich lieber. :-) Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] technische Anfrage Radio Bremen
Hallo, Michael Buege schrieb: Zitat Michael Buege: Moin Folgende Mail ist gerade bei mir eingegangen: . Hallo, ich schreibe Ihnen von Radio Bremen mit folgendem Problem: Wir haben gerade neu gerelauncht und haben Ihr Kartenmaterial auf unseren Seiten verknüpft. Zum Beispiel hier: [...] Für eine Antwort dankt Ihnen Loretta Findeisen . Fuehlt sich jemand Willens und in der Lage, Kontakt mit Radio Bremen auzunehmen und eine Loesung des Problems zu erarbeiten? Wenn sich das darauf beschränkt, RB auf die richtige Schiene zu stellen (technische und nichttechnische Lösungen wie hier diskutiert zu beschreiben - keine turn key solution), will ich das wohl machen. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Welche Straßenschreibweise ist anzuhalte n ?
Frederik Ramm schrieb: Aufgabe als Mapper, diesen Verwaltungsakt vorwegzunehmen. (So a la irgendwann wird hier bestimmt eine Ortsumgehung gebaut, die kann ich auch schonmal mappen.) Wenn die Trassierung klar ist, beispielsweise durch Planfeststellung und wenn es zu den Lizenzbestimmungen von OSM kompatible Möglichkeiten gibt, den Trassenverlauf zu mappen, warum nicht. Spätestens, wenn die Trasse anhand der Absteckungen erkennbar ist würde ich raus. Gut, dann ist es auch eher ein construction=2011 und kein planned=2025. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
