Re: [Talk-de] building:type - Ergänzung
Am 19.02.2012 00:01, schrieb Martin Koppenhoefer: tut mir leid, ich habe da irgendwie Quatsch geschrieben. ele macht eigentlich mehr Sinn für die höchste Höhe an einem Punkt, oder? Ob es mehr Sinn macht, weiß ich nicht, aber zumindest widerspricht es den Annahmen, von denen ich bisher ausgegangen wäre. Die Höhe des Grunds würde man dann indirekt bestimmen können, indem man die Turmhöhe abzieht. Ich kann das jetzt nur aus der Perspektive von 3D-Rendering beurteilen. Dort wird man naheliegenderweise zunächst mal den Boden berechnen und dann Gebäude und andere Objekte in der passenden Höhe draufsetzen. Da wäre es naheliegend, das auch in den Daten entsprechend zu erfassen. Die Höhe des höchsten Punktes an einer Stelle ist in diesem Anwendungsfall uninteressant. Man würde also nie die in deinem Sinne getaggte ele direkt verwenden, sondern müsste immer die abgeleitete Information Höhe des Grunds errechnen. Das hat auch den Nachteil, dass man zur Berechnung von Grundhöhen das Tagging aller möglichen Objektarten kennen muss, auch wenn sie einen an sich wirklich interessieren - sonst kann man ja nicht ihre jeweils richtige Höhe berechnen und abziehen. Gruß, Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] building:type - Ergänzung
Am 19. Februar 2012 09:42 schrieb Tobias Knerr o...@tobias-knerr.de: Am 19.02.2012 00:01, schrieb Martin Koppenhoefer: tut mir leid, ich habe da irgendwie Quatsch geschrieben. ele macht eigentlich mehr Sinn für die höchste Höhe an einem Punkt, oder? Ob es mehr Sinn macht, weiß ich nicht, aber zumindest widerspricht es den Annahmen, von denen ich bisher ausgegangen wäre. das Wiki schreibt, ele wäre die Höhe an einem bestimmten Punkt. Meine Überlegungen waren nun diese: 1. Angenommen, man flöge mit einem Flugzeug, so wäre man sicher an der absoluten Höhe des höchsten Punktes interessiert. 2. Wenn man nur eine simple Karte rendern will (2D), dann will man meist die Höhe der Turmspitze haben (und dazuschreiben). Für diesen (bisher häufigsten) Fall ist es am einfachsten, wenn man das direkt den Daten entnehmen kann. Für 3D-Geschichten muss man sowieso mehr machen, da muss man erst mal rausfinden, ob das 3D-Geländemodell das man hat, die Höhen von Wäldern und Gebäuden bereits rausgerechnet hat (wird wohl oft gemacht), oder ob man sozusagen Rohdaten hat. In diesem Anwendungsfall wird man sowieso mehr recherchieren und rechnen müssen, da kommts auf ne Berechnung mehr auch nicht mehr an. Ich kann das jetzt nur aus der Perspektive von 3D-Rendering beurteilen. Dort wird man naheliegenderweise zunächst mal den Boden berechnen und dann Gebäude und andere Objekte in der passenden Höhe draufsetzen. Da wäre es naheliegend, das auch in den Daten entsprechend zu erfassen. ja, habe ich zuerst auch gedacht, aber solange klar ist, was wie erfasst wird, ist es im Prinzip ja egal ob man nun addiert oder subtrahiert. height würde ich in jedem Fall für die Höhe des Objekts vom Grund bis zur höchsten Stelle sehen (also der netto-Turm). Die Höhe des höchsten Punktes an einer Stelle ist in diesem Anwendungsfall uninteressant. Man würde also nie die in deinem Sinne getaggte ele direkt verwenden, sondern müsste immer die abgeleitete Information Höhe des Grunds errechnen. Das hat auch den Nachteil, dass man zur Berechnung von Grundhöhen das Tagging aller möglichen Objektarten kennen muss, auch wenn sie einen an sich wirklich interessieren - sonst kann man ja nicht ihre jeweils richtige Höhe berechnen und abziehen. Wieso, was spricht dagegen, dass die Höhe immer height ist? Ich nutze das z.B. auch bei Obelisken: height ist die Gesamthöhe des Obelisken plus Sockel und ggf. Aufbauten, während obelisk:height die Höhe des reinen Obelisken ist. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gerätetest - EGNOS
Date: Sat, 18 Feb 2012 21:29:30 +0100 From: Ronnie Soak chaoschaos0...@googlemail.com Die Messungen (zumindest die, die kostenfrei zu empfangen sind) werden einmal in der Sekunde gemacht. Ich bin mir aber sehr sicher, das sich das Ionosphärenwetter nicht sekündlich derart stark ändert, dass es zu merklichen Schwankungen der GPS Position kommt. Sind die Korrekturdaten einmal empfangen, dürfte das eine ganze weil zur Positionsverbesserung ausreichen. Eine Baulücke reicht also, die Korrekturdaten einmal zu empfangen, und man hat etliche Minuten danach eine spürbare Positionsverbesserung. Gruss, Chaos99 Dazu müsste die Software in einem Gerät das auch so auswerten. Lässt sich diese Theorie durch ein Protokoll bestätigen ? Gruß Mibo ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gerätetest - EGNOS
Dazu müsste die Software in einem Gerät das auch so auswerten. Lässt sich diese Theorie durch ein Protokoll bestätigen ? Nein. Nur durch praktische Erfahrung. Wenn man der Anzeige sowohl der Genauigkeit als auch des Egnos-Status glauben schenken darf, stören einige Minuten Abschattung der Egnos Satelliten nicht. Ohne Einsicht im den Quellcode kann man das natürlich nicht “nachweisen“. Bei Geräten, die auch Rohdaten herausschreiben können, möglicherweise sogar mit und ohne Korrektur, ließe sich so etwas vielleicht nachrechnen. Gruß, Chaos99 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gerätetest - EGNOS
On 19.02.2012 12:47, Michael Bojert wrote: From: Ronnie Soakchaoschaos0...@googlemail.com Die Messungen (zumindest die, die kostenfrei zu empfangen sind) werden einmal in der Sekunde gemacht. Ich bin mir aber sehr sicher, das sich das Ionosphärenwetter nicht sekündlich derart stark ändert, dass es zu merklichen Schwankungen der GPS Position kommt. Sind die Korrekturdaten einmal empfangen, dürfte das eine ganze weil zur Positionsverbesserung ausreichen. Eine Baulücke reicht also, die Korrekturdaten einmal zu empfangen, und man hat etliche Minuten danach eine spürbare Positionsverbesserung. Dazu müsste die Software in einem Gerät das auch so auswerten. Lässt sich diese Theorie durch ein Protokoll bestätigen ? Das sollte ja eigentlich im Datenblatt stehen. Jetzt habe ich das Datenblatt mal durchgelesen und bekomme etwas Angst vor SBAS. Ich hatte mich nie zu sehr damit Beschäftigt, da hier Stand, dass die Empfänger selbst entscheiden können ob die Korrekturdaten für die aktuelle Region gültig sind: http://www.kowoma.de/gps/waas_egnos.htm Befindet man sich jedoch auch bei den SBAS deutlich außerhalb des Einzugsgebietes der Korrekturstationen und empfängt beispielsweise in Europa die Korrekturdaten für Nordamerika, so wird der GPS-Empfänger im glücklichsten Fall die Standardionosphärenkorrekturen anwenden, die er gespeichert hat. In diesem Fall wird man keinen Unterschied zwischen aktiviertem und nicht aktiviertem WAAS/EGNOS bemerken. Im unglücklichsten Fall jedoch wird überhaupt keine oder eine falsche Ionosphärenkorrektur angewandt und die Position ist sogar schlechter als mit deaktiviertem WAAS/EGNOS. Wenn die Software des GPS-Empfängers korrekt programmiert ist, sollte dieser Fall jedoch nicht eintreten, da die SBAS-Systeme die Informationen über den Gültigkeitsbereich ihrer Daten in den ausgesendeten Signalen mitliefern. Jetzt lese ich hier: http://www.u-blox.com/images/downloads/Product_Docs/u-blox6_ReceiverDescriptionProtocolSpec_%28GPS.G6-SW-10018%29.pdf Since some WAAS satellites can be received in the western parts of Europe but don't carry correction data for the European continent, the GEOs from all but the EGNOS system should be disallowed, using the PRN Mask. Damit ist der Chip wohl nicht fähig das alleine zu erkennen. Sehr schlecht. Kennt jemand Details dazu wie sich der MT3329 verhält? Der ist ja auch in den neueren Garmins drin. Ich wüsste bei mir nicht wie ich einzelne PRN ausschließen kann. Damit bleibt ja dann nur noch das SBAS komplett abzuschalten. Irgendwie auch nicht im Sinne des Erfinders, oder? Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Welche Tags für Bahngleise
Am 19.02.2012 00:51, schrieb Garry: Am 18.02.2012 08:44, schrieb Michael Neumann: Ich wuerde public_transport=stop_position auf dem Gleis an der Mitte des Bahnsteigs setzen. Welche Information möchtest Du den mit stop_position geben? stop_position vorhanden und Teil einer Relation route=train: Der Zug hält in diesem Bahnhof. Ich kann etwa an der markierten Position Ein- und Aussteigen. Ich denke es gibt zu viele Ausnahmen, Sonderfälle etc. als dass man das in OSM sinnvoll eintragen könnte. Manche Gleise werden doppelt genutzt (hinterer und vorderer Teil), Züge getrennt und zusammgefügt,... Vernüftig wäre da nur das taggen der entsprechende Haltetafeln (Langzug,Vollzug,Kurzzug, achsabhängig,..) Für welche Anwender bietet diese Detailinformation einen Zusatznutzen? Mir fallen dafür nur Zugsimulatoren ein. Für Fahrgäste ist die Mitte des Zuges die relevante Position. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gerätetest - EGNOS
Am 19.02.2012 13:44, schrieb Stephan Knauss: Ich wüsste bei mir nicht wie ich einzelne PRN ausschließen kann. Damit bleibt ja dann nur noch das SBAS komplett abzuschalten. Irgendwie auch nicht im Sinne des Erfinders, oder? Wie bereits gesagt, wurden WAAS und EGNOS für den Einsatz in der Flugzeugnavigation entwickelt. Wird schon seinen Grund haben, wieso das in den Garmins standardmäßig abgeschaltet ist. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Welche Tags für Bahngleise
Am 19.02.2012 14:05, schrieb Stephan Wolff: Am 19.02.2012 00:51, schrieb Garry: Am 18.02.2012 08:44, schrieb Michael Neumann: Ich wuerde public_transport=stop_position auf dem Gleis an der Mitte des Bahnsteigs setzen. Welche Information möchtest Du den mit stop_position geben? stop_position vorhanden und Teil einer Relation route=train: Der Zug hält in diesem Bahnhof. Ich kann etwa an der markierten Position Ein- und Aussteigen. +1 Ich denke es gibt zu viele Ausnahmen, Sonderfälle etc. als dass man das in OSM sinnvoll eintragen könnte. Manche Gleise werden doppelt genutzt (hinterer und vorderer Teil), Züge getrennt und zusammgefügt,... Vernüftig wäre da nur das taggen der entsprechende Haltetafeln (Langzug,Vollzug,Kurzzug, achsabhängig,..) Für welche Anwender bietet diese Detailinformation einen Zusatznutzen? Mir fallen dafür nur Zugsimulatoren ein. Für Fahrgäste ist die Mitte des Zuges die relevante Position. +1 Gruss -- Michael Neumann michael.neum...@uni-dortmund.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Dakota 20 oder Oregon 450?
Am 16.02.2012 08:01, schrieb Manuel Reimer: Hallo, ich möchte mir ein neues GPS zulegen. Anwendungsfälle: - Loggen für OSM. Spuren möchte ich direkt auf der Karte sehen. - Mitnehmen des aktuellen Kartenstands für den Bereich, in dem ich loggen will - POIs erfassen und schon vor Ort mit kurzem Text benennen - Routing für's Fahrrad und zum Wandern (natürlich mit OSM-Karten) Ich schwanke zwischen dem Dakota 20 und dem Oregon 450. Gibt es irgend einen Punkt der für das teurere Oregon 450 spricht, oder genügt das günstigere Dakota 20 für meine Zwecke? Gruß Manuel Hallo Manuel, Nutzen tue ich für's MTB ein Dakota 20 mit Garmin Fahrradhalterung seit gut einem Jahr. Ohne Silikonhülle hätte ich schon ein neues Oregon - kann leicht raus rutschen und auf die Straße fallen (Halterung aus Kunststoff, Oregon - Metall). Von der Genauigkeit her +- 2 - 20m im Wald. Kurven rechnet das Garmin selbst nach, dauert leider Zeit. Das Oregon hat auch noch ein helleres und größeres Display. Daher verwende ich zum Loggen nur noch meine ublox6 USB-Maus mit Laptop. = 1m 2D, 2m 3D mit EGNOS aktiv (12 Satteliten + 3 EGNOS möglich). Laufen hab ich sie mit 2 Punkte/s, damit auch fürs Auto geeignet. Diese hat noch eine deutlich verbesserte Positionserkennung wie das Vorgängermodell. Verglichen mit der aktuell verfügbaren Aerowestkarte kann ich sogar sehen, auf welcher Spur ich fahre. Gruß Christian signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LWG Sitzung vom 14.2.2012
Simon Poole si...@poole.ch wrote: Es wurden an beiden Sitzungen einige wichtige Punkte behandelt: - Festlegung auf den WTFE Algorithmus für den Übergang auf die ODbL Datenbank ( - Klarstellung, dass Splits und Mergers nicht berücksichtigt werden. Falls tatsächlich ein an OSM Beteiligter, seine Rechte verletzt sieht, so würde man das am konkreten Fall untersuchen und allfällige nicht konforme Daten löschen. Und hinter der fachchinesischen Abkürzung WTFE verbirgt die Aussage, dass die Lizenzbereinigung so duchgeführt wird, wie im OSM Inspektor, Frederiks JOSM Plugin und der Clear/Badmap dargestellt, oder? Noch in eigener Sache: ich hab vor ein paar Wochen angekündigt, dass in irgendeiner Form ich Zugriff auf die Profildaten der Grössten noch unentschiedenen Mapper haben werde. Ich habe die Daten jetzt und habe auch bereits eine Liste für Deutschland produziert (ca. 220 Einträge). Die Liste wird wohl in den nächsten Tagen abgearbeitet. Nachdem ich in meiner Homeregion Ostfriesland das erste Mal Frederiks Auswertung gesehen hatte, drängte sich mir ernsthaft die Frage auf, ob OSM noch mein Projekt sei. Auf rundweg 5000 Quadratkilometer blieb kaum ein Stein mehr anderen. Rot fast überall, wohin das Auge sah. Ich habe darauf hin alle per Hand ermittelten Unentschiedenen im Gebiet über den OSM Account angeschrieben, obwohl dies laut LWG schon einmal auf Englisch und auf Deutsch geschehen sein soll. Dabei bin ich ohne Vorgeplänkel gleich mit der Tür ins Haus gefallen: __ Überschrift: Deine OpenStreetMap Daten werden am 01. April gelöscht. (Ich habe bewusst nicht die Abkürzung OSM benutzt.) Text: Deine OpenStreetMap Daten werden am 01. April gelöscht. Das ist kein Aprilscherz. Wie sehr die von Dir gemappte Heimat zerstört wird, kannst du hier sehen. Alles was rot ist, wird verschwinden. (Dazu gab es dann einen persönlich zugeschnitten Link auf den OSM Inspektor.) Du kannst das verhindern, indem Du der neuen Lizenz zustimmst. Logge Dich dazu hier ein. Prüfe aber zuvor, ob Dir diese neue Lizenz zusagt. (Es folgten Links ins Wiki und auf Frederiks FOSSGIS Vortrag zur Lizenz.) Sorry für meine Aufdringlichkeit. Wenn Du weitere Fragen hast, stehe ich gern zur Verfügung. Normalerweise sind solche Mails an Unbekannte nicht meine Art. Aber hier heiligte der Zweck die Mittel. Und es hat gewirkt. Obwohl die LWG (mit welchem Text auch immer) nichts bewegen konnte, haben diesmal fast alle reagiert. Ich habe viele Dankesmails und nicht eine einziges Mecker erhalten. Heute ist Ostfriesland nahezu sauber. :-) Ich kann also nur dringendst empfehlen, alle deutschsprachigen unentschlossenen Mapper ähnlich drastisch mit ihrer zerstörten Heimat zu konfrontieren. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LWG Sitzung vom 14.2.2012
Am 19.02.2012 16:27, schrieb Tirkon: Und hinter der fachchinesischen Abkürzung WTFE verbirgt die Aussage, dass die Lizenzbereinigung so duchgeführt wird, wie im OSM Inspektor, Frederiks JOSM Plugin und der Clear/Badmap dargestellt, oder? Steht ja so im Protokoll. Noch in eigener Sache: ich hab vor ein paar Wochen angekündigt, dass in irgendeiner Form ich Zugriff auf die Profildaten der Grössten noch unentschiedenen Mapper haben werde. Ich habe die Daten jetzt und habe auch bereits eine Liste für Deutschland produziert (ca. 220 Einträge). Die Liste wird wohl in den nächsten Tagen abgearbeitet. Nachdem ich in meiner Homeregion Ostfriesland das erste Mal Frederiks Auswertung gesehen hatte, drängte sich mir ernsthaft die Frage auf, ob OSM noch mein Projekt sei. Auf rundweg 5000 Quadratkilometer blieb kaum ein Stein mehr anderen. Rot fast überall, wohin das Auge sah. Ich habe darauf hin alle per Hand ermittelten Unentschiedenen im Gebiet über den OSM Account angeschrieben, obwohl dies laut LWG schon einmal auf Englisch und auf Deutsch geschehen sein soll. Dabei bin ich ohne Vorgeplänkel gleich mit der Tür ins Haus gefallen: Also 2 Mails sind an jeden geschickt worden, der noch nicht zugestimmt hat. Es hat aber sicher einen gewissen Prozentsatz, der weil im Profile keine Browser-Sprachpräferenz, oder en gesetzt war, die zweite Mail auf Englisch erhalten haben. Daneben sind die Mails vermutlich Spamfilter etc. zum Opfer gefallen. Bezüglich den grössten deutschen Mappern kann ich noch folgendes sagen, es hat einen sehr hohen (ca. 50%) Rate von Bounces (also Mail aus irgendwelchen Gründen nicht zustellbar). EIne Grössenordnung mehr als in anderen Ländern. Das ganze ist also schon recht abgearbeitet, es hat aber wohl noch -viele- kleinere Mapper (mit weniger als 100 erstellten highways nach meinen Listen), die man vermutlich erreichen kann. Simon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Dakota 20 oder Oregon 450?
Christian Kolesa chriskol...@web.de wrote: Daher verwende ich zum Loggen nur noch meine ublox6 USB-Maus diese hier?: http://www.alternate.de/html/product/Navilock/NL-602U_ublox6_USB_Empfaenger/966752/? mit Laptop. Ist die Software zum Loggen bei der Maus dabei oder was bräuchte man da? Gibt es da auch passende offline funktionierende OSM Navi-Programme? = 1m 2D, 2m 3D mit EGNOS aktiv (12 Satteliten + 3 EGNOS möglich). Laufen hab ich sie mit 2 Punkte/s, damit auch fürs Auto geeignet. Auch? Nimmst Du den Laptop auch auf dem Fahrrad mit? In der Beschreibung steht: Durch das Herunterladen der Korrekturdaten aus dem Internet und dem Speichern im GPS-Empfänger, kann dieser weltweit sofort nach dem Empfang des ersten Satellitensignals starten. Sind damit dieselben Korrekturdaten gemeint, die auch über Egnos verbreitet werden? Das Gerät soll auch Galileo-Satelliten sehen können. Hast Du schon mal einen der beiden im Visier gehabt? Verglichen mit der aktuell verfügbaren Aerowestkarte kann ich sogar sehen, auf welcher Spur ich fahre. Das hört sich so an, als wenn man nichts Genaueres mehr bräuchte. :-) Gruß Tirkon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Talk-de Nachrichtensammlung, Band 67, Eintrag 85
Date: Sun, 19 Feb 2012 13:44:38 +0100 From: Stephan Knauss o...@stephans-server.de Damit ist der Chip wohl nicht fähig das alleine zu erkennen. Sehr schlecht. Kennt jemand Details dazu wie sich der MT3329 verhält? Der ist ja auch in den neueren Garmins drin. Ich wüsste bei mir nicht wie ich einzelne PRN ausschließen kann. Damit bleibt ja dann nur noch das SBAS komplett abzuschalten. Irgendwie auch nicht im Sinne des Erfinders, oder? Stephan Ich lasse WAAS/EGNOS ausgeschaltet da ich den Eindruck habe das es verschlimmbessert. Ohne Protokoll kann ich es aber nicht nachweisen. Ging es in diesem Dialog auch um die Frage: Was ist die Referenz? Als Voraussetzung zum Abzeichnen von Luftbildern hatte ich mal getestet. a) messen von in Luftbildern erkennbaren Punkten mit einer Genauigkeit* im Dezimeter-Bereich [1] Zum Einsatz kam ein Testgerät mit 220 Kanal Empfänger unter Nutzung von 2 Frequenz GPS + Glonass-Signal sowie Egnos und Referenzdaten via GSM-Modem. Als in einem Luftbild mit guter Bodenauflösung erkennbaren Punkt können Laternen oder Masten dienen deren Fuß man durch den Schattenwurf ausmachen kann. b) Vergleich von Luftbildern aus unterschiedlichen Quellen und Trackspuren. Aufgrund der Bodenauflösung sind Bing- Bilder nur bedingt geeignet. Alternativ kann eine Gebäudeecke im Nahbereich zu mehreren solcher Referenzpunkte gemessen werden. c) Festlegen des Versatzes für ein Bing-Luftbild. *Da es verschiedene Definitionen von Genauigkeit gibt, müsste an jeden Referenzpunkt ein Protokoll mit Beschreibung der Lagegenauigkeit gehängt werden. Beispiel: x% von n Messungen pro Punkt liegen in einem Radius von y Metern. Flächendeckend ein gesichertes Referenznetz aufzubauen um eine definierte Lagegenauigkeit von Objekten in OSM zu erreichen halte ich für schwierig . Mir ist auch noch unklar, welche absolute Lagegenauigkeit mit Blick auf die Nutzer einer OSM-Karte erstrebenswert ist. Nach meiner Einschätzung führt die zusätzliche Nutzung von Egnos-Signalen in einem Navi allein, zu keiner relevanten Qualitätsverbesserung der OSM-Daten. Zumindest keine Verbesserung der *Genauigkeit von 10-15m auf 1-2m. Die Nutzung von Referenznetzen wie [2] oder Postprocessing [3] hingegen bringt eine wesentliche Verbesserung wobei auch da bei Abschattungen die bekannten Probleme auftreten. Das ist allerdings i.d.R. kostenpflichtig und fällt eher unter Landes- Vermessung als unter mappen. Wenn z. B. örtliche Vermessungsämter in einem Raster von ein paar hundert Metern WGS 84-Koordinaten von Gebäudeecken bereitstellen würden, könnte ein Schuh draus werden. [1] http://global.trimble.com/de/ oder http://www.leica-geosystems.com/en/index.htm oder [2] http://www.sapos.de/ [3] http://de.wikipedia.org/wiki/Postprocessing Gruß Mibo ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] building:type - Ergänzung
Als Wert für den Schlüssel ele nehme ich stets die Höhe der festen Bodenfläche über NN in Meter, so wie Tobias. So sind z. B. auch die Listen der Sendeanlagen der BNetzA aufgebaut (Standorthöhe). Die Bauwerks- oder Antennenhöhe o. ä. wird addiert. Mit height bezeichne ich dann die Gesamthöhe des Bauwerks oberhalb ele. Soweit ich weiß, sind z. B. die offiziellen Berghöhen ohne die Höhe des Gipfelkreuzes oder -steins angegeben. Bernhard -Original Message- From: Martin Koppenhoefer [mailto:dieterdre...@gmail.com] Sent: Sunday, February 19, 2012 11:54 AM To: Openstreetmap allgemeines in Deutsch Subject: Re: [Talk-de] building:type - Ergänzung Am 19. Februar 2012 09:42 schrieb Tobias Knerr o...@tobias-knerr.de: Am 19.02.2012 00:01, schrieb Martin Koppenhoefer: tut mir leid, ich habe da irgendwie Quatsch geschrieben. ele macht eigentlich mehr Sinn für die höchste Höhe an einem Punkt, oder? Ob es mehr Sinn macht, weiß ich nicht, aber zumindest widerspricht es den Annahmen, von denen ich bisher ausgegangen wäre. das Wiki schreibt, ele wäre die Höhe an einem bestimmten Punkt. Meine Überlegungen waren nun diese: 1. Angenommen, man flöge mit einem Flugzeug, so wäre man sicher an der absoluten Höhe des höchsten Punktes interessiert. 2. Wenn man nur eine simple Karte rendern will (2D), dann will man meist die Höhe der Turmspitze haben (und dazuschreiben). Für diesen (bisher häufigsten) Fall ist es am einfachsten, wenn man das direkt den Daten entnehmen kann. Für 3D-Geschichten muss man sowieso mehr machen, da muss man erst mal rausfinden, ob das 3D-Geländemodell das man hat, die Höhen von Wäldern und Gebäuden bereits rausgerechnet hat (wird wohl oft gemacht), oder ob man sozusagen Rohdaten hat. In diesem Anwendungsfall wird man sowieso mehr recherchieren und rechnen müssen, da kommts auf ne Berechnung mehr auch nicht mehr an. Ich kann das jetzt nur aus der Perspektive von 3D-Rendering beurteilen. Dort wird man naheliegenderweise zunächst mal den Boden berechnen und dann Gebäude und andere Objekte in der passenden Höhe draufsetzen. Da wäre es naheliegend, das auch in den Daten entsprechend zu erfassen. ja, habe ich zuerst auch gedacht, aber solange klar ist, was wie erfasst wird, ist es im Prinzip ja egal ob man nun addiert oder subtrahiert. height würde ich in jedem Fall für die Höhe des Objekts vom Grund bis zur höchsten Stelle sehen (also der netto-Turm). Die Höhe des höchsten Punktes an einer Stelle ist in diesem Anwendungsfall uninteressant. Man würde also nie die in deinem Sinne getaggte ele direkt verwenden, sondern müsste immer die abgeleitete Information Höhe des Grunds errechnen. Das hat auch den Nachteil, dass man zur Berechnung von Grundhöhen das Tagging aller möglichen Objektarten kennen muss, auch wenn sie einen an sich wirklich interessieren - sonst kann man ja nicht ihre jeweils richtige Höhe berechnen und abziehen. Wieso, was spricht dagegen, dass die Höhe immer height ist? Ich nutze das z.B. auch bei Obelisken: height ist die Gesamthöhe des Obelisken plus Sockel und ggf. Aufbauten, während obelisk:height die Höhe des reinen Obelisken ist. Gruß Martin ___ 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] LWG Sitzung vom 14.2.2012
Simon Poole si...@poole.ch wrote: Bezüglich den grössten deutschen Mappern kann ich noch folgendes sagen, es hat einen sehr hohen (ca. 50%) Rate von Bounces (also Mail aus irgendwelchen Gründen nicht zustellbar). EIne Grössenordnung mehr als in anderen Ländern. Ich habe keinen blassen Schimmer, ob Folgendes technisch machbar wäre: Vielleicht sollte man darüber nachdenken, die aktuelle Slippy Map schon jetzt durch die ODBL-Cleanmap zu ersetzen, während die alte noch gültige CC-Version dahinter nur verblasst erscheint. Damit würde sie auf der Hauptseite als auch in den Editoren und Anwendungen, die sie nutzen, dergestalt erscheinen und erregt dort Aufmerksamkeit. Zudem gibt man der alten CC-Map eine neue URL, über die sie erreichbar bleibt. Möglicherweise kann man hierzu den neuen Server aus der Spendenaktion nutzen. Er rendert die aktuelle ODBL-Cleanmap und legt die vom alten Server gerenderte aktuelle CC-Map verblasst dahinter. Mit dem Datum der Umstellung lässt man die verblasste Version weg. Zudem lässt man in den vier Ecken große rote Hinweise - sagen wir in zwei Sprachen pro Ecke, insgesamt also acht - erscheinen, die auf eine Erklärung verlinken. Auf deutsch könnte dieser Hinweis etwa so lauten: Achtung! Verblasste Objekte werden am 2. April gelöscht - der 2. April deshalb, damit es nicht als Aprilscherz interpretiert werden könnte. In den Ecken würden die Hinweise beim Arbeiten nicht so arg stören, so dass man einen Monat damit leben kann. Alternativ lässt man die Hinweise nur für einige Sekunden auftauchen und dann verschwinden und wiederholt das alle fünf Minuten. Der nicht ereichbare Mapper vermisst also seine Edits. Dies lässt ihn aufschrecken und nach den Ursachen forschen. Möglicherweise bekehrt das auch noch den ein oder anderen Ablehner. Alternativ könnte man die Slippy Map - alt vs neu - durch diesen Stil ersetzen: http://sautter.com/map/ Dabei stellt man den Schieberegler in der Start-/Grundeinstellung so ein, dass die Cleanmap betont bleibt. Oder aber man macht das Ganze zum 1. April und lässt noch einen Monat Karenzzeit bis zur endgültigen Umstellung. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LWG Sitzung vom 14.2.2012
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 IMHO bringt ein Verschiebung des Termins nichts, die Leute die was auf den letzten Drücker tun wollen lässt das kalt und alle anderen kann man locker vorher noch erreichen. Es ist gut möglich (Rebuild-Sitzung in 30 Minuten!), dass wir ab ca. Anfang März anfangen die Datenbank zu bereinigen. Vermutlich wird es aber mindestens bis zum 1. April noch die Möglichkeit geben zuzustimmen und seine Daten wieder sichtbar zu machen. Es ist aber genau so möglich das man anders vorgeht. Simon -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPQUCwAAoJEEchcRCS4oLqGq0IAI63OJ3qoTvtovpuLkABtJ6b GJAROTqYA2IF5MoYRqvDGW4oBCpcLHhaxduUs6kKaYEQfNGdKMhUSTQD8iKCNSqQ ZQgspqI9dNM4uYOP3ehjmMR6fK0+qhR4Czb9CibepjAO7jcGNk2+hiyE8zWI+Mhg PVspc0bGDNdxdcUcyEqhfXD3nFDEpSqma4980VBI74nfw/6VQ/PYmrEbki8gjbdw e5/+LT+c/lt/SBKUl131IYRFPgcqA0vckb15p2/Pbc815zDkDdt8cvdKoa+sdqre 4ldVOlP+AYOrkH3CCNH0qRR5in3vpt9FScijGENDrlNWzd9Qs/IlQswMNPpHed0= =TAhm -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Denkmal-Tag
hi ! ich habe einiges an historischen Dingen die letzte Zeit erfaßt und weiß das diese teilweise unter Denkmalschutz stehen. Im Wiki habe ich aber nichts passendes gefunden - was würdet Ihr nehmen ?? protected = yes zum Beispiel ? Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Denkmal-Tag
Jan Tappenbeck schrieb: ich habe einiges an historischen Dingen die letzte Zeit erfaßt und weiß das diese teilweise unter Denkmalschutz stehen. Im Wiki habe ich aber nichts passendes gefunden - was würdet Ihr nehmen ?? protected = yes zum Beispiel ? Darunter könnte man beispielsweise auch einen Wachschutz verstehen. Etwas Eindeutigeres wäre besser. etwas in der Art: Denkmal=ja offiziell_anerkanntes_Denkmal=ja Beim Wikimedia-Commons-Wettbewerb gab es Listen mit offiziell anerkannten Denkmälern. Vielleicht könnte man sie für diesen Zweck heranziehen? Gruß Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wochennotiz Nr. 83
Hallo, die neue Wochennotiz Nr. 83 mit allen Neuigkeiten aus der OpenStreetMap-Welt ist da: http://blog.openstreetmap.de/2012/02/wochennotiz-nr-83/ Viel Spaß beim Lesen! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deutscher Kartenstil: Probleme mit Sperrgebieten (Übungsplätze, Kasernen, etc.)
Karsten Gohr findich...@gmx.de wrote: Kann man die militärischen Grenzen und Schraffuren in den deutschen Stil übernehmen? Danke, dass Du Dich soeben bereiterklärt hast zukünftig bei der Pflege des deutschen Stils mitzuhelfen *duck* Gruss Sven P.S.: Falls Du ernsthaft Interesse hast mitzuarbeiten. Unter http://lists.openstreetmap.de/mailman/listinfo/mapnik-de gibt es eine Mailingliste. -- 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] Welche Tags für Bahngleise
Am 19.02.2012 14:05, schrieb Stephan Wolff: Am 19.02.2012 00:51, schrieb Garry: Am 18.02.2012 08:44, schrieb Michael Neumann: Ich wuerde public_transport=stop_position auf dem Gleis an der Mitte des Bahnsteigs setzen. Welche Information möchtest Du den mit stop_position geben? stop_position vorhanden und Teil einer Relation route=train: Der Zug hält in diesem Bahnhof. Der Zug? Du möchtest einen Fahrplan in OSM abbilden? Ich kann etwa an der markierten Position Ein- und Aussteigen. Dafür genügt die Information wo der Bahnsteig beginnt/endet. Sonst bekomme ich eine Informationsgenauigkeit vorgegaukelt die ich nicht habe. Ich denke es gibt zu viele Ausnahmen, Sonderfälle etc. als dass man das in OSM sinnvoll eintragen könnte. Manche Gleise werden doppelt genutzt (hinterer und vorderer Teil), Züge getrennt und zusammgefügt,... Vernüftig wäre da nur das taggen der entsprechende Haltetafeln (Langzug,Vollzug,Kurzzug, achsabhängig,..) Für welche Anwender bietet diese Detailinformation einen Zusatznutzen? Mir fallen dafür nur Zugsimulatoren ein. Für Fahrgäste ist die Mitte des Zuges die relevante Position. Für den Anwender ist der Bahnsteig relevant und soweit vorhanden die Wagenstandsanzeiger. Mitte des Zuges funktioniert nicht, das hängt von viel zu vielen Parametern ab die sich in OSM nicht abbilden lassen. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Welche Tags für Bahngleise
Am 17.02.2012 17:40, schrieb Alexander Matheisen: - oneway: ist oneway=yes sinnvoll, wenn jedes Gleis einer zweigleisigen Strecke nur Signale für eine Fahrtrichtung hat? Ist nicht selbst in diesem Fall z.B: bei Bauarbeiten auf dem anderen Gleis das Befahren des Gegengleises möglich? In der Regel schon. Sinnvoller wäre es den regulären Gleiswechselbetrieb zu taggen, also wenn beide Gleise in beide Richtungen gleichwertige Signaltechnik haben. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Denkmal-Tag
Am 19.02.2012 20:07, schrieb malenki: Jan Tappenbeck schrieb: ich habe einiges an historischen Dingen die letzte Zeit erfaßt und weiß das diese teilweise unter Denkmalschutz stehen. Im Wiki habe ich aber nichts passendes gefunden - was würdet Ihr nehmen ?? protected = yes zum Beispiel ? Darunter könnte man beispielsweise auch einen Wachschutz verstehen. Etwas Eindeutigeres wäre besser. etwas in der Art: Denkmal=ja offiziell_anerkanntes_Denkmal=ja Beim Wikimedia-Commons-Wettbewerb gab es Listen mit offiziell anerkannten Denkmälern. Vielleicht könnte man sie für diesen Zweck heranziehen? Gruß Thomas hi ! sollten tags nicht in englisch gehalten sein ? denkmalschutz gibt es doch in anderen ländern! gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] JOSM: punkte im Wikiformat ausgeben
HI ! wenn ich mich nicht irre hatte ich vor kurzem eine Funktion gesehen bei welcher Nodekoordinaten in speziellen Formaten ermittelt und in den Zwischenspeicher übernommen werden konnten ?!?! Ich finde diese nicht wieder - kann mir einer weiterhelfen? Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Denkmal-Tag
Am 19. Februar 2012 19:56 schrieb Jan Tappenbeck o...@tappenbeck.net: hi ! ich habe einiges an historischen Dingen die letzte Zeit erfaßt und weiß das diese teilweise unter Denkmalschutz stehen. Im Wiki habe ich aber nichts passendes gefunden - was würdet Ihr nehmen ?? es gibt da verschiedene Proposals, z.B.: * http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area mit protect_class=22 * http://wiki.openstreetmap.org/wiki/Proposed_features/heritage Wenn Du sicher gehen willst nimmst Du beides... Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Welche Tags für Bahngleise
Am 19. Februar 2012 02:05 schrieb Henning Scholland o...@aighes.de: Der Unterschied liegt in dem Gültigkeitsraum der Default-Werte. Bei globalen Defaults kann man sich die Erfassung des Normalzustandes sparen. Bei lokalen Defaults halte ich es für sinnvoll, diese zu erfassen. Ansonsten kann man immer sagen gauges=... ist für die Straßenbahn in Kleinkleckersdorf default, muss ich also nicht erfassen. Als Auswerter steht man dann aber da und muss irgendwie an den Default für diese Situation herankommen und man muss wissen, in welcher Region die Schiene gerade liegt. Oder anders ausgedrückt, wenn man diese Eigenschaft auswerten möchte, muss man lokales Wissen haben oder aber eine separate, freie DB, die man anzapfen kann. +1, die Spurbreite zu taggen ist sinnvoll, auch wenn innerhalb eines Landes vorwiegend eine bestimmte Spurbreite in Benutzung ist. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] building:type - Ergänzung
Am 19. Februar 2012 18:44 schrieb Bernhard Weiskopf bweisk...@gmx.de: Als Wert für den Schlüssel ele nehme ich stets die Höhe der festen Bodenfläche über NN in Meter, so wie Tobias. bei einem im Meer schwimmenden Turm hättest Du dann einen negativen Wert in ele? ;-) So sind z. B. auch die Listen der Sendeanlagen der BNetzA aufgebaut (Standorthöhe). Standorthöhe muss ja nicht unbedingt dass sein, was in ele rein kommt, dann müsste man diese Listen halt vor dem Taggen noch umrechnen (ele=height+standorthöhe). ele ist halt die Höhe des Punktes, und wie da dann noch was zusätzlich oben drauf sein kann (wie ein Turm) erschließt sich finde ich nicht. Bei Türmen wird normalerweise angegeben: Höhe über NN und das ist dann die Höhe der Turmspitze, z.B. http://www.schwaebischer-albverein.de/wanderheime/rossberghaus/rossberghaus.html Soweit ich weiß, sind z. B. die offiziellen Berghöhen ohne die Höhe des Gipfelkreuzes oder -steins angegeben. Das ist klar (zumindest für das Gipfelkreuz, den Gipfelstein würde ich der Einfachheit halber lieber erstmal draussen lassen) , aber ein Turm unterscheidet sich da m.E. von einem Berg. Wenn man das Gipfelkreuz taggen würde, dann würde man sicherlich auch für die Höhe die der Spitze verwenden, oder? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] JOSM: Punkt-Koordianten extrahieren
HI ! ich meine kürzlich einen Dialog gesehen zu haben um von einem Node die Koordinaten in verschiedenen Formaten (z.b. Wikipedia) extrahieren zu können und entsprechend formatiert in den Zwischenspeicher zu bekommen. Den finde ich nicht wieder - kann mir einer auf die Sprünge helfen ? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Denkmal-Tag
Am 20.02.2012 00:37, schrieb Martin Koppenhoefer: Am 19. Februar 2012 19:56 schrieb Jan Tappenbeck o...@tappenbeck.net: hi ! ich habe einiges an historischen Dingen die letzte Zeit erfaßt und weiß das diese teilweise unter Denkmalschutz stehen. Im Wiki habe ich aber nichts passendes gefunden - was würdet Ihr nehmen ?? es gibt da verschiedene Proposals, z.B.: * http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area mit protect_class=22 * http://wiki.openstreetmap.org/wiki/Proposed_features/heritage Wenn Du sicher gehen willst nimmst Du beides... Gruß Martin Um mal ein praktisches Beispiel für heritage zu zeigen: http://www.openstreetmap.org/browse/way/101010765 , mit dem ich nach und nach alle Kölner Denkmäler https://de.wikipedia.org/wiki/Liste_der_Denkm%C3%A4ler_in_K%C3%B6ln markiere Raimond. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
