[Talk-de] Höhennetz/Höhendatenbank (was: Höhenmesser: Die Post war da :- ))
Frederik Ramm schrieb: Ist aber nichts, was man mal eben an einem Wochenende entwickelt. Die Datenbank ist trivial (create table hoeheninfo (lat integer, lon integer, ele integer);, fertig) So völlig trivial finde ich es nicht. Man wird z.B. Angaben zur Datenqualität mitabspeichern wollen, damit man bei hinzukommenden Daten entscheiden kann, welche besser sind, respektive, wie man diese zusammenrechnet. Allein die Tatsache, dass SRTM methodisch bedingt in geschlossenen Bebauungen an den Dächern und im Wald an den Kronen orientiert, lässt mir Daten zu Bebauungshöhe/Vegetationshöhe sinnvoll erscheinen. In Binnengewässern kann ich mir vorstellen, dass uns sowohl die absolute Höhe des Wasserspiegels wie auch die Wassertiefe bis zum Grund interessiert. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Hallo, Johann H. Addicks wrote: Man wird z.B. Angaben zur Datenqualität mitabspeichern wollen, damit man bei hinzukommenden Daten entscheiden kann, welche besser sind, respektive, wie man diese zusammenrechnet. Allein die Tatsache, dass SRTM methodisch bedingt in geschlossenen Bebauungen an den Dächern und im Wald an den Kronen orientiert, lässt mir Daten zu Bebauungshöhe/Vegetationshöhe sinnvoll erscheinen. In Binnengewässern kann ich mir vorstellen, dass uns sowohl die absolute Höhe des Wasserspiegels wie auch die Wassertiefe bis zum Grund interessiert. Siehst Du, wenn die Macher von OSM von Anfang an diese Detailverliebtheit besessen haetten, waere aus dem Projekt nie was geworden ;-) Meiner Ansicht nach faengt man entweder, wie OSM damals, mit dem the simplest thing that could possibly work-Prinzip an, oder man erstickt in den selbstgemachten Anforderungen. Das von mir skizzierte ist schon schwer genug. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hierarchisches Tagging (was: Re: Ortsangabe in Namen (war Re: Kieser Training))
Hi, Analog zu: addr:street= addr:city= addr:state= ... Nimmt man also: name= name:loc= name:reg= name:nat= name:disused= name:disused:1900-1975= name:loc:disused:1900-1975= ... Tönt nach einem sehr einfachen und brauchbaren Konzet. Das gleiche ergibt auch viel Sinn bei: access=no access:car=yes (= acces=car) access:car:1200-1800h=no ... natural=wood natural:wood:type=oak natural=water natural:water=lake ... restriction:turn:right=only restriction:turn:left=no restriction:straight=yes ... highway=footway highway:track=1 highway:track:surface=paved ... Das ist alles ins Unreine geschrieben und kann sicher noch durch Umstellen verbessert und ergänzt werden, aber als Grundprinzip macht es irgendwie Sinn und ich würde mir wünschen, dass vor allem bei neuen Tags darauf zurückgegriffen wird. Es skaliert einfach deutlich besser und ist übersichtlicher, als tausend eigenstellige Tags zu entwerfen, a la only_right_turn world_unique_name Bei Tags die bereits existieren tracktype=grade1, woodtype etc, brauchts wahrscheinlich noch ne kleinere Diskusion wie man solche sinvoll umsetzt. Ich seh hier einen brauchbaren Weg Tags-für-Tags zu erzeugen. Grüsse Raphael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhenmesser: Die Post war da :- )
Danke Chris-Hein fürs Umrechnen: http://www.geodaten.bayern.de/bvv_web/service/abc_netz/6434_108_00.htm N 49.572188792 E 11.407215225 (ETRS-89) soweit ich verstanden habe brauchen wir WGS-84 (und ETRS-89 weicht etwas davon ab?) Und dann bräuchte ich auch noch die Höhe als alt-wgs84=... Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Hallo Johann, entscheiden, welche besser sind, wie man diese zusammenrechnet. Ich vermute, da kann man mit intelligenten Algorithmen (Frederik sprach davon 09.02.2009 01:07) viel erreichen. Dazu gibt es eine Idee von Dimitri (14.02.2009 20:28): mehrere Meßwerte mitteln. Mapper 1 trägt einen Punkt ein der aber recht ungenau ist Mapper 2 verschiebt den Punkt auf den Ort den er gemessen hat, in OSM werden beide Koordinaten gespeichert und die Duchschnittsposition angezeigt. - api0.7 Höheninfos am besten automatisch aus einem GPX-File übernehmen. Will man dann die Höhe eines Punktes ermittel sucht man die nächsten 10 (oder so) Punkte und mittelt deren Höhe, ggf gewichtet nach Entfernung und GPS-Empfangsqualität. Initialisieren könnte man die Daten mit den vor kurzem hier erwähnten NASA-Daten. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hierarchisches Tagging
Hi Raphael. Raphael Studer wrote: Hi, Analog zu: addr:street= addr:city= addr:state= ... Nimmt man also: name= name:loc= name:reg= name:nat= name:disused= name:disused:1900-1975= name:loc:disused:1900-1975= ... Tönt nach einem sehr einfachen und brauchbaren Konzet. Das gleiche ergibt auch viel Sinn bei: access=no access:car=yes (= acces=car) access:car:1200-1800h=no ... natural=wood natural:wood:type=oak natural=water natural:water=lake ... restriction:turn:right=only restriction:turn:left=no restriction:straight=yes ... highway=footway highway:track=1 highway:track:surface=paved ... Das ist alles ins Unreine geschrieben und kann sicher noch durch Umstellen verbessert und ergänzt werden, aber als Grundprinzip macht es irgendwie Sinn und ich würde mir wünschen, dass vor allem bei neuen Tags darauf zurückgegriffen wird. Es skaliert einfach deutlich besser und ist übersichtlicher, als tausend eigenstellige Tags zu entwerfen, a la only_right_turn world_unique_name Bei Tags die bereits existieren tracktype=grade1, woodtype etc, brauchts wahrscheinlich noch ne kleinere Diskusion wie man solche sinvoll umsetzt. War von mir auch nicht als konkreter Vorschlag gedacht. Wollte das nur mal zu denken geben, um den Wildwuchs einzudemmen. :) Ich seh hier einen brauchbaren Weg Tags-für-Tags zu erzeugen. Wobei ich inzwischen manches vielleicht noch etwas anders machen würde. Analog zur Verfeinerung der Frage (sub-tags mit Doppelpunkt links vom =) würde ich auch bei der Antwort sub-tags einführen. Also statt: natural=wood natural:wood:type=oak natural=water natural:water=lake wäre hier logischer: natural=wood:oak natural=water:lake So kann man in einem tag verschiedene Detaillevel angeben und der Auswerter kann sich einfach aussuchen, wie weit er das auswertet. Bin allerdings nicht ganz sicher, ob das für den mapper immer klar wäre, wo man die Unterscheidung im Key (Frage) und wo im Value (Antwort) trifft. Gerit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Hallo Frederik, Meiner Ansicht muessen Hoehendaten in eine eigene Gelaendemodelldatenbank, die ganz anders strukturiert ist. eine Datenbank, die beliebige viele Hoehenmesspunkte mit lat/lon/ele festhalten kann und die daraus auf Anfrage Hoehenlinien, schattierte Kacheln oder Hoehenprofile einer vorgegebenen Geometrie berechnen kann, plus ein dazu passender Editor Starten koennte die Datenbank ja mit einem SRTM-Datensatz, der dann schrittweise verfeinert werden koennte. klingt gut. erfordert pfiffige Algorithmen Auch die Editoren sind kein Zuckerschlecken Ja, das sind grössere Herausforderungen... Wie würden die beiden DBs zusammenwirken? Genau so, wie wir jetzt schon mit SRTM-Daten arbeiten. Schnittstelle waere auf jeden Fall die Geometrie; die Hoehe haette mit OSM-Objekten rein gar nichts zu tun. Das verstehe ich nicht. Ich will doch wissen, wie hoch ein Pass/Berg/See/Haus ist. Und wenn das Tal in der Höhen-DB differiert zum Fluss in der Objekte-DB, das hängt doch dreidimensional unmittelbar zusammen - nur dass es halt nach Deinem Vorschlag auf zwei DBs verteilt ist? Wenn ich wissen will, wie der Hoehenverlauf der Strasse X ist, lasse ich mir von OSM die 2D-Geometrie der Strasse geben und frage dann die Hoehendatenbank nach einem Profil dafuer. Ok. Aber damit werden die die verteilten Daten ja wieder zusammengeführt und man braucht eine Regel, wie mit Abweichungen verfahren wird? Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhenmesser: Die Post war da :- )
Markus schrieb: Danke Chris-Hein fürs Umrechnen: http://www.geodaten.bayern.de/bvv_web/service/abc_netz/6434_108_00.htm N 49.572188792 E 11.407215225 (ETRS-89) soweit ich verstanden habe brauchen wir WGS-84 (und ETRS-89 weicht etwas davon ab?) Ja, wenn du es s genau haben willst, musst die Koordinate noch 50 cm nach SW verschieben. Da wäre aber die Frage, ob die angegebene GK Koordinate schon so genau ist. ;-) Und dann bräuchte ich auch noch die Höhe als alt-wgs84=... Höhe ist doch angegeben: 510.076 NN bezogen auf Platte. Dies ist die Oberseite des Pfeilers: http://img.geocaching.com/cache/268a4186-f368-4448-b02f-a31668c57d0f.jpg Die Platte ist 0,9 Meter darunter. http://www.lgnapp.niedersachsen.de/vkv/allgemein/gesetze/n3722319.htm Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Powerpoint-Präsentation
Für PP-Präsentationen gibt es folgende Beispiele, die von den Autoren als Basis für weitere Anwendungen zur Verfügung gestellt wurden: http://wiki.openstreetmap.org/wiki/de:Vorträge Vielleicht gibt es noch weitere? Wer kennt sich mit der Erstellung von Präsentationen aus und bietet seine Unterstützung an? - Gibt es ein schönes einheitliches OSM-Layout? - Wo findet man aktualisierte Zahlen? - Wo findet man Inhaltsbeschreibungen von Videos, Kartenanimationen? Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Markus schrieb: Hallo Frederik, Meiner Ansicht muessen Hoehendaten in eine eigene Gelaendemodelldatenbank, die ganz anders strukturiert ist. eine Datenbank, die beliebige viele Hoehenmesspunkte mit lat/lon/ele festhalten kann und die daraus auf Anfrage Hoehenlinien, schattierte Kacheln oder Hoehenprofile einer vorgegebenen Geometrie berechnen kann, plus ein dazu passender Editor Starten koennte die Datenbank ja mit einem SRTM-Datensatz, der dann schrittweise verfeinert werden koennte. klingt gut. +1 erfordert pfiffige Algorithmen Auch die Editoren sind kein Zuckerschlecken Ja, das sind grössere Herausforderungen... Wie würden die beiden DBs zusammenwirken? Genau so, wie wir jetzt schon mit SRTM-Daten arbeiten. Schnittstelle waere auf jeden Fall die Geometrie; die Hoehe haette mit OSM-Objekten rein gar nichts zu tun. Das verstehe ich nicht. Ich will doch wissen, wie hoch ein Pass/Berg/See/Haus ist. Und wenn das Tal in der Höhen-DB differiert zum Fluss in der Objekte-DB, das hängt doch dreidimensional unmittelbar zusammen - nur dass es halt nach Deinem Vorschlag auf zwei DBs verteilt ist? Ja, und man braucht dann ein Programm, dass die beiden DBs lokal zusammenführen kann, also man lädt seine OSM-Datei und lädt die Höhendaten und kann dann in diesem Programm die Straße meinetwegen anklicken und das Programm errechnet dann ein Höhenprofil für die Straße (vgl. yournavigation.org bzw. das GSoC-Projekt, da funktioniert das so) Wenn ich wissen will, wie der Hoehenverlauf der Strasse X ist, lasse ich mir von OSM die 2D-Geometrie der Strasse geben und frage dann die Hoehendatenbank nach einem Profil dafuer. Ok. Aber damit werden die die verteilten Daten ja wieder zusammengeführt und man braucht eine Regel, wie mit Abweichungen verfahren wird? Man führt sie aber ja nur lokal bzw. für den genauen Anwendungszweck zusammen, genauso wie wir es mit den SRTM-Daten auch machen. Ich bin ebenfalls für eine 2. DB als ein Art Schwesterprojekt zu OSM, wir brauchen noch einen guten Namen, Vorschläge? ;-) Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Powerpoint-Präsentation
Markus schrieb: Für PP-Präsentationen gibt es folgende Beispiele, die von den Autoren als Basis für weitere Anwendungen zur Verfügung gestellt wurden: http://wiki.openstreetmap.org/wiki/de:Vorträge Vielleicht gibt es noch weitere? Schau mal hier vorbei: http://www.slideshare.net/ und nutze die Suche nach osm oder openstreetmap Da findest du auch einige Präsentationen von der letztjährigen SOTM. Hier gibts auch sehr viel Material: http://svn.openstreetmap.org/misc/ (müsste mal ein bisschen besser aufbereitet werden) Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Hallo, Ich will doch wissen, wie hoch ein Pass/Berg/See/Haus ist. Dann fragst Du OSM, wo das Haus ist, und danach fragst Du die Hoehendatenbank nach der Hoehe an dieser Position. Dass da ein Haus steht, ist der Hoehendatenbank egal. Und wenn das Tal in der Höhen-DB differiert zum Fluss in der Objekte-DB, das hängt doch dreidimensional unmittelbar zusammen Das ist aber eine sehr grosse Ausnahme, das mit dem Fluss und dem Tal. Eine Eisenbahn oder eine Strasse koennte z.B. durchaus auch am Hang verlaufen und nicht unten im Tal; bei den allermeisten Objekten in OSM gibt es keinen natuerlichen Zusammenhang zwischen Lage und (relativer) Hoehe. Wenn ich wissen will, wie der Hoehenverlauf der Strasse X ist, lasse ich mir von OSM die 2D-Geometrie der Strasse geben und frage dann die Hoehendatenbank nach einem Profil dafuer. Ok. Aber damit werden die die verteilten Daten ja wieder zusammengeführt und man braucht eine Regel, wie mit Abweichungen verfahren wird? Wie gesagt, die beiden Daten sind in den allermeisten Faellen komplett unabhaengig, und sowas wie Abweichungen gibt es nicht. (Die OSM-Datenbank enthaelt keine Hoeheninformationen.) Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Hallo Frederik, Nach Deinem Vorschlag hätten wir: a) eine Objekt-DB mit x/y b) eine Höhen-DB mt z c) lokale Zusammenführung von a) und b) zu x/y/z wenn das Tal in der Höhen-DB differiert zum Fluss in der Objekte-DB, das hängt doch dreidimensional unmittelbar zusammen Das ist aber eine sehr grosse Ausnahme, das mit dem Fluss und dem Tal. Eine Eisenbahn oder eine Strasse koennte z.B. durchaus auch am Hang verlaufen und nicht unten im Tal; bei den allermeisten Objekten in OSM gibt es keinen natuerlichen Zusammenhang zwischen Lage und (relativer) Hoehe. Wenn ich wissen will, wie der Hoehenverlauf der Strasse X ist, lasse ich mir von OSM die 2D-Geometrie der Strasse geben und frage dann die Hoehendatenbank nach einem Profil dafuer. Ok. Aber damit werden die die verteilten Daten ja wieder zusammengeführt und man braucht eine Regel, wie mit Abweichungen verfahren wird? Wie gesagt, die beiden Daten sind in den allermeisten Faellen komplett unabhaengig, und sowas wie Abweichungen gibt es nicht. (Die OSM-Datenbank enthaelt keine Hoeheninformationen.) In der Realität hängen x/y und z /unmittelbar/ zusammen: - die Bahnlinie hat eine gleichmässige Steigung am Hang - wenn die Bahnlinie auf einen Berg trifft, wird ein Tunnel gebaut - wenn die Bahnlinie auf ein Tal trifft, wird eine Brücke gebaut - Tal und Brücke oder Tunnel und Berg müssen übereinstimmen - mein Zelt stelle ich eben auf (und nicht am Hang) - ein Haus am Hang braucht andere Anker als in der Ebene - ein See braucht eine Ebene (sonst läuft er aus) - ein Stausee braucht eine Staumauer an der richtigen Stelle - die Lawinenverbauung hat für optimale Wirkung einen genauen Standort - der Triangulationspunkt/Höhenmesspunkt ist xyz-definiert Das gilt eigentlich für alle Objekte. Wenn wir also x/y und z auf zwei DBs auftrennen, dann müssen wir für Konsistenz sorgen. Das muss m.E. direkt zwischen den DBs erfolgen (kann nicht auf Anwenderprogramme delegiert werden). Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Hallo, Markus wrote: Wenn wir also x/y und z auf zwei DBs auftrennen, dann müssen wir für Konsistenz sorgen. Das muss m.E. direkt zwischen den DBs erfolgen (kann nicht auf Anwenderprogramme delegiert werden). Das halte ich nicht fuer durchfuehrbar. Es muesste dazu ein kuenstlich intelligentes System gebaut werden, das solche Dinge auswertet, wie Du sie beschrieben hast - hier ist laut Datenbank 1 ein See ohne Staumauer, aber laut Datenbank 2 ist das Terrain so beschaffen, dass er auslaufen wuerde, undsoweiter. Also undurchfuehrbar ist vielleicht das falsche Wort; sagen wir mal so, der sehr grosse Implementierungsaufwand stuende in meiner Meinung nach in keinem Verhaeltnis zum zu erwartenden Nutzen. Ich strebe ein System an, in dem, aehnlich wie bei OSM, die Qualitaet der Daten durch viele und einfach leistbare Benutzerbeitraege zustande kommt, nicht ein System, an dem 5 Programmierer 2 Jahre lang arbeiten und das danach niemand benutzen kann. Eine Verknuepfung von beiden Informationen in einer Datenbank wuerde uns uebrigens nicht im geringsten davor bewahren, einen auslaufenden See zu konstruieren. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wiki hilfe: multi-sprach-seiten
{{Languages}}
Hatte ich gemacht.
Aber es erscheint nicht wie erhofft automagisch der Link
Also, ich hab jetzt einfach mal den Parameter rausgeworfen (und wirklich
nur {{Languages}} geschieben) und es geht anscheinend. Mit
{{Languages|Proposed_features/unified_stoparea}} wärs denk ich auch
gegangen (in der Vorschau zumindest).
Du hast es richtig gemacht.
Das Template kann noch nicht mit Unterseiten umgehen.
Ist auf der ToDo-Liste.
{{Languages|unified_stoparea}} geht wohl nicht, weil die Seite eben
Proposed_features/unified_stoparea heißt. Würde ich auch so erwarten,
oder?
Tobias Tordanik Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wiki - Uhrzeit
Moin ! mit der Unterschrift schreibt das Wiki immer Uhrzeit, Datum und Name. Kann man die Uhrzeit deaktivieren ? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki - Uhrzeit
Hi, Am 16. Februar 2009 12:11 schrieb Jan Tappenbeck o...@tappenbeck.net: mit der Unterschrift schreibt das Wiki immer Uhrzeit, Datum und Name. Kann man die Uhrzeit deaktivieren ? Nein. Mit drei Tilden unterdrückst du Zeit *und* Datum. Mit fünf Tilden unterdrückst du deinen Namen. Tschüss, Tim. -- http://wikipedistik.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki - Uhrzeit
On Mon, 16 Feb 2009 12:19:08 +0100, Tim 'avatar' Bartel openstreet...@computerkultur.org wrote: Hi, Am 16. Februar 2009 12:11 schrieb Jan Tappenbeck o...@tappenbeck.net: mit der Unterschrift schreibt das Wiki immer Uhrzeit, Datum und Name. Kann man die Uhrzeit deaktivieren ? Nein. Mit drei Tilden unterdrückst du Zeit *und* Datum. Mit fünf Tilden unterdrückst du deinen Namen. Warum msollte man die Uhrzeit unterdrücken wollehn? Es ist zum Verfolgen des Gespräches hilfreich wer nach wem geposted hat (ohne ständig die History zu konsultieren). Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Hallo Frederik, Wenn wir also x/y und z auf zwei DBs auftrennen, dann müssen wir für Konsistenz sorgen. Das muss m.E. direkt zwischen den DBs erfolgen (kann nicht auf Anwenderprogramme delegiert werden). Das halte ich nicht fuer durchfuehrbar. Ist eine dreidimensionale Geo-DB grundsätzlich undurchführbar? Wie machen das unsere Mitbewerber? sehr grosser Implementierungsaufwand Wäre der geringer, wenn wir x/y und z in einer DB hätten? Ich strebe ein System an, in dem die Qualitaet der Daten durch viele und einfach leistbare Benutzerbeitraege zustande kommt Ja, das finde ich gut. Eine Verknuepfung von beiden Informationen in einer Datenbank wuerde uns nicht davor bewahren, einen auslaufenden See zu konstruieren. Nein - aber wir würde den Fehler sofort unmittelbar erkennen. Bei einer horizontalen oder vertikalen Lageverschiebung ist immer auch die jeweilig andere Dimension betroffen. Horizontal und vertikal ist immer direkt voneinander abhängig. Sie sind nie voneinander unabhängig. Die zu lösende Aufgabe ist, wie wir die Konsistenz regeln. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Markus liste12a4...@gmx.de wrote: Ist eine dreidimensionale Geo-DB grundsätzlich undurchführbar? Mit GPS-Geräten ist die Antwort eindeutig ja. Wie machen das unsere Mitbewerber? AFAIK hat das Kartenmaterial von Navtec und Teleatlas ebenfalls keinen Höhenwert. Sven -- I'm a bastard, and proud of it (Linus Torvalds, Wednesday Sep 6, 2000) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wiki hilfe: multi-sprach-seiten
Ich bin in der OSM Welt und im Wiki unter Uboot zu finden. Vielleicht sollte ich das beim posten dazuschreiben wie unten. Gru=C3=9F, Markus 'uboot' St=C3=BCrmer signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hierarchisches Tagging
Wobei ich inzwischen manches vielleicht noch etwas anders machen würde. Analog zur Verfeinerung der Frage (sub-tags mit Doppelpunkt links vom =) würde ich auch bei der Antwort sub-tags einführen. Also statt: natural=wood natural:wood:type=oak natural=water natural:water=lake wäre hier logischer: natural=wood:oak natural=water:lake Ich würde den zweiten Vorschlag nicht als logischer, sondern kompatibler bezeichnen :) Aktuelle Datennutzer beschränken sich auf die Tags ohne Subtags. So kann man in einem tag verschiedene Detaillevel angeben und der Auswerter kann sich einfach aussuchen, wie weit er das auswertet. Bin allerdings nicht ganz sicher, ob das für den mapper immer klar wäre, wo man die Unterscheidung im Key (Frage) und wo im Value (Antwort) trifft. Den selben Gedanken hatte ich ebenfalls. Wenn es nur Antworten ohne Subtags gibt, ist klar dass alles andere vorne hin muss :) Grüsse Raphael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hierarchisches Tagging
On Mon, 16 Feb 2009, Raphael Studer wrote: Wobei ich inzwischen manches vielleicht noch etwas anders machen würde. Analog zur Verfeinerung der Frage (sub-tags mit Doppelpunkt links vom =) würde ich auch bei der Antwort sub-tags einführen. Also statt: natural=wood natural:wood:type=oak natural=water natural:water=lake wäre hier logischer: natural=wood:oak natural=water:lake Ich würde den zweiten Vorschlag nicht als logischer, sondern kompatibler bezeichnen :) Hoffentlich entwickelt es sich in diese Richtung, aber bis es soweit ist, müssen die Editoren noch viel lernen. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Hallo, Markus wrote: Bei einer horizontalen oder vertikalen Lageverschiebung ist immer auch die jeweilig andere Dimension betroffen. Nein, nur dann, wenn Lage und Hoehe gleichzeitig gemessen wurden. Wir haben aber viele nur-Lage-Daten und viele nur-Hoehen-Daten (SRTM sagt uns: an dieser Position ist die Hoehe X, ohne uns zu sagen, ob an der Postion ein Briefkasten ist; OSM sagt uns: an dieser Position ist ein Briefkasten, ohne uns zu sagen, wie hoch es da ist. Auch in Zukunft ist es sehr wahrscheinlich, dass wir Lage- und Hoehendaten aus ganz unterschiedlichen Quellen bekommen, denn die wenigsten werden einen Wendorff'schen Hoehenmesser mitfuehren, wenn sie mit dem GPS unterwegs sind. Aber letzten Ende ist es mir wurscht, wie es gemacht wird, Hauptsache, es faengt mal jemand an. Ewiges Rumdiskutieren, bevor die erste Zeile Code geschrieben ist, das ist was fuer Leute, die fuers Programmieren bezahlt werden ;-) Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Hallo, Siehst Du, wenn die Macher von OSM von Anfang an diese Detailverliebtheit besessen haetten, waere aus dem Projekt nie was geworden ;-) Nicht ganz, z.B. die Angabe von Meßfehlern hört sich erstmal kompliziert an, oft würde es aber reichen wenn man die Originaldaten speichert mit der Zusatzinfo ob sie von einem GPS-Gerät mit oder ohne Barometer stammen, oder ob sie als Fixpunkt dienen können (Schild auf der Zugspitze). Wenn wir z.B. jetzt erkennen das es sinnvoll GPX-Files als ganzes zu speichern weil Höhenunterschiede genauer sind als die absoluten Höhen wäre es töricht ein GPX-File zu übertragen und dann Einzelpunkte in die Datenbank einzutragen. In einer ersten Version muß diese info noch nicht ausgewertet werden, aber verwerfen sollte man sie nicht. Und wenn ich mir überlege wie viele gpx-Files bereits in der OSM-Datenbank schlummern könnte man eigentlich gleich loslegen - auch wenn es Datenbanktechnisch von den OSM-Daten getrennt sein soll sollte es soweit mit OSM verbunden sein, daß man diese Daten nutzen kann. Wenn ich mir mal ein GPX-File ansehe, dann steht da bei mir: trkpt lat=50.775800 lon=6.095028 time2009-02-09T15:48:10Z/time ele230.2/ele sat4/sat hdop3.6/hdop /trkpt Aus der Angabe von sat kann man schließen daß es ein GPS-File ist und nicht irgendwie anders entstanden ist, aus der Anzahl der Satelliten und hdop kann man in etwa den Meßfehler abschätzen (frag mich nicht wie) Ich vermute, daß GPS-Geräte mit Barometer einen zusätzlichen Tag für den Luftdruck haben und so als solche erkennbar sind. Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhenmesser: Die Post war da :- )
Hallo, Naja, eine Datenbank halt, die beliebige viele Hoehenmesspunkte mit lat/lon/ele festhalten Hier müßte die Meßgenauigkeit noch rein. Die SRTM-Daten sind ja wohl über recht große Flächen gemittelt. GPS-Daten haben meist eine sehr genaue horizontale Genauigkeit aber eine schlechte Höheninfo. Und wenn ich mit meinem GPS auf der Zugspitze stehe und dort auf einem Schild die Höhe ablese sollten alle 3 Koordinaten recht genau sein. Auch interessant könnte sein Meßwertreihen zu koppeln. Wenn man z.B. mit einem Barometrischen Höhenmesser eine Wanderung macht ist ggf die absolute Höhe ungenau, aber der Höhenunterschied zwischen 2 Punkten sehr genau. Man müßte also die Originaldaten speichern incl einer Info wie sie ermittelt wurden, bzw wenn der Mapper den Meßfehler kennt auch diesen. Dann muß man über die Daten eine Iterative Anpassung laufen lassen. Als Zusatzinfos könnte man noch eingeben wo z.B. Steilwände sind. Weil sonst die Anpassung wersuchen wird diesen abzuflachen. Auch muß man unterscheiden ob man die Bodenhöhe oder die Dachhöhe mißt, bei SRTM ist es ja wohl letzteres. Wenn ich wissen will, wie der Hoehenverlauf der Strasse X ist, lasse ich mir von OSM die 2D-Geometrie der Strasse geben und frage dann die Hoehendatenbank nach einem Profil dafuer. Hier würde optimalerweise natürlich geschaut ob es nicht einen Meßreihe dieser Straße gibt, denn wie schon erwähnt sind evtl die Steigungen genauer bekannt als die absolute Höhe. Wobei das eigentlich eine Info ist die wieder besser in die OSM-Datenbank passen würde Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Hallo, Ist eine dreidimensionale Geo-DB grundsätzlich undurchführbar? Wie machen das unsere Mitbewerber? So wie ich es sehe ist der Unterschied der, in OSM geht man vom Objekt aus und dieses enthält die Info wo es ist. Eine Höhendatenbank geht eher umgekehrt vor, also von den Koordinaten zur Höheninfo. OSM enthält eindeutige (wenn auch ggf falsche) Daten während eine Höhendatenbank sinnvollerweise aus allen Daten ein Höhenmodell berechnet und dies zur Verfügung stellt, vergleichbar zur Pixelkarte. Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhenmesser: Die Post war da :- )
Hallo, Das geht in den Faellen schief, wo das durch den Punkt bezeichnete Objekt physisch verschoben wurde, also z.B. bei einem Briefkasten, der von Ort A nach Ort B ca. 100 entfernt umgesetzt wurde. Etwas mehr muß man in die Funktion schon reinstecken. Man muß unterscheiden zwischen einem Verschieben wie bisher und einem neuer Meßwert Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Hallo, Ich bin ebenfalls für eine 2. DB als ein Art Schwesterprojekt zu OSM, wir brauchen noch einen guten Namen, Vorschläge? ;-) OpenElevationMap Gruß Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhenmesser: Die Post war da :- )
Hallo Marco, Marco Horstmann schrieb: kannst du da ein paar mehr Details verraten wie der dann aussehen und funktionieren soll? Daran wird gerade gearbeitet, sobald der Prototyp funktioniert, werden die Ergebnisse veröffentlicht. Auch bin bezug auf die Eintragung in OSM, weil habe noch keine Werte für die Höhe gesehen. Gibt es ne Projektseite, wo du über den Fortschritt berichtest? Ich denke, ich werde ein Parallelprojekt dazu aufziehen, welches mit OSM eng verknüpft wird. Grund dafür ist, dass viele Leute Höheninformationen nicht drin haben wollen. Grüße Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhenmesser: Die Post war da :- )
Markus schrieb: http://www.geodaten.bayern.de/bvv_web/service/abc_netz/6434_108_00.htm Aber ich habe keine Ahnung, wie ich das in WGS-84 umrechne... Mensch Markus, das haben wir doch schon 100x besprochen. Höhen werden nicht in WGS84 umgerechnet, sondern als Höhe über dem Geoid angeben. Also nicht WGS84, sondern EGM96 !!! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhenmesser: Die Post war da :- )
Markus schrieb: soweit ich verstanden habe brauchen wir WGS-84 (und ETRS-89 weicht etwas davon ab?) Wenn Du es allgemein willst, dann EGM96. Wenn Du es auf Deutschland bezogen willst, dann CG05 etc. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
2009/2/16 Dimitri Junker o...@dimitri-junker.de: Hallo, Ich bin ebenfalls für eine 2. DB als ein Art Schwesterprojekt zu OSM, wir brauchen noch einen guten Namen, Vorschläge? ;-) OpenElevationMap (OEM?) oder OpenTerrainModel (OTM) oder open elevation and surface (OpEaS) [Opeas ist übrigens eine Schneckenart] Die Idee, einer 2. Datenbank finde ich Prima! Die kann man weiterdenken. Möglicherweise findet sich ja ein Satz Diplomanden, die das ganze zu ihrem Projekt machen wollen. Im ersten Stadium sollten die SRTM Daten visualisiert werden, man müsste sich über eine Datenstruktur einigen. Will man ein Raster oder frei positionierbare Referenzpunkte usw. Dann könnte schon gesammelt werden :) Weiter so Torstiko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki - Uhrzeit
Hallo, eine Idee wäre, weil vielleicht der Chef auch in OSM aktiv ist? Mfg Marco marcus.wolsc...@googlemail.com schrieb: On Mon, 16 Feb 2009 12:19:08 +0100, Tim 'avatar' Bartel openstreet...@computerkultur.org wrote: Hi, Am 16. Februar 2009 12:11 schrieb Jan Tappenbeck o...@tappenbeck.net: mit der Unterschrift schreibt das Wiki immer Uhrzeit, Datum und Name. Kann man die Uhrzeit deaktivieren ? Nein. Mit drei Tilden unterdrückst du Zeit *und* Datum. Mit fünf Tilden unterdrückst du deinen Namen. Warum msollte man die Uhrzeit unterdrücken wollehn? Es ist zum Verfolgen des Gespräches hilfreich wer nach wem geposted hat (ohne ständig die History zu konsultieren). Marcus ___ 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] Hierarchisches Tagging
Am 16. Februar 2009 13:46 schrieb Dirk Stöcker openstreet...@dstoecker.de: On Mon, 16 Feb 2009, Raphael Studer wrote: Wobei ich inzwischen manches vielleicht noch etwas anders machen würde. Analog zur Verfeinerung der Frage (sub-tags mit Doppelpunkt links vom =) würde ich auch bei der Antwort sub-tags einführen. Also statt: natural=wood natural:wood:type=oak natural=water natural:water=lake wäre hier logischer: natural=wood:oak natural=water:lake Ich würde den zweiten Vorschlag nicht als logischer, sondern kompatibler bezeichnen :) Hoffentlich entwickelt es sich in diese Richtung, aber bis es soweit ist, müssen die Editoren noch viel lernen. +1 Mir gefällt der zweite Vorschlag sehr gut. Der erste mag vielleicht auch seine Berechtigung haben, ist aber nicht 100% alltagstauglich, da schwerer zu erlernen. Ihr habt meine Unterstützung. Gerne könnt ihr diese Diskussion auch auf die entprechenden talk-Seiten im Wiki tragen. Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Torsten Breda schrieb: Im ersten Stadium sollten die SRTM Daten visualisiert werden, man müsste sich über eine Datenstruktur einigen. Nunja, das ist im Endeffekt ziemlich simpel ... daher finde ich, dass man sich zuerst über das Hosting Gedanken machen sollte :-) Will man ein Raster oder frei positionierbare Referenzpunkte usw. Dann könnte schon gesammelt werden :) Aber dann lieber über eine eigene Liste ... talk-elvation oder so? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbilder aus Bayern - Halbzeit
Hallo André, http://osm.m0nty.de/ http://wiki.openstreetmap.org/wiki/de:OberpfalzMatrix:Luftbilder_Arbeitsmatrix_Oberpfalz Ich denke, wir sollten uns auf /ein/ System einigen! Das dachte ich auch. Aber: - die Systeme scheinen nicht kompatibel - für beide Systeme gibt es eine engagierte Benutzergruppe Letztlich geht es ums Erfassen der Geo-Daten. Die Statistik ist nur Beiwerk. Und beide Systeme helfen noch gezielter zu erfassen. Vielleicht wissen wir ja nach Abschluss des Projektes, welches System sich besser bewährt hat? Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbilder aus Bayern - Halbzeit
Frederik hat zwei neue Grafiken erstellt: - erfasste Strassen in der Operpfalz - erfasste Strassen in einem Vergleichsgebiet http://wiki.openstreetmap.org/wiki/de:Luftbilder_aus_Bayern#Erfolge Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Hallo Torsten, OpenAltitudeMap (OAM) _Altitude_ Ich bin für *Altitude*. Misst man ja auch mit dem *Altimeter*. (Elevation ist ja eigentlich ein Winkel) Die Idee, einer 2. Datenbank finde ich Prima! Da bin ich noch nicht so sicher... Denn letztlich geht es ja darum, reale Objekte in drei Dimensionen zu verorten. Und ich verstehe noch nicht so recht, wieso nun eine Dimension für alle Objekte ausgelagert werden soll - nur um sie danach wieder zusammenzuführen. Die Schwierigkeiten der Dreidimensionalität bleiben m.E. so oder so dieselben. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Hallo, ich habe schon seit einiger Zeit einen Domännamen registriert: http://www.opendtm.org derzeit noch mit Weiterleitung auf http://www.opengeocoding.org (Geokodierung) Meine Intention: Freies, weltweites Höhenmodell, Ausgangspunkt: SRTM, mit schrittweiser Verfeinerung und Ergänzung, ähnlich http://www.openaerialmap.org/ Diese Domain kann ich gerne zur Verfügung stellen bzw. vermutlich auf Server-Ressourcen auf unserem Hochschulserver. Zur Zeit in Vorbereitung: - PostGIS-DB mit Höhenlinien (abgeleitet aus SRTM-Daten, in Zusammenarbeit mit Geofabrik) - Tiles Gruß Franz-Josef -- Participate in http://www.opengeocoding.org! We live at the start of the information age and not enough people care that someone else gains rights to their personal things, their information, friends, images, photos, music... People really need to read the licenses they sign up to. http://www.guardian.co.uk/users/ivanidea Prof. Dr. Franz-Josef Behr - Home Office Author of: Strategisches GIS-Management - http://www.gis-management.de eMail: franz-josef.b...@hft-stuttgart.de http://www.gis-news.de Tel: +49 (0)721 / 453980-1 sowie 45 33 35 Fax: +49 (0)721 / 453980-7 sowie via web.de: +49 (0)1212-5-12048213 Torsten Breda schrieb: 2009/2/16 Dimitri Junker o...@dimitri-junker.de: Hallo, Ich bin ebenfalls für eine 2. DB als ein Art Schwesterprojekt zu OSM, wir brauchen noch einen guten Namen, Vorschläge? ;-) OpenElevationMap (OEM?) oder OpenTerrainModel (OTM) oder open elevation and surface (OpEaS) [Opeas ist übrigens eine Schneckenart] Die Idee, einer 2. Datenbank finde ich Prima! Die kann man weiterdenken. Möglicherweise findet sich ja ein Satz Diplomanden, die das ganze zu ihrem Projekt machen wollen. Im ersten Stadium sollten die SRTM Daten visualisiert werden, man müsste sich über eine Datenstruktur einigen. Will man ein Raster oder frei positionierbare Referenzpunkte usw. Dann könnte schon gesammelt werden :) Weiter so Torstiko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de begin:vcard fn:Dr. Franz-Josef^Behr n:Behr;Franz-Josef org:Stuttgart University of Applied Sciences (SUAS);Faculty of Geomatics, Computer Science and Mathematics adr;quoted-printable:;;Schellingstra=C3=9Fe 24, ;Stuttgart;;D-70174;Germany title:Prof. tel;work:+49) 711/8926-2606 tel;home:+49 (0)721 / 453980-1 url:http://www.hft-stuttgart.de/ version:2.1 end:vcard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
2009/2/16 Tobias Wendorff tobias.wendo...@uni-dortmund.de: Torsten Breda schrieb: Im ersten Stadium sollten die SRTM Daten visualisiert werden, man müsste sich über eine Datenstruktur einigen. Nunja, das ist im Endeffekt ziemlich simpel ... daher finde ich, dass man sich zuerst über das Hosting Gedanken machen sollte :-) Will man ein Raster oder frei positionierbare Referenzpunkte usw. Dann könnte schon gesammelt werden :) Aber dann lieber über eine eigene Liste ... talk-elvation oder so? Ich würde es erst hier auf der Liste lassen. Hier gibt es topics die wesentlich weiter im off sind, aber das ist eine andere Sache. Lese mich gerade auf http://www.terrainmap.com/ in das Thema ein, da ich mich damit noch gar nicht beschäftigt habe. Dazu eine Frage eines Laiens: Kann man nich alle verfügabaren Höhendaten in einer gemeinsamen Datenbank vereinen? Sozusagen die SRTM als Grundlage, die Löcher mit geringer aufgelöstem Material stopfen und Bereiche zu denen genauere DEMs verfügbar sind ergänzen? (Nicht lachen, ich lese mich wirklich gerade erst ein) Gruß Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Am 16. Februar 2009 15:41 schrieb Dr. Franz-Josef Behr franz-josef.b...@hft-stuttgart.de: Meine Intention: Freies, weltweites Höhenmodell, Ausgangspunkt: SRTM, mit schrittweiser Verfeinerung und Ergänzung, ähnlich http://www.openaerialmap.org/ Genau das war meine Laienfrage :) Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Hallo. Am Montag, 16. Februar 2009 schrieb Markus: Und ich verstehe noch nicht so recht, wieso nun eine Dimension für alle Objekte ausgelagert werden soll - nur um sie danach wieder zusammenzuführen. Weil es bei geschätzten 99% der OSM-Datenquellen keine brauchbaren Höheninformationen gibt. Eine fest eingebaute Höheninfo im Sinne dessen dass jedes Objekt eine Höhe haben kann verleitet dazu, irgendwelche Höhen einzutragen die das GPS-Gerät halt so anzeigt. Das kann dir an einer Kreuzung plötzlich 20 Meter Steilhang erzeugen weil die GPS-Geräte die Höhe halt falsch erfasst haben. In einer separaten Datenbank läd man hoffentlich nur etwas hoch was auch aus einer geeigneten Quelle kommt (z.B. barometrischer Höenmesser) Außerdem erfordert dreidimensionales Kartografieren IMHO eine andere Editor-Herangehensweise. Für 2D gefällt mir aber unser bisheriges Konzept ganz gut. Gruß, Bernd -- erno hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Dr. Franz-Josef Behr schrieb: ich habe schon seit einiger Zeit einen Domännamen registriert: http://www.opendtm.org Mal generell eine Übersicht: Digital Terrain Modell, Digitales Geländemodell, Digital Elevation Modell = Objekte auf der Erdoberfläche (z.B. Wälder, Häuser) Digitales Höhenmodell = keine Objekte auf der Erdoberfläche Wichtig ist jedoch, dass bei einem solchem Modell eine Triangulation (regelmäßig oder unregelmäßig) stattgefunden hat. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Hallo, Markus wrote: Denn letztlich geht es ja darum, reale Objekte in drei Dimensionen zu verorten. Eigentlich ist unser derzeitiger Hauptanwendungszweck der, dass wir auch fuer die Gegenden, in denen sich keine Objekte befinden, schoene Topokarten malen wollen. Also gerade nicht verortete Objekte sondern nur ein Oberflaechenmodell. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Torsten Breda schrieb: Lese mich gerade auf http://www.terrainmap.com/ in das Thema ein, da ich mich damit noch gar nicht beschäftigt habe. Dazu eine Frage eines Laiens: Kann man nich alle verfügabaren Höhendaten in einer gemeinsamen Datenbank vereinen? Sozusagen die SRTM als Grundlage, die Löcher mit geringer aufgelöstem Material stopfen und Bereiche zu denen genauere DEMs verfügbar sind ergänzen? (Nicht lachen, ich lese mich wirklich gerade erst ein) Sowas gibt es ja schon: CIGAR etc. die haben anhand von topographischem Kartenmaterial die Fehler aus den SRTM rausgeholt. Allerdings ist die Lizenz nicht cc-by-sa kompatibel... Klar wäre es sinnvoll, als Basis auf SRTM zurückzugreifen, allerdings müsste dann komplett neue Software zu Korrektur der SRTM-Daten geschrieben werden. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Markus schrieb: Hallo Torsten, OpenAltitudeMap (OAM) Das ist schlecht, weil OAM schon die OpenAerialMap ist: http://openaerialmap.org/ Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Hallo, Jonas Krückel (John07) wrote: OpenAltitudeMap (OAM) Das ist schlecht, weil OAM schon die OpenAerialMap ist: http://openaerialmap.org/ Ich haette gern einen Namen, der als Akronym OMG-LOL ergibt, aber ich bin nicht kreativ genug dazu ;-) Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Tobias Wendorff schrieb: Torsten Breda schrieb: Lese mich gerade auf http://www.terrainmap.com/ in das Thema ein, da ich mich damit noch gar nicht beschäftigt habe. Dazu eine Frage eines Laiens: Kann man nich alle verfügabaren Höhendaten in einer gemeinsamen Datenbank vereinen? Sozusagen die SRTM als Grundlage, die Löcher mit geringer aufgelöstem Material stopfen und Bereiche zu denen genauere DEMs verfügbar sind ergänzen? (Nicht lachen, ich lese mich wirklich gerade erst ein) Sowas gibt es ja schon: CIGAR etc. die haben anhand von topographischem Kartenmaterial die Fehler aus den SRTM rausgeholt. Allerdings ist die Lizenz nicht cc-by-sa kompatibel... Die Frage ist unter welcher Lizenz eine Höhendatenbank stehen sollte. Sie müsste sowohl zu SRTM als auch zu OSM kompatibel sein. Vllt. die neue Lizenz von der OSMF? Ich glaube es gibt genug Leute die an solch einer Datenbank Interesse haben und als Schwesterprojekt von OSM hat das durchaus gute Chancen. Zum Thema fällt mir http://wiki.openstreetmap.org/wiki/Route_altitude_profiles_SRTM noch ein, ich denke der Autor hat da schon einiges an Wissen sich aneigenen können und ist vermutlich auch an einer Zusammenarbeit interessiert. Obwohl er nur SRTM-Daten verwendet hat, sind die bei yournavigation angezeigten Ergebnisse selbst für eine 5km Fahrradtour relativ gut, auf jeden Fall bekommt man einen Eindruck, wie die Strecke aussehen wird. (Offtopic: Ich will eine Router, der schon beim berechnen das Höhenprofil miteinbezieht) Wie sieht es eigentl. mit Schildern aus, auf denen die Höhe steht (auf Gipfeln etc.) Ich denke, die sind nicht irgendwie geschützt, oder? Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Frederik Ramm schrieb: Hallo, Jonas Krückel (John07) wrote: OpenAltitudeMap (OAM) Das ist schlecht, weil OAM schon die OpenAerialMap ist: http://openaerialmap.org/ Ich haette gern einen Namen, der als Akronym OMG-LOL ergibt, aber ich bin nicht kreativ genug dazu ;-) FTW im Namen wäre auch noch cool. Irgendwie Free the ... ;-) Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Hallo Frederik, letztlich geht es ja darum, reale Objekte in drei Dimensionen zu verorten. Eigentlich ist unser derzeitiger Hauptanwendungszweck der, dass wir auch fuer die Gegenden, in denen sich keine Objekte befinden, schoene Topokarten malen wollen. Also gerade nicht verortete Objekte sondern nur ein Oberflaechenmodell. Jede Karte entsteht doch aus Punkten, die irgendwie verortet werden? Jeder Punkt hat drei Dimensionen (wenn man die Historie als Zeit dazu nimmt sind es vier). Und aus der Gesamtschau vieler Punkte und ihrer Lage zueinander ergibt sich das Abbild der Realität als Karte? Das ist bei einem Oberflächenmodell doch auch so? Solange man keine Ansprüche an Genauigkeit hat, kann man vieles weglassen. Sogar ganze Dimensionen. Man kann auch mehrere Dimensionen zweidimensional abbilden, zumindest wenn man sich mit Symbolen behilft (Berggipfel, Steigung, Schraffur, Steilwand, Böschung, Senke). Sobald man es aber genauer braucht, man also wissen will, ob ein Weg ober- oder unterhalb eines Felsbandes vorbeiführt, oder welche von mehreren Bücken die obere ist, oder ob eine Wendeltreppe (Ringtunnel) nach oben oder unten führt, dann kommt man ohne Höhe nicht aus. Ein Weg auf einer Staumauer braucht nur wenige Meter verschoben sein, und schon fällt man sehr tief und/oder wird sehr nass. Das ist doch absolut unabhängig davon, ob die Punkte erst zweidimensional erfasst und dann mit Höhendaten richtig oder falsch kombiniert, oder gleich dreidimensional richtig oder falsch erfasst werden? Und sobald ich in einen nur-Oberflächenmodell etwas baue, oder pflanze oder finde, dann ist doch alles wieder eins...? Und auch die Genauigkeit der Erfassung betrifft doch spätestens nach der Zusammenführung der drei Dimensionen das xyz-Modell genauso wie das xy/z-Modell? Wenn ich die Höhe nicht genau erfasse, oder bei der Verschiebung eines Objektes nicht alle drei Dimensionen anpasse, dann ergibt das einen Fehler, der in beiden Modellen gleichermassen wirkt? Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] waterway=riverbank plus name?
Am 15.02.2009 22:51, Christoph Wagner: Carsten Gerlach schrieb: mir ist neulich aufgefallen, daß an einigen Stellen der Flussname irgendwo auf dem Festland steht, z.B hier (Mapnik): ... Ich vermute, das liegt am zusätzlichen name-Tag am waterway=riverbank. Wird der Name da auf dem Flächenschwerpunkt dargestellt? Wenn ja, dann sollte der Name _nur_ an das waterway=river und _nicht_ an das waterway=riverbank. Ja wird er. Naja... Wie ist da die Meinung der alten Hasen? Grüße, Carsten Also das Thema war bei uns auch schon diskutiert, aber eine richtige Lösung haben wir auch nicht. Ich fasse mal zusammen: Rein inhaltlich wäre es richtig den Namen an die riverbank zu taggen, da sonst später keine Beziehung mehr zu dem Fluss hergestellt werden kann (höchstens über die Geometrie...). Meiner Meinung nach ist das ganz klar ein Problem des Renderers. Mapnik sollte wahrscheinlich am besten den Namen bei riverbank überhaupt nicht rendern. Stattdessen sollte nur der Name an der river linie gerendert werden. Wenn das alles so bekannt ist frage ich mich schon, warum es dann noch kein Ticket dazu gibt. Wie sonst sollen der Mapnik-Stilbearbeiter davon erfahren: http://trac.openstreetmap.org/ticket/1599 Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Hallo, Markus wrote: Jede Karte entsteht doch aus Punkten, die irgendwie verortet werden? Dein Posting enthielt zu viele Fragezeichen. Ich glaube, wir reden nicht nur aneinander vorbei, sondern wir denken auch so verschieden, dass es gar keinen Sinn hat, weiter darueber zu reden. Was ich von einer Hoehendatenbank will ist: Zu einer gegebenen Position die Hoehe erfahren. Sonst nichts. Das ist eine einfache Aufgabe, die mir loesbar scheint. Ich will nicht wissen, ob an der Position ein See ist oder ein Berg oder ein Briefkasten, eine Staumauer, ein Haus oder kein Haus. Die aktuellen Anwendungen zeigen uns, dass man mit einer solchen Datenbank schon sehr viel gute Sachen machen kann. Nur sind die aktuell verfuegbaren Daten eben z.T. arg loechrig. Das will ich gern beheben. Sonst nichts. Und mit OpenStreetMap hat das im Grunde gar nicht so viel zu tun. Eventuell kann man die Hoehendaten ja spaeter als WMS-Layer im JOSM anzeigen, dann hilft das dem Mapper, den Way richtig einzuzeichnen. Der Mapper weiss ja, ob er auf dem Bergkamm oder im Tal gelaufen ist. Der Rechner kann das nicht wissen. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Idee zu Routing-Anwendungen (Foto-Routing)
Hallo Community, könnte man unsere Routing-Dienste (z.B. OpenRouteService) erweitern, indem man sich Fotos entlang der Route anzeigen lassen kann? Ich habe in den letzten Wochen rund 200 Fotos von POIs, Straßen und Kreuzungen gemacht und diese mit GPS-Koordinaten verstehen. Wenn man jetzt von Punkt A zu Punkt B will, steht da natürlich nur rechts abbiegen auf Straße xy. Viel schöner wäre es doch, wenn man Fotos von den Straßenkreuzungen oder markanten Punkten auf der Karte anzeigen könnte. Ich könnte meine Bilder jetzt natürlich bei Flicker etc. hochladen und über Google Maps anzeigen lassen aber ... neee. JOSM hat ja ein GeoTag-Plugin ... so könnte jeder mitmachen. Grüße Tobias ps: Gibt es eigentlich einen OSM-Dienst, wie Flicker, auf dem ebensolche Fotos mit Geo-Informationen gespeichert werden können? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Frederik Ramm schrieb: Der Mapper weiss ja, ob er auf dem Bergkamm oder im Tal ^ Jetzt, wo ich das Wort so lese, glaube ich zu wissen, wie der Ortsname Bergkamen entstanden ist :-) SCNR ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
On Mon, 16 Feb 2009 15:57:07 +0100, Frederik Ramm frede...@remote.org wrote: Hallo, Jonas Krückel (John07) wrote: OpenAltitudeMap (OAM) Das ist schlecht, weil OAM schon die OpenAerialMap ist: http://openaerialmap.org/ Ich haette gern einen Namen, der als Akronym OMG-LOL ergibt, aber ich bin nicht kreativ genug dazu ;-) Open Meta Geometry - Level Over Liquid Liquid meaning ozean. :) Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhenmesser: Die Post war da :- )
Dimitri Junker schrieb: er will doch einen druckbasierten Höhenmesser bauen Die wahrscheinlichkeit, daß sich ein großer Teil der Mapper sowas zulegt ist doch eher gering. Die Wahrscheinlichkeit, dass bereits ein grosser Teil der Mapper sowas hat, ist aber auch nicht zu vernachlaessigen. Bei den Geraeten fuer den Outdoor-Einsatz (Wandern, Radfahren) ist das doch quasi Standard. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Idee zu Routing-Anwendungen (Foto-Routing)
Hallo. Am Montag, 16. Februar 2009 schrieb Tobias Wendorff: ps: Gibt es eigentlich einen OSM-Dienst, wie Flicker, auf dem ebensolche Fotos mit Geo-Informationen gespeichert werden können? Meines Wissens nicht. Aber wenn du mal hochrechnest, kommst du ganz schnell auf mehr als nur erhebliche Speichermengen. Ich habe neulich mal die Mapping-verwertbaren Fotos des letzten Jahres bei mir gebrannt (Straßennamen, Briefkästen, ...) und das alleine waren über eine DVD voll. Wenn das jetzt hunderte machen, kommen da Terabyteweise Daten zusammen die man alle Hosten und vor allem auch performant und idealerweise mit Traffic-Flatrate zugänglichen machen muss. Gruß, Bernd -- Seit die Mathematiker über die Relativitätstheorie hergefallen sind, verstehe ich sie selbst nicht mehr. - Albert Einstein signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Markieren von Rodelstrecken / Schlittelwegen
Hallo, Am Mo, 16. Februar 2009 schrieb Michael Buege: Zitat Marian Flor: gibt es ein Zusatzattribut (evtl. auch erst im Status proposed), mit dem Feldwege (highway=track und bspw. tracktype=grade2) als Rodelweg bzw. Schlittelweg markiert werden können? Wenn du nichts passendes findest, denk dir was aus. Das beste was ich kenne ist: http://wiki.openstreetmap.org/wiki/Proposed_features/Piste_Maps (piste:type=...) Ich habe damit zum Teil auch schon an gleicher Stelle verlaufende Wege ergänzt. Und InformationFreeway zeigt dann (z.B. bei Langlaufloipen) auch einen Roten Strich in dem Weg ... Viele Grüße, -- Holger Schoener nume...@ancalime.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Jonas Krückel (John07) schrieb: Man führt sie aber ja nur lokal bzw. für den genauen Anwendungszweck zusammen, genauso wie wir es mit den SRTM-Daten auch machen. Ich bin ebenfalls für eine 2. DB als ein Art Schwesterprojekt zu OSM, Dann geht aber die Information verloren, wie die Daten zusammenpassen. Wenn ich das Hoehenprofil einer Strasse aufnehme, dann muss ich ja auch wissen, dass die Hoehen eben ganau zu dieser Strasse gehoeren und nicht zu irgendwelchen querenden Ueberfuehrungen. Insofern scheint es mir doch wesentlich sinnvoller, die Hoeheninformationen in die OSM-Datenbank mitzuspeichern. Andernfalls kann man als Ergebnis halt kein ordentliches Hoehenprofil fuer die einzelnen Objekte zusammenbekommen, sondern nur eine grobe Huellflaeche, wie man sie ja mit den SRTM-Daten bereits hat. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Frederik Ramm schrieb: Was ich von einer Hoehendatenbank will ist: Zu einer gegebenen Position die Hoehe erfahren. Sonst nichts. Das sehe ich anders. Ich habe einen Weg, der vom Punkt A ueber B nach C verlaeuft. Und fuer diesen Weg will ich nun wissen, in welcher Hoehe der Weg an den drei Punkten ist. Ob einer der Punkte nun 5m nach Osten verschoben ist, ist mir dabei erstmal egal. Es darf aber nicht passieren, dass sich durch diese Verschiebung die Hoehe um ein paar hundert Meter aendert (siehe das Beispiel mit der Staumauer). Insofern braucht meine nicht einfach eine Datenbank, die fuer Lat-Lon-Positionen einem jeweils einen Hoehenwert liefert (das kann SRTM ja an den meisten Stellen hinreichend gut). Was man braucht, ist eine Datenbank, die fuer die einzelnen Objekte die jeweilige Hoehe liefert. Und eben wegen diesen Zusammenhang zwischen Hoehe und Objekt, macht eine getrennte Hoehendatenbank in meinen Augen auch keinen Sinn. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Welche Straßen fehlen noch in Erfurt ?
Hallo Liste, ich würde gern mal wissen welche Straßen in Erfurt noch fehlen. Dazu gibt es ja irgendwie eine Möglichkeit das herauszubekommen. Ich habe aber absolut keine Ahnung wie das geht. Erfurt liegt ungefähr in dem Koordinatenbereich N51.06 E10.9 x N50.93 E11.10 . Auf der Internetseite http://www.erfurt-web.de/Straßenverzeichnisalphabet ist ein Verzeichnis Erfurter Straßen zu finden. Wer kann mir da weiterhelfen? Wie muss diese Liste aufbereitet werden? Vielen Dank Ciao Holger ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbilder aus Bayern - Halbzeit
Markus schrieb: - erfasste Strassen in der Operpfalz - erfasste Strassen in einem Vergleichsgebiet Was verbirgt sich denn hinter diesem steil ansteigenden other? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Idee zu Routing-Anwendungen (Foto-Routing)
On 02/16/2009 04:52 PM, Tobias Wendorff wrote: ps: Gibt es eigentlich einen OSM-Dienst, wie Flicker, auf dem ebensolche Fotos mit Geo-Informationen gespeichert werden können? Gibt es lizenzrechtliche Probleme die Flickr API zu benutzen und zu jeder Koordinate Fotos zu suchen und die dann über der Slippy Map anzuzeigen. Mit dem POI Example vom Wiki sollte sich das doch relativ leicht erledigen lassen, oder spricht da was dagegen? (Abgesehen vielleicht von dem massiven Traffic den man durch das andauernde Suchen von Fotos per Flickr API verursacht.) Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Idee zu Routing-Anwendungen (Foto-Routing)
Tobias Wendorff schrieb: Hallo Community, könnte man unsere Routing-Dienste (z.B. OpenRouteService) erweitern, indem man sich Fotos entlang der Route anzeigen lassen kann? Ich habe in den letzten Wochen rund 200 Fotos von POIs, Straßen und Kreuzungen gemacht und diese mit GPS-Koordinaten verstehen. Wenn man jetzt von Punkt A zu Punkt B will, steht da natürlich nur rechts abbiegen auf Straße xy. Viel schöner wäre es doch, wenn man Fotos von den Straßenkreuzungen oder markanten Punkten auf der Karte anzeigen könnte. Ich könnte meine Bilder jetzt natürlich bei Flicker etc. hochladen und über Google Maps anzeigen lassen aber ... neee. JOSM hat ja ein GeoTag-Plugin ... so könnte jeder mitmachen. Grüße Tobias ps: Gibt es eigentlich einen OSM-Dienst, wie Flicker, auf dem ebensolche Fotos mit Geo-Informationen gespeichert werden können? Das Problem ist doch eigentl. nur, dass Flickr noch nicht weltweit OSM-Karten nutzt, sondern Googlekarten. Aber bietet Flickr nicht vllt. eine API für soetwas, d.h. man erhält Koordinaten und kann die dann selbst visualisieren. Das Framework von unserer Seite (Openlayers, Tiles etc.) ist ja vorhanden. Ein OSM-Dienst wie Flickr macht imo gar kein Sinn, da Flickr ja viel viel mehr als nur Fotos auf Karten anzeigen ist. Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbilder aus Bayern - Halbzeit
Hallo, Ulf Möller wrote: Was verbirgt sich denn hinter diesem steil ansteigenden other? Habs nicht genau ausgewertet, aber ich vermute mal, das duerfte highway=road sein, das verwenden viele ja, wenn sie's nicht besser wissen. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Torsten Leistikow schrieb: Jonas Krückel (John07) schrieb: Man führt sie aber ja nur lokal bzw. für den genauen Anwendungszweck zusammen, genauso wie wir es mit den SRTM-Daten auch machen. Ich bin ebenfalls für eine 2. DB als ein Art Schwesterprojekt zu OSM, Dann geht aber die Information verloren, wie die Daten zusammenpassen. Wenn ich das Hoehenprofil einer Strasse aufnehme, dann muss ich ja auch wissen, dass die Hoehen eben ganau zu dieser Strasse gehoeren und nicht zu irgendwelchen querenden Ueberfuehrungen. Das ist ein wirklich guter Punkt, den ich nicht beachtet habe. Was ist mit eine großen Autobahnbrücke über ein Tal? Da hilft eine OMG-LOL-DB nicht wirklich weiter. Ideen? Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Torsten Leistikow schrieb: Insofern braucht meine nicht einfach eine Datenbank, die fuer Lat-Lon-Positionen einem jeweils einen Hoehenwert liefert (das kann SRTM ja an den meisten Stellen hinreichend gut). Was man braucht, ist eine Datenbank, die fuer die einzelnen Objekte die jeweilige Hoehe liefert. Und eben wegen diesen Zusammenhang zwischen Hoehe und Objekt, macht eine getrennte Hoehendatenbank in meinen Augen auch keinen Sinn. Das kannst Du ja über die ele / altitude / height / whatever Tags machen. Oder möchtest Du ein komplettes 3D Modell der Welt haben ? Das hätte dann nicht mehr viel mit der ursprünglichen Intention von OSM zu tun, eine freie Straßenkarte der Welt zu schaffen.. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
On Mon, 16 Feb 2009 17:25:32 +0100, Torsten Leistikow de_m...@gmx.de wrote: Frederik Ramm schrieb: Was ich von einer Hoehendatenbank will ist: Zu einer gegebenen Position die Hoehe erfahren. Sonst nichts. Das sehe ich anders. Ich habe einen Weg, der vom Punkt A ueber B nach C verlaeuft. Und fuer diesen Weg will ich nun wissen, in welcher Hoehe der Weg an den drei Punkten ist. Ob einer der Punkte nun 5m nach Osten verschoben ist, ist mir dabei erstmal egal. Es darf aber nicht passieren, dass sich durch diese Verschiebung die Hoehe um ein paar hundert Meter aendert (siehe das Beispiel mit der Staumauer). Insofern braucht meine nicht einfach eine Datenbank, die fuer Lat-Lon-Positionen einem jeweils einen Hoehenwert liefert (das kann SRTM ja an den meisten Stellen hinreichend gut). Was man braucht, ist eine Datenbank, die fuer die einzelnen Objekte die jeweilige Hoehe liefert. Wenn ich mich mal kurz einschalten darf... Szenario: x u A-B w\ y \ C z So wie ich es verstehe, soll die Straße (A-B-C) in OSM liegen. Die Punkte u..z liegen in einer seperaten DB und besitzen Höhenangaben. Wenn Du also die Höhen von A, B oder C (oder anderer Punkte) haben möchtest, gibts Du der anderen DB die Koordinaten und diese berechnet Zwischenwerte als Höhe von A,B,C. Um so mehr Werte vorhanden (und um so näher diese an den abgefragten liegen), um so genauer. ich sehe keinen Vorteil darin das in die bestehende DB zu matschen. Und eben wegen diesen Zusammenhang zwischen Hoehe und Objekt, macht eine getrennte Hoehendatenbank in meinen Augen auch keinen Sinn. Der Zusammenhang ist doch über Lat/Lng gegeben. OK, in Höhlen und unter felsforsprüngen gibt es Probleme, aber die Vorteile überwiegen IMHO bei Weitem... Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Hallo Frederik, wir denken verschieden Das ist ja zwischen Menschen nichts ungewöhnliches. Was ich von einer Hoehendatenbank will ist: Zu einer gegebenen Position die Hoehe erfahren. Da wollen wir das Gleiche. Je genauer desto besser. Zumindest so genau, dass ich eine Steigung ableiten kann, und weiss, ob eine Böschung oder Steilstufe kommt (oder ob sie schon vorbei ist). Und ich will auch absolute Höhen wissen: als Flieger ob ich oben drüber komme, als Wanderer ob ich ober- oder unterhalb des Felsbandes bin, als Taucher ob ich runter komme, als Skifahrer wie weit ich hochlaufen muss, als Radfahrer zur Berechnung des Kalorienverbrauchs, als Segler ob ich noch eine Handbreit Wasser unterm Kiel habe. Ich will nicht wissen, ob an der Position ein See ist oder ein Berg oder ein Briefkasten, eine Staumauer, ein Haus oder kein Haus. Das sehe ich ja aus den OSM-xy-Daten. Aber ich will wissen, wie hoch das Haus / der Bauplatz liegt, ob oberhalb oder unterhalb des Überschwemmungsgebietes, und ob die Strasse hinauf oder hinunter führt. mit OpenStreetMap hat das im Grunde gar nicht so viel zu tun. Wie - genau darum geht es doch?! Der Mapper weiss ja, ob er auf dem Bergkamm oder im Tal gelaufen ist. Wie - wir arbeiten doch nicht für den Mapper? Sondern für die Karte und den Router! Und dafür brauchen wir dreidimensionale Daten, wie auch immer wir die speichern und verknüpfen - Hauptsache exakt. ... irgendwie habe ich den Eindruck, Du willst gar keine Höhen wissen - und deshalb sollen sie auch nicht festgehalten und verwertet werden? Oder wenn dann halt ausserhalb von OSM? Gruss, Markus PS: was Du über die Schwierigkeiten der Dreidimensionalität sagst verstehe ich - aber vielleicht gibt es ja Lösungen dafür? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Idee zu Routing-Anwendungen (Foto-Routing)
Bernd Wurst schrieb: Aber wenn du mal hochrechnest, kommst du ganz schnell auf mehr als nur erhebliche Speichermengen. Ich habe neulich mal die Mapping-verwertbaren Fotos des letzten Jahres bei mir gebrannt (Straßennamen, Briefkästen, ...) und das alleine waren über eine DVD voll. Es müssen ja keine 10 Megapixel sein, um sich einen Einblick zu verschaffen :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Idee zu Routing-Anwendungen (Foto-Routing)
On 02/16/2009 05:44 PM, Jonas Krückel (John07) wrote: Tobias Wendorff schrieb: ps: Gibt es eigentlich einen OSM-Dienst, wie Flicker, auf dem ebensolche Fotos mit Geo-Informationen gespeichert werden können? Das Problem ist doch eigentl. nur, dass Flickr noch nicht weltweit OSM-Karten nutzt, sondern Googlekarten. Aber bietet Flickr nicht vllt. eine API für soetwas, d.h. man erhält Koordinaten und kann die dann selbst visualisieren. Afair ist es umgekehrt. Man gibt eine Koordinate und einen Umkreisradius und erhält alle Fotos innerhalb dieses Umkreis. Per API möglich ist es jedenfalls, die Frage ist nur ob lizenzrechtlich etwas gegen eine solche Anwendung spricht. Denke aber nicht. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Chris-Hein Lunkhusen schrieb: Oder möchtest Du ein komplettes 3D Modell der Welt haben ? Ich moechte dreidimensionale Koordinaten fuer (moeglichst) alle Elemente in der OSM-Datenbank haben. Das hätte dann nicht mehr viel mit der ursprünglichen Intention von OSM zu tun, eine freie Straßenkarte der Welt zu schaffen.. Naja, eine 3D-Strassenkarte duerfte noch um einiges dichter an der urspruenglichen Intention sein, als ein Verzeichnis von Hundekottuetenspendern und aehnlichen Sachen die heute in die Datenbank eingetragen werden. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Idee zu Routing-Anwendungen (Foto-Routing)
Norbert Wenzel schrieb: Gibt es lizenzrechtliche Probleme die Flickr API zu benutzen und zu jeder Koordinate Fotos zu suchen und die dann über der Slippy Map anzuzeigen. Mit dem POI Example vom Wiki sollte sich das doch relativ leicht erledigen lassen, oder spricht da was dagegen? (Abgesehen vielleicht von dem massiven Traffic den man durch das andauernde Suchen von Fotos per Flickr API verursacht.) Flickr = Yahoo ... die mögen uns ja sowieso. Muss ich in den Woche mal durcharbeiten. Notfalls kooperiert man halt mit einem Bild-Hoster, der noch keinen Geodienst anbietet?! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Idee zu Routing-Anwendungen (Foto-Routing)
Jonas Krückel (John07) schrieb: Ein OSM-Dienst wie Flickr macht imo gar kein Sinn, da Flickr ja viel viel mehr als nur Fotos auf Karten anzeigen ist. Es ging mir viel mehr um eine Möglichkeit, meine Bilder hochzuladen und irgendwie mit der Welt zu teilen, die sehen will, wie der Platz aussieht, wo man rumrasen will. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki - Uhrzeit
2009/2/16 Marco Horstmann hma...@gmx.net: Hallo, eine Idee wäre, weil vielleicht der Chef auch in OSM aktiv ist? Dann solltest du da nicht rumeditieren sonder deinen vertraglichen Pflichten nachkommen. Der kann viel Einfacher alle Änderungen eines Users suchen und sieht die Uhrzeiten gleich daneben. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki - Uhrzeit
Marco Horstmann schrieb: marcus.wolsc...@googlemail.com schrieb: Warum msollte man die Uhrzeit unterdrücken wollehn? Es ist zum Verfolgen des Gespräches hilfreich wer nach wem geposted hat (ohne ständig die History zu konsultieren). eine Idee wäre, weil vielleicht der Chef auch in OSM aktiv ist? Wenn man ein Mann ist, trägt man die Konsequenzen von Fehlverhalten und versucht nicht, dieses zu vertuschen. malabartiges Quoting reparieren dauert länger als das Schreiben der Antwortenki ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Idee zu Routing-Anwendungen (Foto-Routing)
Norbert Wenzel schrieb: On 02/16/2009 05:44 PM, Jonas Krückel (John07) wrote: Tobias Wendorff schrieb: ps: Gibt es eigentlich einen OSM-Dienst, wie Flicker, auf dem ebensolche Fotos mit Geo-Informationen gespeichert werden können? Das Problem ist doch eigentl. nur, dass Flickr noch nicht weltweit OSM-Karten nutzt, sondern Googlekarten. Aber bietet Flickr nicht vllt. eine API für soetwas, d.h. man erhält Koordinaten und kann die dann selbst visualisieren. Afair ist es umgekehrt. Man gibt eine Koordinate und einen Umkreisradius und erhält alle Fotos innerhalb dieses Umkreis. Hm, ok, das ist schlecht. Im Prinzip hab ich es so verstanden, als wollen wir eine solche Karte ( http://www.flickr.com/map?fLat=49.4437fLon=11.1288zl=7 ) nur mit OSM im Hintergrund. Auf der kann man dann am besten noch sagen, dass man nur alle Bilder mit Tag #osm sehen möchte. Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Idee zu Routing-Anwendungen (Foto-Routing)
On 02/16/2009 06:02 PM, Jonas Krückel (John07) wrote: Norbert Wenzel schrieb: On 02/16/2009 05:44 PM, Jonas Krückel (John07) wrote: Tobias Wendorff schrieb: ps: Gibt es eigentlich einen OSM-Dienst, wie Flicker, auf dem ebensolche Fotos mit Geo-Informationen gespeichert werden können? Das Problem ist doch eigentl. nur, dass Flickr noch nicht weltweit OSM-Karten nutzt, sondern Googlekarten. Aber bietet Flickr nicht vllt. eine API für soetwas, d.h. man erhält Koordinaten und kann die dann selbst visualisieren. Afair ist es umgekehrt. Man gibt eine Koordinate und einen Umkreisradius und erhält alle Fotos innerhalb dieses Umkreis. Hm, ok, das ist schlecht. Im Prinzip hab ich es so verstanden, als wollen wir eine solche Karte ( http://www.flickr.com/map?fLat=49.4437fLon=11.1288zl=7 ) nur mit OSM im Hintergrund. Auf der kann man dann am besten noch sagen, dass man nur alle Bilder mit Tag #osm sehen möchte. Ich glaub ich hab mich undeutlich ausgedrückt. Man bekommt auf die Anfrage eigentlich ein XML zurück, dass neben dem Pfad zum Bild auch die exakten Geokoordinaten zu dem Bild enthält. D.h. man müsste den Punkt, den man abfragt immer in die Mitte der aktuellen Ansicht setzen und als Radius die BB Diagonale nehmen. Möglich ist das auf jeden Fall. Wie's mit den Tags ausschaut, kann ich nicht sagen. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Gerrit Lammert schrieb: Szenario: x u A-B w\ y \ C z So wie ich es verstehe, soll die Straße (A-B-C) in OSM liegen. Die Punkte u..z liegen in einer seperaten DB und besitzen Höhenangaben. Wenn Du also die Höhen von A, B oder C (oder anderer Punkte) haben möchtest, gibts Du der anderen DB die Koordinaten und diese berechnet Zwischenwerte als Höhe von A,B,C. Um so mehr Werte vorhanden (und um so näher diese an den abgefragten liegen), um so genauer. ich sehe keinen Vorteil darin das in die bestehende DB zu matschen. Das Problem entsteht dann, wenn die Hoehenaenderung zwischen A und B bzw. B und C nur sehr klein, zwischen w und x, y und u und y und z aber sehr gross ist. Wenn man dann ueber die Lat-Lon-Koordinaten aus einer anderen Datenbank die Hoeheninformationen holt, erhaellt man als Ergebniss nur Muell, egal wie eng das Netz von u..z ist. Und unangenehmerweise ist der von mir geschilderte Fall nicht nur rein theoretisch. In den Bergen ist es naemlich der Normalfall, dass die Strassen nahezu senkrecht zum Hoehengradienten verlaufen. Bei einer Strasse, die sich in Serpentinen einen Hang hinauf schlaengelt, erhaelt man als Ergebniss dann keine konstante Steigung, sondern bestenfalls eine Treppe, weit relaistischer allerdings einen ansteigenden Saegezahn. (Das kann man z.B. bei den Top50-Karten von der Landesvermessung mal ausprobieren.) Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Idee zu Routing-Anwendungen (Foto-Routing)
Norbert Wenzel schrieb: On 02/16/2009 06:02 PM, Jonas Krückel (John07) wrote: Norbert Wenzel schrieb: On 02/16/2009 05:44 PM, Jonas Krückel (John07) wrote: Tobias Wendorff schrieb: ps: Gibt es eigentlich einen OSM-Dienst, wie Flicker, auf dem ebensolche Fotos mit Geo-Informationen gespeichert werden können? Das Problem ist doch eigentl. nur, dass Flickr noch nicht weltweit OSM-Karten nutzt, sondern Googlekarten. Aber bietet Flickr nicht vllt. eine API für soetwas, d.h. man erhält Koordinaten und kann die dann selbst visualisieren. Afair ist es umgekehrt. Man gibt eine Koordinate und einen Umkreisradius und erhält alle Fotos innerhalb dieses Umkreis. Hm, ok, das ist schlecht. Im Prinzip hab ich es so verstanden, als wollen wir eine solche Karte ( http://www.flickr.com/map?fLat=49.4437fLon=11.1288zl=7 ) nur mit OSM im Hintergrund. Auf der kann man dann am besten noch sagen, dass man nur alle Bilder mit Tag #osm sehen möchte. Ich glaub ich hab mich undeutlich ausgedrückt. Man bekommt auf die Anfrage eigentlich ein XML zurück, dass neben dem Pfad zum Bild auch die exakten Geokoordinaten zu dem Bild enthält. D.h. man müsste den Punkt, den man abfragt immer in die Mitte der aktuellen Ansicht setzen und als Radius die BB Diagonale nehmen. Möglich ist das auf jeden Fall. Wie's mit den Tags ausschaut, kann ich nicht sagen. Ok. Mehr findet man hier: http://www.flickr.com/services/api/ Also scheint das, was Tobias machen möchte, schon möglich. Man müsste praktisch alle Bilder entlang der Routingstrecke (vermutlich in kleine Boxen bzw. hier Kreise aufgeteilt) abfragen und dann hat man die Koordinaten und kann das darstellen. Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
On Mon, 16 Feb 2009 18:09:49 +0100, Torsten Leistikow de_m...@gmx.de wrote: Gerrit Lammert schrieb: Szenario: x u A-B w\ y \ C z So wie ich es verstehe, soll die Straße (A-B-C) in OSM liegen. Die Punkte u..z liegen in einer seperaten DB und besitzen Höhenangaben. Wenn Du also die Höhen von A, B oder C (oder anderer Punkte) haben möchtest, gibts Du der anderen DB die Koordinaten und diese berechnet Zwischenwerte als Höhe von A,B,C. Um so mehr Werte vorhanden (und um so näher diese an den abgefragten liegen), um so genauer. ich sehe keinen Vorteil darin das in die bestehende DB zu matschen. Das Problem entsteht dann, wenn die Hoehenaenderung zwischen A und B bzw. B und C nur sehr klein, zwischen w und x, y und u und y und z aber sehr gross ist. Wenn man dann ueber die Lat-Lon-Koordinaten aus einer anderen Datenbank die Hoeheninformationen holt, erhaellt man als Ergebniss nur Muell, egal wie eng das Netz von u..z ist. Und unangenehmerweise ist der von mir geschilderte Fall nicht nur rein theoretisch. In den Bergen ist es naemlich der Normalfall, dass die Strassen nahezu senkrecht zum Hoehengradienten verlaufen. Bei einer Strasse, die sich in Serpentinen einen Hang hinauf schlaengelt, erhaelt man als Ergebniss dann keine konstante Steigung, sondern bestenfalls eine Treppe, weit relaistischer allerdings einen ansteigenden Saegezahn. (Das kann man z.B. bei den Top50-Karten von der Landesvermessung mal ausprobieren.) Ist mir im Prinzip klar. Aber woher hätte denn das integrierte Modell genauere Daten? Wenn es (woher auch immer) genaue Daten für einen Knoten gibt, gäbe es die doch in beiden Systemen. Und wenn es halt keine genauen Daten gibt, könnte das zweite System (da spezialisierter) besser interpolieren und damit in 99% aller Fälle realistische Höhen generieren. Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Hallo Gerrit, Ich habe einen Weg, der vom Punkt A ueber B nach C verlaeuft. Und fuer diesen Weg will ich nun wissen, in welcher Hoehe der Weg an den drei Punkten ist. Szenario: x u A-B w\ y \ C z So wie ich es verstehe, soll die Straße (A-B-C) in OSM liegen. Die Punkte u..z liegen in einer seperaten DB und besitzen Höhenangaben. Wenn Du also die Höhen von A, B oder C (oder anderer Punkte) haben möchtest, gibts Du der anderen DB die Koordinaten und diese berechnet Zwischenwerte als Höhe von A,B,C. Um so mehr Werte vorhanden (und um so näher diese an den abgefragten liegen), um so genauer. ich sehe keinen Vorteil darin das in die bestehende DB zu matschen. Der Zusammenhang ist doch über Lat/Lng gegeben. Ich suche die dreidimensionale Position von A, B und C. LAT/LON habe ich schon in der OSM-DB. Nun könnte ich doch einfach noch ALT dazuspeichern. Oder aus benachbarten Punkten uwxyz, deren LAT/LON/ALT ich weiss, die Höhe von ABC interpolieren. Wozu soll ich uwxyz in einer anderen DB speichern? Und dann aus einer DB uwxyz und aus der andern ABC nehmen? Oder gar LAT/LON von ABC in einer und LAT/LON/ALT von ABC in einer anderen speichern, um für die Arbeit in ersterer die Höhe aus letzterer zu holen? Für mich macht das irgendwie nicht so richtig Sinn... Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Welche Straßen fehlen noch in Erfurt ?
Holger Schrader schrieb: ich würde gern mal wissen welche Straßen in Erfurt noch fehlen. Dazu gibt es ja irgendwie eine Möglichkeit das herauszubekommen. Technisch ist das nicht schwierig; aber man sollte dabei auf das Urheberrecht achten - besonders wenn du die Informationen zum Mappen benutzen willst. Also wäre die Frage, ob diese Website erlaubt die Daten zu benutzen, und wo die Daten überhaupt herkommen. Die Stadt Erfurt verbietet, Auszüge aus ihrem im Internet veröffentlichten Straßenverzeichnis in elektronische Systeme einzuspeichern. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Welche Straßen fehlen noch in Erfurt ?
Hallo Ulf, danke für deine Antwort. vor einiger Zeit hatte ich bei dem Betreiber der Erfurt WIKI angefragt ob ich die Daten für OSM verwenden darf. Er hatte zugestimmt. Ciao Holger Ulf Möller schrieb: Holger Schrader schrieb: ich würde gern mal wissen welche Straßen in Erfurt noch fehlen. Dazu gibt es ja irgendwie eine Möglichkeit das herauszubekommen. Technisch ist das nicht schwierig; aber man sollte dabei auf das Urheberrecht achten - besonders wenn du die Informationen zum Mappen benutzen willst. Also wäre die Frage, ob diese Website erlaubt die Daten zu benutzen, und wo die Daten überhaupt herkommen. Die Stadt Erfurt verbietet, Auszüge aus ihrem im Internet veröffentlichten Straßenverzeichnis in elektronische Systeme einzuspeichern. ___ 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] Welche Straßen fehlen noch in Erfurt ?
Ulf Möller schrieb: Technisch ist das nicht schwierig; aber man sollte dabei auf das Urheberrecht achten - besonders wenn du die Informationen zum Mappen benutzen willst. Es liegt kein Urheberrecht vor, außer sie haben eine ganz kreative Methode gefunden, die Straßennamen zu katalogisieren. Es handelt sich vermutlich um eine elektronische Datenbank, die Schutz nach § 87b UrhG genießt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Tja. DTM oder DEM? Was wollen wir? Die Triangulation kommt aber später...erst nach den Punkten Tobias Wendorff schrieb: Dr. Franz-Josef Behr schrieb: ich habe schon seit einiger Zeit einen Domännamen registriert: http://www.opendtm.org Mal generell eine Übersicht: Digital Terrain Modell, Digitales Geländemodell, Digital Elevation Modell = Objekte auf der Erdoberfläche (z.B. Wälder, Häuser) Digitales Höhenmodell = keine Objekte auf der Erdoberfläche Wichtig ist jedoch, dass bei einem solchem Modell eine Triangulation (regelmäßig oder unregelmäßig) stattgefunden hat. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de -- Mit freundlichen Grüßen / Regards / Cordialement Dr. Franz-Josef Behr Participate in http://www.opengeocoding.org! We live at the start of the information age and not enough people care that someone else gains rights to their personal things, their information, friends, images, photos, music... People really need to read the licenses they sign up to. http://www.guardian.co.uk/users/ivanidea Prof. Dr. Franz-Josef Behr - Home Office Author of: Strategisches GIS-Management - http://www.gis-management.de eMail: franz-josef.b...@hft-stuttgart.de http://www.gis-news.de Tel: +49 (0)721 / 453980-1 sowie 45 33 35 Fax: +49 (0)721 / 453980-7 sowie via web.de: +49 (0)1212-5-12048213 begin:vcard fn:Dr. Franz-Josef^Behr n:Behr;Franz-Josef org:Stuttgart University of Applied Sciences (SUAS);Faculty of Geomatics, Computer Science and Mathematics adr;quoted-printable:;;Schellingstra=C3=9Fe 24, ;Stuttgart;;D-70174;Germany title:Prof. tel;work:+49) 711/8926-2606 tel;home:+49 (0)721 / 453980-1 url:http://www.hft-stuttgart.de/ version:2.1 end:vcard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Idee zu Routing-Anwendungen (Foto-Routing)
On Mon, 2009-02-16 18:13:22 +0100, Jonas Krückel (John07) o...@jonas-krueckel.de wrote: Norbert Wenzel schrieb: On 02/16/2009 06:02 PM, Jonas Krückel (John07) wrote: Norbert Wenzel schrieb: On 02/16/2009 05:44 PM, Jonas Krückel (John07) wrote: Tobias Wendorff schrieb: ps: Gibt es eigentlich einen OSM-Dienst, wie Flicker, auf dem ebensolche Fotos mit Geo-Informationen gespeichert werden können? Das Problem ist doch eigentl. nur, dass Flickr noch nicht weltweit OSM-Karten nutzt, sondern Googlekarten. Aber bietet Flickr nicht vllt. eine API für soetwas, d.h. man erhält Koordinaten und kann die dann selbst visualisieren. Ok. Mehr findet man hier: http://www.flickr.com/services/api/ Also scheint das, was Tobias machen möchte, schon möglich. Man müsste praktisch alle Bilder entlang der Routingstrecke (vermutlich in kleine Boxen bzw. hier Kreise aufgeteilt) abfragen und dann hat man die Koordinaten und kann das darstellen. Was ich da aus dem Stand nicht gefunden habe, ist die Möglichkeit, nicht nur nach lat/lon zu fragen (Kameraposition, nicht Objekt-Position!), sondern zusätzlich auch nach der Kamera-Richtung. Gerade, wenn man Bilder entlang einer Route zeigen will, um diese besser zu visualisieren, ists Mumpitz, das Haus von der Rückseite (oder den Blick nach hinten) anzuzeigen... MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of: Träume nicht von Dein Leben: Lebe Deinen Traum! the second : signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Dr. Franz-Josef Behr schrieb: Tja. DTM oder DEM? Was wollen wir? Die Triangulation kommt aber später...erst nach den Punkten Huch, nach meinem Wissen sind DTM und DEM das Gleiche? Lass uns doch mal auf Deutsch reden :-) DGM = Digitales Geländemodell, die natürliche Geländeform der Erdoberfläche ohne Bebauung und Bepflanzung DOM = Digitales Oberflächenmodell, die Geländeform aller auf der Erdoberfläche befindlichen Objekte DHM = Digitales Höhenmodell, Oberbegriff für die regelmäßig oder dunregelmäßig erhobenen Daten. Ein primäres DHM beschreibt die Originalmessdaten, ein sekundäres DHM die daraus abgeleiteten Daten. DEM wäre daher ein Allgemeinbegriff, was DGM und DEM beinhaltet. DEM = Digital Elevation Model. Daher würde ich mich für OpenDEM aussprechen. Die Domain kann man ja sicher ummelden :-) Grüße Tobias Achja, habe ich schon erwähnt, dass aus der DGK5 bald die ABK (Amtliche Basiskarte) wird? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Idee zu Routing-Anwendungen (Foto-Routing)
Jan-Benedict Glaw schrieb: Was ich da aus dem Stand nicht gefunden habe, ist die Möglichkeit, nicht nur nach lat/lon zu fragen (Kameraposition, nicht Objekt-Position!), sondern zusätzlich auch nach der Kamera-Richtung. Gerade, wenn man Bilder entlang einer Route zeigen will, um diese besser zu visualisieren, ists Mumpitz, das Haus von der Rückseite (oder den Blick nach hinten) anzuzeigen... Man kann ja eine Datenbank zwischenschalten, in der diese Information hinterlegt ist. Der Router würde eine Information über alle Fotos in der Datenbank haben, und auch die Orientierung kennen. Flickr müsst dann nur angezapft werden. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Idee zu Routing-Anwendungen (Foto-Routing)
On Mon, 2009-02-16 19:54:09 +0100, Tobias Wendorff tobias.wendo...@uni-dortmund.de wrote: Jan-Benedict Glaw schrieb: Was ich da aus dem Stand nicht gefunden habe, ist die Möglichkeit, nicht nur nach lat/lon zu fragen (Kameraposition, nicht Objekt-Position!), sondern zusätzlich auch nach der Kamera-Richtung. Gerade, wenn man Bilder entlang einer Route zeigen will, um diese besser zu visualisieren, ists Mumpitz, das Haus von der Rückseite (oder den Blick nach hinten) anzuzeigen... Man kann ja eine Datenbank zwischenschalten, in der diese Information hinterlegt ist. Der Router würde eine Information über alle Fotos in der Datenbank haben, und auch die Orientierung kennen. Die Orientierung (und ggf. Brennweite etc., man will ja keinen Marienkäfer zeigen, wenn man vor 'nem Schloß abbiegen soll...) separat speichern? Naja... Flickr müsst dann nur angezapft werden. Ich denk' gerade eher darüber nach, ohne Flickr etc. auszukommen. Am Ende sind das immernoch kommerzielle Dienste, die ihre ganz eigenen Interessen verfolgen. Dann doch lieber sowas anlegen, wie ein großes Tahoe-LAFS-Grid und da alles 'reinstopfen. Die Bilder dann als Node anlegen, zusammen mit Blickrichtung, Höhe(nwinkel) und Blickwinkel. Die letzten Daten sollten allesamt aus den Exif-Infos ableitbar sein, Ort und Richtung wird man (erstmal) wohl noch zufuß angeben müssen. MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of: What we do for ourselves dies with us. What we do for the second : others and the world remains and is immortal. (Albert Pine) signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Idee zu Routing-Anwendungen (Foto-Routing)
Jan-Benedict Glaw schrieb: Die Orientierung (und ggf. Brennweite etc., man will ja keinen Marienkäfer zeigen, wenn man vor 'nem Schloß abbiegen soll...) separat speichern? Naja... Nunja, N S W E ... das wird wohl noch irgendwo in den EXIF passen. Notfalls halt direkt ins Bild als Wasserzeichen. Ich denk' gerade eher darüber nach, ohne Flickr etc. auszukommen. Am Ende sind das immernoch kommerzielle Dienste, die ihre ganz eigenen Interessen verfolgen. Dann doch lieber sowas anlegen, wie ein großes Tahoe-LAFS-Grid und da alles 'reinstopfen. Wo willst Du die Bilder speichern? Das ist mein Problem. Die Bilder dann als Node anlegen, zusammen mit Blickrichtung, Höhe(nwinkel) und Blickwinkel. Die letzten Daten sollten allesamt aus den Exif-Infos ableitbar sein, Ort und Richtung wird man (erstmal) wohl noch zufuß angeben müssen. Die GPS-Kameras auf dem Markt sind Schrott und die besseren Varianten sind zu teuer und haben schlechten Support. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Markieren von Rodelstrecken / Schlittelwegen
Marian Flor wrote: gibt es ein Zusatzattribut (evtl. auch erst im Status proposed), mit dem Feldwege (highway=track und bspw. tracktype=grade2) als Rodelweg bzw. Schlittelweg markiert werden können? Auf http://wiki.openstreetmap.org/wiki/Approved_features/Path finde ich: * snowmobile=designated * ski=designated Dementsprechend könnte man ja ergänzen: * sledge=designated Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Idee zu Routing-Anwendungen (Foto-Routing)
Was mir gerade einfällt: Es gibt irgendsoein Projekt (Ich glaube aus den Niederlanden) die wollten ein Dienst für OSM-Mappingbildern starten mit ähnlichen Zielen wie ihr. Vllt. könnt ihr euch da mal absprechen: http://wiki.openstreetmap.org/wiki/OpenStreetPhoto Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Idee zu Routing-Anwendungen (Foto-Routing)
On Mon, 2009-02-16 20:19:15 +0100, Tobias Wendorff tobias.wendo...@uni-dortmund.de wrote: Jan-Benedict Glaw schrieb: Die Orientierung (und ggf. Brennweite etc., man will ja keinen Marienkäfer zeigen, wenn man vor 'nem Schloß abbiegen soll...) separat speichern? Naja... Nunja, N S W E ... das wird wohl noch irgendwo in den EXIF passen. Notfalls halt direkt ins Bild als Wasserzeichen. Klar, das kann man in das Bild packen. Das /tut/ nur bisher niemand! Ich denk' gerade eher darüber nach, ohne Flickr etc. auszukommen. Am Ende sind das immernoch kommerzielle Dienste, die ihre ganz eigenen Interessen verfolgen. Dann doch lieber sowas anlegen, wie ein großes Tahoe-LAFS-Grid und da alles 'reinstopfen. Wo willst Du die Bilder speichern? Das ist mein Problem. http://allmydata.org/trac/tahoe Das als Backend, und irgendwo 'nen nettes kleines Frontend (kann ja so'n Web-Dingsdabumbsta werden mit OSM-Karte im Hintergrund), um die Bilder zu positionieren und ggf. noch die Richtung festzulegen. Die Bilder dann als Node anlegen, zusammen mit Blickrichtung, Höhe(nwinkel) und Blickwinkel. Die letzten Daten sollten allesamt aus den Exif-Infos ableitbar sein, Ort und Richtung wird man (erstmal) wohl noch zufuß angeben müssen. Die GPS-Kameras auf dem Markt sind Schrott und die besseren Varianten sind zu teuer und haben schlechten Support. Mag sein; deshalb ist da noch Einiges in Handarbeit zu machen. Andererseits ist es keine allzugroße Magie, die drei Zahlen in die Exif-Daten zu bekommen... MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of: What we do for ourselves dies with us. What we do for the second : others and the world remains and is immortal. (Albert Pine) signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Idee zu Routing-Anwendungen (Foto-Routing)
Jan-Benedict Glaw schrieb: On Mon, 2009-02-16 20:19:15 +0100, Tobias Wendorff tobias.wendo...@uni-dortmund.de wrote: Jan-Benedict Glaw schrieb: Die Orientierung (und ggf. Brennweite etc., man will ja keinen Marienkäfer zeigen, wenn man vor 'nem Schloß abbiegen soll...) separat speichern? Naja... Nunja, N S W E ... das wird wohl noch irgendwo in den EXIF passen. Notfalls halt direkt ins Bild als Wasserzeichen. Klar, das kann man in das Bild packen. Das /tut/ nur bisher niemand! Ich denk' gerade eher darüber nach, ohne Flickr etc. auszukommen. Am Ende sind das immernoch kommerzielle Dienste, die ihre ganz eigenen Interessen verfolgen. Dann doch lieber sowas anlegen, wie ein großes Tahoe-LAFS-Grid und da alles 'reinstopfen. Wo willst Du die Bilder speichern? Das ist mein Problem. http://allmydata.org/trac/tahoe Das als Backend, und irgendwo 'nen nettes kleines Frontend (kann ja so'n Web-Dingsdabumbsta werden mit OSM-Karte im Hintergrund), um die Bilder zu positionieren und ggf. noch die Richtung festzulegen. Die Bilder dann als Node anlegen, zusammen mit Blickrichtung, Höhe(nwinkel) und Blickwinkel. Die letzten Daten sollten allesamt aus den Exif-Infos ableitbar sein, Ort und Richtung wird man (erstmal) wohl noch zufuß angeben müssen. Die GPS-Kameras auf dem Markt sind Schrott und die besseren Varianten sind zu teuer und haben schlechten Support. Mag sein; deshalb ist da noch Einiges in Handarbeit zu machen. Andererseits ist es keine allzugroße Magie, die drei Zahlen in die Exif-Daten zu bekommen... Hier stehen auch noch ein paar Dinge dazu: http://wiki.openstreetmap.org/wiki/Photo_mapping Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Performance bei Osmarender
Tobias Wendorff schrieb: Martin Koppenhoefer schrieb: es gibt den Osmarender auch in Perl (von Frederik soweit ich weiss), der soll deutlich schneller sein. Wir der eigentlich aktualisiert? or/p wird eher aktualisiert als der xslt-osmarender, weil or/p Teil von ti...@home ist. -- Dirk-Lüder Deelkar Kreie Bremen - 53.0952°N 8.8652°E signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Idee zu Routing-Anwendungen (Foto-Routing)
Jan-Benedict Glaw schrieb: http://allmydata.org/trac/tahoe Live Demo funxt hier nicht wegen Firewall. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbilder aus Bayern - Halbzeit
Ulf Möller use...@ulfm.de [Mon, Feb 16, 2009 at 05:35:41PM CET]: Markus schrieb: - erfasste Strassen in der Operpfalz - erfasste Strassen in einem Vergleichsgebiet Was verbirgt sich denn hinter diesem steil ansteigenden other? natural=karpfenteich -- Johannes Hüsing There is something fascinating about science. One gets such wholesale returns of conjecture mailto:johan...@huesing.name from such a trifling investment of fact. http://derwisch.wikidot.com (Mark Twain, Life on the Mississippi) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rendern: Weinberg, Straße, Wald
Johannes Haller johannes.hal...@web.de [Mon, Feb 16, 2009 at 07:58:56AM CET]: Fairerweise muß ich sagen, daß ich Variante a)1. in Wohngebieten einfachheitshalber noch nicht anwende; prinzipiell denkbar ist das aber. Da hört dann doch alles auf. Bei aller Liebe, die meisten highway=residential liegen nicht zwischen verschiedenen landuse=residential, sondern drin. -- Johannes Hüsing There is something fascinating about science. One gets such wholesale returns of conjecture mailto:johan...@huesing.name from such a trifling investment of fact. http://derwisch.wikidot.com (Mark Twain, Life on the Mississippi) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
