Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)
Hat ein Mensch einen Vorteil, wenn das selbe Modell einer Windmühle einmal mit generator:output:electricity=100 kW und ein anderes Mal als generator:output:electricity=0.1 MW beschrieben wird? Ja. Es gibt Menschen, die Probleme haben, kW in MW umzurechnen - und je nach Art des Kraftwerks (oder anderer technischer Anlagen), auch je nach Art der Veröffentlichung (Bauschild, Pressemeldung in Lokalblatt, Pressemeldung in Fachpresse) wirst du unterschiedliche Angaben bekommen. Mal in kW, mal in MW, mal GW, mal sogar in W (hört sich nach viel an). Und es wird immer Menschen mit Problemen bei der Eingabe geben. Das führt zu Fehlern, wenn du die Einheit auf nur eine Möglichkeit festlegst. Wir haben schließlich nicht nur Techniker hier (und selbst die haben manchmal massive Problem mit dem Unterschied zwischen Leistung und Energie ... um mal ein weiteres Feld aufzumachen). Ob man hinterher (per Bot?) alles auf eine Einheit geradebiegt, das ist ein anderes Thema - da gäbe es dann aber Argumente für W, kW oder auch MW - bei anderen Themen natürlich andere Einheiten. Diese Diskussion finde ich persönlich erstmal ziemlich müßig, ich erfasse da lieber draußen mehr Daten. Gruß, Schusch___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)
On Mon, 14 Feb 2011, Frederik Ramm wrote: PS: zur Illustration die in Europa vorkommenden voltage-Werte samt Anzahl (nur die, die 10x vorkommen). Sind diese Werte plausibel und tatsaechlich alle in Volt? schon ... die Werte zwischen 500 und 1000 V sind vermutlich von Straßen- oder U-Bahnen? Der unplausibelste Wert ist 0 :-) Es gibt auch noch ein paar Leitungen mit Spannungen über 380 kV (Stichwort HGÜ), da könnte es also Verwechslungen geben, aber wohl doch eher selten. Und dann gibt es noch das Gerücht, es gäbe in Europa 400-kV-Leitungen ... das konnte ich bisher nirgendswo bei den einschlägigen Netzbetreibern bestätigt finden - also bei den 40er Werten dürften so einige falsch sein - aber die müssten wohl statt dessen 38 betragen, liegen also nur knapp daneben. Gruß, Schusch___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mappen von (Nicht-)Geodaten
Hi. Am 14.02.2011 01:52, schrieb Micha Ruh: 2011/2/13 M∡rtin Koppenhoeferdieterdre...@gmail.com Obwohl ich mich eigentlich als Inkludist bezeichnen würde (nach gängigem WP-Schubladendenken) finde ich, dass bestimmte Dinge eher schlecht in OSM aufgehoben sind. Dazu zähle ich z.B. Ways die sich auf Kartenmaterial oder Luftbilder beziehen. Z.B. http://www.openstreetmap.org/browse/way/39509794 Das ist wohl ein way, der soweit ich die tags richtig interpretiere, bezeichnet, wo man Yahoo-Bilder in hires (was immer das heissen soll) finden kann. Fast richtig. Es bezeichnet, dass viele OSM-Daten innerhalb des ways von Yahoo Bilder abstammen (Wälder/Häuser), welche bis z17 vorhanden sind. Ausserhalb des ways stammen die Wälder, falls vorhanden, von z13 Landsat-Satellitenbildern ab. http://www.openstreetmap.org/?way=39509794 Das ist doch Blödsinn: Nicht alle Daten in Gebieten, in denen Bing verfügbar ist, stammen von Bing - mindestens ältere Daten sind auch von Landsat, und die Logik, die Du hier annehmen willst, ignoriert jede Straße, die nach GPS-Tracks und Begehung gemapped wurde. Für diese Auswertung kann - wenn überhaupt - nur das source-tag herhalten. So was finde ich perfekt in einer parallelen Datenbank aufgehoben, da es praktisch keinen Bezug zu OSM-Daten gibt (zumindest keinen direkten Bezug) und da es sich auch m.E. nicht um Geodaten handelt. +1 Wird für die neuen Bing-Luftbilder auch gemacht: http://ant.dev.openstreetmap.org/bingimageanalyzer/?lat=46.68lon=8.41 Richtig, und das ist genau die Richtung, was Martin generell fordern will; ich stimme ihm zu. [...] Relationen mit mehr als 50 Members machen keinen Sinn und sollten verboten sein. -1 kann ich so grundsätzlich nicht unterschreiben. Relationen, die nur sammeln, sollten verboten werden; das hat aber mit der Anzahl der Elemente nichts zu tun. Eine Bahnlinie aufzusplitten in mehrere Relationen, NUR weil sie mehr als 50 Elemente umfasst, ist Blödsinn; und ich würde selbiges für alle Relationen annehmen: Wenn die Relation sinnvoll ist, ist dies unabhängig von der Zahl der Elemente. Was nicht sein sollte, sind Sammelrelationen, die berechnet werden könnten: Briefkästen in NRW, Packstationen in Deutschland, Städte-mit-zwischen-100-und-20143-Einwohnern, . Eine Relation ist eine Relation, weil die Mitglieder in Relation zueinander stehen; das bedeutet, mindestens über die Reihenfolge einzeln eine Bedeutung bekommen; und/oder über die Rolle. [...] Für eine erste Einschätzung und Übersicht über die Qualität von den in OSM erfassten Daten sind solche ways äusserst hilfreich, oder weisst Du warum hier die Karte leer ist? http://www.openstreetmap.org/?lat=45.8445lon=9.zoom=15 Die Information ist hilfreich fürs Mappen - soweit richtig. Die besondere Bedeutung als Way in der Karte sehe ich aber nicht. Ein Tool wie der imageanalyzer von ant ist meines Erachtens die bessere Wahl, weil sie a) die Hauptdatenbank nicht belastet, b) ich nicht mehr oder weniger zufällig über einzelne Polygone oder Multipolygon-Relationen in OSM stolpern muss, um mir das anzugucken, und weil c) ein solches Tool eben auch zeigen kann, wo die Auflösung unbekannt ist - im Gegensatz zu den Multipolygon-Relationen in der Datenbank. Für mich also: schöne Mapper-Hilfe, aber besser in 'ner externen Datenbank aufgehoben, und außerdem Rasterdaten, weil Informationen über Tiles; damit sowieso ungeeignet in der Haupt-DB. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)
Am 14.02.11 10:29, schrieb Schorschi: Der unplausibelste Wert ist 0 :-) Wieso? Ich bin schon etlichen Leitungen begegnet, die ohne Saft waren, und am Ende einfach so am Mast befestigt waren. Quasi 7 Erdleiter am Mast, auch als double oder quad ;-) Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Südpol im Atlantik
On Mon, 14 Feb 2011 00:54:59 +0100, Stephan Knauss wrote: Strahlenförmige Ländergrenzen, und beim Reinzoomen erscheint Südpol... http://www.openstreetmap.org/?lat=-0.09lon=0.32zoom=6layers=M Die Software kann unendlich nicht darstellen. Eigentlich müsste alles nördlicher/südlicher von 85 Grad abgeschnitten werden. So landet es dann eben bei 0/0 Siehe: http://forum.openstreetmap.org/viewtopic.php?id=11178 Die Tools sind angeblich gefixt, nur der Datenupdate dauert ein paar Wochen. Ob es am Südpol wirklich 'nen Airport gibt, ist mir nicht bekannt. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Südpol im Atlantik
Hallo Stephan, Strahlenförmige Ländergrenzen, und beim Reinzoomen erscheint Südpol... http://www.openstreetmap.org/?lat=-0.09lon=0.32zoom=6layers=M Das ist auch ein bekanntes Ziel ;-) für Flugzeuge und Schiffe, die vergessen haben, die Koordinaten einzugeben, wenn sie ihre Wegpunkte in den Autopiloten füttern - und der dann 0/0 daraus macht. Die Software kann unendlich nicht darstellen. Eigentlich müsste alles nördlicher/südlicher von 85 Grad abgeschnitten werden. So landet es dann eben bei 0/0 Zumindest müsste eine Fehlerroutine eingebaut sein, die verhindert dass der Südpol bei 0/0 gerendert wird. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neuer Kartenstil auf openstreetmap.de
Wolfgang wolfg...@ivkasogis.de wrote: Es wäre schön, wenn das width-Tag eine Auswirkung hätte, bei Gewässern wie bei Osmarender, möglichst auch bei Straßen Das kann Mapnik nicht! Sven -- Das Internet ist kein rechtsfreier Raum, das Internet ist aber auch kein bürgerrechtsfreier Raum. (Wolfgang Wieland Bündnis 90/Die Grünen) /me is giggls@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] Wiki und Wikipedie
Markus liste12a4...@gmx.de wrote: Bei meiner Arbeit in Kursen für OSM-Neulinge erfahre ich aus erster Hand viel über deren Schwierigkeiten. Ich glaube nicht, dass es so arg zielführend ist OSM Neulingen Details über Projektionen, Koordinatensysteme und Ellipsoide zu erzählen. Gerade weil OSM ja konsequent ausschließlich EPSG:4326 einsetzt (vom Google Merkator in den Tiles jetzt mal abgesehen). Gruss Sven -- Why are there so many Unix-haters-handbooks and not even one Microsoft-Windows-haters handbook? Gurer vf ab arrq sbe n unaqobbx gb ungr Zvpebfbsg Jvaqbjf! /me is giggls@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] Wo aktuelle Garmin Karten für DE?
Andreas Tille andr...@an3as.eu wrote: Irgendwie habe ich den Eindruck, daß derzeit die Kartenerzeugung nicht so gut funktioniert und ich denke, daß es wichtig wäre, eine Standardkarte, die immer funktioniert und mindestens wöchentlich aktualisiert wird anzubieten. Irgendwie habe ich den Eindruck daß ich das Anspruchsdenken Deinerseits nicht nachvollziehen kann. Eine Garminkarte dauernd neu zu rechnen und aktuell zu halten ist nicht ganz einfach. Gerade weil unsere Datenmenge stark wächst. Gruss Sven -- Microsoft ist offenbar die einzige Firma, die in der Lage ist, ein mit Office nicht kompatibles Bürosoftwarepaket einzuführen. (Florian Weimer in de.alt.sysadmin.recovery) /me is giggls@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] Wo aktuelle Garmin Karten für DE?
Hallo in die Runde ! Es hat sich wohl noch nicht rumgesprochen das es seit einiger Zeit eine tägliche Deutschlandkarte gibt. aktuelle Karte : http://dev.openstreetmap.de/aio/germany-daily/ sowie ältere Versionen : http://dev.openstreetmap.de/aio/germany-daily/gmapsupp-images/ An den älteren Versionen sieht man auch schon den Zuwachs der Karte. Dirk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mappen von (Nicht-)Geodaten
Am 14. Februar 2011 01:52 schrieb Micha Ruh gnub...@gmail.com: 2011/2/13 M∡rtin Koppenhoefer dieterdre...@gmail.com Das ist wohl ein way, der soweit ich die tags richtig interpretiere, bezeichnet, wo man Yahoo-Bilder in hires (was immer das heissen soll) finden kann. Fast richtig. Es bezeichnet, dass viele OSM-Daten innerhalb des ways von Yahoo Bilder abstammen (Wälder/Häuser), welche bis z17 vorhanden sind. woher die OSM-Daten dort stammen, kann man nur mutmaßen, vielleicht hat sie ja auch ein Mapper erhoben, indem er die Waldränder abgelaufen ist? Oder von selbstgemachten Luftbildern? Oder von einer anderen Quelle, die Dir nicht bekannt ist, die man aber legal nutzen darf? Ausserhalb des ways stammen die Wälder, falls vorhanden, von z13 Landsat-Satellitenbildern ab. auch das reine Mutmaßungen, die zwar evtl. zutreffen könnten, wo die Info aber IMHO besser im Changesetkommentar, zur Not als source am Way untergebracht werden sollte. Zu allem Überfluss ist der verlinkte Way (mittlerweile immerhin in der 10. Version) inzwischen mit unseren Geodaten (z.B. einem Track und einem Fluss sowie der Schweiz-relation) verwoben, obwohl es da kaum Bezüge geben dürfte. Jetzt nicht mehr. Relationen mit mehr als 50 Members machen keinen Sinn und sollten verboten sein. da steht bei mir immer noch: Part of: Relation Switzerland (215921) (as Bern) Diese Daten haben m.E. auch keine besonders lange Halbwertszeit, da Yahoo jederzeit die zugrundeliegenden Rasterdaten aktualisieren kann. 1,5 Jahre und immernoch gültig. was ist noch gültig? Dass es dort Yahoo-Bilder mit Z17 gibt? Für eine erste Einschätzung und Übersicht über die Qualität von den in OSM erfassten Daten sind solche ways äusserst hilfreich, -1. Dazu reicht m.E. ein Blick auf die Karte, ggf. mit einem guten Luftbild drunter. oder weisst Du warum hier die Karte leer ist? http://www.openstreetmap.org/?lat=45.8445lon=9.zoom=15 weil dort noch niemand Daten eingetragen hat, oder weil sie zwischenzeitlich jemand wieder gelöscht hat. Dazu brauche ich aber keine Ways, das sehe ich auch so. TL;DR: Eigentlich unschön aber wichtige Mapper Hilfe. -1. Eine Mapper-Hilfe sind gute Luftbilder, Informationen darüber, wo es welche gibt schon deutlich weniger, auf keinen Fall gehören solche Sachen m.E. in die OSM-Datenbank. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mappen von (Nicht-)Geodaten
Am 14. Februar 2011 10:30 schrieb Peter Wendorff wendo...@uni-paderborn.de: Relationen mit mehr als 50 Members machen keinen Sinn und sollten verboten sein. -1 kann ich so grundsätzlich nicht unterschreiben. Relationen, die nur sammeln, sollten verboten werden; das hat aber mit der Anzahl der Elemente nichts zu tun. Eine Bahnlinie aufzusplitten in mehrere Relationen, NUR weil sie mehr als 50 Elemente umfasst, ist Blödsinn; und ich würde selbiges für alle Relationen annehmen: Wenn die Relation sinnvoll ist, ist dies unabhängig von der Zahl der Elemente. ja, im Prinzip hast Du Recht, wobei es ein paar Auswüchse gibt, die beim Mappen stören, z.B. Europastraßen, die tausende von Kilometern lang sind, und wo es beim Editieren dann oft Konflikte gibt. Wenn ich hier in Italien eine Hauptstraße editiere und dann einen Konflikt bekomme, weil ein anderer gerade in Finnland dieselbe Straße editiert hat, dann ist das ein gutes Anzeichen dafür, dass man so was lieber anders organisieren sollte. Lieber kürzere Relationen (z.B. national) und diese dann mit einer Sammelrelation wieder zusammenführen. 50 Elemente sind allerdings deutlich zu wenig, schon ein kleinerer Wald, der sorgfältig gemappt ist (MP-Relation) kommt auf mehr Member. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki und Wikipedie
Hallo Sven, Bei meiner Arbeit in Kursen für OSM-Neulinge erfahre ich aus erster Hand viel über deren Schwierigkeiten. Ich glaube nicht, dass es so arg zielführend ist OSM Neulingen Details über Projektionen, Koordinatensysteme und Ellipsoide zu erzählen. *lach* - denen erzähle ich nur, dass die Erde eine Kartoffel ist, und den Fortgeschrittenen erzähle ich, dass wir noch keine Höhen darstellen, bzw. nur die SRTM-Daten als grober Layer, und vielleicht noch etwas über den Unterschied zwischen Geoid und Ellipsoid. Aber für Menschen die etwas über EPSG-Code wissen möchten, ware es halt schon schön, wenn es in WP einen tollen Artikel dazu gäbe. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki und Wikipedie
Am 14. Februar 2011 13:01 schrieb Markus liste12a4...@gmx.de: Aber für Menschen die etwas über EPSG-Code wissen möchten, ware es halt schon schön, wenn es in WP einen tollen Artikel dazu gäbe. Gibt es doch: http://de.wikipedia.org/wiki/European_Petroleum_Survey_Group_Geodesy ich habe dort den (AFAIK) Fehler wieder rausgenommen, dass OSM EPSG 3395 benutze, und den anderen Fehler mal drin gelassen, Google sei EPSG 900913, das ist nämlich eigentlich gar kein EPSG-Code, sondern leetspeech für Google. Die Korrekturen werden allerdings erst dann allen Benutzern angezeigt werden, wenn ein Experte sie gesichtet hat, bis dahin sind die Fehler in der vom Experten gesichteten Version als bestätigt drin ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wo aktuelle Garmin Karten für DE?
On Mon, Feb 14, 2011 at 10:20:49AM +, Sven Geggus wrote: Andreas Tille andr...@an3as.eu wrote: Irgendwie habe ich den Eindruck, daß derzeit die Kartenerzeugung nicht so gut funktioniert und ich denke, daß es wichtig wäre, eine Standardkarte, die immer funktioniert und mindestens wöchentlich aktualisiert wird anzubieten. Irgendwie habe ich den Eindruck daß ich das Anspruchsdenken Deinerseits nicht nachvollziehen kann. Das erweckt in mir wiederum den Eindruck, daß ich meine Zeit damit zubringen soll, im Gelände Dinge zu erfassen, die zwar schon in der Datenbank sind, aber wegen veralteter Karten vor Ort noch nicht als gemappt erkennbar sind. Bitte schlag mal eine korrekte, für niemanden mißverständliche Formulierung vor, die aktuelle Karten auch als Arbeitsmittel ansieht und nicht bloß wie Freibier-Download aufgefaßt wird. Ich würde sie bei nächster Gelegenheit dann wählen, um niemanden zu verletzen. Eine Garminkarte dauernd neu zu rechnen und aktuell zu halten ist nicht ganz einfach. Gerade weil unsere Datenmenge stark wächst. Sicher. Ich würde ja nur gerne gewußt haben, warum etwas, was letztes Jahr noch täglich erfolgte jetzt nicht mal mehr zuverlässig wöchentlich passiert. So doof war meine Anfrage (mal abgesehen von der Formulierung ja wohl auch nicht, denn es kam ja schließlich der Hinweis auf die tägliche Karte). Wahrscheinlich sollte diese etwas prominenter verlinkt werden. Viele Grüße und danke für die restlichen Hinweise Andreas. -- http://fam-tille.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)
Am 14.02.2011 01:40, schrieb Frederik Ramm: Hallo, Stephan Wolff wrote: Wollte man Osmarender beibringen, Einheiten bei width auszuwerten, müsste man das Programm ergänzen und an hunderte Teilnehmer verteilen. Für Mapnik sind unhandliche Umrechnungen nötig. Bei Datenbankabfragen (etwa nach den 100 leistungsstärksten Kraftwerken) vervielfacht sich der Aufwand. Diese Regeln müssen für jede Auswertung erneut durchlaufen werden. Der Aufwand ist nicht klein und wird wohl meist unterbleiben. Es ist trotzdem nicht akzeptabel, diese Arbeit den Mappern aufzubuerden, egal wie trivial die Umrechnung ist. Da bin ich ein ziemlicher Hardliner - nur weil irgendein Programmierer es nicht hinkriegt, die Daten richtig auszuwerten, darf es fuer den Mapper nicht schwieriger werden. Ich bin auch hartnäckig und opfere für die Antwort sogar einen Teil meiner Mittagspause. :-) Ein Komma zu verschieben ist keine Arbeit. Ein Label/Tooltip im Editor Breite in m versteht jeder Mapper. Ein Label Breite, bei dem nur im Wiki erklärt ist, welche Zahlen und Einheiten in welcher Formatierung erlaubt sind, kostet mehr Zeit. Wir muten den Mappern an anderer Stelle zuviel zu. Wenn ein Mapper einen Weg teilt, der zufällig zu einer Relation gehört, dann muss er den Aufbau dieser Relation erlernen, um sie ggf. zu reparieren. Würden wir festlegen, dass man die Elemente jeder Relation teilen darf (dann hätte eine Abbiegerelation evtl. mehrere from und to Elemente), wäre das eine echte Erleichterung für die Mapper. Auch eine Editor-Unterstuetzung hilft uns hier nicht, denn der Mapper wuerde width=700cm eingeben, der Editor das auf 7m umrechnen, und der Mapper sich dann beim naechsten wundern, wieso seine Angabe nicht richtig ankam. Wenn der Editor für das Feld Breite in m nur Zahlen erlaubt, macht der Mapper keine Fehler und alle Programme werten die Angabe richtig aus. Wenn er width=700cm bei einem Fluss einträgt und Osmarender einen 700m breiten See malt, ein anderes Tool die Textausgabe Flussbreite : 700cm m macht oder der Editor beim Zusammenfügen die Angabe width=700cm; 7 erzeugt, ist der Mapper verwirrt. Nicht allen Mappern gelingt es, ein Gebiet exklusiv zu bearbeiten. Sobald man mit anderen gemeinsam arbeitet, kann man seine bevorzugte Einheit ohnehin nicht durchsetzten, sondern müsste zwischen allen verwendeten Angaben umrechnen. Ein Standard erleichtert die Zusammenarbeit. (Noch schlimmer bei Einheiten, bei denen nicht einfach der Dezimalpunkt verschoben wird.) Dann werden die Vorteile der einheitlichen Angabe noch deutlicher. Besser ich zwinge einen Mapper, seine Angabe von Seemeile, yard, Landmeile oder fathom in Meter umzurechnen (Wolfram Alpha: 8 fathom in m - 14.63 meters), als alle Mapper und alle Anwender mit diesen Einheiten zu belasten. Und an hunderte Teilnehmer verteilen, was meinst Du damit? Bei Osmarender muss eine angepasste Version an alle Teilnehmer verteilt werden, bis eine neue Schreibweise zur korrekten Kartendarstellung führt. Wahrscheinlich hätten wir dauerhaft eine defekte Karte, weil der Mapper auf der Zulässigkeit seiner Einheit besteht und niemand den Renderer anpassen will. Ein Validator kann einfacher auf Zahl als auf Zahl mit zulässiger Einheit testen. Falsche Zahlen kann ein Validator nie erkennen. Eine Einheit mitzuführen bringt keinen Vorteil. Da bin ich aber entschieden anderer Ansicht. Zu den Möglichkeiten des Validators oder zu anderen Vorteilen wählbarer Einheiten? Hat ein Mensch einen Vorteil, wenn das selbe Modell einer Windmühle einmal mit generator:output:electricity=100 kW und ein anderes Mal als generator:output:electricity=0.1 MW beschrieben wird? Mir wäre generator:output:electricity=0.1 mit der eindeutigen Definition Werte in MW lieber. Deshalb sollst Du ein Tool nutzen, das Dir die Daten so umbaut, wie sie Dir am liebsten sind. Jemand anders will vielleicht fuer schnelles Rendering die Generatoren in 3 Groessenklassen unterteilen und will gar keine konkrete Zahl mehr, sondern nur noch small,medium,large. Jemand drittes hat eine Software, die mit Kommazahlen nicht so gut umgehen kann und haette gern alles in vollen Watt. Deine Herangehensweise wuerde bedeuten, dass ihr Euch alle auf eine Loesung einigen muesst - wenn statdessen jeder nimmt, was er kriegt, und es geeignet umwandelt, gibt es diesen laestigen Abstimmungsbedarf (der aufd em Ruecken der Mapper ausgetragen wird) nicht. Jeder der drei Anwender würde von einer Zahlenangabe in MW profitieren. Für den ersten vereinfacht sich das Umrechnungstool, der andere kann die Zahl ohne Vorverarbeitung nutzen. Der Mapper spart drei Zeichen und kann sich an der sinnvollen Nutzung seiner Daten erfreuen. Viele Grüße, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wo aktuelle Garmin Karten für DE?
Andreas Tille andr...@an3as.eu wrote: Bitte schlag mal eine korrekte, für niemanden mißverständliche Formulierung vor, die aktuelle Karten auch als Arbeitsmittel ansieht und nicht bloß wie Freibier-Download aufgefaßt wird. Ich würde sie bei nächster Gelegenheit dann wählen, um niemanden zu verletzen. Es geht hier nicht um Formulierungen! Es geht darum, dass die Macher der Garminkarten ganz explizit Helfer brauchen und dass es niemandem hilft hier rumzuheulen. Siehe auch das Posting von Christoph hier vor einigen Wochen. Dass gerade Karten wie die AIO auch für Mapper sehr nützlich sind hat hier niemand bezweifelt. Sven -- Whenever there is a conflict between human rights and property rights, human rights must prevail. (Abraham Lincoln) /me is giggls@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] Wiki und Wikipedie
M∡rtin Koppenhoefer dieterdre...@gmail.com wrote: Gibt es doch: http://de.wikipedia.org/wiki/European_Petroleum_Survey_Group_Geodesy ich habe dort den (AFAIK) Fehler wieder rausgenommen, dass OSM EPSG 3395 benutze, und den anderen Fehler mal drin gelassen, Google sei EPSG 900913, das ist nämlich eigentlich gar kein EPSG-Code, sondern leetspeech für Google. OSM verwendet WGS84 (EPSG:4326) Die Spherical Merkator Projektion (auch Google Merkator) hat inzwischen auch eine offizielle Nummer, die aber kaum jemand verwendet: EPSG:3785 http://docs.openlayers.org/library/spherical_mercator.html Gruss Sven -- Kernel panic: I have no root and I want to scream (Linux Kernel Error Message) /me is giggls@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] Wiki und Wikipedie
Am 14. Februar 2011 15:13 schrieb Sven Geggus li...@fuchsschwanzdomain.de: OSM verwendet WGS84 (EPSG:4326) ja, so hatte ich das auf der entspr. Wikipediaseite auch vermerkt. Die Spherical Merkator Projektion (auch Google Merkator) hat inzwischen auch eine offizielle Nummer, die aber kaum jemand verwendet: EPSG:3785 ja, wobei die EPSG dazu sagt: not valid (was immer das heissen soll, der Name dazu ist: Popular Visualisation CRS / Mercator) Die haben auch noch eine andere Nummer (3857) die ähnlich ist (und valid gem. EPSG, Name WGS84 / Pseudo-Mercator), aber die verwendet ein Ellipsoid mit inv. flattening und kein Spheroid... Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)
Am 14.02.2011 14:45, schrieb Stephan Wolff: Nicht allen Mappern gelingt es, ein Gebiet exklusiv zu bearbeiten. Sobald man mit anderen gemeinsam arbeitet, kann man seine bevorzugte Einheit ohnehin nicht durchsetzten, sondern müsste zwischen allen verwendeten Angaben umrechnen. Ein Standard erleichtert die Zusammenarbeit. Jetzt müssen wir aber mal klarstellen, worüber wir reden: Werte, die abgelesen werden (z.B. von einem Schild) oder vom Mapper selbst gemessene Werte? Bei ersteren verwende ich einen ganz einfachen Standard: Das Schild gibt die Einheit vor, eine Umrechnung durch den Mapper findet nicht statt. Das betrifft Schlüssel wie maxspeed, maxheight, maxwidth, maxweight und so weiter. Das ist schon dann sinnvoll, wenn der nächste Mapper, der mit seinem Mobileditor vorbeispaziert, den Wert aus den Daten direkt mit dem auf dem Schild vergleichen und so nachprüfen kann. Da solche Schilder üblicherweise gewissen Reglements unterliegen, wird man auf diese Weise auch nur mit einem beschränkten Satz vernünftiger Einheiten konfrontiert, die keinen Auswerter überfordern sollten. Selbst gemessene Werte sind natürlich etwas anders gelagert, denn dort gibt es on the ground keinen Anhaltspunkt für die Wahl der Einheit. Missverständnisse vermeiden kann eine explizit angegebene Einheit dort aber sehr wohl. (Noch schlimmer bei Einheiten, bei denen nicht einfach der Dezimalpunkt verschoben wird.) Dann werden die Vorteile der einheitlichen Angabe noch deutlicher. Besser ich zwinge einen Mapper, seine Angabe von Seemeile, yard, Landmeile oder fathom in Meter umzurechnen (Wolfram Alpha: 8 fathom in m - 14.63 meters), als alle Mapper und alle Anwender mit diesen Einheiten zu belasten. Da werden eher die Vorteile von Einheiten wie ausgeschildert noch deutlicher, denn eine standardisierte Einheit würde nicht nur denjenigen, der sie einträgt, zum Umrechnen zwingen, sondern auch jeden, der sie später nachprüfen will. Bei Verwendung einer ausgeschilderten Einheit muss nur einer umrechnen: Die Software, die irgendetwas aus der Angabe berechnen will. Aber da hier nur pro Einheit - statt pro Objekt, das die Einheit verwendet - menschliche Arbeitskraft gefordert ist, kann ich damit gut leben. Gruß, Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Höhe umrechnen
In DE bekommt man Höhen meist mit der Angabe müM, NN oder NHN. Wie rechnet man das genau in unser Höhensystem um? Gruss, Markus PS: Welches ist unser Höhensystem? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin BaseCamp Version 3.1.4 (MAC OS) und OSM Karten
Sorry, Es ist natürlich eine GARMIN Software und sicherlich nicht die Beste auch wenn sie einige gute Gimiks enthält. Ja ich bekomme alles was ich brauche auch auf anderen Wegen hin, es ist nur machmal reichlich zeitaufwendig und manches wäre mit BaseCamp eigentlich ganz komfortabel zu lösen. ich weiß auch dass QlandkarteGT und MacCaching einige Funktionen besser beherrschen als Garmin BaseCamp ( falls du es nicht kennst, hier kannst du es laden: http://www8.garmin.com/support/download_details.jsp?id=4450 ) Base Camp hätte vor allem einen großen Vorteil gegenüber den anderen Applikationen, dass die Poi- und Trackverwaltung mit den GARMIN Navis sehr problemlos und vor allen schnell funktionieren kann. Leider ist die Basis Kart wie gesagt uralt und solange die OSM Karte in BaseCamp nicht angezeigt wird, ist das eigentlich recht attraktive Programm so nicht sinnvoll. Am 14.02.2011 um 00:42 schrieb Wolfgang: Hallo, Am Sonntag 13 Februar 2011 15:10:21 schrieb UMAX974: Hallo Liste, Dem nun folgenden Schweigen auf meine Anfrage entnehme ich, dass ihr alle mit de GarminBaseCamp - so ihr es verwendet - keine Probleme habt. Wenn das so ist, würde mich interessieren, ob es etwas gibt, was ihr in eurem workflow anders macht als ich! Könnt ihr mir darauf mal eine Rückmeldung geben? Ganz einfach: Ich weiß nicht mal, was dieses base camp ist :-) Ich gehe mal davon aus, das es sich um die leider übliche Garmin-Windows- Klicki-SW handelt, die man nur mühsam zur Mitarbeit überreden kann und eher nicht braucht. Ich installiere alle Karten direkt im Navi bzw. auf der SD- Karte und habe damit eigentlich keine Probleme. Gruß, Wolfgang ___ 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öhe umrechnen
Markus schrieb am 14.02.2011 16:45: In DE bekommt man Höhen meist mit der Angabe müM, NN oder NHN. Wie rechnet man das genau in unser Höhensystem um? Gruss, Markus PS: Welches ist unser Höhensystem? Unsere lat-lon-Daten beruhen ja auf den WGS84 Koordinaten. Die Hoehen auf das entsprechende Ellipsoid zu beziehen, ist wenig sinnvoll, da voellig praxisfern (nirgendwo werden Ellipsoidhoehen benutzt). Neben dem Ellipsoid gibt es verschiedene Geoid-Modelle, die leider normalerweise nicht frei sind (so dass man auch nicht einfach vom Ellipsoid auf ein Geoid umrechnen kann). Die gute Nachricht ist aber, dass die verschiedenen Geoid-Modelle sich nur wenig voneinander unterscheiden, ueblicherweise sind die Unterschiede deutlich geringe als unsere Messgenauigkeit. Insofern kann man sich das umrechnen gleichsparen. Wenn du eine Hoehenangabe in die Datenbank eintraegst, ist es zu 99,9% egal, ob das nun NN oder NHN oder was auch immer ist. So genau kann man das selber sowieso nicht messen, und auch irgendwelche Angaben auf Schildern sind i.A. eher nicht so genau. Wenn du bei einem Hoehenwert ganz sicher bist (ein ordentlich vermessener Punkt), dann trage das zugrundeliegende System einfach als zusaetzliche Information in die Datenbank ein. (Die ueblichen Tags habe ich gerade nicht vorliegen, sollten sich aber im Wiki finden.) Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin BaseCamp Version 3.1.4 (MAC OS) und OSM Karten
Hallo, Am Montag 14 Februar 2011 16:45:10 schrieb UMAX974: Sorry, Es ist natürlich eine GARMIN Software und sicherlich nicht die Beste auch wenn sie einige gute Gimiks enthält. Ja ich bekomme alles was ich brauche auch auf anderen Wegen hin, es ist nur machmal reichlich zeitaufwendig und manches wäre mit BaseCamp eigentlich ganz komfortabel zu lösen. ich weiß auch dass QlandkarteGT und MacCaching einige Funktionen besser beherrschen als Garmin BaseCamp ( falls du es nicht kennst, hier kannst du es laden: http://www8.garmin.com/support/download_details.jsp?id=4450 ) Ich kann es laden, aber läuft es mit wine? Garmin sitzt auf dem hohen Ross und unterstützt Windows und eingeschänkt Apple. Wobei die entsprechenden Garmin- Geräte von Kunden gekauft werden, die relativ technik-affin sind und daher zu einem großen Teil Systeme aus dem Linux-Umfeld einsetzen. Das geht solange gut, bis es ein System für GPS-Geräte gibt, dass das Linux-Umfeld unterstützt... Base Camp hätte vor allem einen großen Vorteil gegenüber den anderen Applikationen, dass die Poi- und Trackverwaltung mit den GARMIN Navis sehr problemlos und vor allen schnell funktionieren kann. Da kann ich nur zum Colorado etwas sagen, und gerade da ist das mit den Linux- Bordmitteln recht einfach. Zusätzlich hat man noch eine komplette Datensicherung für das GPS incl. aller Einstellungen. Aufwändig ist noch das (massenweise) Löschen von Waypoints, da muss ich nocht etwas wühlen. Hardreset und Datensicherung sind nicht so der Weisheit letzter Schluss. Leider ist die Basis Kart wie gesagt uralt und solange die OSM Karte in BaseCamp nicht angezeigt wird, ist das eigentlich recht attraktive Programm so nicht sinnvoll. so richtig attraktiv wäre kompatibel... Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki und Wikipedie
M∡rtin Koppenhoefer schrieb am 14.02.2011 15:23: Die Spherical Merkator Projektion (auch Google Merkator) hat inzwischen auch eine offizielle Nummer, die aber kaum jemand verwendet: EPSG:3785 ja, wobei die EPSG dazu sagt: not valid (was immer das heissen soll, der Name dazu ist: Popular Visualisation CRS / Mercator) .. heisst, da hat man Unsinn verzapft und den Eintrag wieder zurückgezogen. Stattdessen gibt es seit geraumer Zeit EPSG::3857 - der Unterschied ist hierbei, dass ersteres fälschlicherweise eine Kugel als Referenzellipsoid und letzteres das richtige WGS84 verwendet. Die haben auch noch eine andere Nummer (3857) die ähnlich ist (und valid gem. EPSG, Name WGS84 / Pseudo-Mercator), aber die verwendet ein Ellipsoid mit inv. flattening und kein Spheroid... Jep, die Koordinaten beziehen sich ja weiterhin auf WGS84 nur die Projektion ist halt auf eine Kugel. PS: der Artikel in der WP droht irgendwie grad in Richtung Deutschland/OSM umzukippen. Die Sammlung Wichtigste Codes in Europa ..das sehen Österreicher, Franzosen, Schweizer etc pp sicher etwas anders. Ich weiß nicht, ob es viel Sinn macht, so eine Liste als bunten Strauß diverser EPSG-Codes aufzumachen. Da hat ohnehin jedes Grüppchen ihre EPSG-Codes, die für sie total wichtig sind. Die vollständige Liste zum nachrecherchieren findet man ja auch im Internet. Ich fänd es aus Wiki-Sicht interessanter, mal ein paar Hintergründe zur Entwicklung zu beleuchten. zB die krampfhaften Zugeständnisse an das Webmapping und die Besonderheit des Google-ESPG-Codes sind sicher erwähnenswert. Meine bescheidene Meinung. Grüße, Alex -- http://de.wikipedia.org/wiki/Benutzer:Alexrk2 http://de.wikipedia.org/wiki/Wikipedia:Kartenwerkstatt/Blog ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Südpol im Atlantik
Markus schrieb am 14.02.2011 00:00: Interessant: Strahlenförmige Ländergrenzen, und beim Reinzoomen erscheint Südpol... http://www.openstreetmap.org/?lat=-0.09lon=0.32zoom=6layers=M http://www.openstreetmap.org/?lat=-90lon=0zoom=6layers=M ... da der Permalink für den Südpol ebenfalls auf 0,0 verlinkt, passt es ja auch irgendwie wieder. Sicher eine pragmatische Lösung, den Südpol einfach im Atlantik einzuzeichnen ;) Und laut OSM-Karte in Wikipedia[1] liegt der Südpol schließlich ebenfalls bei 0,0 Alex [1] http://de.wikipedia.org/wiki/Südpol -- http://de.wikipedia.org/wiki/Benutzer:Alexrk2 http://de.wikipedia.org/wiki/Wikipedia:Kartenwerkstatt/Blog ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki und Wikipedie
Am 14. Februar 2011 18:11 schrieb Alexrk alex...@yahoo.de: PS: der Artikel in der WP droht irgendwie grad in Richtung Deutschland/OSM umzukippen. Die Sammlung Wichtigste Codes in Europa ..das sehen Österreicher, Franzosen, Schweizer etc pp sicher etwas anders. +1, ich wollte mich nicht soweit da einmischen, habe daher nur die offensichtlichen Fehler rausgenommen, aber es stimmt sicherlich, dass man nicht von den wichtigsten Codes in Europa faseln kann, ohne überhaupt die Kriterien dafür offen zu legen. OSM, Google und GPS ist darüberhinaus ja nicht auf Europa beschränkt. findet man ja auch im Internet. Ich fänd es aus Wiki-Sicht interessanter, mal ein paar Hintergründe zur Entwicklung zu beleuchten. zB die krampfhaften Zugeständnisse an das Webmapping und die Besonderheit des Google-ESPG-Codes sind sicher erwähnenswert. Meine bescheidene Meinung. ja, wobei der Google-Code wohl 3785 ist, jedenfalls nicht 3857 und 900913 gibt es bei EPSG gar nicht (die ja die Hochheit darüber hat, was ein EPSG-code ist und was nicht). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki und Wikipedie
Die Experten von der Wikipedia haben meine Änderungen übrigens abgelehnt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wo aktuelle Garmin Karten für DE?
On Mon, Feb 14, 2011 at 02:09:42PM +, Sven Geggus wrote: Es geht hier nicht um Formulierungen! Es geht darum, dass die Macher der Garminkarten ganz explizit Helfer brauchen und dass es niemandem hilft hier rumzuheulen. 1. Ich arbeite seit 15 Jahren in Open Source Projekten mit und lasse mir ungern von jemandem Anspruchsdenken / rumheulen vorwerfen. 2. Ich weiß, daß in jedem Projekt für verschiedene Aufgaben Helfer gesucht werden. 3. Ich weiß auch, daß durch unnötige Vorwürfe keine zusätzlichen Helfer gewonnen werden. 4. Weitere unflätige Mails beantworte ich nicht. Ich halte eine Information an leicht zu findender Stelle für angemessen, wenn ein Dienst der früher mal zur Verfügung stand für längere ( 2 Wochen) Zeit / unvorherbar lange Zeit nicht mehr zur Verfügung steht. Ein Mangel an Information schadet dem Projekt, weil Neulinge eventuell abgeschreckt werden. Meine Mail diente dazu herauszufinden, ob ich nur eine offensichtliche Information verpaßt habe oder ob sie wirklich fehlt. Viele Grüße Andreas. -- http://fam-tille.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki und Wikipedie
Hallo Martin, Die Experten von der Wikipedia haben meine Änderungen übrigens abgelehnt. ? Du hast drei Änderungen hochgeladen, die letzte Version wurde gesichtet und ist online. Wenn Du öfter schreibst, sind Deine Beiträge automatisch gesichtet. Sichten ist nur ein Schutz gegen Kinderscherze (keine inhaltliche Prüfung). Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wo aktuelle Garmin Karten für DE?
Hallo, On Sat, 12 Feb 2011 14:09:19 +0100, Henning Scholland o...@aighes.de wrote: Wie lange es mit der OpenMTB noch dauert, kann ich dir nicht sagen. Felix sucht gerade einen neuen Server (siehe OSM-Forum). Das Server-Problem wurde inzwischen gelöst. Die Downloads sind also wieder verfügbar. Mitja ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki und Wikipedie
Am 14. Februar 2011 18:59 schrieb Markus liste12a4...@gmx.de: Die Experten von der Wikipedia haben meine Änderungen übrigens abgelehnt. Du hast drei Änderungen hochgeladen, die letzte Version wurde gesichtet und ist online. ja, das war wohl ein Caching-Problem. Die offenen Fehler sind wohl jetzt raus (Google Earth nutzt glaub auch nicht die 900913, die haben ja eine 3D-Kugel, sondern Google-Maps). Wenn Du öfter schreibst, sind Deine Beiträge automatisch gesichtet. Sichten ist nur ein Schutz gegen Kinderscherze (keine inhaltliche Prüfung). habe meinen Login vergessen, und beim Anfordern eines neuen Passworts gabs ein technisches Problem. Ich habe auch eher keine Lust auf Anmelden, wenn ich einen Fehler finde, dann korrigiere ich den, auch Kleinigkeiten wie Orthographie oder Grammatik, und wenn es sein muss, dann kann das ja jemand sichten. Einen User habe ich nur mal angelegt, um ein Banner anzubringen... http://de.wikipedia.org/wiki/Benutzer:Dieterdreist Habe jetzt nochmal ein bisschen auf der Seite rumeditiert, aber so richtig toll finde ich das Ergebnis immer noch nicht... Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wo aktuelle Garmin Karten für DE?
On Mon, Feb 14, 2011 at 07:13:00PM +0100, Mitja Kleider wrote: Wie lange es mit der OpenMTB noch dauert, kann ich dir nicht sagen. Felix sucht gerade einen neuen Server (siehe OSM-Forum). Das Server-Problem wurde inzwischen gelöst. Die Downloads sind also wieder verfügbar. Ahh, super. Danke für die Info. Bedanken darf man sich wohl auch bei der GWDG (die Karten sind ja umgezogen ...) Viele Grüße Andreas. -- http://fam-tille.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)
Moin! Am 14.02.2011 15:24, schrieb Tobias Knerr: Am 14.02.2011 14:45, schrieb Stephan Wolff: Nicht allen Mappern gelingt es, ein Gebiet exklusiv zu bearbeiten. Sobald man mit anderen gemeinsam arbeitet, kann man seine bevorzugte Einheit ohnehin nicht durchsetzten, sondern müsste zwischen allen verwendeten Angaben umrechnen. Ein Standard erleichtert die Zusammenarbeit. Jetzt müssen wir aber mal klarstellen, worüber wir reden: Werte, die abgelesen werden (z.B. von einem Schild) oder vom Mapper selbst gemessene Werte? Ursprünglich ging es um die Angabe von elektrischer Leistung bei BHKW. Eine Angabe von zwei Megawatt darf gemäß Vorschlag im Wiki beliebig als 200 W, 2000 kW, 2 MW oder 0.002 GW geschrieben werden. Dies hatte ich kritisiert. Die Diskussion weitete sich auf andere geschätzte, berechnete oder gemessene Größen aus. Bei Schildern oder amtlich festgelegten Grenzen würde ich auch die offizielle Einheit verwenden. Damit hat man innerhalb eines Staates meist einheitliche Werte und auch weltweit nur wenige Sonderfälle. Viele Grüße, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wo aktuelle Garmin Karten für DE?
On 14.02.2011 18:35, Andreas Tille wrote: Ich halte eine Information an leicht zu findender Stelle für angemessen, wenn ein Dienst der früher mal zur Verfügung stand für längere ( 2 Wochen) Zeit / unvorherbar lange Zeit nicht mehr zur Verfügung steht. Ein Mangel an Information schadet dem Projekt, weil Neulinge eventuell abgeschreckt werden. Meine Mail diente dazu herauszufinden, ob ich nur eine offensichtliche Information verpaßt habe oder ob sie wirklich fehlt. Du bist schon irgendwie blind, oder? Seit 8. Feber gepublished. Hatte vorher auch schon in Comments über die Situation geschrieben, dass Domainbox scheinbar nicht mehr in der Lage war den Traffic zu sponsern. http://openmtbmap.org/updates/enopenmtbmap-download-server-background-deopenmtbmap-download-server-nicht-erreichbar/ bzw am 12.2: http://openmtbmap.org/updates/enmaps-online-yehaa-fully-working-address-search-de-karten-bald-wieder-online-und-erstmals-mit-voll-funktionierender-addressuche/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wo aktuelle Garmin Karten für DE?
Hallo, Merkt ihr eigentlich nicht, dass der Ton hier so nicht passt UMAX974 Am 14.02.2011 um 19:35 schrieb Felix Hartmann: On 14.02.2011 18:35, Andreas Tille wrote: Ich halte eine Information an leicht zu findender Stelle für angemessen, wenn ein Dienst der früher mal zur Verfügung stand für längere ( 2 Wochen) Zeit / unvorherbar lange Zeit nicht mehr zur Verfügung steht. Ein Mangel an Information schadet dem Projekt, weil Neulinge eventuell abgeschreckt werden. Meine Mail diente dazu herauszufinden, ob ich nur eine offensichtliche Information verpaßt habe oder ob sie wirklich fehlt. Du bist schon irgendwie blind, oder? Seit 8. Feber gepublished. Hatte vorher auch schon in Comments über die Situation geschrieben, dass Domainbox scheinbar nicht mehr in der Lage war den Traffic zu sponsern. http://openmtbmap.org/updates/enopenmtbmap-download-server-background-deopenmtbmap-download-server-nicht-erreichbar/ bzw am 12.2: http://openmtbmap.org/updates/enmaps-online-yehaa-fully-working-address-search-de-karten-bald-wieder-online-und-erstmals-mit-voll-funktionierender-addressuche/ ___ 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] Werte in OSM besser ohne Einheit (war: BHKW)
Hallo, Stephan Wolff wrote: Wir muten den Mappern an anderer Stelle zuviel zu. Wenn ein Mapper einen Weg teilt, der zufällig zu einer Relation gehört, dann muss er den Aufbau dieser Relation erlernen, um sie ggf. zu reparieren. Würden wir festlegen, dass man die Elemente jeder Relation teilen darf (dann hätte eine Abbiegerelation evtl. mehrere from und to Elemente), wäre das eine echte Erleichterung für die Mapper. Das hatten wir neulich schonmal - nur, weil anderswo etwas laestig ist, ist das keine Lizenz, neue laestige Sachen einzufuehren. Wenn der Editor für das Feld Breite in m nur Zahlen erlaubt, macht der Mapper keine Fehler und alle Programme werten die Angabe richtig aus. Wenn er width=700cm bei einem Fluss einträgt und Osmarender einen 700m breiten See malt, ein anderes Tool die Textausgabe Flussbreite : 700cm m macht oder der Editor beim Zusammenfügen die Angabe width=700cm; 7 erzeugt, ist der Mapper verwirrt. Es gibt bei OSM keine strenge Typisierung von Tags, und ich denke nicht, dass es die jemals geben wird. Du musst Dich von dem Gedanken verabschieden, dass das, was da in England auf dem Server ist, irgendwie eine saubere, leicht auswertbare Datenbank ist oder jemals sein kann. Kein Ausmass an Editorvorschriften und Bots wird dazu fuehren - diese Datenbank wird immer das Rohmaterial sein, aus dem man brauchbare Daten ableiten muss. Nicht allen Mappern gelingt es, ein Gebiet exklusiv zu bearbeiten. Sobald man mit anderen gemeinsam arbeitet, kann man seine bevorzugte Einheit ohnehin nicht durchsetzten, Ja, genau darum geht es, dass jeder seine bevorzugte Einheit verwenden kann, ohne sie durchsetzen zu muessen. Dann werden die Vorteile der einheitlichen Angabe noch deutlicher. Besser ich zwinge einen Mapper, seine Angabe von Seemeile, yard, Landmeile oder fathom in Meter umzurechnen (Wolfram Alpha: 8 fathom in m - 14.63 meters), als alle Mapper und alle Anwender mit diesen Einheiten zu belasten. Das ist etwas, was ganz gewiss nicht passieren wird. Erstens, weil wir keine Seetiefen mappen ;) zweitens wegen (Wolfram Alpha) 14.63 meters in fathoms = 7.9998 fathoms - der englische Mapper hat voellig zu recht den Anspruch, dass aus seinen vom Verkehrsschild abgelesenen 20 mph nicht ploetzlich 19.9997 werden, weil irgendjemand das partout intern in Meter pro Sekunde speichern wollte oder so. Bei Osmarender muss eine angepasste Version an alle Teilnehmer verteilt werden, bis eine neue Schreibweise zur korrekten Kartendarstellung führt. 1. tiles@home ist eh tot, 2. die meisten Tile-Renderer machen eh regelmaessig automatisch ein svn up. Wenn Dein Argument stichhaltig waere, koennte es ja in tiles@home nie irgendwelche Stil-Updates geben. Ein Validator kann einfacher auf Zahl als auf Zahl mit zulässiger Einheit testen. Falsche Zahlen kann ein Validator nie erkennen. Eine Einheit mitzuführen bringt keinen Vorteil. Da bin ich aber entschieden anderer Ansicht. Zu den Möglichkeiten des Validators oder zu anderen Vorteilen wählbarer Einheiten? Dazu, dass die mitgefuehrte Einheit keinen Vorteil bringt. Jeder der drei Anwender würde von einer Zahlenangabe in MW profitieren. Für den ersten vereinfacht sich das Umrechnungstool, der andere kann die Zahl ohne Vorverarbeitung nutzen. Der Mapper spart drei Zeichen und kann sich an der sinnvollen Nutzung seiner Daten erfreuen. Die mitgelieferte Einheit gibt eine groessere Sicherheit bei der Interpretation; die Freiheit des Mappers, die Zahl so eintragen zu koennen, wie er sei in der freien Wildbahn antrifft, ist m.E. hoeher zu bewerten als der Komfort des Programmierers. 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] Höhe umrechnen
Hallo Torsten, Unsere lat-lon-Daten beruhen ja auf den WGS84 Koordinaten. Die Hoehen auf das WGS84 Ellipsoid zu beziehen, ist wenig sinnvoll, Hm - man hätte eine gemeinsame einheitliche Basis. (nirgendwo werden Ellipsoidhoehen benutzt). Auch nicht SRTM? CIGAR? verschiedene Geoid-Modelle, die leider normalerweise nicht frei sind eben - und jedes ist verschieden. Die gute Nachricht ist aber, dass die verschiedenen Geoid-Modelle sich nur wenig voneinander unterscheiden, Hm - man liest von bis 100 m Wenn du bei einem Hoehenwert ganz sicher bist dann trage das zugrundeliegende System einfach als zusaetzliche Information in die Datenbank ein. Ja, es geht um genaue Höhen. Die man als Referenzpunkte nutzen kann. Die bei unterschiedlichen Einheiten oder gar unterschiedlichen Systemen entstehenden Probleme werden grad im anderen Thread diskutiert. Deshalb suche ich nach einem einheitlichen Höhensystem für OSM. Bisher war die OSM-Empfehlung WGS84: http://wiki.openstreetmap.org/wiki/DE:Altitude#Umrechnung_für_Deutschand aber das Webformular für die Umrechnung ist nicht für müM gedacht... Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)
Am 14. Februar 2011 19:30 schrieb Stephan Wolff s.wo...@web.de: Ursprünglich ging es um die Angabe von elektrischer Leistung bei BHKW. Eine Angabe von zwei Megawatt darf gemäß Vorschlag im Wiki beliebig als 200 W, 2000 kW, 2 MW oder 0.002 GW geschrieben werden. Dies hatte ich kritisiert. es geht ja dabei nicht nur um elektrische Leistung sondern auch um Wärme. In der Diskussion hier haben einige Leute sich dafür ausgesprochen, dass man noch weitergehend Einheiten verwenden können soll. Hier wäre es z.B. ja durchaus auch möglich, PS oder Kilokalorien pro Stunde anzugeben. Oder Pondmeter pro Sekunde. Im Prinzip fände ich das auch gar nicht schlecht, die wünsch-dir-was-Version wäre allerdings, man hätte ein von der Community entwickeltes Tool, mit dem man die Daten dann wieder normalisieren kann, so dass auch allen möglichen Einheiten, z.B. gerade auch die nichtmetrischen, in einer (einfach) verwendbaren Form rauskommen. So eine Art universeller Einheiten-Normalisierer, idealerweise gleich als Ergänzung eines bestehenden Tools und mit separaten Einheitendefinitionen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhe umrechnen
Markus schrieb am 14.02.2011 19:46: (nirgendwo werden Ellipsoidhoehen benutzt). Auch nicht SRTM? CIGAR? Auch dort werden die Hoehen ueber dem Geoid angegeben. Die Sache ist ja, dass es nur ein Geoid gibt, die unterschiedlichen Modelle sind halt verschiedene Versuche dieses mathematisch zu beschreiben. Die gute Nachricht ist aber, dass die verschiedenen Geoid-Modelle sich nur wenig voneinander unterscheiden, Hm - man liest von bis 100 m Sicher, dass damit nicht der Unterschied zwischen Geoid und Ellipsoid gemeint ist? Ja, es geht um genaue Höhen. Die man als Referenzpunkte nutzen kann. Und die hast du mit einer entsprechenden genauigkeit in einer kompatiblen Lizenz vorliegen? Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin BaseCamp Version 3.1.4 (MAC OS) und OSM Karten
Am 14.02.2011 17:57, schrieb Wolfgang: ... Ich gehe mal davon aus, das es sich um die leider übliche Garmin-Windows- Klicki-SW handelt, die man nur mühsam zur Mitarbeit überreden kann und eher nicht braucht. ... ... Wobei die entsprechenden Garmin- Geräte von Kunden gekauft werden, die relativ technik-affin sind und daher zu einem großen Teil Systeme aus dem Linux-Umfeld einsetzen. ... ... so richtig attraktiv wäre kompatibel... ... könntest du bitte deinen Missionierungseifer mal etwas eindämmen? Das wird ja langsam lächerlich. @UMAX: Anscheinend gibt es hier leider keinen, der sich mit Base Camp wirklich auskennt. Ich hab es zwar mal probeweise installiert aber verwende es eigentlich nicht. Karten auf das Gerät zu bekommen geht direkter (und aus meiner Sicht einfacher): SD-Karte kaufen, garmin Verzeichnis erzeugen, gmapsupp.img kopieren. Tourenplanung mache ich persönlich mit einer anderen Software Motorrad Tourenplaner. Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin BaseCamp Version 3.1.4 (MAC OS) und OSM Karten
Hallo, so recht kenne ich mich mit gmap und Mac nicht aus. Ich gehe mal davon aus, dass die Karte als gmapsupp auf dem Gerät funktioniert. Passt denn die Größe des gmap-Ordners mit der gmapsupp.img ungefähr überein? Wenn du einen Windows-PC zur Verfügung hast, könntest du das Konvertieren auch mit dem GarminConverter [1] versuchen. Hast du schonmal andere OSM-Karten probiert? Ist das ein generelles Problem? Henning [1] http://www8.garmin.com/support/download_details.jsp?id=3897 Am 11.02.2011 17:08, schrieb UMAX974: Hallo, Aus irgendeinem unerfindlichen Grund bekomme ich die OSM Karten in Garmin BaseCamp nicht zum Laufen. Ich mache folgendes: ich lade von der teddy Seite: deutschland.tgz die wird expandiert dann nutze ich den neuen .gmapi Builder und lasse ihn mit den TDB, img und Typ Files eine OSM_DE.gmapi erstellen dann wird die mit dem Garmin MapManager anstandslos installiert. (Ich hab es inzwischen mit und ohne TYP File probiert, beides ohne Erfolg) Aber: Wenn ich diese Karte in BaseCamp auswähle, dann kann ich zwar gelb sehen welche Abdeckung diese Karte hat, sonst aber nichts... hat jemand eine Idee was ich falsch mache? Gruß UMAX974 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin BaseCamp Version 3.1.4 (MAC OS) und OSM Karten
Danke, mach ich schon lange - mir gehet es um die Nachbearbeitung meiner POI und Tracks am MAC möglichst auf Grundlage der gleich aktuellen OSM Karte, die ich auch im Navi nutze. Ich sehe es ja aufgrund eurer Rückmeldungen ein: QLandkarteGT ist also das Mittel meiner Wahl und die Garmin Software außen vor. Aber danke für die netten ;)) Versuche UMAX974 Am 14.02.2011 um 21:44 schrieb Ulf Lamping: Karten auf das Gerät zu bekommen geht direkter (und aus meiner Sicht einfacher): SD-Karte kaufen, garmin Verzeichnis erzeugen, gmapsupp.img kopieren. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki und Wikipedie
Hallo Martin, kann das ja jemand sichten. Mache ich Dir gern. Schicke mir einfach eine PM. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wo aktuelle Garmin Karten für DE?
http://wiki.openstreetmap.org/wiki/DE:All_in_one_Garmin_Map#Neuigkeiten Zur Info es ist ein Wiki du kannst gerne die Position der Info verändern. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin BaseCamp Version 3.1.4 (MAC OS) und OSM Karten
Am 14.02.2011 22:15, schrieb UMAX974: Danke, mach ich schon lange - mir gehet es um die Nachbearbeitung meiner POI und Tracks am MAC möglichst auf Grundlage der gleich aktuellen OSM Karte, die ich auch im Navi nutze. Ich sehe es ja aufgrund eurer Rückmeldungen ein: QLandkarteGT ist also das Mittel meiner Wahl und die Garmin Software außen vor. Da BaseCamp von Garmin für die zukünftigen Geräte (meines Wissens) stark propagiert wird, schätze ich, das es so nach und nach bei den OSM Karten bessere Unterstützung auch für BaseCamp geben wird (soweit halt für Open Source machbar). Aktuell dürfte QLandkarteGT wahrscheinlich die bessere Wahl sein. Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO fehlt völlig
Ich bin ja schrecklich neugierig... Aber weiß jemand was über den Stand der Dinge zum AIOTM? Gruß UM AX974 Am 07.01.2011 um 20:16 schrieb fla...@googlemail.com: Wartet auf den neuen AIO-Tiles Manager und urteilt nachdem ihr Ihn 4 Wochen benutzt habt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wo aktuelle Garmin Karten für DE?
On Mon, Feb 14, 2011 at 07:35:01PM +0100, Felix Hartmann wrote: bzw am 12.2: http://openmtbmap.org/updates/enmaps-online-yehaa-fully-working-address-search-de-karten-bald-wieder-online-und-erstmals-mit-voll-funktionierender-addressuche/ Also am Date: Sat, 12 Feb 2011 13:49:47 +0100 (module eventueller Browser-Cache) stand da noch: Download server currently offline for maintenance (25.01.2011) Sorry, wenn ich da ein paar Stunden zu ungeduldig war. Ich wurde auch nur deswegen unruhig, weil eben zur gleichen Zeit auch die AOI Karte in einer unvollständigen Version am gewohnten Platz war und ich halt auch die Neuigkeiten im Wiki der AIO nicht so interpretiert hatte, wie das der Schreiber gedacht hatte. Weil der Ton der Antwort auch wieder recht harsch war: *Ich* kann recht gut damit umgehen (wie gesagt bin ich schon zu lange in OS Projekten tätig, um hier den Dünnhäutigen zu spielen). Die Leute, die ich gerade für OSM begeistern möchte, können's nicht. Soll ich aufhören für OSM Werbung zu machen, bis der Ton wieder etwas gepflegter wird und auch durch Neulinge als seriös eingestuft werden kann? In jedem Fall: Danke, daß die OpenMTB Karten wieder da sind Andreas. -- http://fam-tille.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin BaseCamp Version 3.1.4 (MAC OS) und OSM Karten
Ach übrigens - das Problem hat sich plötzlich ganz einfach lösen lassen. In GarminBaseCamp gibt es eine Funktion in den Einstellungen - auf Werkseinstellungen zurücksetzten Hab ich gemacht, nach dem ja nichts zu verlieren war und siehe da, die OSM Karten, sogar die AIO Karten sind jetzt sichtbar, ganz so wie es sein sollte. schönen Abend noch ;) UMAX974 Am 14.02.2011 um 22:31 schrieb Ulf Lamping: Am 14.02.2011 22:15, schrieb UMAX974: Danke, mach ich schon lange - mir gehet es um die Nachbearbeitung meiner POI und Tracks am MAC möglichst auf Grundlage der gleich aktuellen OSM Karte, die ich auch im Navi nutze. Ich sehe es ja aufgrund eurer Rückmeldungen ein: QLandkarteGT ist also das Mittel meiner Wahl und die Garmin Software außen vor. Da BaseCamp von Garmin für die zukünftigen Geräte (meines Wissens) stark propagiert wird, schätze ich, das es so nach und nach bei den OSM Karten bessere Unterstützung auch für BaseCamp geben wird (soweit halt für Open Source machbar). Aktuell dürfte QLandkarteGT wahrscheinlich die bessere Wahl sein. Gruß, ULFL ___ 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] OpenLayers-Frage: Projektionssystem für Punkt?
Am 14.02.2011 22:33, schrieb Johannes Huesing: Ich weiß nicht, wie weit OpenLayers hier OT ist. In diesem Minimalbeispiel erscheint der fünfzackige Stern nicht in dem anfänglichen Kartenausschnitt, sondern am OSM-Südpol: Um genau zu sein am OSM Nullpunkt (Mitte des Äquators, westlich von Afrika). Ich hab ein bisschen rumgespielt aber leider spontan auch keine Lösung gefunden. Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenLayers-Frage: Projektionssystem für Punkt?
hi, so siehts besser aus: var point = new OpenLayers.Geometry.Point(8.718685,48.475637).transform (map.displayProjection, map.projection); gruss walter - 33,33% aller Statistiken beruhen auf kleinen Datenmengen. -- View this message in context: http://gis.638310.n2.nabble.com/OpenLayers-Frage-Projektionssystem-fur-Punkt-tp6025303p6025603.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki und Wikipedia
Am 14.02.2011 18:11, schrieb Alexrk: Ich fänd es aus Wiki-Sicht interessanter, mal ein paar Hintergründe zur Entwicklung zu beleuchten. zB die krampfhaften Zugeständnisse an das Webmapping und die Besonderheit des Google-ESPG-Codes sind sicher erwähnenswert. Da gerät man dann verdammt fix in die Untiefen von Original-Research. Die Suche nach zitierfähigen Quellen wird dort vermutlich länger in Anspruch nehmen als das Abfassen des eigentlichen Textes. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin BaseCamp Version 3.1.4 (MAC OS) und OSM Karten
Am 14.02.2011 22:31, schrieb Ulf Lamping: Da BaseCamp von Garmin für die zukünftigen Geräte (meines Wissens) stark propagiert wird, Oder etwas deutlicher: Mapsource wird die Funktionen neuer Geräte noch weniger unterstützen als jetzt schon. Das was Mapsource vom Gerät lesen kann, das ist jetzt schon bei den aktuellen Oregons/GPSmap sehr, sehr bescheiden. Noch weniger geht eigentlich gar nicht. Dass es hier jedes Mal wenn die Sprache auf Mapsource (oder jetzt Basecamp) kommt mit einer konkreten Benutzungsfrage, die Diskussion dreht auf Warum gibt's das nicht aus für den Mac und Läuft im Wine aber irgendwie nicht: Mag ja sein, hilft nur dem Threadstarter mit an Sicherheit grenzender Wahrscheinlichkeit nicht. Zumal ja bei der Betriebsystemdiskussion auch nie(?) etwas herauskommt. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)
Moin! Am 14.02.2011 19:42, schrieb Frederik Ramm: Stephan Wolff wrote: Wir muten den Mappern an anderer Stelle zuviel zu. Wenn ein Mapper einen Weg teilt, der zufällig zu einer Relation gehört, dann muss er den Aufbau dieser Relation erlernen, um sie ggf. zu reparieren. Würden wir festlegen, dass man die Elemente jeder Relation teilen darf (dann hätte eine Abbiegerelation evtl. mehrere from und to Elemente), wäre das eine echte Erleichterung für die Mapper. Das hatten wir neulich schonmal - nur, weil anderswo etwas laestig ist, ist das keine Lizenz, neue laestige Sachen einzufuehren. Die Umrechnung zwischen metrischen Einheiten ist nicht lästig. Der Mapper spart die dafür verwendete Sekunde wieder ein, da er keine Einheit tippen muss. Die Einarbeitung in unbekannte Relationen kostet dagegen viel Zeit. Wenn der Editor für das Feld Breite in m nur Zahlen erlaubt, macht der Mapper keine Fehler und alle Programme werten die Angabe richtig aus. Wenn er width=700cm bei einem Fluss einträgt und Osmarender einen 700m breiten See malt, ein anderes Tool die Textausgabe Flussbreite : 700cm m macht oder der Editor beim Zusammenfügen die Angabe width=700cm; 7 erzeugt, ist der Mapper verwirrt. Es gibt bei OSM keine strenge Typisierung von Tags, und ich denke nicht, dass es die jemals geben wird. Du musst Dich von dem Gedanken verabschieden, dass das, was da in England auf dem Server ist, irgendwie eine saubere, leicht auswertbare Datenbank ist oder jemals sein kann. Kein Ausmass an Editorvorschriften und Bots wird dazu fuehren - diese Datenbank wird immer das Rohmaterial sein, aus dem man brauchbare Daten ableiten muss. Die OSM-Datenbank wird immer Daten in seltsamen Formaten enthalten. In den meisten Fällen werden diese Daten keinen Nutzen haben und keinen Schaden machen. In wenigen Fällen wird es Fehlinterpretationen geben und ein Freiwilliger muss die problematischen Daten ändern. Falls Osmarender einen Fluss mit width=700cm als 700m breiten See malt (ich habe das nicht getestet), würde ich die Angabe in width=7 ändern. Dadurch habe ich Arbeit, das Kartenbild ist zeitweise defekt und der ursprüngliche Mapper verliert seine Einheit. Dann werden die Vorteile der einheitlichen Angabe noch deutlicher. Besser ich zwinge einen Mapper, seine Angabe von Seemeile, yard, Landmeile oder fathom in Meter umzurechnen (Wolfram Alpha: 8 fathom in m - 14.63 meters), als alle Mapper und alle Anwender mit diesen Einheiten zu belasten. Das ist etwas, was ganz gewiss nicht passieren wird. Erstens, weil wir keine Seetiefen mappen ;) Der Wittensee (http://osm.org/go/0Hm7TLEs-) und einige hundert Punkte mit waterway=depth beweisen das Gegenteil :-) zweitens wegen (Wolfram Alpha) 14.63 meters in fathoms = 7.9998 fathoms - Der Mapper meinte wahrscheinlich (8+-1)fathom, so dass alle Angaben zwischen 14 und 15 Meter gleichbedeutend sind. Anderenfalls dürften wir auch einen Kreis nicht durch ein Polygon mit endlich vielen Punkten beschreiben. der englische Mapper hat voellig zu recht den Anspruch, dass aus seinen vom Verkehrsschild abgelesenen 20 mph nicht ploetzlich 19.9997 werden, weil irgendjemand das partout intern in Meter pro Sekunde speichern wollte oder so. Für gesetzliche Einschränkungen, insbesondere Verkehrsschilder sollte man sicherlich die offizielle Angabe nutzen. Bei geschätzten/gemessenen Größen hat ein einheitlich metrisches System viele Vorteile. Die Googlesuche nach osm ist metrisch lieferte mir gerade das Zitat: ... Und Wassertiefen immer in Faden angeben, ist ja klar, oder :-) Bye Frederik (PS: War Spass - OSM ist metrisch.) Jeder der drei Anwender würde von einer Zahlenangabe in MW profitieren. Für den ersten vereinfacht sich das Umrechnungstool, der andere kann die Zahl ohne Vorverarbeitung nutzen. Der Mapper spart drei Zeichen und kann sich an der sinnvollen Nutzung seiner Daten erfreuen. Die mitgelieferte Einheit gibt eine groessere Sicherheit bei der Interpretation; die Freiheit des Mappers, die Zahl so eintragen zu koennen, wie er sei in der freien Wildbahn antrifft, ist m.E. hoeher zu bewerten als der Komfort des Programmierers. Eine Datenbank hat nur einen Nutzen, wenn die Daten sinnvoll auswertbar sind. Wenn ein Mapper highway=Autobahn eingibt (wie es im Gesetz und auf Schildern steht), ist das komfortabel, aber der Weg wird vom Renderer nicht dargestellt und von Router nicht ausgewertet. Die Umsetzung in highway=motorway ist beim ersten Mal lästig, aber der Weg wird dann gezeichnet und für das Routing benutzt. Jemand, der Regeln für Osmarender, Mapnik, Kosmos oder Maperative erstellt, kann Längen- und Breitenangaben mit beliebigen Einheiten in der Regel nicht korrekt auswerten. Jemand, der alle Straßen schmaler als x Meter aus einer bestehenden OSM-Datenbank ziehen will, wird scheitern oder sehr viel Zeit brauchen. Für den Komfort des Mappers, einen Wert im von ihm bevorzugten Textformat zu kodieren, möchtest du die Freiheit der Datennutzung auf die wenigen Programmierer
Re: [Talk-de] Garmin BaseCamp Version 3.1.4 (MAC OS) und OSM Karten
Hallo Johann, Danke für die klaren Worte ;) Am 15.02.2011 um 02:21 schrieb Johann H. Addicks: ..., hilft nur dem Threadstarter mit an Sicherheit grenzender Wahrscheinlichkeit nicht. Zumal ja bei der Betriebsystemdiskussion auch nie(?) etwas herauskommt. -jha- ___ 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
