Re: [Talk-de] Wohnmobil-Stellplätze bei OSM
Hallo Martin, Martin Mainzer schrieb: Bei der Arbeit mit den Daten ist mir aufgefallen, dass zwar schon eine Menge an Wohnmobilstellplätzen in Deutschland verzeichnet ist (560, Europa 1447), aber kaum weitergehende Informationen eingetragen sind. Ich denke, dass es insbesondere interessant wäre zu wissen, ob die Stellplätze kostenlos oder kostenpflichtig sind (fee=*) und ob Stromanschlüsse vorhanden sind (power_supply=*). Hier http://www.womo-sp.org/ gibt es ausführliche Listen von WoMo-Stellplätzen. Vielleicht könnte man ja mal nachfragen, ob man diese Infos in OSM integrieren dürfte. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wohnmobil-Stellpl?tze bei OSM
Jacob Hampel schrieb: bist du dir sicher, dass die Qualität der Daten auch gut ist. Ich weiß es nicht, habe die Liste mehr durch Zufall gefunden. Du kannst ja mal die in OSM vorhandenen Stellplätze stichprobenartig vergleichen. Es gibt in der Liste viele Wohnwagenstellplätze, die mit einem Fragezeichen versehen sind. Das wird seinen Grund haben... Wenn ja, soll ich mal ne Mail schicken Dann kannst du ja auch gleich nach der Qualität fragen. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mautdaten
Frederik Ramm schrieb: hat jemand schon mal Mautdaten fuer deutsche Autobahnen in OSM erfasst? korrelieren diese Daten nicht teilweise mit den TMC-Segmenten? Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wissenschaftliche Untersuchung von OSM
Peter Körner schrieb: Auf der Hinweisseite passts ;) (...) Da müsste man der Suchen- und Ersetzten-Funktion noch die deutsche Grammatik beibringen, damit diese einen Genitiv als solchen erkennt... ... oder besser jemanden haben, der sich bei der Erstellung einer Umfrage etwas mehr Mühe gibt! Mir scheint das Ganze ja mehr als zweifelhaft zu sein! Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM auf Arte
Rainer Kluge schrieb: es gibt darin einen kurzen Bericht über OSM Mapping im Hinblick auf Zugänglichkeit für Behinderte. sozusagen Beitrag-Recycling http://lists.openstreetmap.org/pipermail/talk-de/2009-September/054994.html Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Demo Routingfunktion openstreetmap,org
Sven Geggus schrieb: Fahrradrouting über Autobahn. Ich glaube damit würd ichs bis ins Radio schaffen. Das kann ich nicht bestätigen! Du musst nach dem Wechsel des Verkehrsmittels nochmals auf FindRoute klicken, sonst behält es das alte. OK, zugegeben pfeilschnell ist das Ding. Stimmt! Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ... pack - ftp - unpack ....
Hallo Jan, Jan Tappenbeck schrieb: hat einer von euch schon einmal eine lösung gebastelt bei der die tiles lokal gezippt werden, dann dieses große file hochgeladen wird (soweit auch für mich kein problem) und dann erst auf dem webserver ausgepackt werden. könnte mir vorstellen das soetwas schneller ist als die tiles manuell hochzuladen. kommt darauf an, was Du auf Deinem Webspace alles machen kannst bzw. darfst: Wenn Du einen Entpacker auf dem Server starten kannst, ist das kein Problem. Wenn Du z.B. PHP am Server zur Verfügung hast, dann sollte das auch realisierbar sein. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-Bauchscmerzen
Heiko Jacobs schrieb: Nach kurzem Blick in die Wikipedia hätten D-A-CH und USA kein Problem mit Löschungen von Einzelobjekten, die Englände rund Kanadier (und evtl. andere Länder mit Anlehnung an englisches Recht) aber schon, weil man da auch Rechte am Einzelobjekt zu haben scheint. Das zeigt aber auch, wie unsinnig eine global einheitliche Vorgehensweise bei Einzelobjekten ist. Und in das Urheberrecht JEDES Landes kann man sich aber wiederum vermutlich auch nicht einarbeiten, so dass es irgendwo auf der Welt immer zu Problemen kommen könnte, egal was man (nicht) macht. Das wiederum spräche für eine globale Vorgehensweise, aber nach der Devise: alles behalten, Augen zu und durch ... Welches Urheberrecht findet denn Anwendung, wenn z.B. ein englischer Mapper in Deutschland etwas einträgt, oder umgekehrt ich in Kanada etwas verändere? Oder ich mich im Ausland befinde und von dort aus was mappe? Weiß man überhaupt, welcher Mapper aus welchem Land kommt und welches Recht für welchen Mapper gilt? Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deine Stadt an Deinem Ohr
Thomas Ineichen schrieb: Tolle Idee! :) finde ich auch! (Bin ja gespannt, wann sich jemand darüber beschwert, dass keine Lizenzangabe auf dem Kunstwerk aufgedruckt wird...) Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Announce: Die Hausbrauereikarte - Open Brewpub Map
Sven Geggus schrieb: im Wiki steht auch nicht mehr drin: http://wiki.openstreetmap.org/wiki/Tag:microbrewery%3Dyes Ich frage mich ob man auch für normale Brauereien einen Tag erfinden sollte. wundert mich etwas, dass es da noch keinen gibt. Könnte man in einem anderen Layer anzeigen. Die Abgrenzung zur normalen Brauerei ist nicht ganz einfach: Im Wiki steht z.B. dass man den Tag für Kloster verwenden kann. Wenn ich mir aber nun z.B. Kloster Andechs vorstelle, dann ist das bestimmt keine Hausbrauerei mehr. Oder was ist mit Brauereigasthöfen? Da wird teilweise das Bier auch in anderen Gaststätten oder auch in lokalen Supermärkten verkauft. Ich denke es wäre sinnvoller ein Tag für Brauerei zu haben und dann die Größe dieser (nach Ausstoß pro Jahr?) genauer zu spezialisieren. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ-Import, Widersprüche
Frederik Ramm schrieb: Grundsaetzlich ist es natuerlich schoen, wenn wir fuer jede PLZ eine PLZ-Relation haben, aber der Mehraufwand fuer derlei Kosmetik in Gebieten, bei denen beide Grenzen identisch sind, rechtfertigt das m.E. nicht. Man muss dann nur bei Änderungen der Gemeindegrenzen (Eingemeindung, Grundstückstausch, etc.) auch auf die PLZ achten, die sich ja dadurch nicht zwangsläufig ebenso ändern muss, oder? Sobald die Gemeindegrenze nicht mehr 1:1 mit dem PLZ-Gebiet übereinstimmt muss dann trotzdem eine eigene PLZ-Relation erstellt werden. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Karten für NaviPOWM auf dem Dev-Server
Hallo zusammen, ich habe am Devserver wieder neue NaviPOWM-Karten aus dem kompletten planetfile erstellt! NEU: Es werden die MAP-Dateien nur noch aus dem planetfile generiert. Dafür gibt es jetzt extra Verzeichnisse für ALLE Länder der Welt mit den entsprechend verlinkten Daten! Die bisherigen Verzeichnisse für die Kontinente (und D-A-CH) existieren weiterhin und enthalten ebenso nur noch Links zu den relevanten Dateien im Planet-Verzeichnis. Übersicht: http://dev.openstreetmap.de/navipowmmaps/ Direkter Planet-Download: http://dev.openstreetmap.de/navipowmmaps/navipowm/planet/ Alle Länder der Welt: http://dev.openstreetmap.de/navipowmmaps/navipowm/world/ Datenquelle: planet.osm vom 22.07.2010 (komplett) Anzahl: 20458 Dateien entpackte Größe (Mapfiles): 22 GB gepackte Größe (7z-Files): 4,9 GB MAP-Version: V0.2.4 (=V0.2.5 dev) Falls Kacheln in Ländern fehlen sollten (oder Ländergrenzen falsch sind, ...), dann die Änderungen mir bitte mitteilen. Die Zuordnung zwischen Kachelnummern und Land findet man hier in TXT-Datein für alle Kontinente, Länder und teilweise Bundesstaaten: http://dev.openstreetmap.de/navipowmmaps/navipowm/countries/ Fehlt sonst noch was? Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straße mit unterschiedlichen Namen auf rechter und linker Seite
Andreas Tille schrieb: in dem es eine Straße gibt, die auf der linken Straßeseite Amtshof und auf der rechten Straßenseite Am Schmiedeteich heißt. Ich würde es so wie hier vorgeschlagen machen: http://lists.openstreetmap.org/pipermail/talk-de/2010-February/062881.html oder alternativ statt name:left= und name:right= besser sogar so mane:forward= und name:backward= Zusätzlich könnte man ja noch in name= beide Namen mit Semikolon getrennt angeben. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straße mit unterschiedlichen Namen auf rechter und linker Seite
Tobias Knerr schrieb: Ich würde name:left= und name:right= verwenden. Was hat das denn mit forward und backward zu tun? Wenn ich mich auf dem Bürgersteig umdrehe, ändert das den Namen meiner Straßenseite? Hm, da hast Du auch wieder recht! Also bis es eine vernünftige Lösung per Linienbündel gibt, ist wohl name:left= und name:right= die passende Wahl! Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straße mit unterschiedlichen Namen auf rechter und linker Seite
Ich sehe das so: Falk Zscheile schrieb: forward/backward bezieht sich direkt auf die vom Element vorgegebene Richtung. d.h. wenn ich mich in dieser Richtung *bewege*, also z.B. bei maxspeed. Bei left/right muss man zuerst nach der Richtung des Weges schauen und erst darauf kann man dann rechts/links beziehen. Genau, so ist das ja auch gedacht, da es eine *Lage *bezeichnet, die unabhängig von der Bewegungsrichtung ist. Hier ein konstruiertes Beispiel: maxspeed:forward=50 maxspeed:backward=30 name:left=Amtshof name:right=Am Schmiedeteich Ich fahre in Wegrichtung vorwärts: - Es gilt 50 km/h und die Straße (mit den Häusern auf meiner rechten Seite) heißt Am Schmiedeteich. Ich fahre rückwärts ohne zu wenden: - Es gilt 30 km/h und die Straße (mit den Häusern auf meiner rechten Seite) heißt Am Schmiedeteich. Ich (wende und) fahre gegen die Wegrichtung vorwärts: - Es gilt 30 km/h und die Straße (mit den Häusern auf meiner rechten Seite) heißt Amtshof. Ich fahre gegen die Wegrichtung rückwärts: - Es gilt 50 km/h und die Straße (mit den Häusern auf meiner rechten Seite) heißt Amtshof. Stefan P.S.: Das Drehen des Weges in OSM ist eigentlich kein Problem, da JOSM die richtungsabhängigen Attribute automatisch mitändert. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ-Import, Widersprüche
Bernd Wurst schrieb: Am Montag 26 Juli 2010, 09:53:55 schrieb Stefan Dettenhofer (StefanDausR): Sobald die Gemeindegrenze nicht mehr 1:1 mit dem PLZ-Gebiet übereinstimmt muss dann trotzdem eine eigene PLZ-Relation erstellt werden. Du musst aber zusätzlich unterscheiden: Wenn man mit gleichen Grenzverläufen eine eigene Relation erzeugt, packt man ja nur die Grenz-ways in eine neue Relation. Ist der Verlauf abweichend, muss man ggf. einen neuen way zeichnen. Das ist mir schon klar! Ich wollte ursprünglich ja auch nur darauf hinweisen, dass wenn der Trivialfall (Gemeinde=PLZ) vorliegt und daher nur die PLZ an die Gemeindegrenze getaggt ist, man bei späteren Änderungen aufpassen muss: Stellt man später fest, dass die Grenzverläufe doch nicht identisch sind, so darf man nicht einfach die eine Grenze ändern, sondern muss eben eine neue Relation erstellen. Das zieht ggf. relativ viel Arbeit nach sich (tags ändern, ways kopieren und neu anlegen). Daher dachte ich, es wäre die sauberste Lösung, prinzipiell eine neue PLZ-Relation anzulegen. Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways (ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)
steffterra schrieb: a) Einzeichnen zusätzlicher paralleler ways, die _nicht_ extra durch eine Relation oder einen Tag als zum gleichen way =ohne bauliche Trennung, gehörig verbunden werden müssen. Das sollte durch eine neue Datenart ermöglicht werden. Ich würde diese Funkion Gruppierung nennen und könnte durch eine gemeinsame abstrakte Signatur/ID erreicht werden, die von der DB (oder einem Algorithmus aus den way-id's jedes mal neu errechnet wird, wenn ein way dazukommt, oder abgezogen wird) vergeben wird. Könnte man das Ziel nicht auch ohne neue Datenart realisieren? Ich denke eine Änderung an der API ist nur schwer durchsetzbar. Es würde ja erst mal reichen, wenn man solche Gebilde anlegen und editieren kann. Der Schutz gegen Vandalismus bzw. versehentliches Ändern könnte ja immer noch später folgen. Was mir an Deinem Vorschlag gut gefällt, ist die Tatsache, dass man das highway-Element (datenway) nicht unnötig auftrennen muss um ein (richtungsabhängiges) Attribut zu setzten, sondern dass es reicht, wenn man einen Knoten setzt und von da ab einen way zeichnet. Natürlich kann man die selben Informationen auch über Attribute (und Auftrennen des highway-Elements) modellieren. Das Drehen der Wege sehe ich aber nicht so als Problem, das ja JOSM auch schon jetzt die Attribute entsprechend anpasst. Vielleicht können auch beide Systeme parallel existieren und je nach Anwendungsfall die einfachere Variante gewählt werden. Bei einer Kreuzung sehe ich die Attribut-Variante am Ende, sobald man einzelne Fahrspuren abbilden will. Bei einer einfachen richtungsabhängigen Geschwindigkeitsbeschränkung könnte aber 3 ways etwas übertrieben sein. Ich versuche mal ein einfaches Beispiel: Einseitige Geschwindigkeitsbeschränkung auf dem Weg von A nach D zwischen B und C Realität: Ein Weg von A bis D (B und C sind nur Knoten) o**=*=o A B 70 km/h C D Zur Abbildung mit Attributen muss der Weg bei B und C aufgetrennt werden Weg AB: highway=secondary Weg BC: highway=secondary | maxspeed:forward=70 Weg CD: highway=secondary oo===*=oo A B C D Neues Datenmodell (so wie ich es verstanden habe): Weg AD: highway=secondary Weg BC: maxspeed=70 Weg CB: (nichts) B*-C o**=*=o A B*-C D Zu beachten ist aber, dass die Wege BC und CB in den OSM-Daten deckungsgleich (selbe Koordinaten) mit dem Abschnitt BC des Weges AD sind. Die Spreizung ist nur im Editor zu sehen. Ich weiß nicht, ob die Wege BC und CB mit einem speziellen Attribut gekennzeichnet werden müssen. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] All in One (AIO) wird nicht mehr aktualisiert
Hallo, Elchtreiber schrieb: Alternativ könnte man den Fehler suchen und beheben, oder? ;-) die Kartenerzeugung am DevServer scheint letztes mal schief gelaufen zu sein, zumindest wurde ein stampfile nicht erzeugt, das anzeigt, das alles ok ist! Ich habe das file mal manuell erzeugt. Es kann aber sein, dass noch ein lock-File gelöscht werden müsste, nur da weiß ich nicht genug bescheid. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Karten im Monatsabo? Immerhin auch f ür andere Platformen als die üblichen.
Frederik Ramm schrieb: Wird interessant, zu sehen, was die Spezialisten-Karte im Vergleich zu unseren Standard-Angeboten zu bieten hat. Ich habe mir mal die Testversion auf meinem Medion PNA installiert. Diese läuft problemlos auch ohne Installation direkt von der SD-Karte. Der GPS-Empfänger wird automatische erkannt (scanning). Leider sind die interessanten Funktionen in der Testversion gesperrt, so kann man z.B. keine Route berechnen. Das dort beiliegende Kartenmaterial beinhaltet nur ausgewählte Flächen, Autobahnen, Trunk und Bundesstraßen. Der Zoom ist eingeschränkt (keinen große Übersicht möglich), dürfte aber fürs Wandern ausreichen. Orte können gesucht werden (exakte Schreibweise vorausgesetzt!) Falls das Routing aber einigermaßen funktionieren sollte (kann ja nicht getestet werden), wäre es eine Möglichkeit OSM-Vektordaten auf einem nicht-Garmin Gerät zu nutzen! Ich weiß nur nicht ganz, wie das Karten-Abo mit der OSM-Lizenz vereinbar ist. Nach meinem Verständnis dürfte natürlich die Software verkauft werden, aber die Karten müssten kostenlos zur Verfügung gestellt werden, da sie ja ein aus OSM-Daten hergestellte Werk sind. Gruß Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Karten im Monatsabo? Immerhin auch f ür andere Platformen als die üblichen.
Frederik Ramm schrieb: Hallo, Stefan Dettenhofer (StefanDausR) wrote: Ich weiß nur nicht ganz, wie das Karten-Abo mit der OSM-Lizenz vereinbar ist. Nach meinem Verständnis dürfte natürlich die Software verkauft werden, aber die Karten müssten kostenlos zur Verfügung gestellt werden, da sie ja ein aus OSM-Daten hergestellte Werk sind. Das ist falsch. Die Karten muessen unter der CC-BY-SA-Lizenz stehen, aber der Hersteller muss sie deswegen nicht kostenlos abgeben. Es ist voellig zulaessig, dass er sie nur an zahlende Kunden verteilt. Diese Kunden duerfen dann natuerlich, wenn sie wollen, die Karten beliebig weiterverteilen, auch kostenlos. Das war so natürlich falsch von mir hingeschrieben, sorry! Nur de facto wird das Abo dann trotzdem ad absurdum geführt, da es ja ausreichen würde, wenn ein einziger Kunde die Karten kauft und diese dann kostenlos -und das völlig legal- ins Netz stellt. Bernd Wurst schrieb: Dann solltest du (wie eigentlich fast jeder hier der irgendwas zum Thema die bösen Leute verlangen Geld schreibt) vielleicht mal an deinem Verständnis der Lizenz arbeiten. Irgendwann nervt es nämlich einfach nur noch. Mir ist die Lizenz schon klar -ich habe es falsch ausgedrückt. Es tut mir leid, wenn ich Dich dadurch genervt habe. Ich habe auch überhaupt nichts dagegen, wenn man mit OSM-Daten Geld verdienen kann, ganz im Gegenteil! Nur wenn von einem Karten-Abo die Rede ist, geht ein durchschnittlicher Kunde (der die CC-BY-SA-Lizenz nicht kennt) nicht davon aus, dass er die gekauften Karten frei weitergeben darf. Aber wenn das so funktioniert und es genug zahlende Abonnenten gibt, soll mir das recht sein. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Footmap-Vektorkarten
Johann H. Addicks schrieb: Wenn die bei Footmap auch Karten für Falk anbieten, dann wird's das auch früher oder später für Medion/Gopal geben, weil das doch afaik die gleiche Engine ist, oder? Du hast da was missverstanden: Für Falk meint die Hardware, nicht die Software-Engine! Die bieten keine PSF-Dateien an sondern ein eigenes Programm mit eigenem Datenformat, dass auf vielen Plattformen (u.a. auch Medion-PNA) läuft! Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Breitband Versorgung aufnehmen ?
Hallo, Jonas Stein schrieb: Die Bandbreite haengt sehr stark von der Technik des Netzanbieters ab und davon, wieviele Kunden schon an der Leitung angeschlossen sind. Das ist richtig! Und gerade deshalb fände ich die Info als Overlay schon interessant! Es ist also keine Eigenschaft, die in eine Landkarte gehoert. Vielleicht nicht unbedingt in die OSM-Datenbank aber extern erfasst und in der OSM-Karte angezeigt, könnte man schon eine gewisse Tendenz ablesen. Wenn ueberhaupt koennte man den Verlauf von Glasfaser und Kupfer in der Erde mappen. Das hingegen finde ich in OSM eher überflüssig! Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lastenseilbahn. Auf ein Neues!
Hallo Sven, die Seite http://www.steurer-seilbahnen.com/seilbahnen.html kennst Du ja sicher schon, oder? Sven Geggus schrieb: Ich würde jetzt ungern noch einen separaten Tag für Werkverkehrsbahn erfinden. Wie denkt ihr denn, dass man das lösen könnte? Gibt es eventuell schon ein passendes key/value Paar dass man hierfür verwenden könnte. Ich würde vorschlagen passenger=yes oder sowas der default wäre dann no. Wenn ich die Werkverkehrsbahn richtig verstehe, dann ist die Personenbeförderung dort nicht öffentlich, sondern nur für einen eingeschränkten Nutzerkreis zulässig. Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lastenseilbahn. Auf ein Neues!
Sven Geggus schrieb: Ich sollte im konkreten Fall vielleicht einfach aerialway=cable_car und access=private verwenden. oder aerialway=goods und access=private, wenn der Hauptzweck der Materaltransport sein sollte. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Frage zu asia.osm von der Geofabrik
Hallo, beim Erzeugen der NaviPOWM-Karten für Asien ist mir aufgefallen, dass keine Daten östlich von E179.99 erzeugt werden. Kann es sein, dass in der Asia.osm der Teil von Asien fehlt, dessen Koordinaten im Bereich von -180.00 (W180) bis ca. -168.00 (W168) liegt, oder bin ich zu dumm, den Bereich richtig mit osmosis auszuschneiden? Daten gibt es dort (auch wenn nicht viele), denn mit der xapi kann ich mir den fehlenden Bereich (stückchenweise) laden. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zu asia.osm von der Geofabrik
Frederik Ramm schrieb: Hi, Stefan Dettenhofer (StefanDausR) wrote: Kann es sein, dass in der Asia.osm der Teil von Asien fehlt, dessen Koordinaten im Bereich von -180.00 (W180) bis ca. -168.00 (W168) liegt, oder bin ich zu dumm, den Bereich richtig mit osmosis auszuschneiden? Ich glaube, diese Daten fehlen - weil *ich* nicht wusste, wie ich ein Osmosis-Polygon konstruiere, das ueber die 180°-Grenze hinausgeht. Bist aber bislang der erste, der deswegen fragt ;-) Bye Frederik Hallo Frederik, danke für die Antwort! Wäre es möglich, mit Hilfe eines 2. Asia-Polygons den Rest von Asien zu erschlagen (in einer 2. osm-Datei)? Besser wäre es natürlich, wenn der gültige Koordinatenbereich von Osmosis erweitert würde (oder vielleicht ist er es sogar?), so dass man Werte bis ca. +- 200° angeben darf. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zu asia.osm von der Geofabrik
Frederik Ramm schrieb: Hi, Stefan Dettenhofer (StefanDausR) wrote: Kann es sein, dass in der Asia.osm der Teil von Asien fehlt, dessen Koordinaten im Bereich von -180.00 (W180) bis ca. -168.00 (W168) liegt, oder bin ich zu dumm, den Bereich richtig mit osmosis auszuschneiden? Ich glaube, diese Daten fehlen - weil *ich* nicht wusste, wie ich ein Osmosis-Polygon konstruiere, das ueber die 180°-Grenze hinausgeht. Bist aber bislang der erste, der deswegen fragt ;-) Bye Frederik Hallo Frederik, Analoges gilt auch für australia-ociania.osm! Übrigens gibt es Überschneidungen von australia-ociania.osm mit asia.osm: Indonesien und die ganze Inselwelt sind in beiden Dateien vorhanden. Die betroffenen Gebiete siehst Du hier: http://wince.dentro.info/koord/osm/TileMap.htm Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zu asia.osm von der Geofabrik
Christoph Eckert schrieb: Moin, danke für die Antwort! Wäre es möglich, mit Hilfe eines 2. Asia-Polygons den Rest von Asien zu erschlagen (in einer 2. osm-Datei)? die Polygondateien unterstützen disjunkte Flächen, oder um es anders auszudrücken, Inseln außerhalb des Kerngebietes. Sollte also klappen, es sei denn, Fred ist über ein weiteres Problem gestolpert :) . Gruß, ce Ja genau, damit sollte es eigentlich funktionieren! Wahrscheinlich werden die ways, die ohne node über die magische 180°-Grenze verlaufen, trotzdem Probleme machen, aber damit kann man (momentan) gut leben. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zu asia.osm von der Geofabrik
Frederik Ramm schrieb: Hallo, Stefan Dettenhofer (StefanDausR) wrote: Ja genau, damit sollte es eigentlich funktionieren! Wahrscheinlich werden die ways, die ohne node über die magische 180°-Grenze verlaufen, trotzdem Probleme machen, aber damit kann man (momentan) gut leben. Ich habe das Asien-Polygon jetzt dahingehend abgeaendert. Allerdings wird es wohl noch ein paar Tage dauern, bis es auf download.geofabrik.de wieder Extrakte gibt, dazu muss erstmal das erste API 0.6-Planetfile kommen... Bye Frederik Hallo Frederik, danke! Es eilt aber gar nichts... Wenn wir schon gerade dabei sind: Wird es von Nord-Amerika auch ein Extrakt geben? Das Verzeichnis USA gibt es ja schon. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Windkraftanlagen
Das würde sich doch als OpenLayers Overlay eignen Gruß, Stefan Alexrk schrieb: Bernd Wurst schrieb am 20.04.2009 12:22: Kannst/Darfst du die mit dem Geocoder gewonnenen Koordinten als GPX-File veröffentlichen? Könnte die Daten als TXT rausgeben. Nur wie wo veröffentlichen? Ich hab das Zip (250k) erst mal auf Sourceforge zwischengelagert; wenn es jemand woanders (zb auf OSM) veröffentlichen oder umwandeln möchte - nix dagegen. Ich werde es alsbald von SF wieder löschen, da SF ja nicht als Filehoster gedacht ist ;) http://incanto.sourceforge.net/files/eeg_komplett.zip Ein paar Metadaten: * Quelle: EEG-Veröffentlichungen aller UENB's aus dem Jahr 2008 (also quasi Stand 2007) - Ausnahme: Netzgebiet der N-ERGIE (Nürnberg) - da hab ich mir die paar Anlagen selbst raussuchen müssen - Geocoder: geonames.org * Genauigkeit: da über die Ortsnamen geokodiert ca 5km * Lizenztechnisch: da Koordinaten aus geonames.org, würde ich das ebenfalls unter CC-BY sehen * Inhalt: - NETZBETREIBER (Einspeisung in Transportnetz) - ID (EEG Anlagenschlüssel) - STANDORT - BUNDESLAND - PLZ - LAGE - LEISTUNG_INST (in MW) - SPANNUNGSEBENE (Einspeisung auf welcher Ebene) - BAUJAHR - UENB (Übertragungsnetzbetreiber) - X - Y Gruß, Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] neue Karten für NaviPowm 0.2.1
Hallo zusammen, es gibt wieder aktuelle NaviPOWM-Karten und es sind auch neue Länder dazugekommen: - Deutschland - Europa - Afrika - Asien (komplett) - Australien + Ozeanien - Südamerika Insgesamt sind das nun fast 10 GB MAP-Files. Alle Dateien können wie immer als komprimierte 7z-Files von http://wince.dentro.info/koord/osm/TileMap.htm heruntergeladen werden. Viel Spaß! Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Autobahnauffahrt
Hallo, Ulf Lamping schrieb: a) Baulich getrennte Fahrspuren werden getrennt gezeichnet (soweit wohl konsens) b) Eine dicke weiße Trennlinie ist (k)eine bauliche Trennung (hier herrscht anscheinend kein konsens) c) Bei einem nicht unerheblichen Teil von Autobahnauffahrten werden die beiden entgegenkommenden Fahrspuren nur durch eine weiße Trennlinie getrennt. Ich verstehe das hier auch nicht ganz so: Sonst wird immer gesagt, dass man nicht für die Renderer oder sonstigen Programme taggt, sondern die Realität abbildet, aber gerade hier sollte eine Ausnahme gemacht werden?!? Mit der selben Logik müsste ich nun jede Straße, die eine durchgezogene Mittellinie hat, als baulich getrennt (und oneway=yes) taggen. Ich sehe auch kein Problem dabei, eine Autobahnauffahrt in mehrere Teilstücke aufzutrennen. Eine durchgezogene Mittellinie ist aber sicherlich keine bauliche Trennung! Das Ganze kann aber wahrscheinlich erst mit dem Lane-Tool richtig abgebildet werden. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Autobahnauffahrt
Guenther Meyer schrieb: aber zumindest eine doppelte durchgezogene linie wird rechtlich genau wie eine bauliche trennung behandelt. drum erscheint es schon sinnvoll, sowas auch entsprechend zu mappen... wenn das so ist, dann natürlich schon! Aber ich bin mir nicht ganz sicher, ob das stimmt: §3 Abs.3 StVO: 2c) (...) sowie auf anderen Straßen mit Fahrbahnen für eine Richtung, die durch Mittelstreifen oder sonstige bauliche Einrichtungen getrennt sind. Sie gilt ferner nicht auf Straßen, die mindestens zwei durch Fahrstreifenbegrenzung (Zeichen 295) oder durch Leitlinien (Zeichen 340) markierte Fahrstreifen für jede Richtung haben. Also obiges gilt für auch für *einspurige *Straßen mit Mittelstreifen oder sonstiger baulicher Trennung Sind 2 Fahrstreifen je Richtung vorhanden, so ist eine bauliche Trennung nicht erforderlich. Die Fahrstreifen müssen nur durch Fahrstreifenbegrenzungen oder durch Leitlinien gekennzeichnet sein. Eine *Fahrstreifenbegrenzung *dient sie zur Abgrenzung des Gegenverkehrs oder gleichgerichteten Verkehrs und darf auch vom Ein- oder Abbieger nicht überfahren werden. Ausnahme ist nur bei einem nicht ganz vorübergehenden Hindernis auf der Fahrbahnseite möglich (BayObLG VRS 70,55). Sie kann aus einer Doppellinie bestehen. Also: Ein Fahrstreifen pro Richtung, getrennt duch eine Doppellinie ist was anderes als ein Fahrstreifen pro Richtung mit baulicher Trennung! Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Autobahnauffahrt
Guenther Meyer schrieb: Ich glaube immer noch nicht, dass eine bauliche Trennung mit einer doppelt durchgezogenen Linie gleichzusetzen ist. mir wurde das damals so beigebracht, mehr kann ich dazu nicht sagen. Ansonsten wäre, wenn die Geschwindigkeit nicht eingeschränkt ist, sie 'unlimitiert', nur wenn in der Mitte der Straße zwei weiße Linien sind. davon sprech ich doch die ganze zeit... Aber das ist nicht unbedingt so! Ich habe es doch weiter oben schon erläutert! Stefan P.S.: Ansonsten soll es jeder so taggen, wie er meint, dass es richtig ist, so lange es keine vernünftige Möglichkeit gibt, das realitätsnah abzubilden. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Autobahnauffahrt
Garry schrieb: Es ist eine Fahspur die genau eine Fahrmöglichkeit (vorwärts, der Fahrspur folgend) zulässt - das entscheidenste Merkmal für eine Einbahnstrasse. Ich kann (bzw. darf) sie nicht am gleichen Ende wieder verlassen wo ich eingefahren bin. Das ist Realität! Das ist aber auch überall dort so, wo Wenden verboten ist! Aber ich denke, wir drehen uns im Kreis: Erst mit einem vernünftigen lane-Tool kann man das ordentlich abbilden. Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
Bernd Wurst schrieb: (...) Wir haben also dasselbe Problem wie bei den is_in der Ortschaften oder der Straßenzugehörigkeit von Hausnummern: Es ist nicht schön, aber das einzige bei dem jetzt im Moment jemand konkret ne Idee zur Auswertung hat, ist die redundante Information, in diesem Fall also das setzen von maxspeed für jede Straße. Je länger ich bei OSM dabei bin, umso mehr gefallen mir solche eigentlich total uneleganten Lösungen, denn irgendwie geht das einfach ratz-fatz, keiner muss irgendwelche hässlichen Implikationen beachten und man hat sofort ein Ergebnis. Volle Zustimmung! Da gibt es zwar Redundanz, aber es geht schnell und man sieht sein Ergebnis. Wenn man dadurch Vorverarbeitung (die nicht richtig funktioniert) einsparen kann hat es auch einen Vorteil. Außerdem muss man nicht raten, ob es keine Beschränkung gibt oder ob sie nur noch nicht erfasst ist. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
Florian Lohoff schrieb: (...) Hier ist das ergebniss: http://maxspeed.osm.lab.rfc822.org (...) Update derzeit Stuendlich ... Das sieht super aus! Dann kann ich meine Karte getrost bald abschalten. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
Marc Schütz schrieb: Glaubst du wirklich, dass es schneller geht, an jede Straße ein maxspeed=innerorts hinzuhängen, als schnell ein Polygon um die Stadt rumzumalen? Ja! Ein schnell mal herumgemaltes Polygon bringt doch auch nichts. Du müsstest die Ways an der Polygongrenze auftrennen, etc.. Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
Mario Salvini schrieb: also versuchen wirs mal: Default-maxspped nach highway-value: motorway = no motorway_link = 60 trunk = 100 trunk_link = 60 primary = 100 secondary = 100 teriary = 100 residential = 50 unclassified = 100 und z.B. primaries in der Innenstadt bekommen dann ein maxspeed=city statt ein maxspeed=no Wäre echt coool mal ein maxspeed-Layer zu sehen, was sich nach diesen Defaults richtet (für die Ways die nicht exmplit ein maxspeed-value haben) Ok, aber wie kommst Du auf den Default für *_link? Außerdem wäre es doch sinnvoll, noch die Länderkennung dazuzuschreiben, also: maxspeed=de:city maxspeed=at:motorway maxspeed=it:trunk ... Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
Tobias Knerr schrieb: Völlig ok, mir gings um die Entscheidung zwischen Wert und Schlüssel. Vielleicht sollte man noch ein maxspeed=city:DE draus machen (wegen des Einwands Sprache vs. Land). Ok das schein vernünftig zu sein! Eigentlich bin ich zwar auch eher für die von Garry bevorzugte einfachste Minimallösung das direkten taggens des Zahlenwertes, aber die länderspezifischen Defaultwerte hätten auch Ihren Vorteil: maxspeed=motorway:DE kann je nach Verkehrsmittel unterschiedlich interpretiert werden, also im PKW-Modus als no/none/unlimited/gar nichts LKW-Modus als 80 oder ein maxspeed=non_motorway:DE (oder maxspeed=primary:DE oder wie auch immer) kann so interpretiert werden: PKW-Modus als 100 klein-LKW-Modus als 80 LKW-Modus als 60 Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
Bernd Wurst schrieb: Hallo. Am Mittwoch 29 April 2009 13:44:00 schrieb Mario Salvini: wir hätten also schonmal als neuen Vorschlag: maxspeed=motorway:DE maxspeed=city:DE müsste man also nur noch überlegen, wie man das Kind tauft, wenns außerorts aber nicht eine Autobahn ist. mein Vorschlag wäre: maxspeed=default:DE Könnt ihr diese Prosa-Werte bitte in einen unbenutzten Key bzw. einen Subkey auslagern, so dass die Pragmatiker maxspeed auf den an Ort und Stelle gültigen Wert setzen können? Danke. Meinst Du so: maxspeed=50 und maxspeed:default=city:DE bzw. maxspeed=100 und maxspeed:hgv=60 und maxspeed:default=default:DE aber pflegt das jemand wirklich so? Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
Bernd Wurst schrieb: Weil maxspeed=7 und maxspeed=walk sich gegenseitig ausschließen. Man kann nicht beide Vorgehensweisen parallel nutzen. Das würde nur so Sinn machen: maxspeed=7 und zusätzlich maxspeed:default=walk:DE Dann bedeutet das, jeder, der es besser weiß, kann für walk:DE einen Wert zwischen 4 und 10 annehmen, alle anderen benutzen einfach 7 Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
Mario Salvini schrieb: Sind die gelben Autobahnen nicht auch klar/eindeutig über highway=trunk + motorroad=yes zu erkennen? Könnte man auch als eindeutiges Kriterium deklarieren. Überall da wo highway=motorway ODER highway=trunk + motorroad=yes UND kein maxspeed-Tag gilt -- maxspeed=unlimited=no=none ODER highway=primary UND lanes=2 (2 oder mehr Spuren) ODER highway=primary UND onway=true (baulich getrennte Fahrbahnen) Aber eine Kraftfahrstraße (highway=trunk + motorroad=yes) erfüllt nicht per se o.g. Bedingungen Ich denke bei so vielen Ausnahmen ist es besser ein Klares tag zu setzten! Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map - Kompromissvorschlag
Chris-Hein Lunkhusen schrieb: Proposal: speedzone Values: speedzone=default:DE (100) speedzone=default:NL (80) speedzone=city:DE (50) speedzone=motorway:DE (keine/Richtgeschw. 130) 30er Zonen würde ich weiterhin mit maxspeed=30 taggen alternativ mit speedzone=30. maxspeed hat Vorrang vor speedzone. Diesen Vorschlag finde ich schon mal recht gut und möchte ihn noch etwas konkretisieren: 1) maxspeed=... und speedzone=... dürfen unter der Voraussetzungen gleichzeitig verwendet werden, dass der numerische Wert in maxspeed=... genau dieser Wert ist, der dem momentan gültigen Defaultwert für PKW in speedzone= entspricht und die Geschwindigkeit nicht explizit (s. Punkt 2) geregelt ist. speedzone=... hat hier Vorrang vor maxspeed=...! 2) maxspeed=... steht alleine, wenn die Geschwindigkeit explizit durch ein Verkehrszeichen (Zeichen 274) geregelt ist. Es dürfen ausschließlich numerische Werte angegeben werden! Hier darf speedzone=... nicht stehen. 3) speedzone=... steht alleine, wenn die Geschwindigkeit implizit geregelt ist, bzw. kein exakter numerischer Wert existiert. Hier kann maxspeed=... unter der Voraussetzung (s. Punkt 1) zusätzlich angegeben werden. 4) explizite Regelungen der Geschwindigkeit für andere Fahrzeuge als PKW (maxspeed:hgv=...) können jederzeit zusätzlich angegeben werden. 5) Bei allen Wegen, für die eine Geschwindigkeitsangabe nicht sinnvoll ist (footway, path) oder sich eindeutig aus der Straßenklasse (living_street) ergibt, kann auf die Angabe von speedzone=... verzichtet werden, muss aber nicht. Was ist der Vorteil meines Vorschlages? - Man ist kompatibel mit der derzeitigen Definition von maxspeed - existierende Programme müssen nicht umgeschrieben werden - alle derzeit vorhandenen, nicht-numerischen Werte in maxspeed=... können automatisch aus der Datenbank entfernt werden und in Werte für speedzone=... gewandelt werden. - Man kann jederzeit (per bot oder Vorverarbeitung) fehlende bzw. benötigte numerische Werte für maxspeed= erzeugen - Bei der Änderung der Gesetzeslage kann man die impliziten maxspeed-Werte ebenfalls per bot automatisch (aus den speedzone-Defaults) ändern. - Man kann unterscheiden, ob für eine Strecke keine Beschränkung existiert oder sie noch nicht erfasst wurde. Welche Defaults werden für speedzone=... benötigt? default:DE würde ich durch z.B. outside:DE ersetzten, da erkennt man besser das außerhalb geschlossener Ortschaften Beispiele (für PKW): speedzone=outside:DE (100) speedzone=outside:NL (80) speedzone=city:DE (50) speedzone=motorway:DE (keine/Richtgeschw. 130) speedzone=zone30 (30) alternativ auch maxspeed=30 oder speedzone=zone30:DE speedzone=walk:DE (Schrittgeschwindigkeit ohne exaktem Wert) speedzone=variable(variable Geschwindigkeitsregelung) speedzone=variable80 (variable Geschwindigkeitsregelung, die auf max. 80km/h eingestellt werden kann) speedzone=motorway:IT (130) speedzone=outside:IT (90) ... Beispiele für best. Straßen (in DE) - Autobahn ohne Beschränkung:speedzone=motorway:DE (maxspeed=no/none/... wird entfernt) - Autobahn mit Wechselschildern: speedzone=variable (maxspeed=var wird entfernt) - Landstraße ohne Beschränkung: speedzone=outside:DE (maxspeed=100 kann zusätzlich angegeben werden) - Innerorts ohne Beschränkung: speedzone=city:DE (maxspeed=50 kann zusätzlich angegeben werden) - Innerorts auf 80 erhöht: maxspeed=80 (speedzone=city:DE darf hier nicht stehen!) - Innerorts auf 50 (per Z 274): maxspeed=50 (speedzone=city:DE darf hier nicht stehen!) - Innerorts 30er-Zone: speedzone=zone30 (oder maxspeed=30 oder beides) - Verkehrsberuhigter Bereich:speedzone=walk:DE (maxspeed=walk/7/... wird entfernt) Was haltet Ihr davon? Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map - Kompromissvorschlag
Guenther Meyer schrieb: (...) zusammen mit der langen liste an definitionen und beispielen, wann was zu verwenden ist, wird erst richtig klar, dass das alles nur unnoetige komplexitaet in was eigentlich recht einfaches bringt. mein Vorschlag ist -wenn man ihn genau gelesen und verstanden hat- nicht kompliziert. Ich habe nur versucht, es mit Beispielen zu verdeutlichen: Kurzfassung: 1) Da wo ein Schild steht - maxspeed=... 2) Da wo kein Schild steht - speedzone=... Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map - Kompromissvorschlag
Guenther Meyer schrieb: Am Montag 04 Mai 2009 schrieb Stefan Dettenhofer (StefanDausR): Guenther Meyer schrieb: (...) zusammen mit der langen liste an definitionen und beispielen, wann was zu verwenden ist, wird erst richtig klar, dass das alles nur unnoetige komplexitaet in was eigentlich recht einfaches bringt. mein Vorschlag ist -wenn man ihn genau gelesen und verstanden hat- nicht kompliziert. Ich habe nur versucht, es mit Beispielen zu verdeutlichen: naja, wenn man fuer das ganze nur ein tag, naemlich maxspeed verwendet, dann wird deine definition schon mal um ganze drei punkte kuerzer, und information geht auch keine verloren... Das ist schon klar, aber es gibt ja viele, die das rein numerische maxspeed noch brauchen oder haben wollen! Daher hatte ich das auch Kompromissvorschlag genannt. Es stellt ja kein Problem dar, sobald sich die Dafaultwerte etabliert haben, per bot alle values von speedzone= nach maxspeed= zu kopieren und speedzone= zu löschen. Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed: alternativer Vorschlag
Guenther Meyer schrieb: dann muss ich doch mal meinen vorschlag ausformulieren: Um die auf einem way gueltige Geschwindigkeitsbeschraenkung anzugeben, wird der key maxspeed benutzt. (...) Damit kann ich genauso leben... Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map - Kompromissvorschlag
Guenther Meyer schrieb: warum willst du es dann einfuehren um es dann wieder zu loeschen? das bringt nur noch mehr verwirrung rein. was spricht dagegen, diese zwischenschritt wegzulassen, und das gleich zu migrieren? Ich habe -wie bereits geschrieben- kein Problem mit Deinem Vorschlag, aber es gibt viele Programme, die nur numerische Werte in maxspeed auswerten. Die jetzt existierenden nichtnumerischen Werte entsprechen auch nicht der Definition im Wiki. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neuer WMS-Dienst mit dem Josm-WMS-Plugin // Nachtrag // Nachtrag 2
Tobias Wendorff schrieb: Witzig: die GK-Blätter weichen auch um 3 Meter ab! Nun sei doch mal nicht so genau... Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neuer WMS-Dienst mit dem Josm-WMS-Plugin // Nachtrag // Nachtrag 2
Tobias Wendorff schrieb: Stefan Dettenhofer (StefanDausR) schrieb: Tobias Wendorff schrieb: Witzig: die GK-Blätter weichen auch um 3 Meter ab! Nun sei doch mal nicht so genau... Wir reden hier über einen digitalen Datensatz, der einfach nur eingefügt und geladen wird. Es *kann* eigentlich gar keine Fehler geben, außer man gibt falsche Parameter ein. Ich würde mir im Job sowas jedenfalls nicht erlauben. sorry, ich hatte den smily vergessen! Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ref tag bei ways erforderlich wenn eine relation existiert?
Werner Hoch schrieb: ich frage mich ob ich an jeden einzelnen Wegabschnitt ein ref= tag anbringen muss obwohl viele Wege ja bereits über eine Relation eine ref= tag haben. Beispiel1: Jeder Weg mit Referenz: http://www.openstreetmap.org/browse/relation/3420 operator = Bodenseekreis ref = K 7735 route = road type = route Beispiel2: Wege ohne Referenz: http://www.openstreetmap.org/browse/relation/10949 operator = Bodenseekreis ref = K 7719 route = road type = route Im Beispiel2 werden die Referenzen auf den Straßen in Mapnik und TAH nicht dargestellt. Momentan ist es wohl besser, die Tags doppelt zu führen, da die Relation mit type=route und route=road von keiner mir bekannten Anwendung ausgewertet wird. Zukünftig ist es natürlich sinnvoller, gemäß Beispiel 2 zu taggen. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ref tag bei ways erforderlich wenn eine relation existiert?
Hallo Nop, Nop schrieb: Hallo! Stefan Dettenhofer (StefanDausR) schrieb: Werner Hoch schrieb: ich frage mich ob ich an jeden einzelnen Wegabschnitt ein ref= tag anbringen muss obwohl viele Wege ja bereits über eine Relation eine ref= tag haben. Beispiel1: Jeder Weg mit Referenz: http://www.openstreetmap.org/browse/relation/3420 operator = Bodenseekreis ref = K 7735 route = road type = route Momentan ist es wohl besser, die Tags doppelt zu führen, da die Relation mit type=route und route=road von keiner mir bekannten Anwendung ausgewertet wird. Zukünftig ist es natürlich sinnvoller, gemäß Beispiel 2 zu taggen. Auch wenn die Aussage grundsätzlich nicht falsch ist, möchte ich wie immer bei diesem Thema darauf hinweisen, daß vor einer technischen Umsetzung auch noch einige grundsätzliche logische Probleme zu klären und Festlegung zu treffen wären. Z.B. was überhaupt passieren soll, wenn der way keine ref hat, aber er gehört zu einer road-Relation, zu einer bus-Relation und zu zwei hiking-Relationen und alle 4 Relationen haben eine ref. Das mit den Relationen sieht nur auf den ersten Blick einfach aus, ist aber ziemlich knifflig. Stichwort für Informatiker: Mehrfachvererbung. eigentlich ist es doch ganz einfach (oder sehe ich da was falsch): 1) Es werden erst einmal nur die Relationen gerendert bzw. ausgewertet, also nicht mehr auf der Ebene von ways gearbeitet sondern eine Ebenen höher. 2) Dann ist das mit der Vererbung auch kein Problem, denn die Tags in der Relation stellen den Defaultwert dar, der durch einen speziellen am way überschrieben werden kann. 3) Zuletzt werden noch alle ways, die keiner road-Relation angehören, klassisch rerendert. Um bei Deinem Beispiel zu bleiben: - Mit Hilfe der road-Relation und vererbtem ref-Tag (ggf. auch name-Tag) plus aller way ohne road-Relation wird die normale Straßenkarte erzeugt. - Mit Hilfe der bus-Relation und vererbtem (anderem) ref-Tag werden die Buslinien darüber gezeichnet - Mit Hilfe der hiking-Relation und vererbtem (anderem) ref-Tag (und weiteren vererbten Tags) werden die Wanderwege generiert. Aber das ist doch jetzt im Prinzip auch schon nicht anders, oder? Gruß, Stefan P.S.: So können auch die Superrelationen behandelt werden: Erst alle Superrelationen eines typs, dann alle Relationen dieses typs, die keinen Superrelation angehören und zum Schluss alle ways, die keiner Relation angehören. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] abkickende vorfahrt
Florian Lohoff schrieb: Im moment wird das ja mit unserem datenmodell nicht funktionieren das das navi entweder sagt Der abbiegende Vorfahrt nach Rechts folgen oder auch nur einfach die klappe haelt wie mein festeinbau. Ich denke dass man das ohne spezieller turn_restriction o.ä. nur von der höheren Straßenklasse ableiten kann und ggf. bei gleicher Straßenklasse auswertet, ob sich der ref-Tag bzw. der Name ändert. Bei meinem Navi ist das auch oft so, dass es sagt: in 300m geradeaus fahren, obwohl nur links eine Straße der selben Klasse abzweigt. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] abkickende vorfahrt
Bernd Wurst schrieb: Hallo. Am Mittwoch 06 Mai 2009 09:39:08 schrieb Stefan Dettenhofer (StefanDausR): Ich denke dass man das ohne spezieller turn_restriction o.ä. nur von der höheren Straßenklasse ableiten kann und ggf. bei gleicher Straßenklasse auswertet, ob sich der ref-Tag bzw. der Name ändert. Bei meinem Navi ist das auch oft so, dass es sagt: in 300m geradeaus fahren, obwohl nur links eine Straße der selben Klasse abzweigt. Es wird oft genug ohne eine besondere Angabe der Vorfahrtsregelung nicht möglich sein, die Situation algorithmisch zu erkennen. Beispiel: http://www.openstreetmap.org/?lat=49.005005lon=9.502024zoom=18 Die Bundesstraße zweigt ab, in einem Winkel 90°, grade aus geht nur eine Landesstraße. Eigentlich spricht da alles für eine abknickende Vorfahrtstraße. Wie man hier sieht... http://maps.google.de/?ll=49.004951,9.501194z=18t=k ...ist das aber nicht so. Gruß, Bernd Ja das wollte ich ja sagen: 1) Auswertung nach Straßenklasse - Normalfall 2) Spezielle relation analog der turn_restriction - Sonderfall Der Sonderfall kann dann natürlich auch eine Vorfahrtsregel sein, die geradeaus weist. Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ref tag bei ways erforderlich wenn eine relation existiert?
Hallo Nop, Nop schrieb: (...) Ja. :-) Du machst einige Annahmen, für die es noch weder eine Einigung noch eine dokumentierte Festlegung gibt. (...) Du hast natürlich recht, dass das momentan so noch nicht läuft (daher hatte ich ja weiter oberen geschrieben, dass man derzeit die ref-tags besser auch noch an die ways schreibt. Wir diskutieren hier aber doch eher über die zukünftige Entwicklung! Aber auch nach momentanem Stand ist es doch so (egal ob beschrieben oder nicht): Eine Relation mit route=road und type=route wird gar nicht ausgewertet, stellt aber eine logische Zusammenfassung einer Straße dar, die aus vielen ways besteht (mit unterschiedlichen maxspeed=..., bridge=... etc.), aber die selbe ref und highway-typ hat. Also hier mein verbesserter *Vorschlag*, wie man das lösen könnte: Relation: operator = Bodenseekreis ref = K 7735 route = road type = route highway = secondary Member 1: cycleway = lane name = Meistershofener Straße Member 2: junction = roundabout oneway = yes ... Es wird auf Relationsebene gerendert, wenn dort auch der highway-typ angegeben ist. Die ways selber dürfen dann keine highway-Tag mehr enthalten und die tags werden vererbt. Ways ohne road/highway-Relation werden normal behandelt. Es läuft doch jetzt bei der Bus- und Wanderrouten genauso: Man benutzt doch für die Darstellung der Route nur die Geometrie der Wege und die Tags, die einem interessieren, der Rest wird aus der Relation genommen. Ich denke, dass langfristig ein Umdenken erfolgen muss, was die Bedeutung der Grundtypen angeht: früher gab es: node - segment - way jetzt gibt es: node - way - relation ich sehe das eigentlich so, dass ein way eher einem segment entspricht, das aus mehreren geordneten Stützpunkten (nodes) besteht und mehrere ways zu einer geordneten relation zusammengefasst werden. Bei den Multipolygonen ist das ja auch schon so. Je mehr Attribute erfasst werden (maxspeed=, ...) um so zerstückelter und kürzer werden die einzelnen ways, so dass es durchaus Sinn macht, diese Teile wieder logisch zusammenzufassen. Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] abkickende vorfahrt
Florian Lohoff schrieb: Es ging ja eben nicht um verziehen sondern es ging drum die realitaet zu erfassen das ein Navi die moeglichkeit hat richtige und konsistente anweisungen zu geben. Im moment wird das Navi immer von abbiegen sprechen was IMHO zu viel gequatsche ist. Wenn es das wissen um die abknickende vorfahrt hat kann es so der Fahrer moechte: a) darauf hinweisen das der vorfahrt zu folgen ist Folgen sie der abknickenden Vorfahrt nach Rechts b) Stumpf abbiegeanweisungen geben: Biegen sie in 50m rechts ab c) Einfach die klappe halten was imho der groesste Komfort ist. Ohne diese erfassten abknickenden Vorfahrten bleibt nur b). Es gibt auch noch die Möglichkeit, dass wenn man bei einer nach rechts abknickenden Vorfahrt geradeaus fährt, vom Navi gewarnt wird, dass man hier aufpassen muss! Da gibt es mehrere sehr gefährliche Stellen. Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ref tag bei ways erforderlich wenn eine relation existiert?
Nop schrieb: Versteh mich richtig: Ich bin nicht gegen Neuerungen. Ich bin aber für vernünftig definierte Neuerungen anstatt Chaos durch überstürzte Benutzung undefinierter Mechanismen. Nochmal mein Mantra: Es ist nicht so einfach, wie es aussieht. Wir brauchen genaue Regeln, was wie vererbt werden kann. Sauber im Wiki aufgeschrieben. Das ist schon klar, dass es definiert und aufgeschrieben werden sollte, bevor es eingeführt wird, aber wir sind doch momentan erst im brainstorming-Status. Wir überlegen doch erst, was wie funktionieren könnte. Wenn nicht irgendwo klar definiert ist, daß ein highway-Typ vererbt werden kann, dann verschwinden die Ways aus Deinem Besipiel komplett aus der Karte. Gefällt mir aber gar nicht, denn das zwingt jeden Editor und Renderer solche Abhängigkeiten zu prüfen. Wenn Du Dir nur den Way ansiehst und nichts von der Relation weißt, erscheint er Dir kaputt und schon bist Du als guter Mapper am verschlimmbessern. Das ist ein generelles Problem von OSM, das jeder alles machen darf. Sobald es aber gute Werkzeuge gibt (JOSM-Unterstützung), setzen sich aber Neuerungen schon durch. Wenn ich Dein Beispiel oben nehme und füge die Wege noch in einer Wanderroute hinzu, dann würde der Roundabout nach aktuellem Stand des Wikis den Namen der Wanderroute erben, weil er selber keinen hat. Kaum das was wir haben wollen, oder? Nein, es muss schon klar definiert sein, was von welcher Relation vererbt wird.. Für name müsste man sich das gut überlegen, denn z.B. bei einer Wohnstraße, die aus mehreren Stichstraßen besteht, würde ein Vererben Sinn machen, bei einer Landstraße eher nicht, da diese verschiedene Namen oder auch teilw. keine tragen kann. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: Relationen - Element-Reihenfolge bearbeiten
Jan Tappenbeck schrieb: gibt es noch ein weiteres Hilfsmittel darüberhinaus welches mir noch nicht bekannt ist. Mit dem OSM Relation Analyzer http://betaplace.emaitie.de/webapps.relation-analyzer/ kann man zumindest nachsehen, ob die Wege verbunden werden können. Ansonsten fände ich eine Integration in JOSM natürlich sehr wünschenswert! Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] route=flight
Claudius schrieb: Insofern halte ich die dauerhafte GPS-Erfassung von festen Flugrouten für sinnfrei, da es diese nicht gibt. Hm, müsste man dann nicht für (Schiffs-)Fährrouten die selben engen Maßstäbe ansetzten? Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map - Kompromissvorschlag
Mario Salvini schrieb: Also gibts keinen Fall wo speedzone und maxspeed gleichzeitig Sinn machen. Das heißt aber dann auch, dass speedzone unnötig ist, und wir alles mit maxspeed abbilden können. (siehe meine Argumentation weiter oben Das ist richtig! Meinen Kompromissvorschlag hatte ich ja nur deshalb erstellt, damit -zumindest übergangsweise- beide Tags parallel laufen können und die alten Programme mit rein numerischen maxspeed-Werten versorgt werden können. Je länger ich mir das überlege, ist es aber wahrscheinlich doch besser, gleich alles nur in maxspeed zu packen. Die nötige Vorverarbeitung für die alten Programme hält sich ja in Grenzen. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zu OSM-WMS
Kai Behncke schrieb: ich frage mich, ob es möglich ist einen OSM-WMS in der Qualität hinzukriegen, wie die OSM-Daten, welche über Mapnik gerendert werden? Es gibt ja den frei zugänglichen OSM-WMS der Wheregroup: http://osm.wheregroup.com/cgi-bin/mapserv?map=/data/umn/osm/osm_basic.map Die Qualität ist ja auch wirklich nicht schlecht, kommt meiner Meinung nach aber nicht an die typischen OSM-Mapnik-Kacheln heran. Es gibt auch noch diesen WMS-Dienst (für Deutschland) http://osm.omniscale.de/ aber bitte die Nutzungsbedingungen beachten! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Namen von Relationen
Hallo Nop, ekkeh...@gmx.de schrieb: Das Problem ist, daß Nodes und Ways physikalische Objekte sind, aber Relationen Beziehungen zwischen Objekten. Es kann sein, dass das mal so gedacht war, aber: 1) Es gibt ways, die auch keinen realen Weg darstellen, sondern eine logische Beziehung, nämlich die Hausnummern-Interpolation 2) Ein way ist eine logische Verknüpfung von nodes, eine relation ist eine logische Verknüpfung von nodes, ways und relations. Was ist da der prinzipielle Unterschied? Eigentlich keiner! 3) Es gibt Typen von Relationen, die eine genau definierte grafische Bedeutung haben, nämlich die Multipolygone. Ich denke, das Wichtigste ist, genaue Definitionen und Regeln aufzustellen, was bei welchem Element (node, way, relation+type) wo und wie dargestellt werden soll. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Höhlen / Höhleneingang
Hallo zusammen, ich habe eine Frage zu Höhlen bzw. Höhleneingängen: Die König-Otto-Höhle ist mit name: König Otto Tropfsteinhöhle tourism: attraction getaggt und - sie wird in der Reit- und Wanderkarte gar nicht angezeigt: http://topo.geofabrik.de/?zoom=15lat=49.25473lon=11.68969layers=BT - es wird mit Osmarender und Mapnik zumindest der Text gerendert: http://www.openstreetmap.org/?lat=49.25387lon=11.68914zoom=17layers=B000FTF Die Räuberhöle habe ich mit name: Räuberhöhle natural: cave_entrance getaggt und sie wird - in der Reit- und Wanderkarte angezeigt und der Text gerendert: http://topo.geofabrik.de/?zoom=15lat=49.04208lon=11.98065layers=B - mit Osmarender und Mapnik gar nicht angezeigt: http://www.openstreetmap.org/?lat=49.04208lon=11.98065zoom=17layers=B000FTF Wie sollte man nun eine Höhle am besten taggen? Die Höhle selbst als tourism: attraction und den (die) Eingang (Eingänge) zusätzlich als natural: cave_entrance? Wie kann man die ungefähre unterirdische Form der Höhle wiedergeben? Als highway=path mit tunnel=yes und area=yes? Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zu OSM-WMS
Hallo Kai, Kai Behncke schrieb: Ich habe einmal http://osm.omniscale.net/proxy/service?service=WMS in den UMN eingebunden und lasse mir die Layer osm bzw. osm_roads ausliefern, das Resultat allerdings sieht eher sparsam und komplett anders (pixelig, unscharf) als die wirklich toll aussehende Demo bei http://osm.omniscale.de/ aus. Woran könnte das liegen? ich habe den WMS-Server mal testweise in mein Auskunftssystem für Geodaten eingebunden und mit den amtl. Grenzen und Gebäuden überlagert. Das sieht eigentlich ganz gut aus, oder? http://wince.dentro.info/koord/osm/temp/omniscale.png Vielleicht liegt es an dem von Dir verwendeten Koordinatensystem (Projektion). Ich benutze GK-Koordinaten. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Namen von Relationen
ekkeh...@gmx.de schrieb: Du zwingst dann jeden Renderer und jedes Tool, diese Relation zu kennen und auszuwerten, ansonsten fehlen die Tags und die nodes/way verschwinden oder werden falsch ausgewertet. Das ist aber bei den Adress-Interpolationen (ways) jetzt auch schon so. Wenn man die nicht kennt, werden Wege gerendert, die es nicht gibt. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhlen / Höhleneingang
ekkeh...@gmx.de schrieb: Wie sollte man nun eine Höhle am besten taggen? Die Höhle selbst als tourism: attraction und den (die) Eingang (Eingänge) zusätzlich als natural: cave_entrance? Die Höhle auf jeden Fall mit cave_entrance taggen, denn dieses Tag beschreibt das Vorhandensein einer Höhle. Attraction ist sehr unspezifisch. Eine generelle Anzeige wäre vielleicht für eine Freizeitkarte interessant, aber auf einer Topokarte ist es völlig irrelevant. Ok! Und wo setzt man dann das name-Tag d'ran? An den (Haupt-)Eingang der Höhle oder doch lieber an eine zusätzliche node (welche?), die das ungefähre Zentrum der Höhle markiert? Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhlen / Höhleneingang
ekkeh...@gmx.de schrieb: Hi! naja, bei Höhlen, die 2 Eingänge haben, könnte man so erkennen, dass man durchkommt, das hat durchaus seine Berechtigung. Ok. Eine Durchgangshöhle ist ein absoluter Sonderfall. Wenn wirklich ein Weg durchgeht, der ohne Ausrüstung begehbar ist, würde ich den ganz normal als path eintragen. Aber ich glaube das war hier nicht gemeint, wenn ein Tag area=yes vorgeschlagen wird. Na ja schon irgendwie: Meine Beispielhöhle besteht nur aus einem voll erschlosseenen, runden Raum mit ca. 20m Durchmesser. Es gibt einen Haupteingang und hinten kann man diesen ins Freie verlassen und noch etwas weiter gehen. Momentan habe ich halt 2 Höhleneingänge (einer mit name) getaggt und den Weg bis zum Eingang und dann wieder am 2. Eingang weiter gezeichnet. Der Weg in der Höhle fehlt. Meine Idee war entweder einen path als Tunnel (geht das?), damit die Wege verbunden sind oder gleich irgendwie die Ausdehnung mit anzugeben, daher der Vorschlag mit area. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map - Kompromissvorschlag
Mario Salvini schrieb: man kanns ja auch gerne *traffic*zone nennen oder gleich nur zone=, also zone=in_town:DE zone=out_of_town:DE zone=motorway:DE (zone=walk:DE) Eine Vorverarbeitung kann dann an alle relevanten ways, die *kein* maxspeed (etc.) haben, den entsprechenden Defaultwert setzten. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhlen / Höhleneingang
Markus schrieb: natural=cave natural=cave_entrance Die überwiegende Mehrheit der Tags ist cave_entrance. cave wurde ja abgelehnt: http://wiki.openstreetmap.org/wiki/Proposed_features/Cave Hm - der Eingang ist ja nur das erste Erkennungsmerkmal einer Höhle. Das Wesentliche entdeckt man erst dahinter. Daher ja meine Frage! Also dann würde ja doch dafür tourism=attraction (plus weiterer spezieller Tags) recht gut passen, oder? Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhlen / Höhleneingang
ekkeh...@gmx.de schrieb: Hi! Daher ja meine Frage! Also dann würde ja doch dafür tourism=attraction (plus weiterer spezieller Tags) recht gut passen, oder? Das paßt _zusätzlich_ an jede Schauhöhle oder ausgeschilderte/beworbene Höhle. Für den Höhleneingang selber ist aber cave_entrance das einzige passende Tag. Ja der Höhleneingang ist ja klar! Es geht um die Höhle selber! Dafür suche ich ein passenden Key/Tag. Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] neue Karten für NaviPowm 0.2.2
Hallo zusammen, die Mai-Daten liegen in der Version 0.2.2 am Server und es sind auch neue Länder dazugekommen: - Deutschland (953 MB) - Europa (4,01 GB) - Afrika (1,07 GB) - Antarktis (277 MB) - Asien (2.53 GB) - Australien + Ozeanien (806 MB) - Südamerika (818 MB) Insgesamt sind das nun über 10 GB MAP-Files. Abdeckung: http://wince.dentro.info/koord/osm/NaviPOWM_Karten.png Alle Dateien können wie immer als komprimierte 7z-Files von http://wince.dentro.info/koord/osm/TileMap.htm heruntergeladen werden. Viel Spaß! Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wanderwetter
Hallo Nop, Nop schrieb: in der Warteliste [2], wenn irgendwas fehlt. [2] http://topo.geofabrik.de/Relationsprobleme.html könntest Du mir bitte sagen, was für ein Problem die Relation 49531 hat? In der Warteliste steht Länge zu gering, aber das kann ich nicht nachvollziehen! In der generierten Wiki-Liste erscheint sie richtig! Wie soll ich die Superrelation 49759 kennzeichnen, dass sie nicht in der Warteliste auftaucht? Das Symbol hatte ich ja schon deshalb entfernt. Gruß und Danke, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wanderwetter
Nop schrieb: Hi! Stefan Dettenhofer (StefanDausR) schrieb: könntest Du mir bitte sagen, was für ein Problem die Relation 49531 hat? In der Warteliste steht Länge zu gering, aber das kann ich nicht nachvollziehen! In der generierten Wiki-Liste erscheint sie richtig! Vermutlich gar keines. Es gibt ein paar einzelne Falschmeldungen bei der Längenberechnung, bin aber noch nicht drauf gekommen, was da schief läuft. Die Relation wird aber auch in der Karte nicht angezeigt! (sie wurde aber früher schon mal gerendert!) Wie soll ich die Superrelation 49759 kennzeichnen, dass sie nicht in der Warteliste auftaucht? Das Symbol hatte ich ja schon deshalb entfernt. Gar nicht. Der Kartenrenderer kann das nicht unterscheiden, das ist für ihn einfach eine überflüssige, leere Relation. ok Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map - zone:traffic als Liste
Per schrieb: Ich schlage vor diese durch Semikolon getrennt zu mappen! Z.B. zone:traffic=DE:speed:30;DE:no_waiting Ich würde es lieber in seperate Tags schreiben: zone:traffic:maxspeed=DE:speed:30 zone:traffic:parking=DE:no_waiting Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Amenity Editor
Hallo Adrian, ich habe auch gerade ein paar Adressen eingetragen. Das läuft sehr gut - Danke! Wie ist das Format für die Telefonnummern eigentlich gedacht? Internationale Rufnummer ist klar. Wie ist das bei Nebenstellen: Soll da ein Bindestrich oder ein Leerzeichen hin? ansonsten trenne ich die Teile (ONKZ und Rufnummer) per Leerzeichen. Adrian Stabiszewski schrieb: Ich denke, addr:country kann man automatisch irgendwann mal nachtragen. ;) Könntest Du nicht einfach einen mit DE vorbelegten Button -analog zur Telefonnummer- erzeugen? Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=no
Heiko Jacobs schrieb: Ich bastel gerade an einer Nebenkarte, in der man wohl auch highway=anything sehen wird, schaun mer mal, die würde dann demnach Pflichtlektüre für nach fehlende Wege Suchende... ;-) NaviPOWM zeigt alle ways, die es nicht kennt als dünne schwarze Linie an, momentan sogar die Interpolationslinien für Hausnummern! Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] FYI: Webserver download.geofabrik.de nicht erreichbar
Frank Glück schrieb: Oder könnte es mir evtl. jemand zum Download bereitstellen? Danke!! Vom 24.5.09 6:00 Uhr hätte ich! Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] FYI: Webserver download.geofabrik.de nicht erreichbar
Frederik Ramm schrieb: Grundsaetzlich darf das File natuerlich gern jeder mirrorn, der moechte. Ich habe die Daten (teilweise ein paar Tage alt), die ich mir zur Generierung der NaviPOWM-Karten herunterlade bei mir auf der Platte. Wenn Bedarf -so wie gestern geschehen- kann ich einzelne Files auf Anfrage gerne temporär auf meinen Server legen. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Testprogramm für OSM-Dateien
Hallo zusammen, ich habe mir ein kleines Windows-Programm geschrieben, mit dem man ganz einfach testen kann, ob eine OSM-Datei vollständig erzeugt wurde oder nicht. Mir ist es schön mehrmals so ergangen, dass Osmosis auf Grund eines Fehlers eine OSM-Datei nur teilweise erzeugt hat. Bei sehr großen Dateien tut man sich schwer, festzustellen ob die nun komplett sind, da das Laden in einen Editor schwierig ist. Daher das Miniprogramm TestOSM.exe (V0.1): - es ist für der Batch-Betrieb gedacht - es wir als Parameter einfach der OSM-Dateiname angegeben, also z:B. TestOSM.exe germany.osm - es liest die letzten 10 Zeichen der Datei ein und prüft dort das Vorhandensein von /osm - ist auch bei sehr großen Dateien schnell - liefert einen Rückgabewert (errorlevel), af den man in der BATCH-Datei reagieren kann + 0 - OSM ist ok + 1 - OSM ist nicht ok + 2 - OSM-Datei kann nicht geladen werden Hier könnt Ihr Euch das Programm herunterladen: http://wince.dentro.info/koord/osm/prog/TestOSM_V001.zip Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Testprogramm für OSM-Dateien
Dirk-Lüder Kreie schrieb: Carsten Schwede schrieb: Moin, Stefan Dettenhofer (StefanDausR) schrieb: ich habe mir ein kleines Windows-Programm geschrieben, mit dem man ganz einfach testen kann, ob eine OSM-Datei vollständig erzeugt wurde oder nicht. Falls das jemand mit Unix oder mit Cygwin schnell haben möchte: tail -1 osm-datei |grep /osm ; echo $? Ergibt zwar nur 0, wenn es korrekt /osm in der letzten Zeile beinhaltet und 1 wenn nicht, aber immerhin. #!/bin/bash if [[ -f $1 ]]; then if tail -n2 $1 | grep -q /osm; then echo valid exit 0 else echo invalid exit 1 fi else echo \$1\: file not found exit 2 fi # Testet die letzten 2 Zeilen auf /osm Danke für die Hinweise! Mir ging es darum eine schnelle Lösung für Windows zu haben, ohne die ganze Datei zu durchsuchen. Ich weiß nicht, wie lange die o.g. Befehle brauchen, ich habe auch bei 80GB innerhalb einer Sekunde das Ergebnis. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umweltbundesamt benutzt OSM-Karten
Tobias Wendorff schrieb: Bei einem Studenlohn für den Programmierer von 250 EUR Wo darf ich anfangen? Von so einem Stundensatz kann ich nur träumen... Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Straßen über Plätze
Hallo zusammen, wie sollen eigentlich Straßen (bzw. Fahrspuren), die über Plätze führen richtig getaggt werden? Im konkreten Fall: Der Platz ist innerorts und hat einen Namen. Die umliegenden Häuser haben Namen des Platzes als Straßennamen. Quer über den Platz führt eine Straße, der Rest sind Parkplätze und kleine Grünflächen. Zu dem Platz führen auch noch Fußwege. Mir geht es nun auch um ein Routing. Wird dabei ein Platz berücksichtigt, also dass man in jeden abzweigenden Weg einbiegen kann oder muss man zusätzlich noch richtige Verbindungen zwischen den Straßen (und Fußwegen) machen? Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßen über Plätze
Tobias Knerr schrieb: Martin Koppenhoefer schrieb: Am 29. Januar 2009 13:13 schrieb Stefan Dettenhofer (StefanDausR) Mir geht es nun auch um ein Routing. Wird dabei ein Platz berücksichtigt, also dass man in jeden abzweigenden Weg einbiegen kann oder muss man zusätzlich noch richtige Verbindungen zwischen den Straßen (und Fußwegen) machen? ja, man muss an jedem Schnittpunkt Straße mit Platz (pedestrian-area) eine Verbindung machen Man muss aber, um hier eventuellen Missverständnissen vorzubeugen, kein Spinnennetz von Wegen auf den Platz legen (sprich: die Wege, die in den Platz münden, miteinander verbinden). Das kann ein Router prinzipiell selber tun (auch wenn die meisten das momentan afaik noch nicht eingebaut haben). Selbst wenn ein Programm kein spezielles Platzrouting hat, wird es die Straßen immer noch erreichen, aber möglicherweise halt am Rand des Platzes entlang statt quer drüber routen -- was gerade für Fußgänger völlig akzeptabel ist. Tobias Knerr Vielleicht zur Verdeutlichung folgende vereinfachte Grafik: --- |-+...|. Fußweg Straße | \ ! | | \_ ! | | * \! | | ***+--| Straße --- Also ein rechteckigen Platz, links-oben kommt die Straße an, führt quer über den Platz und geht rechts unten weiter. Der Fußweg (..) heißt außerhalb des Platzes anders. Desweiteren gibt es noch einen Parkplatzweg (**) und eine Anwohnerstraße (!!) auf dem Platz. Die Häuser sind rund um den Platz angeordnet. Also ich denke schon, dass ich die Straßensituation auf dem Platz abbilden muss, oder? Es ist nur die Frage, ob ich den Platz selber als highway=residential, area=yes taggen soll, damit die Adresszuordnung zu den Häusern passt oder ob ich nur den Parkplatz als Fläche anlege. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verkehrsinseln
Bernd Wurst schrieb: Hallo. Am Freitag, 30. Januar 2009 schrieb Hatto von Hatzfeld: Hier spielt m.E. wieder das Kriterium Abstraktionsgrad eine Rolle. Oberflächlich gesehen mag das Taggen als 2 kleine Einbahnstraßen einen höheren Informationsgehalt haben; aber für Anwendungen in dem für OSM typischen Abstraktionsgrad - und zwar sowohl für Router wie für Karten - hat ein passendes Tag crossing=* einen höheren Informationswert als die zwei Einbahnsträßchen. - Die Leistung des Kartographierens liegt ja in der Abstraktion, im Erfassen der wesentlichen Informationen und Weglassen der unwesentlichen. Da sind wir doch froh, dass bei OSM so viel Multi-Kulti-Suppe zusammenkommt. Es gibt die richtigen Kartographen, die wissen wie man Karten schön macht, es gibt die Abtraktionskartographen, die nur das einzeichnen wollen was ein Navi braucht um eine Route sinnvoll anzusagen. Aber, und das ist auch wichtig, es gibt noch mehr. Es gibt z.B. unglaublich viele Leute die Zugriff auf die Rohdaten haben und eine Transformation und Konversion ist nach belieben erlaubt und möglich. Das unterscheidet unseren Datenbestand von den Alternativen. Ein Navi das auf OSM-Daten arbeiten will, muss entweder ein bisschen intelligenter sein (es geht hier nur halb rechts, also sagt man nichts an, Wenn man 20 Meter weit sehen kann, wird klar was gemeint ist, also sagt man nichts an) oder es braucht eine passende Vor-Verarbeitung. Die Vor-Verarbeitung ist in ganz vielen Fällen algorithmisch machbar. Daher sollte sie auch so gemacht werden und nicht schon im Kopf der Mapper. Unser Ziel sollte es sein, alle Informationen in der Datenbank zu haben, aus der man mittels algorithmischer Methoden alles errechnen kann was man haben will. Grade die genannten kurzen oneway-Stückchen kann man für Routing-Ansagen ohne weiteres prima aussortieren. Sie irgendwie drin zu haben erhöht aber wesentlich die Schönheit und auch die realitätstreue der Karten. Gruß, Bernd Hier mal ein Beispiel einer ganz normalen Kreuzung auf Sardinien: 1) OSM: http://www.informationfreeway.org/?lat=40.71625556742705lon=9.682141275763735zoom=17layers=0F0B0F 2) Luftbild aus GE: http://wince.dentro.info/koord/osm/temp/Kreuzung_Sardinien.jpg 3) Darstellung in GoPal (Navteq-Karte): http://wince.dentro.info/koord/osm/temp/Kreuzung_Sardinien_GoPal.gif Ich denke, ein vernünftiger Routing-Algorithmus kann das schon verkraften. Außerdem -muss ich sagen- war die Anzeige am Navi vor Ort schon recht hilfreich, die richtige Spur zu finden... Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Karten für NaviPowm 0.2.0
Hallo Dieter, ich nehme die europe.osm von der Geofabrik, um die NaviPOWM-Daten zu erzeugen. Da scheinen die Kanaren zu fehlen (die waren aber schon mal d'rin). Ich müsste den Bereich mal extra umsetzten lassen, wenn Du es brauchst! Gruß, Stefan dieter jasper schrieb: Hallo, gibt es Karten für NaviPOWM für die Kanraren? Bei http://wince.dentro.info/koord/osm/TileMap.htm kann ich sie nicht finden. MfG Dieter Jasper ___ 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] Karten für NaviPowm 0.2.0
Hallo zusammen, so, nun erzeuge ich auch aus der africa.osm die Karten für NaviPOWM! Darin sind auch die Kanaren enthalten. Bitte mal bei Gelegenheit testen - Danke! Gruß, Stefan Stefan Dettenhofer (StefanDausR) schrieb: Hallo Dieter, ich nehme die europe.osm von der Geofabrik, um die NaviPOWM-Daten zu erzeugen. Da scheinen die Kanaren zu fehlen (die waren aber schon mal d'rin). Ich müsste den Bereich mal extra umsetzten lassen, wenn Du es brauchst! Gruß, Stefan dieter jasper schrieb: Hallo, gibt es Karten für NaviPOWM für die Kanraren? Bei http://wince.dentro.info/koord/osm/TileMap.htm kann ich sie nicht finden. MfG Dieter Jasper ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amenity=toilets - Pisuar - Pissoir
Hallo Jan, ich bin bis jetz noch nicht in die Verlegenheit geraten, das zu taggen, aber nur als Hinweis, es wird so geschrieben: Pissoir und normalerweise als Urinal bezeichnet! Gruß, Stefan Jan Tappenbeck schrieb: Moin! mancher Orts gibt es öffentliche Pisuars - als Toiletten zu taggen wäre wohl etwas fehl am Platze. Abgesehen davon, dass man die Damenwelt in die falsche Richtung führen würde. Unterscheidet Ihr dieses ? Gruß Jan :-) ___ 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] Fußwege, Wanderwege, Waldwege, forstwirtschaftliche Wege
Johannes Haller schrieb: (...) Mache ich einen Fehler, wenn ich im Wald aufräume und die für Fahrzeuge geeigneten Forstwirtschaftswege als entsprechend abgestufte Tracks umtagge, Trampel- und breitere, nicht motorbefahrene Fußpfade aber zu path ohne foot=designated umwidme? Es gibt noch viele footway-Leichen, da es den path ja noch nicht so lange gibt. Früher konnte man nur track oder eben footway angeben. Wenn Du das mir Ortskenntnis richtig stellst, ist das sicher sehr gut! Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nachtrag Plattenverschiebung
Ohne es genauer geprüft zu haben: In Deiner Karte steht was von platteninterner Verschiebung. Dazu kommt aber m.E. noch die Verschiebung der ganzen Platte als solcher! Die platteninterne Verschiebung ist relevant, wenn man lokale Koordinaten (z.B. Gauß-Krüger) nach ETR-89 umrechnen will. Die Verschiebung der ganzen Platte muss man berücksichtigen, wenn man ETR-89 nach WGS-84 umrechnet und das sind dann die ca. 2cm/Jahr. Gruß, Stefan P.S.: Oder habe nun totalen Mist erzählt? Martin Koppenhoefer schrieb: ich habe gerade durch Zufall eine Karte gefunden, die die Verschiebung innerhalb der Platten in Europa darstellt (Thema vor einiger Zeit hier auf der ML), in der Tat sind diese Verschiebungen relativ gering: es geht nur um einige mm pro Jahr. http://www.oberrheingraben.de/Tektonik/Karte_Tesauro_Gross.jpg Gruss Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Reit- und Wanderkarte - Fragen
Hallo Nop, ich habe nun erfolgreich die erste Relation mit den erforderlichen Attributen versehen, damit der Wanderweg in der autom. generierten Wikiseite erscheint. Nun habe ich folgende Fragen: 1) Soll ich mein Gebiet trotzdem noch unter Gebietsabdeckung eintragen oder rechnest Du Deutschland (spezielle Süddeutschland) sowieso regelmäßig? 2) Das Wegeverzeichnis wird wahrscheinlich gemeinsam mit der Karte erzeugt und ist daher unabhängig von der autom. generierten Wikiseite, oder? 3) Weglänge: Ich muss bei distance= anscheinend auch die Einheit mit angeben? distance=14.9 geht nicht. Ich werde es in distance=14.9km ändern. Wie berechnest Du die Weglänge? Angegeben ist der Weg mit 14,9km, der OSM Relation Analyzer errechnet 15.05 KM und Du zeigst 18 km an! 4) Superrelation: Ich habe eine Superrelation, die die einzelnen Etappen zusammenfasst, da der Wanderweg aus mehreren definierten Etappen besteht. Die relevanten Attribute der Relation führe ich nun in allen (Teil-)Relationen, damit Du diese auswerten kannst. Wäre es zukünftig möglich, die Superrelation zumindest für die Wikiliste auszuwerten, damit eine logische Zusammenfassung der Etappen zum Gesamtweg möglich ist? Bräuchtest Du da spezielle Attribute? Ansonsten sieht die Karte schon mal super aus! Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Reit- und Wanderkarte - Fragen
Hallo Nop, Nop schrieb: Du solltest nur Deinen Namen bei den Gebieten eintragen. Ich update zwar regelmäßig, aber wenn ich mitbekomme daß sich irgendwo besonders viel getan hat, versuche ich die Gegend bevorzugt zu rendern. Also wenn ich z.B. sehe daß stefanDausR ein paar tolle Relationen erstellt hat, dann würde ich die Gegend, in der Dein Name steht zuerst anwerfen. werde ich machen. (...) Vermutlich noch ein Fehler bei der Umrechnung Grad - Meter. Ich habe mal eben schnell ein Grad als 60 * 1852 Meter angenommen. Aber dabei ist glaub ich die Projektion der Karte nicht korrekt berücksichtigt. Kann mir vielleicht jemand hier eine bessere Umrechnungsvorschrift nennen? Ich habe die Formeln von hier http://de.wikipedia.org/wiki/Orthodrome bei mir erfolgreich in einem WinCE-Programm (das auf dem PNA läuft) eingesetzt, um die Entfernung zum Ziel zu berechnen. Wenn Du den C-Code brauchst, dann melde Dich. 4) Superrelation: Ich habe eine Superrelation, die die einzelnen Etappen zusammenfasst, da der Wanderweg aus mehreren definierten Etappen besteht. Die relevanten Attribute der Relation führe ich nun in allen (Teil-)Relationen, damit Du diese auswerten kannst. Wäre es zukünftig möglich, die Superrelation zumindest für die Wikiliste auszuwerten, damit eine logische Zusammenfassung der Etappen zum Gesamtweg möglich ist? Bräuchtest Du da spezielle Attribute? Ein ganz klares Nein! Superrelationen werden zwar oft als Allheilmittel empfohlen, aber Tatsache ist, daß sie noch überhaupt nicht ausreichend beschrieben sind. Weder das Tagging, noch die Vererbungsregeln und ganz besonders nicht die Probleme, die auftreten, wenn etwas Mitglied in mehreren Superrelationen ist. [1] Bisher gibt es nur sehr knapp forumlierte Proposals, die auf die Probleme nicht eingehen und eine Superrelation für Routen wird dort noch nicht mal erwähnt. Solange es keine Definition gibt, werde ich nicht versuchen, irgendwas auszuwerten. Ich werde dran bleiben. Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Reit- und Wanderkarte - Fragen
Nop schrieb: (...) Zur Gliederung im Wiki wäre es schön, wenn die Gesamtstrecke (distance) und das Symbol (wiki:symbol) aus der Superrelation genommen werden könnte und nicht bei jeder Etappe erscheinen muss. Ich würde es z.B. für sehr sinnvoll halten, zumindest mal die Gesamtstrecke aus den Etappen auszurechnen. Das Symbol kannst Du bei den Etappen einfach weglassen, wenn es bei der Gesamtrelation schon angezeigt ist muß es ja nicht in jeder Zeile wiederholt werden, oder? Also: Woran soll mein Programm erkennen, welche Superrelation die von Dir gemeinte ist, wenn es deren mehrere gibt? Ich denke, am einfachsten erkennt man eine Superrelation daran, dass die keine Ways sondern nur Relationen enthält, aber trotzdem mit mindestens route = hiking/foot/horse/... type = route getaggt ist. Von mir aus könnte man auch festlegen, dass die oberste Relation, also die mit der Du mit der Auswertung beginnen sollst, als einzige einen network = rwn/... tag hat, dann könntest Du ganz einfach erkennen, was die Super(super-super)-Relation ist. M.W. ignorierst Du ja sowieso momentan alle Relationen, die keinen network-tag haben. Dann wprde das ja gut ins vorhandene System passen, oder? Noch eine Frage: Du hast anscheinend die Karte neu rechnen lassen, da neue Wege von mir erscheinen, aber die Relation 37505 (meine Teststrecke) wird nicht markiert, d.h. ich sehe das Symbol nicht auf der Karte. Woran liegt das? habe ich da noch einen Fehler d'rin? Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Frage zum OSM Relation Analyzer
Hallo zusammen, kann es sein, dass der OSM Relation Analyzer bei Routen nicht zwischen Hauptweg (role=) und Alternativweg (role=variation) bzw. Abstecher (role=excursion) unterscheidet? Kommen diese Elemente vor, so kann der Hauptweg nicht mehr zusammengefasst werden. Ist es möglich, den OSM Relation Analyzer dahingehend zu erweitern, dass er die Rollen einzeln betrachtet und entsprechend zusammenfasst? Eine beispielrelation ist diese: 49531 Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Reit- und Wanderkarte - Fragen
Hallo Nop, Nop schrieb: Ich denke, am einfachsten erkennt man eine Superrelation daran, dass die keine Ways sondern nur Relationen enthält, aber trotzdem mit mindestens route = hiking/foot/horse/... type = route getaggt ist. Also gut, ich werde mal solche Relationen suchen und als Obergruppe auswerten, schaun wir mal was dabei rauskommt. Schön! Ich habe die Superrelation 49759 nun so getaggt: Tags: name = Jurasteig route = hiking wiki:symbol = Jurasteig.png network = rwn type = route operator = www.jurasteig.de description = Jurasteig alle 12 Etappen Länge 230 km osmc:symbol = yellow:yellow::J:blue ref = Jurasteig distance = 230km Members: Relation 37505 http://www.openstreetmap.org/browse/relation/37505 Relation 49531 http://www.openstreetmap.org/browse/relation/49531 Von mir aus könnte man auch festlegen, dass die oberste Relation, also die mit der Du mit der Auswertung beginnen sollst, als einzige einen network = rwn/... tag hat, dann könntest Du ganz einfach erkennen, was die Super(super-super)-Relation ist. M.W. ignorierst Du ja sowieso momentan alle Relationen, die keinen network-tag haben. Dann wprde das ja gut ins vorhandene System passen, oder? Nein, das Tag ist sogar sehr wichtig für die Anzeige. Die Wege werden nach network gruppiert, Relationen ohne network werden ganz unten unter Unklassifiziert eingeordnet. Wenn Du also network nur bei der Superrelation hast, wird diese z.B. als Regionaler Wanderweg einsortiert und Deine Etappen landen unter Unklassifizert. Die müssen schon das gleiche network Tag haben, wenn sie zusammen dargestellt werden sollen. ok, war nur als Vorschlag gemeint. Noch eine Frage: Du hast anscheinend die Karte neu rechnen lassen, da neue Wege von mir erscheinen, aber die Relation 37505 (meine Teststrecke) wird nicht markiert, d.h. ich sehe das Symbol nicht auf der Karte. Woran liegt das? habe ich da noch einen Fehler d'rin? Welchen Namen hat Weg denn? Es ist die Etappe 3 mit der Relationnummer 37505. Hier habe ich nun das wiki-Symbol weggelassen: Tags: name = Jurasteig (Etappe 3) symbol = stilisiertes handschriftliches blaues J auf gelbem Grund route = hiking network = rwn operator = www.jurasteig.de type = route osmc:symbol = yellow:yellow::J:blue description = Jurasteig Etappe 3: Schönhofen - Pielenhofen, Länge 14,9 km ref = Jurasteig distance = 14.9km Wie behandelst Du eigentlich die Rollen? Also Hauptweg (role=) und Alternativweg (role=variation) bzw. Abstecher (role=excursion). Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kieser Training
Holger Issle schrieb: On Thu, 12 Feb 2009 10:08:50 +0100, Sven Anders wrote: name=Kieser Training Nein, lass den Ort mit drin, sonst hat man bei der Suche genau das Problem. Vor allem am Garmin, wenn das mal funktionieren wird. Der Ort und PLZ gehören in die Adresse und nicht in den Namen! Wenn zukünftig bei jedem POI der Ort mit dabeisteht wird die Karte nicht mehr lesbar! Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen / Entfernte Wanderwegstück e / JOSM / X19 Schlösserweg
Hallo, hansdorfff schrieb: (...) Ich denke ich mache dann mal einen lokalen X19, X24 usw auf, und dann wird sich das irgendwie entwicklen. Das ist ja auch eine das faszinierenden Seiten im OSM-Projekt. mfg, hansdorfff Wenn der Wanderweg so lange ist, dann wird man sie Relation wahrscheinlich sowieso irgendwann aufteilen müssen (und damm diese Teile mit Hilfe einer Superrelation verbinden). Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Reit- und Wanderkarte - Fragen
Hallo Nop, Stefan Dettenhofer (StefanDausR) schrieb: Nop schrieb: Ich denke, am einfachsten erkennt man eine Superrelation daran, dass die keine Ways sondern nur Relationen enthält, aber trotzdem mit mindestens route = hiking/foot/horse/... type = route getaggt ist. Also gut, ich werde mal solche Relationen suchen und als Obergruppe auswerten, schaun wir mal was dabei rauskommt. Schön! Ich habe die Superrelation 49759 nun so getaggt: Tags: name = Jurasteig route = hiking wiki:symbol = Jurasteig.png network = rwn type = route operator = www.jurasteig.de description = Jurasteig alle 12 Etappen Länge 230 km osmc:symbol = yellow:yellow::J:blue ref = Jurasteig distance = 230km Members: Relation 37505 http://www.openstreetmap.org/browse/relation/37505 Relation 49531 http://www.openstreetmap.org/browse/relation/49531 Von mir aus könnte man auch festlegen, dass die oberste Relation, also die mit der Du mit der Auswertung beginnen sollst, als einzige einen network = rwn/... tag hat, dann könntest Du ganz einfach erkennen, was die Super(super-super)-Relation ist. M.W. ignorierst Du ja sowieso momentan alle Relationen, die keinen network-tag haben. Dann wprde das ja gut ins vorhandene System passen, oder? Nein, das Tag ist sogar sehr wichtig für die Anzeige. Die Wege werden nach network gruppiert, Relationen ohne network werden ganz unten unter Unklassifiziert eingeordnet. Wenn Du also network nur bei der Superrelation hast, wird diese z.B. als Regionaler Wanderweg einsortiert und Deine Etappen landen unter Unklassifizert. Die müssen schon das gleiche network Tag haben, wenn sie zusammen dargestellt werden sollen. ok, war nur als Vorschlag gemeint. Noch eine Frage: Du hast anscheinend die Karte neu rechnen lassen, da neue Wege von mir erscheinen, aber die Relation 37505 (meine Teststrecke) wird nicht markiert, d.h. ich sehe das Symbol nicht auf der Karte. Woran liegt das? habe ich da noch einen Fehler d'rin? Welchen Namen hat Weg denn? Es ist die Etappe 3 mit der Relationnummer 37505. Hier habe ich nun das wiki-Symbol weggelassen: Tags: name = Jurasteig (Etappe 3) symbol = stilisiertes handschriftliches blaues J auf gelbem Grund route = hiking network = rwn operator = www.jurasteig.de type = route osmc:symbol = yellow:yellow::J:blue description = Jurasteig Etappe 3: Schönhofen - Pielenhofen, Länge 14,9 km ref = Jurasteig distance = 14.9km Wie behandelst Du eigentlich die Rollen? Also Hauptweg (role=) und Alternativweg (role=variation) bzw. Abstecher (role=excursion). Die Route sieht in der Karte schon mal gut aus, danke! Musst du eigentlich noch jede Route manuell freischalten oder reicht es, wenn sie vollständig getaggt ist? Noch eine Frage zu: osmc:symbol = yellow:yellow::J:blue Das blaue J scheint etwas zu groß für den geben Hintergrund, aber das ist nur eine Kleinigkeit. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhenkarte für Aachen
Hallo, Dimitri Junker schrieb: Außerdem habe ich zwar Aussagen über hdop - horizontaler Fehler gefunden nicht aber entsprechendes für vdop-v.Fehler die Info über VDOP kann man aus dem NMEA GPGSA-Datensatz herauslesen. Im GPGGA-Datensatz steht die Höhe über Meer (über Geoid) und in einem weiteren Feld Höhe Geoid minus Höhe Ellipsoid (WGS84). Wenn diese Felder von GPS-Empfänger korrekt genutzt werden, dann hätte man doch schon mal eine Basis, oder? Ich habe für mein Medion-Navi ein Programm geschrieben, dass die NMEA-Daten abgreift und so GPX-Dateien mit Lage und Höhe erzeugt. Bei Bedarf könnte ich das Programm erweitern, so dass auch VDOP und die Höhendifferenz ausgewertet werden. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] alle Relations ermitteln bzw. anzeigen lassen
Hallo Jan, ich hatte mal versucht, eine Karte -analog zu meinem maxspeed-Overlay- zu erzeugen, die alle Relationen visualisiert, es aber nicht weiter verfolgt, da Kosmos noch nicht so viele Möglichkeiten bietet, Relationen zu beschriften etc. Außerdem ist die Wanderkarte von NOP viel schöner... Falls da aber Interesse besteht, kann ich das Projekt wiederbeleben. Gruß, Stefan o...@tappenbeck.net schrieb: Moin ! nicht alle Wanderwege, Radwege etc. werden in den entsprechenden Listen hinterlegt. Es gibt zwar die autom. Generierung [1] - aber da sind keine Lokalen Zuordnungen erkennbar. Kennt einer von Euch einen Weg aus einer bestehenden OSM-Datei entsprechende Relation-ID's zu extrahieren bzw. das ganze zu visualisieren ? Gruß Jan :-) [1] http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Wanderwege-Netz/Generiert ___ 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] JOSM-Vorlagen
Hallo Markus, Markus schrieb: Hallo Dirk, die Vorlagen werden immer schöner - danke! Sie sind ein sehr wertvoller Beitrag zur Benutzerfreundlichkeit von OSM. Ich benutze sie irgendwie intuitiv. Dabei gehe ich davon aus, dass mich die Vorlage schrittweise zu einem konformen verwertbaren DB-Eintrag führt. Beispiel: Gebäude Schule Da erwarte ich als Ergebnis: amenity=school name=* building=yes addr:housenumber=### addr:street=* Gefragt werde ich aber nur nach name=* Wird der Rest irgendwie im Hintergrund zusammengebaut? Könnte man die anderen Schlüssel nicht auch gleich mit aufnehmen? (für alle Gebäude) Gruss, Markus PS: Bahnhof/Haltestelle finde ich weder unter Gebäude, noch unter Bahn? Mir ist es genauso mit Gebäude-Kindergarten gegangen, das geschlossene Polygon wird zwar als Fläche in JOSM angezeigt, aber nicht gerendert, da building=yes fehlt. Man muss also erst das Gebäude erzeugen und dann nochmal als Schule bzw. Kindergarten definieren. Wie sieht das eigentlich mit dem rendern von Kindergarten aus? Bisher passiert das nichts. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
