[Talk-de] Mapping Software windows mobile
Hallo! Gibt es eine Freeware mapping-software für windows mobile, bei der man online direkt vor Ort Daten anexakten Positionen eintragen und hochlanden kann? Evtl. würde es auch reichen die Daten zu sammeln und später hochzuladen. Aber nicht wie bei OSMTracker, da man dort nicht die POIs DIREKT auf der Karte eintragen kann und so bei Detailangaben Ungenauigkeiten durch die Differenz zwischen GPS-Position und tatsächlicher Position entstehen. -- Mit freundlichen Gruessen Wolfgang Wienke ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin-Karte mit Skipisten?
Pisten anhand schwierigkeit habe ich etwa in der Openmtbmap.org bzw VeloMap integriert... piste:ref werde ich zum nächsten Update auch integrieren, hab den Key noch gar nicht gekannt On 02.03.2012 20:26, Bodo Meissner wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo alle, gibt es eine fertige Garmin-Karte auf der Skipisten dargestellt werden? Oder hat jemand schon eine geeignete Konfiguration, um eine solche Karte selbst zu generieren? Ich würde gern den Schwierigkeitsgrad (piste:difficulty) und die Nummer (piste:ref) erkennen. Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk9RHskACgkQnMz9fgzDSqc3oACcD7f7lCkFTOz7W3sVHxDZEkKf SHYAniFjCXpVRwvJ5YGuJIR9ogawW8TD =VtHB -END PGP SIGNATURE- ___ 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] Summer of Code Ideen
bernhard zwischenbrugger b...@datenkueche.com wrote: Im Moment fehlen noch Projekt Ideen. http://wiki.openstreetmap.org/wiki/GSoC_Project_Ideas_2012 Hm, wie wäre es denn wenn jemand osm2pgsql in brauchbar modularer Form neu implementieren würde? Gruss Sven -- linux is evolution, not intelligent design (Linus Torvalds) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] railway electrified - polarity at DC?
Am 4. März 2012 13:51 schrieb Stephan Wolff s.wo...@web.de: Andere Daten zu Oberleitungen, die wir meist nicht in OSM erfassen: ... Mittlere Spannweite zwischen zwei Masten Mittelwerte sind Analyseergebnisse, keine Geodaten. Was man erfassen könnte wären einzelne Masten. ... Die meisten dieser Daten sind vor Ort zu erkennen und wären evtl. für Planungen überhoher Schwertransporte oder Bahnsimulatoren verwendbar, aber mir fehlen sie nicht in OSM. Dann planst Du wohl keine überhohen Sondertransporte? ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Summer of Code Ideen
Am 05.03.12 10:13, schrieb Sven Geggus: bernhard zwischenbruggerb...@datenkueche.com wrote: Im Moment fehlen noch Projekt Ideen. http://wiki.openstreetmap.org/wiki/GSoC_Project_Ideas_2012 Hm, wie wäre es denn wenn jemand osm2pgsql in brauchbar modularer Form neu implementieren würde? ... und eventuell auch unter Windows 7/64bit lauffähig? duckundwech André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Summer of Code Ideen
Hi, On 03/05/12 10:13, Sven Geggus wrote: bernhard zwischenbruggerb...@datenkueche.com wrote: Im Moment fehlen noch Projekt Ideen. http://wiki.openstreetmap.org/wiki/GSoC_Project_Ideas_2012 Hm, wie wäre es denn wenn jemand osm2pgsql in brauchbar modularer Form neu implementieren würde? Ich bin dieses Jahr ein strikter Verfechter von: Wir nehmen nur Ideen von Leuten, die danach vorhaben, sich mit genau dieser Idee zu bewerben. Dieses Schema OSM-Insider schreibt eine man-sollte-mal-Idee auf und irgendein Externer bewirbt sich dann, setzt das um und ist danach wieder weg fuehrt doch zu nichts. Daher halte ich mich mit Ideen zurueck - aber wenn irgnedjemand eine Idee hat fuer etwas, das er SELBER im Rahmen von Summer of Code umzusetzen versuchen moechte, kann ich mir durchaus vorstellen (wenn ich was von der Sache verstehe) das auch zu unterstuetzen. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Education (war: Navigationssystem mit der Maus)
Hallo Alexander, Gegend um Schulen herum schon zu genau erfasst Versuchs mal mit Luftbildern. Damit kann man im Unterrricht spannende Dinge erforschen... Oder Mikromapping... Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Renderproblem bei Multipolygon (inner) im deutschen Style
Ich habe mal gerade den Hochwald im deutschen Style angesehen: http://www.openstreetmap.de/karte.html?zoom=12lat=49.5923lon=6.73381layers=BTF stellt die inneren Teile des Mulitpolygons (Waldfläche) anscheinend halbtransparent dar. Man kann farmland und meadow erkennen und die innere Leerfläche bei Schillingen ... ist etwas schwächer grün (ich hab die gerade mal auf farmland gesetzt, das ist genauer). Geht man dann aber näher ran: http://www.openstreetmap.de/karte.html?zoom=13lat=49.61143lon=6.75485layers=BTF so sind die inneren Teile der Multipolygone gar nicht mehr erkennbar. Kann man da was machen? Leider kenne ich mich selber mit den Stylesheets gar nicht aus. Aber ich wäre durchaus bereit da auch was dran zu machen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Renderproblem bei Multipolygon (inner) im deutschen Style
Hi. Vermutlich (hab ich nicht nachgeguckt) ist nicht nur das Multipolygon, sondern auch der outer-way als Wald getagged. Dadurch wird der Wald zweimal, vermutlich beides mal halbtransparent gerendert. Wenn ich recht habe, entferne das Wald-Tagging vom Outer-Way und alles sollte wieder passen. Gruß Peter Am 05.03.2012 15:17, schrieb Wolfgang Barth: Ich habe mal gerade den Hochwald im deutschen Style angesehen: http://www.openstreetmap.de/karte.html?zoom=12lat=49.5923lon=6.73381layers=BTF stellt die inneren Teile des Mulitpolygons (Waldfläche) anscheinend halbtransparent dar. Man kann farmland und meadow erkennen und die innere Leerfläche bei Schillingen ... ist etwas schwächer grün (ich hab die gerade mal auf farmland gesetzt, das ist genauer). Geht man dann aber näher ran: http://www.openstreetmap.de/karte.html?zoom=13lat=49.61143lon=6.75485layers=BTF so sind die inneren Teile der Multipolygone gar nicht mehr erkennbar. Kann man da was machen? Leider kenne ich mich selber mit den Stylesheets gar nicht aus. Aber ich wäre durchaus bereit da auch was dran zu machen. ___ 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] Summer of Code Ideen
Frederik Ramm frede...@remote.org wrote: Dieses Schema OSM-Insider schreibt eine man-sollte-mal-Idee auf und irgendein Externer bewirbt sich dann, setzt das um und ist danach wieder weg fuehrt doch zu nichts. Jepp! Vielleicht will ja jemand osm2pgsql neu schreiben *duck* Sven -- Ich fürchte mich nicht vor der Rückkehr der Faschisten in der Maske der Faschisten, sondern vor der Rückkehr der Faschisten in der Maske der Demokraten (Theodor W. Adorno) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Renderproblem bei Multipolygon (inner) im deutschen Style
Am 05.03.2012 15:17, schrieb Wolfgang Barth: Ich habe mal gerade den Hochwald im deutschen Style angesehen: http://www.openstreetmap.de/karte.html?zoom=12lat=49.5923lon=6.73381layers=BTF stellt die inneren Teile des Mulitpolygons (Waldfläche) anscheinend halbtransparent dar. Man kann farmland und meadow erkennen und die innere Leerfläche bei Schillingen ... ist etwas schwächer grün (ich hab die gerade mal auf farmland gesetzt, das ist genauer). Geht man dann aber näher ran: http://www.openstreetmap.de/karte.html?zoom=13lat=49.61143lon=6.75485layers=BTF so sind die inneren Teile der Multipolygone gar nicht mehr erkennbar. Kann man da was machen? Leider kenne ich mich selber mit den Stylesheets gar nicht aus. Aber ich wäre durchaus bereit da auch was dran zu machen. Ja, die Waldpolygone sind transparent im deutschen Stil: zoom 7 60% zoom 8+9 40% zoom 10 50% zoom 11+12 60% zoom 13 90% zoom 14-17 100% Wenn dann Linienelement und Multipolygon beide landuse=forest haben, addieren sich die Einfärbungen. Nur hat die outer-Linie nicht die Löcher wie das Multipolygon. Im offiziellen Stil ist dagegen alles undurchsichtig. Dann ist es eben Zufall, was gerendert wird. Sauber ist es, den landuse nur im MP zu vergeben (und ggf für die inner). Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abgeordnetenbüro - Vorschag fürs Taggen?
Am 04.03.2012 19:33, schrieb Jacques Nietsch: In meinem Stadtteil gibt es ein Abgeordnetenbüro, mit Sprechzeiten und so. Hat jemand hier eine Idee, wie man so etwas taggen könnte? Jacques name=Name des Abgeordneten brand=Partei office=political_party Oder alternativ: name=Abgeordnetenbüro operator=Name des Abgeordneten brand=Partei office=political_party MfG Andreas -- Diese Nachricht wurde maschinell erstellt und ist daher ohne Unterschrift gültig. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin-Karte mit Skipisten?
On Mon, Mar 05, 2012 at 09:30:28AM +0100, Felix Hartmann wrote: Pisten anhand schwierigkeit habe ich etwa in der Openmtbmap.org bzw VeloMap integriert... Das ist schon fast, wie ich es mir vorgestellt hätte. piste:ref werde ich zum nächsten Update auch integrieren, hab den Key noch gar nicht gekannt Super, danke. Es gibt auch noch piste:name, aber das wäre für mich weniger wichtig. (Keine Ahnung, warum für die Pisten nicht einfach ref und name verwendet wird.) Es hängt vielleicht vom Skigebiet ab, ob zur Orientierung die Nummern oder Namen besser geeignet sind. (Ich hatte bisher an den Pisten nur Schilder mit Nummern.) Ich würde mir das so wünschen, daß die Pisten-Nummern direkt sichtbar sind und die Namen als Zusatzinformation angezeigt werden, wenn man mit dem Pfeil auf die Piste zeigt. Wenn keine Nummer definiert ist, könnte möglicherweise der Name direkt angezeigt werden. Mir ist aber auf meinem GPSMAP76CSx aufgefallen, daß die Pisten mit dem Pfeil nicht selektierbar sind. Bei mir wurde immer nur eine Bezeichnung für den Hintergrund angezeigt. (Bei Höhenlinien wird in einem Mini-Popup die Höhe angezeigt, wenn der Pfeil darauf steht.) Sind die Pisten für das Gerät andere Objekte als Wege oder Höhenlinien? Viele Grüße Bodo signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin-Karte mit Skipisten?
Am 5. März 2012 18:43 schrieb Bodo Meissner b...@bodo-m.de: Es gibt auch noch piste:name, aber das wäre für mich weniger wichtig. (Keine Ahnung, warum für die Pisten nicht einfach ref und name verwendet wird.) +1, wenn man eine Relation benutzt, sonst gibt es evtl. einen Wegnamen und einen Pistenamen, die sich in die Quere kommen könnten. Gruß Martin PS: die wenigsten nutzen allerdings Route bisher: http://taginfo.openstreetmap.org/keys/piste%3Atype piste:type Ways 51.765 Relations 1.494 919 route=piste ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Fahrspuren die 315.
Hallo, grad beschwert sich einer auf der Tagging-Liste ueber http://www.openstreetmap.org/?lat=51.324213lon=12.290977zoom=18layers=M (data layer anschalten) und http://www.openstreetmap.org/browse/node/1656923757: note:DE = Für komplizierte Kreuzungen eignet sich die Sterntopologie, um Abbiegeeinschränkungen einfach zu erfassen - alles läuft über einen Punkt. Darunter leidet zwar die Darstellung, aber die Korrektheit des Routings hat Vorrang. Witzige Idee zwar, aber dass die Korrektheit des Routings Vorrang habe vor der Korrektheit der Geometrie, zaehlt m.E. bislang nicht zu unserem Konsens, oder? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Tagwatch timed out
Ich wollte in der dt. Tagwatch-Liste nach schon verwendeten key:values suchen. Aber sobald ich in der Trefferliste genauere Infos anfordere timed die Anfrage dauernd aus. Ist dies nur ein momentanes Problem? hike39 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrspuren die 315.
Frederik Ramm schrieb: grad beschwert sich einer auf der Tagging-Liste ueber http://www.openstreetmap.org/?lat=51.324213lon=12.290977zoom=18layers=M [Luetzner Ecke Schoenauer in Leipzig] note:DE = Für komplizierte Kreuzungen eignet sich die Sterntopologie, um Abbiegeeinschränkungen einfach zu erfassen - alles läuft über einen Punkt. Darunter leidet zwar die Darstellung, aber die Korrektheit des Routings hat Vorrang. Die Notiz ist mir auch aufgefallen, aber die Kreuzung hab ich jetzt erst angesehen. Die ist uebrigens ein schoenes Beispiel fuer Fahrspurmapping, die einzelnen Spuren sind naemlich in Wirklichkeit nicht getrennt. An sich ist die Kreuzung gar nicht so kompliziert. Witzige Idee zwar, aber dass die Korrektheit des Routings Vorrang habe vor der Korrektheit der Geometrie, zaehlt m.E. bislang nicht zu unserem Konsens, oder? Wie sah es denn vorher aus? Gab es zahlreiche Hilfsspuren fuer die verschiedenen Abbieger? Ich wuerde vorschlagen, das denjenigen reparieren zu lassen, der es so schon spurgetreu eingezeichnet hat. stw ein Kreuzpost zur Leipziger Liste versuchend -- Motto der Robotikforscher: Es muß Hand und Fuß haben. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrspuren die 315.
Am 5. März 2012 21:15 schrieb Steffen Wolf s...@gmx.de: Die Notiz ist mir auch aufgefallen, aber die Kreuzung hab ich jetzt erst angesehen. Die ist uebrigens ein schoenes Beispiel fuer Fahrspurmapping, die einzelnen Spuren sind naemlich in Wirklichkeit nicht getrennt. An sich ist die Kreuzung gar nicht so kompliziert. Ein wahres Juwel. Diese ganzen Geisterspuren in der Kreuzungsmitte dann wieder sternförmig zusammen zu fassen unterstreicht die Brillanz des mappens nicht getrennter Spuren als eigene Wege sogar noch besser als das wilde kreuzen oder überschneiden aller möglichen Abbiegespuren im Kreuzungsbereich. Sahnehäubchen: Abbiegerelationen ohne Kreuzungsmöglichkeit, um an der Haltelinie in JOSM die schönen blauen Pfeile angezeigt zu bekommen. Schokostreusel obendrauf: layer=-5 für Spuren und und layer=1 für Radwege. Herr Mapnik macht Freudensprünge. ;-) Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrspuren die 315.
Na ja, das Projekt heißt Open Street Map. Die Korrektheit des Routings sollte also eine übergeordnete Rolle spielen. Zudem heißt es ununterbrochen, man tagge nicht für Renderer. Zu guter letzt ist die Geometrie gar nicht falsch, der Kreuzungspunkt der Mitte ist tatsächlich der meistfrequentierte Abschnitt der Kreuzung und wird befahren. Wenn das korrekte routing kein Ziel mehr sein soll, hat sich das Projekt arg von seinen Wurzeln entfernt. Wer die Diskussion im Wiki beleben möchte: http://wiki.openstreetmap.org/wiki/Talk:Lanes_and_complex_intersections_visual_approach Gruß Frederik Ramm frede...@remote.org schrieb: Hallo, grad beschwert sich einer auf der Tagging-Liste ueber http://www.openstreetmap.org/?lat=51.324213lon=12.290977zoom=18layers=M (data layer anschalten) und http://www.openstreetmap.org/browse/node/1656923757: note:DE = Für komplizierte Kreuzungen eignet sich die Sterntopologie, um Abbiegeeinschränkungen einfach zu erfassen - alles läuft über einen Punkt. Darunter leidet zwar die Darstellung, aber die Korrektheit des Routings hat Vorrang. Witzige Idee zwar, aber dass die Korrektheit des Routings Vorrang habe vor der Korrektheit der Geometrie, zaehlt m.E. bislang nicht zu unserem Konsens, oder? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 _ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de -- Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrspuren die 315.
Am 05.03.2012 22:00, schrieb Christian Müller: Na ja, das Projekt heißt Open Street Map. Die Korrektheit des Routings sollte also eine übergeordnete Rolle spielen. ... Wenn das korrekte routing kein Ziel mehr sein soll, hat sich das Projekt arg von seinen Wurzeln entfernt. Ja, so heißt es, von Anfang an. Nur hat damals, meiner Erinnerung nach, noch niemand ernsthaft an Routing gedacht. Das kam erst einiges später. Aber eigentlich spielt das auch keine Rolle. Zudem heißt es ununterbrochen, man tagge nicht für Renderer. Aber für den Router ja wohl auch nicht, das wäre ja grotesk. Kein Renderer kann eine korrekte Karte malen, wenn die Daten für einfacheres Routen verbogen werden. Ein Router kann aber sehr wohl über eine korrekte Geometrie routen. Dass das Eintragen der Abbiegeregeln für den Datenerfasser dann etwas mühsamer ist, steht auf einem anderen Blatt. Will sagen (Neusprech): S geht das jedenfalls gar nicht. Überhaupt nicht ... :-) ym2c -fri- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrspuren die 315.
Frederik Ramm schrieb: grad beschwert sich einer auf der Tagging-Liste ueber http://www.openstreetmap.org/?lat=51.324213lon=12.290977zoom=18layers=M [Luetzner Ecke Schoenauer in Leipzig] Am 5. März 2012 22:00 schrieb Christian Müller cmu...@gmx.de: Na ja, das Projekt heißt Open Street Map. Die Korrektheit des Routings sollte also eine übergeordnete Rolle spielen. Hier kann ich Deine Argumentation nicht nachvollziehen. Wie Du richtig sagst heißt das Projekt OpenStreetMap. Von Routing ist im Namen nicht die Rede. Zudem heißt es ununterbrochen, man tagge nicht für Renderer. Auch dieses Argument lässt sich pro und contra auf den vorliegenden Fall anwenden: pro routing: es wird richtig geroutet ./. contra routing: das routing ist unvereinbar mit der Abbildung der Straßenlage pro Karte: die Straße sieht nicht wie dargestellt aus ./. contra Karte: bei richtiger Kartendarstellung wird nicht richtig geroutet. Zu guter letzt ist die Geometrie gar nicht falsch, der Kreuzungspunkt der Mitte ist tatsächlich der meistfrequentierte Abschnitt der Kreuzung und wird befahren. Aber es bleibt eben ein eher fiktiver am häufigsten überfahrener Punkt, den es so auf der Kreuzung nicht geben dürfte. Diese Kreuzung aus dem Beispiel zeigt nur (wie der Thread es andeutet) das grundsätzliche Problem auf welches wir derzeit hin steuern: Die Abbildungsgenauigkeit bei gleichzeitigem spurgenauem Routing zu erhalten. Wie dieses Problem gelöst werden kann steht derzeit noch in den Sternen. Verschiedene Ansätze sind gemacht. Persönlich sehe ich die Lösung in der Trenneung von Tags und Ways für das Spurenrouting von den Tags, die (bisher) für die Kartendarstellung genutzt werden. Ob dies so kommen wird? Da lasse ich mich von der Zukunft überraschen :-) Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrspuren die 315.
Hallo, On 03/05/2012 10:00 PM, Christian Müller wrote: Na ja, das Projekt heißt Open Street Map. Die Korrektheit des Routings sollte also eine übergeordnete Rolle spielen. Eine definitiv unzutreffende Folgerung. Mit der gleichen Konsequenz koennte man folgern, dass das Mappen von Strassen wichtiger sei als etwas anderes... Zudem heißt es ununterbrochen, man tagge nicht für Renderer. Das wird leider immer wieder fehlinterpretiert. Grund des Ausspruchs ist, dass Leute zuweilen Dinge voellig falsch mappen, nur um ein bestimmtes Rendering-Ergebnis zu erzielen (Beispiel: Ich will einen roten und einen gruenen Wanderweg unterschieden und tagge deswegen einen Radweg und einen Fussweg, obwohl keins von beiden ein Radweg ist; oder ich will ein Wildschutzgebiet markieren und tagge es als landuse=military, damit es schoen rot wird). Der Ausspruch sollte nicht als Lizenz dazu interpretiert werden, nach Belieben Dinge zu mappen, die eine Karte verunstalten. Wenn das korrekte routing kein Ziel mehr sein soll, hat sich das Projekt arg von seinen Wurzeln entfernt. Korrektes Routing wie auch korrekte Kartendarstellung sind wuenschenswert. Keines der beiden sollte dem anderen geopfert werden. Das allerwichtigste aber ist, meiner Ansicht nach, dass die Karte von moeglichst vielen Leuten editierbar bleibt, und daran kranken sehr viele der vorgeschlagenen Fahrspur-Vorschlaege - eventuell ist das sogar ein unloesbarer Widerspruch, das einfach editieren und spurgetreu mappen. Wie dem auch sei, korrektes Routing ist auch ohne Fahrspur-Tagging moeglich. Es ist vielleicht weniger praezis, und der Nutzer muss die Anweisung an der naechsten Kreuzung links selbstaendig um vorher auf die Abbiegespur wechseln ergaenzen. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrspuren die 315.
Am 05.03.2012 22:00, schrieb Christian Müller: Zudem heißt es ununterbrochen, man tagge nicht für Renderer. Damit ist gemeint, dass man nicht absichtlich falsch taggt, um eine ansprechende Darstellung in einem bestimmten Renderer zu erreichen. Beispielsweise sollte man keine frei erfundenen unverbundenen Ways zur Verschönerung der Mapnik-Karten in seine Kreuzungen malen. *hust* Wenn das korrekte routing kein Ziel mehr sein soll, hat sich das Projekt arg von seinen Wurzeln entfernt. Natürlich ist das ein Ziel, aber eine Darstellung, die _nur_ für Routing taugt, genügt nicht. Zum Glück braucht das hier aber gar nicht diskutiert zu werden, denn die Darstellung einer Kreuzung von zwei Straßen mit getrennter Fahrbahn als eine sternförmige Kreuzung von 14 Straßen taugt auch nicht für Routing. Die taugt einfach überhaupt nichts. Sorry für die klaren Worte, aber ich finde diese Art des Mappings eine richtig schlechte Idee. Trotzdem einen schönen Abend, Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrspuren die 315.
Am 05.03.2012 22:46, schrieb Frederik Ramm: Wie dem auch sei, korrektes Routing ist auch ohne Fahrspur-Tagging moeglich. Es ist vielleicht weniger praezis, und der Nutzer muss die Anweisung an der naechsten Kreuzung links selbstaendig um vorher auf die Abbiegespur wechseln ergaenzen. Seltsamerweise hat sich in OSM kein Konzept für Kreuzungen etabliert. Je nach Komplexität der Straßen (1 oder 2 Fahrbahnen, getrennt erfasste Fuß- und Radwege) ergeben sich meist 1-16 Schnittpunkte der ways. Der menschliche Betrachter der Karte kann raten, welche der Schnittpunkte zur selben Straßenkreuzung gehören. Der Router weiß nicht, was eine Kreuzung ist, und gibt meist nur nach 100m links aus. Ampeln sind neben dem highway, auf dem highway an der Haltelinie, am Kreuzungspunkt mit dem ersten querenden way (meist der Radweg) oder nur auf Kreuzungspunkten der Straßen eingetragen. Aussagen wie an der dritten Ampel links sind mit den aktuellen OSM-Daten kaum zu erzeugen oder auszuwerten. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrspuren die 315.
Am 05.03.2012 21:33, schrieb Martin Simon: Am 5. März 2012 21:15 schrieb Steffen Wolfs...@gmx.de: Die Notiz ist mir auch aufgefallen, aber die Kreuzung hab ich jetzt erst angesehen. Die ist uebrigens ein schoenes Beispiel fuer Fahrspurmapping, die einzelnen Spuren sind naemlich in Wirklichkeit nicht getrennt. An sich ist die Kreuzung gar nicht so kompliziert. Ein wahres Juwel. Diese ganzen Geisterspuren in der Kreuzungsmitte dann wieder sternförmig zusammen zu fassen unterstreicht die Brillanz des mappens nicht getrennter Spuren als eigene Wege sogar noch besser als das wilde kreuzen oder überschneiden aller möglichen Abbiegespuren im Kreuzungsbereich. Sahnehäubchen: Abbiegerelationen ohne Kreuzungsmöglichkeit, um an der Haltelinie in JOSM die schönen blauen Pfeile angezeigt zu bekommen. Schokostreusel obendrauf: layer=-5 für Spuren und und layer=1 für Radwege. Herr Mapnik macht Freudensprünge. +1, wer auf Spurmapping abfährt soll das gerne Eintragen, aber dabei nicht den highway-Tagg, der für Straßen gedacht ist, für Spuren missbrauchen. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] railway electrified - polarity at DC?
Moin! Am 05.03.2012 10:20, schrieb Martin Koppenhoefer: Am 4. März 2012 13:51 schrieb Stephan Wolffs.wo...@web.de: Mittlere Spannweite zwischen zwei Masten Mittelwerte sind Analyseergebnisse, keine Geodaten. Was man erfassen könnte wären einzelne Masten. Auch abgeleitete Werte wie Mittelwerte sind Geodaten: - lit beschreibt die Beleuchtung eines Objekts auch ohne dass einzelne Lampen erfasst sind - width ist die mittlere Breite eines Objekts - ein highway wird als virtuelle Mittellinie zwischen den realen Außengrenzen eines Wegs / einer Straße erfasst. Die meisten dieser Daten sind vor Ort zu erkennen und wären evtl. für Planungen überhoher Schwertransporte oder Bahnsimulatoren verwendbar, aber mir fehlen sie nicht in OSM. Dann planst Du wohl keine überhohen Sondertransporte? ;-) Nein, aktuell habe ich einen anderen Job. ;-) Ich fürchte, wir müssen noch viel verbessern, bevor die Behörden eine Planung von Sondertransporten mit OSM-Daten akzeptieren und genehmigen. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagwatch timed out
On Mon, Mar 05, 2012 at 08:50:38PM +0100, hike39 wrote: Ich wollte in der dt. Tagwatch-Liste nach schon verwendeten key:values suchen. Aber sobald ich in der Trefferliste genauere Infos anfordere timed die Anfrage dauernd aus. Ist dies nur ein momentanes Problem? Benutz stattdessen taginfo.openstreetmap.org. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Remappen von wichtigen Strassen in DE
Jochen Topf joc...@remote.org wrote: Also dieses Remapping wird immer seltsamer. Wenn wir automatisiert und im großen Stil die alten Daten verwenden, um festzustellen, welche Daten wir neu erfassen müssen, dann machen wir damit ja wohl ein abgeleitetes Werk der alten Daten und dann sind die neuen Daten damit nicht clean. Wärs dann nicht einfacher wir verwenden die Daten einfach weiter? Ich habe das mal in einem früheren Beitrag im Forum thematisiert: Wenn man es sehr streng sieht, ist beispielsweise der POI an der Straßenecke von zwei nicht lizensierten Straßen nur aufgrund deren Vorhandenseins lokalisierbar gewesen. Noch mehr ausgeweitet: Erst durch die Orientierung, die uns frühe Mapper durch das Eintragen von Autobahnen, Hauptstraßen und Städtenamen in die weiße Karte gaben, konnte die Folgegeneration - und auch Remapper - an diese Orientierungsgebung anknüpfen. Streng genommen wird also der gesamten OSM Karte immer noch der ferne Geruch der Nichtlizensierer mit gleichwohl abnehmender Tendenz anhaften. Gleichzeitig ist natürlich auch klar, dass diese Arbeit auch von Lizensierern spätestens seit dem Vorhandensein von Luftbildern geleistet worden wäre, wenn sie noch nicht getan gewesen wäre. Von daher würde ich zustimmen, die automatische Auswertung nicht lizensierbarer Inhalte nicht zu übertreiben, um diesen Geruch so milde wie möglich zu gestalten. Inhaber der jetzigen roten Flecken zu benachrichtigen sowie gefährdete Objekte zu markieren und zu remappen, ist o.k. Ansonsten sollten wir uns mit dem Verlust der roten Flecken und der zeitweise eingeschränkten Nutzbarkeit durch Router und Navis am 1. April abfinden, so schmerzlich das auch sein mag. Gerade die Hauptstraßen werden sich, sodenn erstmal verschwunden, als erste wieder einfinden. Für viele mag es einfacher sein, Verschwundenes zu remappen als Vorhandenes. Mich persönlich stört inzwischen das verlorene Material weniger, als die vergraulten und teilweise langjährig engagierten Mapper. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Renderproblem bei Multipolygon (inner) im deutschen Style
Am 05.03.12 15:37, schrieb Peter Wendorff: Hi. Vermutlich (hab ich nicht nachgeguckt) ist nicht nur das Multipolygon, sondern auch der outer-way als Wald getagged. Dadurch wird der Wald zweimal, vermutlich beides mal halbtransparent gerendert. Wenn ich recht habe, entferne das Wald-Tagging vom Outer-Way und alles sollte wieder passen. Nee, war noch anders: zusätzlich zum eigentlichen MP hat jemand noch zwei Multipolygone mit jeweils einem inner und einem outer drübergelegt. Insgesamt also drei Multipolygone übereinander, mit unterschiedlichen inner. Insofern ist der deutsche Stil mit seiner Transparenz gut, um solche Fehler zu entdecken. BTW: Könnte jemand der Befugten auf openstreetmap.de/karte.html die Kartenauswahl Osmarender/Tiles@Home ensorgen? Da kommen ja jetzt keine Tiles mehr. Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
